The problem nobody talks about.
You explain your tech stack. Again. Your naming conventions. Again. Your bug report format. Again. By the time AI actually understands your project, you've spent ten minutes re-teaching it something it already knew yesterday.
One engineer, ten fresh chats a week. Ten different re-explanations. Output quality depends entirely on how much they bothered to type that day.
One shared Project or CLAUDE.md. Every chat starts already knowing the stack, the conventions, the format. Quality doesn't depend on who's typing.
The gap isn't skill. It's that nothing about the project persists between sessions unless someone builds a way for it to. Ten QA engineers each re-explaining the project their own way get ten different flavors of output.
Claude Projects.
A Project is a persistent workspace inside Claude that holds context across every conversation you have in it. Upload your test plan templates, your framework's README, a sample of your team's best bug reports. Every new chat inside that Project starts already knowing all of it. It's the difference between hiring someone new every morning and having one teammate who remembers yesterday.
| Put in a QA Project | Keep out of it |
|---|---|
| Your framework's real folder structure and conventions | Credentials, API keys, anything sensitive |
| 2-3 real examples of your team's best bug reports | One-off ticket details that change every sprint |
| Your acceptance criteria format, good and bad side by side | Anything that isn't reusable across sessions |
CLAUDE.md: the same idea, for your codebase.
If you're working with Claude Code instead of chat, the equivalent is a CLAUDE.md file in your repo. Claude Code reads it automatically at the start of every session, no re-explaining required.
# CLAUDE.md ## Stack - Playwright, TypeScript - Page Object Model pattern in /pages - Test data in .env, never hardcoded ## Conventions - Selectors: data-testid only, no CSS class selectors - One assertion focus per test where possible - New tests go in /tests/[feature]/, mirroring the page object folder ## Do not - Do not modify playwright.config.ts without asking - Do not commit .env files
Four sections, plain language, no ceremony. Every suggestion Claude Code makes after this respects your actual conventions instead of guessing at generic ones.
The team standardization payoff.
Share the Project with your team, or commit the CLAUDE.md to the repo, and everyone gets the same baseline quality of AI-assisted output, not just the person who happened to write the best prompts. You don't want quality depending on which engineer remembers the conventions that day. You build the conventions into something everyone reads.
What to do this week.
Open one
A Claude Project or a CLAUDE.md for your current test framework.
Add real structure
Your framework's folder layout and one test you'd hold up as "do it like this."
Use it
Start your next AI task inside it instead of a fresh chat. Notice the difference.
Share it
One teammate is the whole standardization play. It doesn't need to be a company initiative.
It drafts, you decide. The context just means it stops drafting from zero.
The takeaways:
- The shift: every module before this one assumed you'd re-explain your product from scratch each new conversation. This module removes that assumption
- The "aha": it isn't a new testing technique. It's an infrastructure decision
- The ceiling: the quality of everything from Modules 1 through 7 is capped by how much real context the AI has about your actual product
The bottom line: a CLAUDE.md file or a Claude Project isn't a convenience feature. It's what turns every technique in this course from "works okay in a demo" into "works well on your actual codebase."
Check yourself: open your most recent AI conversation about your real work. How many lines did you spend re-explaining your stack, conventions, or project structure before you got to the actual question? That number is exactly what a shared context file would have saved you, and it compounds every single session from here forward.
This is the whole picture, condensed.
Guide 2 (The Manual Tester's AI Toolkit) and Guide 1 (How to Use AI to Be a Better Tester) build every technique in this course into a full 30-day system: copy-paste prompts, worked examples, and the daily habits that make this second nature.
See the full AI-Augmented QA Path →