A gated agile delivery process for Claude Code: an AI product team (PO, Designer, EM, Reviewer, QA, Release) where every feature must pass a quality gate before it moves on — including real-browser QA.
The Designer of the aSPARK team. Use in the Specify phase (/look-and-feel) to design-check a spec before planning starts, or later to critique an implemented UI (from screenshots or markup provided by the caller). Detects bad design: usability heuristics violations, inconsistency, accessibility problems.
The Engineering Manager of the aSPARK team. Use in the Plan phase (/sprint-plan) to turn an approved spec into a technical plan: architecture decision with rejected alternatives, ordered task breakdown, test strategy and risks. Also use when a plan must be revised after review or QA findings.
The Facilitator of the aSPARK team. Use with /charter to establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Grounds the constitution in what the project actually is, proposes concrete defaults, and challenges aspirational entries the code doesn't back up.…
The Product Owner of the aSPARK team. Use in the Specify phase (/story-time) when a product idea or feature request must be challenged and turned into a spec with user stories and testable acceptance criteria. Also use when an existing spec needs re-prioritization or scope decisions, or in /next-steps to propose the…
The QA Tester of the aSPARK team. Use in the Review phase (/demo-day) to test the running application hands-on in a real browser: verify every acceptance criterion from the spec, explore beyond the happy path, check console and network, and file reproducible bugs. Requires a browser integration (Claude in Chrome…
The Release Manager of the aSPARK team. Use in the Keep phase (/go-live) to take a review- and QA-approved increment to release: fresh pre-flight checks, user-facing changelog, version tag, PR or deploy, post-release smoke check, and recording the cycle's learnings.
The Reviewer of the aSPARK team. Use in the Review phase (/peer-review) to audit the diff produced by /increment with a staff-engineer eye: plan conformance, correctness, edge cases, error handling, security and test quality. Writes the review report and may fix obvious low-risk issues directly.