Delivery

Software QA skill — validates that current code changes satisfy the linked Linear issue. Fetches the issue, reads acceptance criteria, executes the ticket's attached test plan when one exists (produced by /plan-qa), runs every test layer it finds, and uses Playwright to visually verify the UI against any design attachments on the ticket. Use whenever the user wants to QA a feature, verify a fix, check that code matches a ticket's acceptance criteria, run a pre-merge review, or confirm the UI looks right against a design. Trigger on — "/qa", "run QA", "QA this", "verify the feature", "does this match the ticket", "check AC", "acceptance criteria check", "visual QA", "playwright verify", "does this pass QA".

Generate a post-incident report (PIR) from the current session and write it to docs/pir/. Use this skill whenever the user types "/pir", "write a PIR", "write up what happened", "document this incident", "post-incident report", "post-mortem", or "incident retrospective". Use it proactively whenever a debugging session, production outage, failed deployment, data migration incident, or any problem-solving session is winding down — even if the user doesn't explicitly say "PIR". The output is a structured markdown document capturing the timeline, root cause, impact, resolution, and lessons learned.

Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.

Test-planning entry point — reads a Linear issue and its acceptance criteria (plus the repo's test conventions if available), then drafts a comprehensive, layer-aware test plan — per-AC scenarios (happy path, edge, negative) each tagged with a test layer and an expected result, the auth roles / fixtures / data setup needed, the visual states to verify, and the regression watch areas. Shows you the draft for approval, then attaches it to the ticket as <issue-id>-test-plan.md so the qa skill can execute against it later. Use this skill whenever you are refining or grooming a ticket, planning QA before implementation, or whenever someone says "/plan-qa", "plan the QA", "write a test plan", "what should we test for this ticket", "QA plan", "test strategy for this issue", or "how do we verify this" — even if they don't say the words "plan-qa".

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

Design planning entry point — reads DESIGN.md, CONTEXT.md, and ADRs plus a Linear issue, identifies all UI surfaces that need design, lets you choose which to work through, then for each surface conducts an alignment interview, generates three layout-archetype mockups via OpenAI image generation, lets you pick one, produces an HTML/CSS implementation, and attaches it to the Linear issue. Use when starting design work on any feature, when you need visual options before committing to layout, or any time you want a Linear ticket to carry its own design artifacts.

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.