菜单
Run a retrospective on the current milestone or latest batch. Checks goal/contract coverage, summarizes planned vs delivered, and proposes rule updates. Use "/chief-retro" after completing a batch or milestone.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run chief-agent in full autopilot. Requires goals and contracts to exist. Chief creates TODO, delegates to builder, and repeats until milestone is done. Auto mode makes all decisions autonomously; safe mode stops on ambiguity. Use "/chief-autopilot" for auto or "/chief-autopilot safe" for safe mode.
Deep grill that interviews the user one question at a time AND verifies each answer against the codebase via background `answer-verifier-agent` calls. Catches factual conflicts, contradictions with prior decisions, and unfounded assumptions inline. Persists the session to `.chief/_grill/opened/NNNN-topic.md` so it survives context compaction. Use when the user wants a stress-tested grill — when stakes are high, when claims must be cross-checked against actual repo state, or when the topic spans many decisions. Heavier than `/grill-design`; prefer this when correctness matters more than speed.
Bootstrap `.chief/project.md` for a Chief-installed project by interviewing the user about their tech stack, dev commands, architecture, and key rules. Use after `/chief-install` (or any time the user wants to set up project-wide context). This is the lazy entry point for `.chief/` — it creates only `project.md`; milestones and rules are created later, on demand.
Plan a new milestone or extend an existing one step-by-step with review gates. Starts with a grill-design session to clarify requirements, then walks through goal → contract → todo → task specs, pausing for user approval at each step.
Proactively add a rule to `.chief/_rules/`. Counterpart to `/chief-retro` (which proposes rules reactively from observed patterns). Use when the user has a rule in mind and wants to capture it now. Interviews the user (what / why / when / examples), classifies the rule into a category (_standard / _contract / _goal / _verification), shows a draft, and writes after confirmation. One rule per invocation.
Stress-test a design, idea, or approach by interviewing the user one question at a time. Each question comes with a recommended answer AND a one-line self-critique of that recommendation. After each user answer, briefly stress-test the answer against prior decisions before moving on. Use when the user wants a sharp grill on a design or decision tree without persistence overhead. Lighter than `/chief-grill` (which adds codebase verification and a session log).
| name | chief-retro |
| description | Run a retrospective on the current milestone or latest batch. Checks goal/contract coverage, summarizes planned vs delivered, and proposes rule updates. Use "/chief-retro" after completing a batch or milestone. |
Run a retrospective on the current milestone.
Auto-detect the scope:
_plan/_todo.md in the active milestone.[x] → milestone retro._report/autopilot-run-batch-<N>.md_plan/_todo.md (completed vs remaining)_goal/ and _contract/ filesgit log for commits since the previous batch report (or milestone start)_report/ files (batch reports, task outputs, etc.)_plan/_todo.md (full history)_goal/ and _contract/ filesgit log for the entire milestoneWrite the report with these sections:
# Retro: <milestone> — <batch N | milestone>
## Coverage Check
For each goal and contract file, check whether the work done satisfies it:
| File | Status | Notes |
|------|--------|-------|
| _goal/xxx.md | ✅ Satisfied / ⚠️ Partial / ❌ Missing | what's done or missing |
| _contract/xxx.md | ✅ / ⚠️ / ❌ | ... |
## Planned vs Delivered
- What was in the TODO
- What was actually completed
- What was skipped or changed mid-execution
## Blockers Hit
- Issues encountered during execution
- How they were resolved (or not)
## Lessons Learned
- Patterns observed (good and bad)
- Recurring problems
- Surprises or unexpected outcomes
- What worked well and should be repeated
## Proposed Rule Updates
For each proposal:
- **What:** the rule to add or change
- **Where:** which file in `.chief/_rules/` (e.g. `_standard/auth.md`, `_verification/tests.md`)
- **Why:** what happened that motivates this rule
- **Suggestion:** recommended for the user
## User Action Needed
Items requiring human decision:
- Uncovered goals or contracts that need another batch
- Decisions to promote to permanent rules
- Manual steps that automation couldn't handle
.chief/<milestone>/_report/retro-batch-<N>.md.chief/<milestone>/_report/retro-milestone.mdWhere <N> matches the batch number being reviewed.
Present the proposed rule updates to the user. Ask:
"Want me to apply any of these rule proposals?"
.chief/_rules/._rules/ can be updated.