Team QA

Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else. Prerequisites — INTEGRATED SYSTEM FIRST: this skill is one piece of the complete "Claude Code Game Studios" template (49 agents, 74 skills, studio templates and a studio CLAUDE.md, per the repository README). Each skill assumes that template is installed, with its conventions, its project.yaml / project.local.yaml configuration, its .claude/docs/ mode documents, its hooks (for example hooks/yaml-helper.sh, outside this skill's folder) and its .claude/scripts/ helpers. Installing this listing alone copies only this skill's folder, without the rest of the system: the skill may reference template agents, files, hooks or scripts that are absent outside the full template, and it may not run as designed on its own. No account, no key and no payment are needed to copy the files, and nothing is run during installation. At use time (never during installation) this skill also appends one QA-run comment line to production/session-state/active.md silently, without asking — the file's own Session State Update section says so, and it is disclosed in this listing. Install "Team QA" for me. The skill itself orchestrates the QA team — only the qa-lead and the qa-tester — through a full testing cycle for a sprint or a feature. It first resolves review_mode, automation, team.size and qa.level by running the template's hooks/yaml-helper.sh, outside this skill's folder (its allowed-tools grant has no Edit and no task tools), and announces the active set: at the default team.size individual the qa-tester runs and the qa-lead is invoked at phase gates only; at small both run as a pipeline; at studio one qa-tester is spawned per story, in parallel, plus sign-off. Phase 1 loads context: it finds the sprint file under production/sprints/ or the feature's stories, infers the active sprint from production/session-state/active.md and production/sprint-status.yaml when no argument is given (and never invents a sprint), reads project.stage, and greps the open bugs already on file in production/qa/bugs/. Phase 2 spawns the qa-lead for the QA strategy — story classification, test-evidence requirements by qa.level (at minimal, tests are waived and acceptance criteria are walked instead), and a smoke-check verdict taken from the most recent existing production/qa/smoke-*.md report, never re-interviewed: a FAIL smoke check stops the cycle there, UNKNOWN or NOT ASSESSED continues only with a warning, and the strategy goes through an explicit review question. Phase 3 produces the test plan and the orchestrator writes it to production/qa/qa-plan-[sprint]-[date].md only after asking "May I write the QA plan…?". Phase 4 spawns the qa-tester to write test cases to a path the phase itself names, production/qa/test-cases/[story-slug]-cases.md, under a bounded exception the file documents (orchestrator-named path, new artifact under production/, docs/ or tests/, phase gate ending in an AskUserQuestion, whatever the automation mode) — no per-write prompt inside those bounds; case groups are reviewed before execution. Phase 5 walks manual QA story by story, recording only results the tester actually gives (an unanswered story stays unexecuted, never filled in): a FAIL spawns the qa-tester to file a formal bug report in production/qa/bugs/BUG-[NNNN].md in the /bug-report format, and a PASS on a Visual/Feel or UI story is evidenced in production/qa/evidence/ — the orchestrator asks once per story group and writes the evidence file from the template, referencing screenshots the tester saved there, with sign-off rows left unchecked unless the sign-off actually happened, because /story-done gates on that directory. Phase 6 spawns the qa-lead to draft the sign-off report as text in its reply — it writes nothing — under verdict rules briefed verbatim (an open S1 or S2 bug in scope, on file or newly filed, makes it NOT APPROVED first; any story without executed evidence, or an UNKNOWN / NOT ASSESSED smoke check, makes it NOT ASSESSED, never APPROVED); the orchestrator checks the verdict against the same rules and writes the report to production/qa/qa-signoff-[sprint]-[date].md only after asking. Finally — disclosed here because the file states it plainly — after the final phase the orchestrator silently appends a one-line QA RUN comment to production/session-state/active.md, without asking. Its frontmatter pins model: sonnet. Repository: https://github.com/Donchitos/Claude-Code-Game-Studios (the skill is the whole .claude/skills/team-qa/ folder at the pinned commit: 1 file in total) Pinned version: install the code at commit 05ad7c8a5b8aa2aa86bbd3439ae7cf7295cac418 exactly. Do not substitute a newer version. If this commit is unreachable, stop and tell me. 1. Clone https://github.com/Donchitos/Claude-Code-Game-Studios into a temporary folder, check out commit 05ad7c8a5b8aa2aa86bbd3439ae7cf7295cac418, and copy the .claude/skills/team-qa/ folder from that checkout. Then compare every file in the folder with the fingerprints recorded for this listing on 2026-10-22: [FINGERPRINTS] - SKILL.md: SHA-256 19448b88956168db4a56c8e6be312def07f7c8297cdaa746d8bead633a1716bb If a file does not match, it changed since the listing was prepared: do not install it yet, tell me what you found and let me decide. 2. Read SKILL.md in full, and tell me in plain words: what the skill does when used, what it connects to, whether it reads or sends any personal information or credentials, and anything that seems unusual. Stop on any red flag and tell me before going further. Confirm these points from the files: - The skill folder holds 1 file: SKILL.md only. Nothing in the folder is a program; it is instructions the agent follows at use time. - Nothing is sent anywhere during installation itself; the only download at install time is the skill folder from GitHub at the pinned commit, and no project of mine is audited, read or modified. - Integrated-system reality, from the file: at use time the skill runs the template's hooks/yaml-helper.sh to resolve review_mode, automation, team.size and qa.level, follows .claude/docs/automation-modes.md, config-resolution.md and coding-standards.md, reads my project's sprint, story, bug, smoke-report and session-state files under production/, and spawns only the template's qa-lead and qa-tester agents (scoped by team.size) — agents, docs and project files that live outside this skill's folder and are absent in a standalone install, so it cannot run as designed on its own; other template skills (/bug-report, /bug-triage, /smoke-check, /story-done) define formats and gates this cycle feeds. - At use time the qa-tester writes test-case files under production/qa/test-cases/ without a per-write prompt, but only inside the bounded exception the file documents (orchestrator-named path, new artifact under production/, docs/ or tests/, phase gate ending in an AskUserQuestion in every automation mode). Everything else is written by the orchestrator only after asking: the QA plan (production/qa/qa-plan-[sprint]-[date].md), the per-group evidence files under production/qa/evidence/, and the sign-off report (production/qa/qa-signoff-[sprint]-[date].md); bug reports under production/qa/bugs/ are written by the qa-tester spawned after a FAIL. One write is the exception to all of this and is disclosed as such: after the final phase the orchestrator silently appends a QA RUN comment line to production/session-state/active.md, with no ask. No third-party service, account or credential is named in the file. - Do not run any QA cycle, do not spawn the qa-lead or the qa-tester, do not run any template hook, and do not use the skill in any way during this install: using it is a separate step that only starts when I ask for it later. 3. When I say "yes, install", install it as a skill: copy the whole team-qa folder into the agent's skills directory, in a folder named exactly "team-qa", keeping its 1 file in their original relative layout (SKILL.md at its root). 4. Verify with no network calls: frontmatter valid (name: team-qa), the 1 file in place with matching fingerprints. Do not run anything from the folder and do not use the skill to verify. 5. Report what was installed, where, and what I still need to do myself (for example: that it belongs to the full Claude Code Game Studios template and may not run standalone (it resolves its settings through the template's yaml-helper hook, reads the template's production/ QA files and spawns its qa-lead and qa-tester agents), and that at use time its test cases are written under production/qa/ under a documented bounded exception, its plan, evidence and sign-off files only after the orchestrator's asks, and it silently appends one QA RUN line to production/session-state/active.md at the end of a run, as the file itself states). GitHub is optional: if I have a GitHub account or the gh CLI, you may use it; otherwise public access is fine. Never require it unless it's in the prerequisites above. Rules: don't touch anything outside the temp folder and the install target. If anything looks off, stop and ask me.