Skip to main content

sage-tiers

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.

Ir a la instalación

Datos de origen

Repositorio
xoai/sage
Última actividad en el origen
11 de julio de 2026 a las 18:22
Idioma detectado de SKILL.md
inglés
Estrellas
27
Forks
7

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
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
# Tiers 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. ## The three tiers | 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. | ## The bias **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: - a behavior change - an API change - a decision the team would want to see 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 is a real escape hatch, not a trap 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. ## Rationalizations that do not survive contact | 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. |
Ver en GitHub