添加 claude code game studios 到项目
This commit is contained in:
panw
244
.claude/skills/team-qa/SKILL.md
Normal file
244
.claude/skills/team-qa/SKILL.md
Normal file
@@ -0,0 +1,244 @@
|
||||
---
|
||||
name: team-qa
|
||||
description: "Orchestrate the QA team through a full testing cycle. Coordinates qa-lead (strategy + test plan) and qa-tester (test case writing + bug reporting) to produce a complete QA package for a sprint or feature. Covers: test plan generation, test case writing, smoke check gate, manual QA execution, and sign-off report."
|
||||
argument-hint: "[sprint | feature: system-name] [--review full|lean|solo]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion
|
||||
model: sonnet
|
||||
agent: qa-lead
|
||||
---
|
||||
|
||||
When this skill is invoked, orchestrate the QA team through a structured testing cycle.
|
||||
|
||||
**Decision Points:** At each phase transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next phase.
|
||||
|
||||
## Phase 0: Resolve Review Mode
|
||||
|
||||
1. If `--review [mode]` was passed as an argument, use that mode.
|
||||
2. Else read `production/review-mode.txt` — use whatever is written there.
|
||||
3. Else default to `lean`.
|
||||
|
||||
Modes:
|
||||
- `full` — spawn all director and lead gates as described
|
||||
- `lean` — skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
|
||||
- `solo` — skip all director gate spawning entirely; run the skill without any agent gates
|
||||
|
||||
Store the resolved mode for use in all subsequent phases.
|
||||
|
||||
## Team Composition
|
||||
|
||||
- **qa-lead** — QA strategy, test plan generation, story classification, sign-off report
|
||||
- **qa-tester** — Test case writing, bug report writing, manual QA documentation
|
||||
|
||||
## How to Delegate
|
||||
|
||||
Use the Task tool to spawn each team member as a subagent:
|
||||
- `subagent_type: qa-lead` — Strategy, planning, classification, sign-off
|
||||
- `subagent_type: qa-tester` — Test case writing and bug report writing
|
||||
|
||||
Always provide full context in each agent's prompt (story file paths, QA plan path, scope constraints). Launch independent qa-tester tasks in parallel where possible (e.g., multiple stories in Phase 5 can be scaffolded simultaneously).
|
||||
|
||||
## Pipeline
|
||||
|
||||
### Phase 1: Load Context
|
||||
|
||||
Before doing anything else, gather the full scope:
|
||||
|
||||
1. Detect the current sprint or feature scope from the argument:
|
||||
- If argument is a sprint identifier (e.g., `sprint-03`): Glob `production/sprints/` for files matching `*[sprint-identifier]*.md`. Read the matched file. If multiple match, use the most recently modified.
|
||||
- If argument is `feature: [system-name]`: glob story files tagged for that system
|
||||
- If no argument: read `production/session-state/active.md` and `production/sprint-status.yaml` (if present) to infer the active sprint
|
||||
|
||||
2. Read `production/stage.txt` to confirm the current project phase.
|
||||
|
||||
3. Count stories found and report to the user:
|
||||
> "QA cycle starting for [sprint/feature]. Found [N] stories. Current stage: [stage]. Ready to begin QA strategy?"
|
||||
|
||||
### Phase 2: QA Strategy (qa-lead)
|
||||
|
||||
Spawn `qa-lead` via Task to review all in-scope stories and produce a QA strategy.
|
||||
|
||||
Prompt the qa-lead to:
|
||||
- Read each story file
|
||||
- Classify each story by type: **Logic** / **Integration** / **Visual/Feel** / **UI** / **Config/Data**
|
||||
- Identify which stories require automated test evidence vs. manual QA
|
||||
- Flag any stories with missing acceptance criteria or missing test evidence that would block QA
|
||||
- Estimate manual QA effort (number of test sessions needed)
|
||||
- **Before assessing smoke status, check for an existing smoke check report**: Glob `production/qa/smoke-*.md` and read the most recently modified file (if found). If a report exists, use its verdict and findings directly — do not re-interview the user. If no report exists, note: "No prior smoke check report found — run `/smoke-check sprint` before proceeding." and set smoke check status to UNKNOWN (treat as PASS WITH WARNINGS for the purpose of continuing). Produce a smoke check verdict: **PASS** / **PASS WITH WARNINGS [list]** / **FAIL [list of failures]** / **UNKNOWN (no report found)**
|
||||
- Produce a strategy summary table and smoke check result:
|
||||
|
||||
| Story | Type | Automated Required | Manual Required | Blocker? |
|
||||
|-------|------|--------------------|-----------------|----------|
|
||||
|
||||
**Smoke Check**: [PASS / PASS WITH WARNINGS / FAIL / UNKNOWN] — [source: `production/qa/smoke-[date].md` or "no report found"] — [details if not PASS]
|
||||
|
||||
If the smoke check result is **FAIL**, the qa-lead must list the failures prominently. QA cannot proceed past the strategy phase with a failed smoke check.
|
||||
|
||||
Present the qa-lead's full strategy to the user, then use `AskUserQuestion`:
|
||||
|
||||
```
|
||||
question: "QA Strategy Review"
|
||||
options:
|
||||
- "Looks good — proceed to test plan"
|
||||
- "Adjust story types before proceeding"
|
||||
- "Skip blocked stories and proceed with the rest"
|
||||
- "Smoke check failed — fix issues and re-run /team-qa"
|
||||
- "Cancel — resolve blockers first"
|
||||
```
|
||||
|
||||
If smoke check **FAIL**: do not proceed to Phase 3. Surface the failures from the smoke check report and stop. The user must fix them, re-run `/smoke-check sprint`, and then re-run `/team-qa`.
|
||||
If smoke check **UNKNOWN**: surface a warning — "No smoke check report found. Recommend running `/smoke-check sprint` before QA. Proceeding with caution."
|
||||
If smoke check **PASS WITH WARNINGS**: note the warnings for the sign-off report and continue.
|
||||
If blockers are present: list them explicitly. The user may choose to skip blocked stories or cancel the cycle.
|
||||
|
||||
### Phase 3: Test Plan Generation
|
||||
|
||||
Using the strategy from Phase 2, produce a structured test plan document.
|
||||
|
||||
The test plan should cover:
|
||||
- **Scope**: sprint/feature name, story count, dates
|
||||
- **Story Classification Table**: from Phase 2 strategy
|
||||
- **Automated Test Requirements**: which stories need test files, expected paths in `tests/`
|
||||
- **Manual QA Scope**: which stories need manual walkthrough and what to validate
|
||||
- **Out of Scope**: what is explicitly not being tested this cycle and why
|
||||
- **Entry Criteria**: what must be true before QA can begin. Always include: (1) Smoke check PASS or PASS WITH WARNINGS report exists at `production/qa/smoke-*.md`, (2) build is stable (no crashes on launch), (3) all Must Have stories have Status: in-progress or done in `production/sprint-status.yaml`. Add any sprint-specific criteria beyond these.
|
||||
- **Exit Criteria**: what constitutes a completed QA cycle (all stories PASS or FAIL with bugs filed)
|
||||
|
||||
Ask: "May I write the QA plan to `production/qa/qa-plan-[sprint]-[date].md`?"
|
||||
|
||||
Write only after receiving approval.
|
||||
|
||||
### Phase 4: Test Case Writing (qa-tester)
|
||||
|
||||
> **Smoke check** is performed as part of Phase 2 (QA Strategy). If the smoke check returned FAIL in Phase 2, the cycle was stopped there. This phase only runs when the Phase 2 smoke check was PASS, PASS WITH WARNINGS, or UNKNOWN.
|
||||
|
||||
For each story requiring manual QA (Visual/Feel, UI, Integration without automated tests):
|
||||
|
||||
Spawn `qa-tester` via Task for each story (run in parallel where possible), providing:
|
||||
- The story file path
|
||||
- The relevant section of the QA plan for that story
|
||||
- The GDD acceptance criteria for the system being tested (if available)
|
||||
- Instructions to write detailed test cases covering all acceptance criteria
|
||||
|
||||
Each test case set should include:
|
||||
- **Preconditions**: game state required before testing begins
|
||||
- **Steps**: numbered, unambiguous actions
|
||||
- **Expected Result**: what should happen
|
||||
- **Actual Result**: field left blank for the tester to fill in
|
||||
- **Pass/Fail**: field left blank
|
||||
|
||||
Present the test cases to the user for review before execution. Group by story.
|
||||
|
||||
Use `AskUserQuestion` per story group (batched 3-4 at a time):
|
||||
|
||||
```
|
||||
question: "Test cases ready for [Story Group]. Review before manual QA begins?"
|
||||
options:
|
||||
- "Approved — begin manual QA for these stories"
|
||||
- "Revise test cases for [story name]"
|
||||
- "Skip manual QA for [story name] — not ready"
|
||||
```
|
||||
|
||||
### Phase 5: Manual QA Execution
|
||||
|
||||
Walk through each story in the approved manual QA list.
|
||||
|
||||
Batch stories into groups of 3-4 and use `AskUserQuestion` for each:
|
||||
|
||||
```
|
||||
question: "Manual QA — [Story Title]\n[brief description of what to test]"
|
||||
options:
|
||||
- "PASS — all acceptance criteria verified"
|
||||
- "PASS WITH NOTES — minor issues found (describe after)"
|
||||
- "FAIL — criteria not met (describe after)"
|
||||
- "BLOCKED — cannot test yet (reason)"
|
||||
```
|
||||
|
||||
After each FAIL result: use `AskUserQuestion` to collect the failure description, then spawn `qa-tester` via Task to write a formal bug report in `production/qa/bugs/`.
|
||||
|
||||
Bug report naming: `BUG-[NNN]-[short-slug].md` (increment NNN from existing bugs in the directory).
|
||||
|
||||
After collecting all results, summarize:
|
||||
- Stories PASS: [count]
|
||||
- Stories PASS WITH NOTES: [count]
|
||||
- Stories FAIL: [count] — bugs filed: [IDs]
|
||||
- Stories BLOCKED: [count]
|
||||
|
||||
### Phase 6: QA Sign-Off Report
|
||||
|
||||
Spawn `qa-lead` via Task to produce the sign-off report using all results from Phases 4–6.
|
||||
|
||||
The sign-off report format:
|
||||
|
||||
```markdown
|
||||
## QA Sign-Off Report: [Sprint/Feature]
|
||||
**Date**: [date]
|
||||
|
||||
### Test Coverage Summary
|
||||
| Story | Type | Auto Test | Manual QA | Result |
|
||||
|-------|------|-----------|-----------|--------|
|
||||
| [title] | Logic | PASS | — | PASS |
|
||||
| [title] | Visual | — | PASS | PASS |
|
||||
|
||||
### Bugs Found
|
||||
| ID | Story | Severity | Status |
|
||||
|----|-------|----------|--------|
|
||||
| BUG-001 | [story] | S2 | Open |
|
||||
|
||||
### Verdict: APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED
|
||||
|
||||
**Conditions** (if any): [list what must be fixed before the build advances]
|
||||
|
||||
### Next Step
|
||||
[guidance based on verdict]
|
||||
```
|
||||
|
||||
Verdict rules:
|
||||
- **APPROVED**: All stories PASS or PASS WITH NOTES; no S1/S2 bugs open
|
||||
- **APPROVED WITH CONDITIONS**: S3/S4 bugs open, or PASS WITH NOTES issues documented; no S1/S2 bugs
|
||||
- **NOT APPROVED**: Any S1/S2 bugs open; or stories FAIL without documented workaround
|
||||
|
||||
Next step guidance by verdict:
|
||||
- APPROVED: "Build is ready for the next phase. Run `/gate-check` to validate advancement."
|
||||
- APPROVED WITH CONDITIONS: "Resolve conditions before advancing. S3/S4 bugs may be deferred to polish."
|
||||
- NOT APPROVED: "Resolve S1/S2 bugs and re-run `/team-qa` or targeted manual QA before advancing."
|
||||
|
||||
Ask: "May I write this QA sign-off report to `production/qa/qa-signoff-[sprint]-[date].md`?"
|
||||
|
||||
Write only after receiving approval.
|
||||
|
||||
## Error Recovery Protocol
|
||||
|
||||
If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:
|
||||
|
||||
1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
|
||||
2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input.
|
||||
3. **Offer options** via AskUserQuestion with choices:
|
||||
- Skip this agent and note the gap in the final report
|
||||
- Retry with narrower scope
|
||||
- Stop here and resolve the blocker first
|
||||
4. **Always produce a partial report** — output whatever was completed. Never discard work because one agent blocked.
|
||||
|
||||
Common blockers:
|
||||
- Input file missing (story not found, GDD absent) → redirect to the skill that creates it
|
||||
- ADR status is Proposed → do not implement; run `/architecture-decision` first
|
||||
- Scope too large → split into two stories via `/create-stories`
|
||||
- Conflicting instructions between ADR and story → surface the conflict, do not guess
|
||||
|
||||
## Output
|
||||
|
||||
A summary covering: stories in scope, smoke check result, manual QA results, bugs filed (with IDs and severities), and the final APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED verdict.
|
||||
|
||||
Verdict: **COMPLETE** — QA cycle finished.
|
||||
Verdict: **BLOCKED** — smoke check failed or critical blocker prevented cycle completion; partial report produced.
|
||||
|
||||
## Session State Update
|
||||
|
||||
After the final phase completes (sign-off report written or BLOCKED verdict reached), silently append to `production/session-state/active.md`:
|
||||
|
||||
```
|
||||
<!-- QA RUN: [date] | Sprint: [sprint identifier or "ad-hoc"] | Verdict: [PASS/FAIL/CONCERNS] | Report: production/qa/qa-[date].md -->
|
||||
```
|
||||
Reference in New Issue
Block a user