spec

Estrelas0

Forks0

Atualizado17 de junho de 2026 às 22:04

Author or revise a work item's spec at docs/spec/<id>.md before any code is written, then run it through the spec gate. Use when starting a new work item, when a spec needs revision after a spec-gate rejection, or when acceptance criteria must be defined. Produces a fully-signed spec — Goal, Non-goals, evidence-cited claims, stable spec-item IDs, and frozen executable acceptance criteria.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

dw218192

dw218192/spec-driven-project-template

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

Explorador de arquivos

2 arquivos

SKILL.md

readonly

Mais deste repositório

mesmo repositório

adr

dw218192/spec-driven-project-template

Record a new architectural decision, or supersede an existing one, as a plain-markdown ADR under docs/adr/. Use when making a significant or hard-to-reverse design decision, or when an accepted decision must change (which requires a NEW superseding ADR — accepted ADRs are immutable). Handles the frontmatter schema, numbering, and the additive supersede workflow (accepted ADRs are never edited — reverse links are derived).

2026-06-170

remote-memory

dw218192/spec-driven-project-template

Set up and operate the git-remote sync of the agent's machine-local memory directory. Use to configure the memory remote the first time, to push or pull memory manually, to onboard a new machine, or to resolve a memory merge conflict. The memory_push Stop hook handles routine per-turn pushes automatically once setup is done.

2026-06-170

spike

dw218192/spec-driven-project-template

Resolve an uncertainty during spec authoring by running a throwaway investigation and recording a concluded docs/spike/SPIKE-<n>.md evidence artifact. Use when a spec or ADR makes a design claim that is not yet backed by a concluded spike, a cited code path, or a doc — the spec gate rejects uncited claims and open questions.

2026-06-170

update-from-template

dw218192/spec-driven-project-template

Pull later framework improvements (process, gates, skills, hooks, scripts) from the upstream template into this project — without touching project content. Use when the template repo has shipped updates you want to adopt; it syncs only framework-owned paths and stages them for review.

2026-06-170

name	spec
description	Author or revise a work item's spec at docs/spec/<id>.md before any code is written, then run it through the spec gate. Use when starting a new work item, when a spec needs revision after a spec-gate rejection, or when acceptance criteria must be defined. Produces a fully-signed spec — Goal, Non-goals, evidence-cited claims, stable spec-item IDs, and frozen executable acceptance criteria.

A spec is the written commitment for one work item (one branch work/<id>). It is authored before code and reviewed adversarially by the spec-gate subagent. Code does not start until the gate passes. See docs/process.md.

Author the spec

Copy this skill's references/spec-template.md to docs/spec/<id>.md and complete every section. The gate fails a spec that is missing any of them.

Goal — what this work item delivers, bounded.
Non-goals — what's explicitly out of scope. Required: without them the gate cannot distinguish an authorized deferral from a silent scope cut.
Evidence — every non-trivial claim cites a concluded spike (SPIKE-<n>), a code path (file:line), or a doc. Use the spike skill for uncertainties.
Spec items — each normative requirement gets a stable ID (<PREFIX>-<n>) so it is citable in code (an implements <PREFIX>-1 marker in a comment) and traceable.
Acceptance criteria — executable commands (prefer pixi run tasks), written verbatim in a fenced block and frozen here. Each ties to a spec item. The impl gate re-runs them itself; never author criteria that pass without exercising real behavior.

A spec is fully signed only when every item has all three of: evidence, a criterion, and spec-gate sign-off.

Run the spec gate

Invoke the spec-gate subagent to review the spec (and every ADR it depends on) adversarially. It hunts for: unauthorized scope cuts, uncited claims, open questions, and infeasibility. On a fail, address each finding by editing the spec (and/or concluding more spikes) and re-run — do not start implementation.

On a pass, present the spec to the human for sign-off. Implementation begins only after the human approves the spec — spec→impl is a human gate, not just an AI one.

Back-edge

If implementation reveals the spec is wrong, return here: edit the spec and re-run the spec gate before continuing. The spec is the contract; keep it true.