| name | qa-init |
| description | Onboard the QA toolkit onto any project. Use on first contact with a new codebase, when the user says "set up QA", "qa init", "/qa-init", or when any QA agent finds no qa-profile.md. Studies the project deeply and writes the persistent QA profile that every other agent reads first — the toolkit's long-term memory for this project.
|
QA Init — Project Onboarding
You are building the toolkit's permanent understanding of this project. Every
agent reads the profile you write before doing anything. Spend real effort
here: a good profile makes every future audit faster and smarter.
Step 1 — Study the project
Read broadly (README, manifests, config, directory structure, routes, models,
docker-compose, CI files). Determine:
- What it is: web app / API / fullstack / CLI / library / mobile /
desktop / monorepo with several of these. The toolkit adapts per type:
- Web/fullstack → full agent roster
- API only → api-sentinel, security-scout, perf-guardian, data-validator
- CLI/library → regression-watcher + test-architect (unit/integration
instead of E2E), security-scout static
- Unknown stack → say what you can and can't test, don't pretend
- How to run it: exact commands (install, dev server, port, how long
startup takes, how to know it's ready). VERIFY by actually running them.
- How to test it: existing test suite, runner, how to execute.
- Data layer: DB engine, how to query it read-only, seed/test data.
- Auth: is there a login, and is it active? Detect the mechanism
(local user/password, external SSO, social login) and whether a CAPTCHA
guards it. Find how to get test credentials (point to .env.example vars,
never store actual secrets in the profile) and whether a programmatic
test-login / seed user exists. Record all of this in the profile's Auth
section so agents know, before testing, whether they can get past the login
or will need to ask the user. See
.claude/agents/_auth-protocol.md.
- The 3–6 critical user flows by business impact.
If something essential can't be derived (test credentials, deployed URL), ask
the user ONE consolidated question.
Step 2 — Write the profile
Write qa-reports/qa-profile.md:
# QA Profile — [project]
*Created: [date] — Updated: [date]*
## Identity
Type / stack / DB / auth mechanism
## How to Run
| Action | Command | Notes |
|--------|---------|-------|
| install | ... | |
| dev server | ... | port, ready signal, startup time |
| tests | ... | |
| db query (read-only) | ... | |
## Critical Flows (ranked)
1. [flow] — [why it matters]
## Auth
- Login: yes/no, active?
- Mechanism: local | SSO (which provider) | social
- CAPTCHA on login: yes/no (which)
- Can we get in automatically? test creds in [env vars] / programmatic
test-login at [path] / NO — will need to ask the user
- Bypass options if blocked: test reCAPTCHA keys / disable captcha in test env
/ dedicated QA account
## Test Credentials
[where they live — env var names, never values]
## Do Not Touch
[prod URLs, real data, rate-limited services, anything destructive]
## Quirks & Learnings <!-- agents append here after every run -->
- [date] [agent]: [observation]
## Known Non-Issues <!-- user-dismissed findings; do not re-report -->
- [finding summary] — dismissed [date]: [reason]
Step 3 — Smoke-verify
Actually start the app using your own profile instructions. If a command in
the profile doesn't work, fix the profile, not the report. The profile must
be executable truth, not documentation fiction.
Step 4 — Final response
- Project type + what the toolkit can and cannot test here.
- Profile path.
- Suggested first command (
/qa-audit).
