菜单
Presenting work for approval and formatting the response footer. Use when reaching an approval gate, showing a spec, plan, brief, or finished deliverable, offering the user choices, or when unsure which zone footer a response should end with.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
When --quality-locked is active, loop review/revise at each Quality Gate until findings reach a clean bar (no Critical, no Major, only cosmetic Minor) or the iteration cap (10) is reached. Uses a deterministic Python checker for classification and decision logic; agent runs the actual review and revision steps.
Use after implementation passes the quality gates, when a change needs an independent pass over the code before it ships, or when the user asks to "QA this", "check the implementation", or "verify it matches the spec". Applies to Standard and Comprehensive scopes with the Task tool available; Lightweight tasks skip.
Use when the user picks [A] Review at a spec/plan/ADR/root-cause/fix-plan checkpoint, or asks for an independent review before implementation begins. Applies to Standard and Comprehensive scopes with the Task tool available; Lightweight tasks skip.
Use as the code-quality gate after spec-compliance and constitution checks pass, or when the user says "review my code", "quality check", "security review", or "is this code good". Runs as an independent sub-agent when the Task tool is available.
Adversarial review verifying implementation matches its specification — checks completeness (nothing missing) and precision (nothing extra). Distrusts the implementer's self-report. Use after implementation, or when the user says "check against spec", "does this match requirements", or "verify the implementation".
Configure Sage preset and project settings. Switch between base, startup, enterprise, or opensource constitution presets. Use when the user says "configure sage", "change preset", or "sage settings".
| name | sage-checkpoints |
| description | Presenting work for approval and formatting the response footer. Use when reaching an approval gate, showing a spec, plan, brief, or finished deliverable, offering the user choices, or when unsure which zone footer a response should end with. |
| version | 1.0.0 |
| type | system |
The eager layer carries the contract: [A] approve, [R] revise, [C]
continue — show the work, wait. This carries the detail.
Never skip human approval on a brief, a spec, a plan, or a final deliverable.
The last one is the one that gets violated, and it never looks like a violation from the inside. It looks like judgment: the remaining task seemed unnecessary, or blocked, or the user seemed to want to be done. Scope is the user's to change. Surfacing an unfinished task costs a sentence; deciding it away for them costs their trust in every completion claim you make afterwards.
Every response that expects input ends with exactly one zone footer. The footer tells the user what inputs are valid, so they never have to guess.
Zone 1 (Choice) — picking a direction:
[1] [Option] — [skill → chain] ([N] steps)
[2] [Alternative] — [chain] ([N] steps)
Pick 1-N, type / for commands, or describe what you need.
Zone 2 (Approval) — reviewing a deliverable:
[A] Approve [R] Revise [N] New session → /[next] to continue
Pick A/R/N, or tell me what to change.
Zone 3 (Next step) — the workflow is done, point at what follows:
/[command] — [chain] ([context])
/[command] — [chain]
Type a command, or describe what you want to do next.
Zone 4 (Open) — waiting for the user to describe something:
Describe what you want to work on, or type / to see commands.
→ and step counts. No time estimates.[N] always names the next slash command inline.Never use code blocks for interaction. Checkpoints, options, and transitions are plain text with bold emphasis. Code blocks are for code.
A checkpoint rendered in a code block reads as output rather than as a question, and users scroll past it.