qa-init

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).