菜单
Write a sprint retro to capture context for the next session. Use when user says "retro", "write a retro", "sprint retro", "fill in retro". Do NOT activate for general retrospective discussions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Implan is an opt-in structured planning workflow. Trigger ONLY when the user explicitly invokes it ("/implan", "create an implan", "make an implan", "start an implan", "use Implan for X", "set up an Implan for Y") or is actively working inside an existing `ai-plans/` directory. Do NOT trigger for general planning conversations, even substantial ones, and do NOT trigger just because the user says things like "plan a feature", "plan a project", "plan a launch", "plan a campaign", or "set up a plan"; those phrases alone are not enough. Most planning discussions do not need Implan, and unwanted activation creates files, folders, and friction. When invoked, Implan produces a self-contained Plan Directory under `ai-plans/` containing a main plan, a mental model with diagrams, a test strategy (the Definition of Done the work iterates towards), and a notes scratchpad, designed so a fresh agent or the user themselves can pick the work up cold and execute it well. Suits anything substantial, code or otherwise (software
AI-driven mutation testing — Claude acts as the mutation engine. Analyzes source code, generates and applies mutations, runs tests, tracks killed vs survived mutants, analyzes test gaps, and recommends test improvements. No external mutation testing libraries. Use when user says "mutate", "mutation testing", "mutation test", "test my tests", "check test quality", "find weak tests", "are my tests good enough", or "/mutate". Do NOT activate for general testing questions, writing new tests from scratch, code coverage analysis, or TDD workflows.
Run an exploratory spike, a throwaway implementation that proves whether key technical assumptions hold before the real implementation begins. Works against an existing Implan in ai-plans/ when one is present, and works standalone otherwise. Produces a spike report the HU can hand to the implementing agent or use to update the Implan. Use whenever the user says "/implan-spike", "spike this", "create a spike", "start a spike", "do a spike on X", "prove this assumption", "spike a feature", "proof of concept", or "throwaway implementation". The Spike Agent writes only inside its spike folder; it never modifies the Implan or the rest of the codebase. Do NOT activate for production implementation work, code reviews, refactors, or finishing real features; those belong to the implementing agent, not the spike agent.
AAID (Augmented AI Development) - BDD/ATDD acceptance testing workflow using the Three-Layer Model where the developer maintains architectural control and reviews all AI-generated code. Use when the user initiates acceptance testing or references AAID BDD. Trigger phrases include: "start BDD", "begin ATDD", "acceptance testing", "acceptance test", "three-layer model", "executable spec", "transform BDD scenarios", "BDD scenarios", "protocol driver", "phase 1", "phase 2", "phase 3", "DSL layer". Also activate when user provides BDD scenarios and asks for executable specifications, or when currently in an active BDD/ATDD cycle that hasn't completed. Do NOT activate for general programming questions, architecture discussions, context sharing, unit-test/TDD work, or presentation-only changes.
Validate acceptance tests against AAID BDD quality criteria. Scans for proper three-layer architecture, isolation patterns, state management, and stubbing practices. Produces pass/warn/fail table with specific findings. Do NOT activate for writing new tests, running tests, or general testing questions.
AAID (Augmented AI Development) - TDD workflow enforcing disciplined RED/GREEN/REFACTOR cycles where the developer maintains architectural control and reviews all AI-generated code. Use when the user initiates TDD or references AAID. Trigger phrases include: "start TDD", "begin AAID", "use test list", "RED phase", "GREEN phase", "REFACTOR phase", "write test", "test for", "red", "next test", "make pass", "implement", "green", "refactor", "improve", "clean up". Also activate when user asks to write a failing test, make a test pass, or refactor with tests green, or when currently in an active TDD cycle that hasn't completed. Do NOT activate for general programming questions, architecture discussions, context sharing, or non-TDD tasks.
| name | retro |
| description | Write a sprint retro to capture context for the next session. Use when user says "retro", "write a retro", "sprint retro", "fill in retro". Do NOT activate for general retrospective discussions. |
| argument-hint | [optional: specific sprint to retro] |
Write a retro for the sprint just completed. Scope to the most recent sprint only, not the entire session or project.
$ARGUMENTS
If the user named a specific sprint, retro that. If empty, retro the most recent completed work.
Output as a single markdown table. Use <br> for multiple bullets within a cell.
| Category | Details |
|---|---|
| **Went well** | • Approaches or plan sections that worked as-is and should be repeated |
| **Problems** | • Plan inaccuracies, wrong assumptions, things that required workarounds |
| **Learnings** | • Key decisions made during implementation, plan changes applied |
| **Risks** | • Unresolved issues, fragile areas, unvalidated assumptions that could affect later sprints |
Always include all four categories. If a category has nothing substantive, write "Nothing notable". Do not pad with filler. Keep each bullet to 1-3 sentences. Be specific and factual; avoid vague summaries. Focus on information that would help a future session pick up work with full context.
If the user specifies a different format (e.g. bullet list, YAML block, plain text), use that instead.