Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

spec-driven

Estrellas3

Forks1

Actualizado11 de julio de 2026 a las 12:59

Model-invoked discipline for spec-driven development — no code without a spec, openspec-style change contracts without the openspec dependency. Fire when a feature, fix, or refactor is about to be built without a written spec, when scope is agreed and needs freezing before implementation, when implementation reveals the spec was wrong (drift), or on "spec this", "write the spec first", "spec contract". Scaffold with `cto-brain spec init <change-id>`; lint with `cto-brain spec check`. Not for exploratory spikes or one-line fixes.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

ggichuru

ggichuru/cto-brain

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name

spec-driven

description

Spec-driven development — the contract before the code

The spec is the source of truth; code is its shadow. A written, frozen spec is what lets tests mean something, lets parallel agents code against the same seams, and lets tomorrow's session (or a different model) pick the work up.

When to fire

A non-trivial feature, fix, or refactor is about to be written with no spec.
Scope just got agreed (e.g. after a grill interview) and needs freezing.
Implementation contradicts the spec — stop and amend the spec first.
Multiple agents are about to fan out and need frozen contracts to code against.

When NOT to fire

Exploratory spikes where the shape is unknown — spike, then spec the keeper.
Trivial edits (a chmod, a typo, a one-line config). Doctrine is for load-bearing work.

The change-contract workflow (openspec-style, built in)

Propose — cto-brain spec init <change-id> scaffolds specs/changes/<change-id>/{proposal.md,tasks.md}. Fill every required section: Intent (why), Behavior (what, observable), Acceptance criteria (the tests-to-be), Non-goals (the scope fence), Frozen contracts (schemas, interfaces, layouts agents code against).
Freeze — cto-brain spec check must pass (all sections present and non-empty). A frozen proposal is a contract: agents READ it, they don't edit it mid-flight.
Implement — hand each acceptance criterion to the tdd loop: red, green, refactor. One criterion at a time.
Verify — whole suite plus one end-to-end walk. Verdict is one of proven / UNPROVEN / blocked — a failing criterion is never "mostly done".
Archive — when shipped, the change dir stays as the decision record; its version history is the project's register of what was agreed and when.

Rules that keep it honest

Spec drift is a bug. Code silently diverging from the spec is the failure mode this skill exists to stop. Amend the proposal, then the code.
Acceptance criteria are executable. Each one must map to a test a reviewer can run; "works well" is not a criterion.
Non-goals are load-bearing. An empty Non-goals section means unbounded scope — spec check treats empty sections as errors for this reason.
The spec and tests ARE the portability layer. A well-specced, well-tested change can be handed to any model or agent tomorrow.

Pairs with

grill (surfaces the scope the spec freezes), tdd (implements each criterion), domain-modeling (the spec uses CONTEXT.md vocabulary), agentic-learning-loop (the archived change feeds the round-close ritual), cto-orchestration (frozen contracts are the seams builder briefs cite).

Más de este repositorio

mismo repositorio

meta-brain

ggichuru/cto-brain

Use FIRST on any ambiguous intent — the router that maps the user's request to the right downstream skill(s). Fires on session start, on intent shifts mid-conversation, when the user mentions something the model doesn't have a clear single-skill home for, when multiple skills could fire, when the user asks "what skills do I have" / "what can the brain do", when a new project domain enters, or when you need to know whether to load CTO vs domain vs maintenance trio vs a brand-new skill. The brain's switchboard. Knows the catalog, the precedence order, the maintenance cadence, and the "if unsure" fallback.

2026-07-063

agentic-learning-loop

ggichuru/cto-brain

Use when reasoning about HOW this brain learns — not what it should do, but the mechanism by which it gets better over time. Fires on questions about the round-close ritual, feedback file shape, the replay buffer, the policy update rule, exploration vs exploitation calibration, the always-running guarantee, periodic optimization cadence, or "is this thing actually learning or are we just writing docs?" Also fires when designing a new sub-skill that needs to plug into the loop, when debugging why a lesson isn't sticking, when the growth ledger shows a plateau, or when adapting the loop to a new domain. The formal description of the learning system that the cto-orchestration skill is the lead policy of.

