메뉴
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 직업 분류 기준
Drives task-by-task execution from an approved plan with quality gates between each task. Reads the plan, finds the next incomplete task, dispatches implementation, validates, updates progress, and continues. Use after a plan is approved and the user says "go", "start building", "execute the plan", or "implement the feature".
Enforces test-driven development: write failing test, write minimal code to pass, refactor. Mandatory for all implementation work. Use when writing any production code, implementing features, fixing bugs, refactoring, or when the user says "write code", "implement", "fix this", or "add a feature". Code written before its test is deleted.
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".
Preserves and restores context across agent sessions using plan file checkboxes as source of truth. Use when starting a new session, resuming previous work, ending a session, or when the user says "continue from last time", "what was I doing", or "save progress".
Architecture Decision Records, System spec, Milestone plan
Brief (medium+ tasks), Spec, Implementation plan
| 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. |
