菜单
Review the last commit for complexity, dead code, missed invariants, test quality, and broader code quality opportunities. Returns a numbered findings list for discussion — does not implement fixes. Use after task-implement completes a task.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Stage 5 of the spec-driven workflow — archive a shipped feature. Run this only once every task in the feature's tasks.md has shipped AND you are satisfied the work is done (typically after review, and when PR is ready to open). It promotes any durable insight into the live reference specs, then deletes the spec folder. It never writes an archive summary file. Invoke explicitly; it is not auto-chained from feature-implement.
Orchestrate the full implementation of a feature's tasks.md end to end. A supervisor agent loops over every uncompleted task, spawning an implement sub-agent then a review sub-agent, triaging the review findings with its own judgement — auto-approving the evident fixes and escalating only genuinely structuring decisions to the user via AskUserQuestion — applying the fixes, and continuing to the next task. Use when you want to drive a whole feature with minimal human intervention, surfacing only the decisions that genuinely need you.
Use to execute a single task from an approved tasks.md. Fourth stage of the four-stage spec-driven workflow. Reads spec.html, plan.html, tasks.md, then implements one task at a time, respecting constitution gates.
Use after the user approves a spec.html to write or refine the corresponding plan.html. Second stage of the four-stage spec-driven workflow. Plan answers HOW the spec becomes code; respects architecture.md. Still no code execution.
Use when the user wants to start a new feature in this repo. Walks the agent through writing specs/features/<feature-name>/spec.html — the first stage of the four-stage spec-driven workflow (specify → plan → tasks → implement). Read-only on code. May also draft plan.html in the same pass when the kickoff is design-rich.
Use after the user approves a plan.html to break it into ordered, independently-shippable tasks. Third stage of the four-stage spec-driven workflow. Output is tasks.md; still no code execution.
| name | task-review |
| description | Review the last commit for complexity, dead code, missed invariants, test quality, and broader code quality opportunities. Returns a numbered findings list for discussion — does not implement fixes. Use after task-implement completes a task. |
You are reviewing the diff of the last commit. You are a critic, not a fixer. Your output is a numbered list of findings for the user to discuss and prioritise. Do not touch any file.
Identify the task. The user will tell you the feature name and task. Read specs/features/<feature-name>/spec.html, plan.html, and tasks.md to understand the intent of the task.
Get the diff. Run git show HEAD to obtain the full diff of the last commit.
Load standards. Read specs/constitution.md and specs/conventions.md.
Analyse against this checklist:
ModelingObject subclass that no existing test path was reaching, flag whether the relevant integration fixture has an assertion that touches the new call site. run_test_materialize_all_cached_properties already covers new cached_property definitions; this rule catches the rest (plain @property, methods, dict lookups, new behavioural shapes on existing APIs).constitution.md or conventions.md.Report findings. For each finding, output:
#N [Category] file:line — one sentence describing the problem.
Direction: one sentence on the high-level approach to resolve it (no code).
If nothing is found, output "LGTM — no findings." and stop.
Wait. Do not implement anything. The user will decide which findings to address, defer, or reject.