Define Quality Standards

Purpose

Decide what "good" means for this project up-front so the scaffold can include the right guardrails from day one.

Questions to ask (in order)

1. Code style: existing style guide (company, open-source convention) or pick language defaults?
2. Linting and formatting tools per language.
3. Testing strategy: which levels apply (unit, integration, end-to-end) and rough coverage expectation.
4. Test frameworks per language.
5. Security baseline: dependency scanning, secrets management, SAST, auth testing, and whether to include a threat-modeling commitment (ask explicitly whether a threat model document should be part of the scaffold).
6. Accessibility target (for any UI): none, WCAG AA, or WCAG AAA.
7. Performance budgets: any hard numbers (page load, API p95 latency, memory ceiling, bundle size)?
8. Documentation expectations: README only, README plus ADRs, or full docs site.
9. Observability baseline: logs only, logs + metrics, or logs + metrics + tracing.
10. Profile opt-ins: which profile-* skills in the session workspace should this project follow? List skill names by exact name (e.g., profile-java-database-access). Leave empty if none apply. If the user is unsure, glob <SESSION_DIR>/.claude/skills/profile-*/SKILL.md and show the names plus their description lines so the user can pick.

Use AskUserQuestion where multiple choice fits.

Solution space to present

• Test pyramid shapes: heavy unit / balanced / heavy integration or E2E. Tradeoff: feedback speed vs. realism.
• Security tooling: language-native audit tools (npm audit, pip-audit, cargo audit), Dependabot or Renovate, Snyk, Semgrep, Trivy (containers), explicit threat-model document.
• Observability: OpenTelemetry + self-hosted (Prometheus/Grafana/Jaeger), hosted (Datadog, Honeycomb, New Relic, Grafana Cloud), print-to-stdout + log aggregator.
• ADR practice: none / lightweight markdown ADRs / formal architecture docs.

Required schema

• style_guide (string)
• linters_formatters (list per language)
• testing ({levels, coverage_target, frameworks})
• security (list)
• accessibility_target (string)
• performance_budgets (list)
• documentation (string)
• observability (string)
• profiles (list of profile skill names — possibly empty)

Output

Write two top-level sections to PROJECT_BRIEF.md, in this order:

1. ## Quality & Standards — captures the answers to questions 1–9 above. Replace any prior ## Quality & Standards section when re-run.
2. ## Profiles — one profile skill name per line, exactly as they appear in .claude/skills/. Write None on a single line if the list is empty. Replace any prior ## Profiles section when re-run.

The ## Profiles section is a separate top-level heading (not a subsection) because every role agent reads it independently during the develop workflow.

Frontmatter contribution

Update these YAML frontmatter fields (see CLAUDE.md for the full schema). Leave every other field untouched:

• test.framework — the primary test framework (e.g., junit, spock, pytest, vitest, jest, go test)
• test.levels — list of levels the project commits to (e.g., [unit, integration], [unit, integration, e2e])
• test.coverage_target — the stated target (e.g., 80%, none)
• profiles — list of profile skill names, exactly as they appear in .claude/skills/. Must be identical to the names written in the ## Profiles prose section; keep them in sync.