Sponsored by APIMart - AI API, 99.9% SLA. 언제나 끊김 없이, 나만의 AI를. 대부분의 모델을 20~60% 저렴하게 이용할 수 있으며, nanobanana pro API는 단

AI 광고 라이브러리

Spec-Driven Change

Openclaw용 Spec-Driven Change

Create, review, and execute risk-tiered software change plans with requirements traced to tasks and approvals secured by SHA-256 receipts.

vxncxnx

v0.1.1

Oct 20, 2026

설치

정보

Skill.md

설치 및 다운로드

1. ClawHub CLI

레지스트리에서 스킬을 바로 설치하는 가장 빠른 방법입니다.


                  npx clawhub@latest install spec-skill

2. 수동 설치

스킬 폴더를 다음 위치 중 하나로 복사하세요

글로벌

~/.openclaw/skills/

워크스페이스

<project>/skills/

우선순위: 워크스페이스 > 로컬 > 번들

3. 프롬프트 설치

이 프롬프트를 OpenClaw에 복사하면 자동으로 설치됩니다.


                  Clawhub를 사용해서 spec-skill 설치를 도와줘. Clawhub가 설치되어 있지 않다면 먼저 설치해 줘 (npm i -g clawhub).

다운로드를 원하시나요?

ZIP 아카이브 형태의 원본 스킬 파일을 받으세요.

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.

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.

Spec-Driven Change 작동 원리

Read the consuming repository's AGENTS.md or 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.json in 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, or verified. Archive only at deployment or later, distinguish archived intent from living project rules, and migrate any load-bearing guidance into its current home.

Spec-Driven Change 설정 가이드

Install or make the skill directory available to the coding agent. The skill identifies preuve.ai as its homepage and supports invocation with /spec in Claude Code or $spec in Codex.
In the consuming repository, review AGENTS.md or the file it references. Confirm the repository's risk-tier surfaces, deployment/apply step, hard stops, and specialist reviewers.
Read references/example-spec.md in 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 omit design.md as 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.

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.

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 deployed or later, with load-bearing guidance migrated into living project rules.