Create, review, and execute risk-tiered software change plans with requirements traced to tasks and approvals secured by SHA-256 receipts.
Installer & Télécharger
1. ClawHub CLI
Le moyen le plus rapide d'installer une compétence directement depuis le registre.
npx clawhub@latest install spec-skill
2. Installation manuelle
Copiez le dossier de la compétence dans l'un de ces emplacements
~/.openclaw/skills/ <project>/skills/ Priorité : Espace de travail > Local > Intégré
3. Installation du prompt
Copiez ce prompt dans OpenClaw pour l'installer automatiquement.
Aide-moi à installer spec-skill via Clawhub. Si Clawhub n'est pas installé, installe-le d'abord (npm i -g clawhub).
Vous préférez télécharger ?
Obtenez les fichiers bruts de la compétence dans une archive ZIP.
Qu'est-ce que Spec-Driven Change ?
Spec-Driven Change guides an AI coding agent through a structured software change lifecycle: define observable requirements, document the design, break implementation into verifiable tasks, and record decisions in a ledger that survives session interruptions. Risk-based approval gates help teams match review depth to the change, while hash-pinned receipts make approval state verifiable rather than inferred from files alone.
Designed for Openclaw Skills workflows, it creates organized plans under docs/plans/ and uses a validator to check approval hashes, requirements coverage, verification commands, citations, and other consistency rules. The result is a more resumable, auditable path from an idea to verified production behavior.
Cas d'utilisation de Spec-Driven Change
- Planning a feature that spans multiple files or subsystems, with requirements linked to implementation tasks.
- Investigating a bug by recording symptoms, reproduction steps, root cause, expected behavior, and regression coverage.
- Applying extra review gates to high-risk changes involving money, access control, entitlements, migrations, or production data.
- Preparing a quick specification for straightforward, multi-file work without a separate design document.
- Resuming an interrupted change in a fresh session using the decision ledger and current approval receipts.
- Coordinating sequential execution, or carefully constrained task-level subagent work when file ownership does not overlap.
- Tracking whether work is implemented, merged, deployed, or verified instead of treating those states as interchangeable.
Comment fonctionne Spec-Driven Change
- Read the consuming repository's
AGENTS.mdor its named overlay to learn its risk surfaces, deployment procedure, hard stops, and reviewers; read the skill's example spec for the required document shapes. - Choose and explain a risk tier: one gate for quick or obvious work, two gates for requirements and design, or three separate gates for high-risk changes and implementation reviews.
- Create a dated plan directory under
docs/plans/and choose a spec type: feature, bug, or quick. Write each gated document separately, stop at the gate, report the path and decision, and wait for approval. - Write numbered, observable requirements and criteria, including explicit out-of-scope items and open questions. Record decisions and their answers in
.spec-state.jsonin the same turn they are made. - For feature work, design the approach and explain how it satisfies each requirement. For bug work, document the investigation in requirements. For quick work, omit
design.md. - Create ordered coding tasks with
Files:,Verify:, and_Requirements:fields. Ensure every criterion is covered, and use an enabler label for foundation tasks that do not directly implement a user-visible criterion. - Run the validator before presenting a gate and again before execution. Resolve errors, including invalid receipts, uncovered criteria, missing verification lines, and unsupported commands, before proceeding.
- Execute unchecked tasks in order, run each task's verification, and stop on the first failed check or real blocker. Keep one session responsible for a spec's shared task list and ledger.
- Record closure accurately as
implemented,merged,deployed, orverified. Archive only at deployment or later, distinguish archived intent from living project rules, and migrate any load-bearing guidance into its current home.
Configuration de Spec-Driven Change
- Install or make the skill directory available to the coding agent. The skill identifies
preuve.aias its homepage and supports invocation with/specin Claude Code or$specin Codex. - In the consuming repository, review
AGENTS.mdor the file it references. Confirm the repository's risk-tier surfaces, deployment/apply step, hard stops, and specialist reviewers. - Read
references/example-spec.mdin the skill directory before creating a plan; use its document shapes rather than guessing. - Create a plan directory following
docs/plans/<YYYY-MM-DD>-<slug>/. A feature includes requirements, design, tasks, and ledger files; a bug or quick spec may omitdesign.mdas appropriate. - Validate the plan before presenting a gate and before execution:
node <this-skill-dir>/scripts/check-spec.mjs docs/plans/<date>-<slug>
- Treat exit code 1 as a blocking validation failure: fix the reported issues before continuing. The validator recomputes approval hashes and checks consistency, coverage, citations, verification lines, and related plan constraints.
- Do not assume the plan directory alone marks a phase or approval. Phase is derived from the files present, and approved documents require matching SHA-256 receipts in
.spec-state.json.
Schéma de données et taxonomie de Spec-Driven Change
A plan is stored in a dated directory:
| Path | Purpose |
|---|---|
docs/plans/<YYYY-MM-DD>-<slug>/requirements.md |
Numbered user stories and observable criteria; bug specs also document the investigation here. |
docs/plans/<YYYY-MM-DD>-<slug>/design.md |
Architecture, data model, interfaces, error handling, and testing strategy for feature work; omitted for quick specs. |
docs/plans/<YYYY-MM-DD>-<slug>/tasks.md |
Ordered implementation checkboxes with file scope, verification commands, and requirement references. |
docs/plans/<YYYY-MM-DD>-<slug>/.spec-state.json |
Durable decision ledger and approval receipts; phase is derived from files, not stored as a field. |
The ledger records the spec type (feature, bug, or quick) and declared tier (1–3). Its approved entries contain a document file, its sha256 hash, and approval timestamp at. A changed hash invalidates that approval and downstream approvals; remove voided entries rather than editing a hash to conceal a mismatch.
Each decisions[] entry has a stable id, the question, a recommended option while open, an answer that is null until decided and retained afterward, and a one-sentence why recorded with the answer. blocking states what human input is pending. closure is absent while open and may be implemented, merged, deployed, or verified. context.template identifies the module the work models.
Requirements use stable numbered criteria such as 1.1 and EARS-style conditions, so tasks can cite them without ambiguous references. Tasks include Files:, Verify:, and _Requirements:; every criterion should be covered, and non-user-facing foundation work uses _Requirements: enabler_. Existing flat, single-file plans in docs/plans/ remain unchanged.
Fonctionnalités avancées de Spec-Driven Change
- Risk-tiered approval gates: one, two, or three gates based on change risk rather than file count.
- SHA-256 approval receipts with downstream invalidation when an approved document changes.
- A durable decision ledger that preserves questions, recommendations, answers, rationale, blockers, and closure state across sessions.
- Validator checks for receipt integrity, uncovered requirements, orphan citations, missing
Verify:lines, invented npm scripts, and unproven non-regression assertions. - Requirement-to-task traceability, stable criterion numbering, coverage reporting, and test-backed non-regression assertions for sensitive changes.
- Explicit backward-flow procedure for invalidating approvals, amending requirements without breaking citations, recording reversals, and reopening downstream gates.
- Resume workflow that reads the ledger and all plan documents, validates receipt state, and checks the codebase before assuming unchecked tasks remain undone.
- Constrained subagent execution: dispatch only tasks whose declared
Files:do not intersect, using the task text, files, and verification as the complete brief; merge in the main thread. - Unattended execution safeguards: stop after ten consecutive tasks without human review, stop at the first failed verification, and leave tool approvals to the user.
- Lifecycle tracking distinguishes implementation, merge, deployment, and production verification; archiving is allowed only at
deployedor later, with load-bearing guidance migrated into living project rules.
SKILL.md
Chargement
Compétences Openclaw associées
Coach de recherche d'emploi Four-Leaf
Four-Leaf Coach connecte un agent de programmation IA à des outils en temps réel de recherche d'emploi et de préparation aux entretiens, afin que les utilisateurs puissent prendre des décisions de carrière éclairées et s'entraîner avec des commentaires précis.
Agentic Maestro
Agentic Maestro aide les orchestrateurs à déléguer les tâches de codage à des agents spécialisés et à guider leur travail en toute sécurité au fil de la revue, de la vérification et de l’intégration.
Nor'easter Hatteras Island Outer Banks — Traverser un Nor'easter | Expérience IA
Une expérience IA de 14 étapes à faible intensité qui guide un agent à travers la solitude, le danger et la résilience de traverser un nor'easter sur Hatteras Island.
Contract Triage Lite
Contract Triage Lite vérifie hors ligne les contrats de freelance pour détecter quatre risques courants et met en évidence les clauses et protections manquantes sans envoyer le texte du document où que ce soit.
EmpirioLabs AI Transcription
Convertissez des enregistrements audio et vidéo en texte précis avec EmpirioLabs AI, y compris des étiquettes de locuteur, des indices de langue, des données temporelles et un traitement asynchrone.
Catalogue de modèles d’IA EmpirioLabs
Recherchez dans le catalogue d’IA EmpirioLabs en temps réel pour comparer les capacités, les prix, les paramètres, les limites et les endpoints pris en charge des modèles sans clé API.
En vedette*
