メニュー
Sizing a task before doing it. Use when the user asks which tier a task is, how big or small a change is, whether something needs a spec or a plan, whether to just do it or slow down, or when deciding how much process a piece of work deserves.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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-tiers |
| description | Sizing a task before doing it. Use when the user asks which tier a task is, how big or small a change is, whether something needs a spec or a plan, whether to just do it or slow down, or when deciding how much process a piece of work deserves. |
| version | 1.0.0 |
| type | system |
Tier is the answer to one question: how much process does this deserve?
Too much process on a trivial change is bureaucracy, and users learn to route around it. Too little on a consequential one is how a "quick fix" becomes an outage. Tier is where that judgment is made explicit instead of being made silently, differently, every time.
| Tier | Response | What it looks like |
|---|---|---|
| Tier 1 | Just do it. | Single file, no design decisions, a quick answer. No manifest, no spec, no confirmation. |
| Tier 2 | Announce and proceed. | Multiple steps, creates artifacts. Say what you are doing, then do it. |
| Tier 3 | Card and choose. | Major effort, genuine ambiguity. Present options and let the user pick. |
Bias toward Standard scope. When a task sits on a boundary, take the higher tier.
Any of these puts a task at Tier 2 minimum, regardless of how small the diff looks:
The asymmetry is deliberate. The cost of over-tiering is a few minutes of ceremony. The cost of under-tiering is a change nobody reviewed, in a place nobody expected, discovered later by someone who did not know it happened.
Tier 1 exists so the process does not tax trivial work, and it is genuinely
free: no manifest is created, so the spec-gate hook has nothing to block on
(the hook reads gate_state from a manifest; no manifest means no active
cycle means edits are unrestricted).
That is the escape hatch working as designed. It is not a loophole — "I will call it Tier 1 so I do not have to write a spec" is a rationalization, and the list above is what it collides with.
| The thought | Why it is wrong |
|---|---|
| "It is literally one line" | One line that changes behavior is a behavior change. The diff size is not the blast radius. |
| "The design is obvious" | Obvious to you, now, with your context. Write it down and find out. |
| "I will note it in the commit message" | A commit message is not a decision record and nobody reads it before the fact. |
| "The user just wants it done" | The user wants it right. They will not thank you for speed on the change that broke checkout. |