2026-06-253

cto-orchestration

ggichuru/cto-brain

Use when acting as the CTO / engineering lead orchestrating a multi-day or multi-week build with one human and many parallel agents, OR as the LEAD-CTO orchestrator-of-orchestrators that deploys and monitors subordinate CTOs across multiple parallel projects, OR when the round needs a lead skill to route between sub-skills, learn from what just happened, and enable the rest of the brain to grow. Fires on scope assessment, decomposition, dispatch, integration, reviewer-trio gating, tool selection, focused search, self-critique, mentorship, operationalization, pre-handover discipline, the round-close learning ritual that writes lessons to memory and updates downstream skills, AND the lead-CTO tier behaviors — subordinate-CTO deployment (charter, scope, reporting cadence), cross-project monitoring (per-project growth-ledger reads, status digest, blocker triage), cross-project synthesis (promoting project-level lessons to brain-policy), and portfolio-level authority/escalation. Covers prompt eng, context eng, fil

2026-06-253

diagnosing-bugs

ggichuru/cto-brain

Model-invoked discipline for debugging without guessing. Fire when something is broken and the cause is not obvious. Reproduce, minimize, hypothesize, instrument, then fix — and lock the fix with a regression test. Read the FIRST error in the chain, not the last. Stops the flailing-edit anti-pattern. Inspired by mattpocock/skills `/diagnosing-bugs`.

2026-06-253

domain-modeling

ggichuru/cto-brain

Model-invoked discipline for building and maintaining a project's shared vocabulary in CONTEXT.md. Fire when a project keeps re-explaining the same concept, when a new load-bearing noun appears, or at the start of a build to name the domain. One agreed word replaces a 20-word paragraph every round — cutting tokens and speeding navigation. Inspired by mattpocock/skills `/domain-modeling`.

2026-06-253

grill

ggichuru/cto-brain

Fire BEFORE building anything non-trivial, or whenever a request is vague, broad, or likely to grow. A structured interview that surfaces the real scope — deploy target, distribution, proof bar, docs/media, design bar, positioning — and gets explicit sign-off before any brief is written. The front-end mirror of the close-out report. Model- or user-invocable. Inspired by mattpocock/skills `/grill`.

2026-06-253

name

spec-driven

description

Spec-driven development — the contract before the code

When to fire

A non-trivial feature, fix, or refactor is about to be written with no spec.
Scope just got agreed (e.g. after a grill interview) and needs freezing.
Implementation contradicts the spec — stop and amend the spec first.
Multiple agents are about to fan out and need frozen contracts to code against.

When NOT to fire

Exploratory spikes where the shape is unknown — spike, then spec the keeper.
Trivial edits (a chmod, a typo, a one-line config). Doctrine is for load-bearing work.

The change-contract workflow (openspec-style, built in)

Propose — cto-brain spec init <change-id> scaffolds specs/changes/<change-id>/{proposal.md,tasks.md}. Fill every required section: Intent (why), Behavior (what, observable), Acceptance criteria (the tests-to-be), Non-goals (the scope fence), Frozen contracts (schemas, interfaces, layouts agents code against).
Freeze — cto-brain spec check must pass (all sections present and non-empty). A frozen proposal is a contract: agents READ it, they don't edit it mid-flight.
Implement — hand each acceptance criterion to the tdd loop: red, green, refactor. One criterion at a time.
Verify — whole suite plus one end-to-end walk. Verdict is one of proven / UNPROVEN / blocked — a failing criterion is never "mostly done".
Archive — when shipped, the change dir stays as the decision record; its version history is the project's register of what was agreed and when.

Rules that keep it honest

Spec drift is a bug. Code silently diverging from the spec is the failure mode this skill exists to stop. Amend the proposal, then the code.
Acceptance criteria are executable. Each one must map to a test a reviewer can run; "works well" is not a criterion.
Non-goals are load-bearing. An empty Non-goals section means unbounded scope — spec check treats empty sections as errors for this reason.
The spec and tests ARE the portability layer. A well-specced, well-tested change can be handed to any model or agent tomorrow.