菜单
Sage's quality gates and the file checks each workflow must pass. Use when an edit was blocked, when asking why a hook stopped you, when a gate fails or reports UNVERIFIABLE, before claiming work is done, or when you need the spec/plan preconditions for build, fix, or architect.
用 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-gates |
| description | Sage's quality gates and the file checks each workflow must pass. Use when an edit was blocked, when asking why a hook stopped you, when a gate fails or reports UNVERIFIABLE, before claiming work is done, or when you need the spec/plan preconditions for build, fix, or architect. |
| version | 1.0.0 |
| type | system |
Two different mechanisms share the word "gate", and confusing them is how people end up arguing with a hook.
| Hooks | Gates | |
|---|---|---|
| When | Before a tool call (PreToolUse) | After work, on demand |
| What | Block the edit itself | Score the result |
| Failure mode | Fail open — a broken hook must not brick the session | Fail closed — an unrun gate is not a passed gate |
| Examples | sage-spec-gate.sh, sage-tdd-gate.sh | Gates 1–6 |
Hooks are guards, not gates.
"Sage spec gate: no spec exists for the active cycle." A cycle in
.sage/work/*/manifest.md has gate_state: pre-spec, and you tried to edit a
source file. Write the spec, get [A], and the manifest advances to
spec-approved. Then the edit lands.
"Sage TDD gate: tests before code." No test has been written for this change. Write the failing test first. The gate accepts a dirty/untracked test file or a red commit (tests touched, no source) as evidence.
Completion blocked. The manifest cannot reach complete while
gate_state is anything short of gates-passed, and it cannot complete with
an unresolved qa: disposition. This is Rule 5 with a script behind it.
Neither hook is arguing with you. Both are stating a precondition you can satisfy in about a minute.
Build (Standard+) — BEFORE implementing, verify both files exist on disk:
.sage/work/<initiative>/spec.md — status: completed.sage/work/<initiative>/plan.md — status: completedIf either is missing, create it first. No exceptions.
Do not rationalize past this:
| The thought | The reality |
|---|---|
| "The design is clear from earlier discussion" | Not a spec file. |
| "The user described what they want" | Not a spec file. |
| "This is straightforward" | If it is Standard scope, a spec is required. |
| "Just build it" | Write a minimal five-line spec and get [A]. |
Branch gate (Standard+, git projects). Before implementation commits begin,
HEAD must not be the default branch — unless a branching decline is recorded in
the initiative's decision log. Merging is always a user-gated [M] action.
No workflow path merges on its own. Full protocol:
sage/core/capabilities/execution/git-discipline/SKILL.md.
Gate sequence (build):
.sage/work/ → [A]/[R] → wait.sage/work/ → [A]/[R] → wait[A]/[R]Fix — scope AFTER root cause:
[A]/[R]/[S] → wait[A]/[R]/build or /architect[A]/[R]Do not fix before the root cause is confirmed. Do not skip fix scoping — a "quick fix" that touches eight files is a rebuild wearing a smaller word.
Architect — brief BEFORE design:
brief.md must exist before design begins. Do not
compress the rounds. Do not skip them because "I understand the system.".sage/docs/ → spec → .sage/work/ → [A]/[R][A]/[R] → phased build; each milestone follows the
build gates independently.Before presenting any completion checkpoint:
Spec compliance is adversarial. Do not trust your own report that the implementation matches the spec. You wrote it; you are the last one who will notice what it does not do. Verify independently, or let a fresh reviewer do it.
Gate scripts exit 0 pass, 1 fail, 2 unverifiable.
Exit 2 is the one that matters. It exists because "the suite is green" and "there is no suite" are different claims that used to share exit 0 — which is precisely how a gate reports success on code it never looked at.
Exit 2 is never a pass. It is also not a failure: it has produced no evidence either way. On exit 2, present the choice and record it:
[P] Proceed unverified — logged as a waiver in .sage/decisions.md
[F] Fix verification setup — install the runner, then re-run