원클릭으로 Manus에서 모든 스킬 실행

spec-driven

스타2

포크0

업데이트2026년 4월 7일 21:58

Create a SPEC.md for a feature, validate via Council, then generate failing tests from acceptance criteria before implementation.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

stoa-platform

stoa-platform/stoa

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Spec-Driven Development

CAB-2005: Formalize the spec-first pattern. Council validates the spec BEFORE code. Acceptance criteria become test cases. Tests are written BEFORE implementation.

Usage

/spec-driven CAB-XXXX
/spec-driven "feature description"

Step 1: Create Spec

If a CAB-XXXX ID is given, fetch the ticket from Linear: linear.get_issue("CAB-XXXX")
Copy template from .claude/templates/SPEC.md
Fill in: Problem, Goal, API Contract, Acceptance Criteria, Edge Cases
Write to branch root as SPEC.md

Step 2: Council on Spec (Stage 1 variant)

Run the 4-persona Council but evaluate the spec quality, not the feature itself:

Chucky: Are edge cases covered? Missing failure modes?
OSS Killer: Is the goal measurable? Will this deliver user value?
Archi: Is the API contract consistent with existing patterns? Breaking changes?
Better Call Saul: Security considerations complete? PII/GDPR noted?

Threshold: >= 7.0 to proceed. Below 7.0: revise spec first.

Step 3: Generate Failing Tests

From each acceptance criterion, generate a test:

Python (api): test_spec_ac1_<description>() in tests/test_spec_<ticket>.py
TypeScript (ui/portal): describe('spec/CAB-XXXX', () => { it('AC1: ...') }) in src/__tests__/spec/
Rust (gateway): fn spec_ac1_description() in inline #[cfg(test)] mod tests

All tests MUST fail (red) at this stage. If any passes, the criterion is already met or the test is wrong.

Step 4: Implement

Write code to make all tests pass. Standard Pattern 3 workflow.

Step 5: Verify

All spec tests green
No other tests broken
SPEC.md stays in the branch (committed with the PR) as documentation

Rules

Spec lives in branch root, committed in the same PR as the implementation
Council scores the spec, not the implementation plan
Every acceptance criterion = exactly one test
Edge cases table = additional tests (tagged @edge-case)
If spec changes during implementation, re-run Council
.spec.md = technical only. Business data → stoa-strategy (private repo)

이 저장소의 다른 Skills

같은 저장소

rewrite

stoa-platform/stoa

Force a full-file rewrite (Write) instead of patch (Edit) when Edit keeps failing or diff is large. Context rot mitigation — use when Edit has failed ≥2× on same file, or when estimated diff >30% of file size.

2026-04-222

pr-guardian

stoa-platform/stoa

STOA PR Guardian — advisory three-axis review (ADR compliance, security, AI code smell) with binary GO/NO-GO verdict + confidence. Never approves, never blocks merge.

2026-04-162

fill-cycle

stoa-platform/stoa

Analyze cycle capacity gap and propose backlog items to fill the sprint to ~80% of proven velocity.

2026-04-162

roadmap

stoa-platform/stoa

Visual roadmap snapshot — theme progress, milestones, velocity. Zero new infra (Linear MCP + velocity.json).

2026-04-162

sync-plan

stoa-platform/stoa

Cycle-aware bidirectional sync between plan.md and Linear. Discovers all cycle tickets, detects drift, updates markers.

2026-04-162

ci-debug

stoa-platform/stoa

Debug GitHub Actions CI pipeline failures. Analyse les logs de workflow, identifie la cause racine et propose un fix.

2026-04-152

name	spec-driven
description	Create a SPEC.md for a feature, validate via Council, then generate failing tests from acceptance criteria before implementation.
user_invocable	true

Spec-Driven Development

CAB-2005: Formalize the spec-first pattern. Council validates the spec BEFORE code. Acceptance criteria become test cases. Tests are written BEFORE implementation.

Usage

/spec-driven CAB-XXXX
/spec-driven "feature description"

Step 1: Create Spec

If a CAB-XXXX ID is given, fetch the ticket from Linear: linear.get_issue("CAB-XXXX")
Copy template from .claude/templates/SPEC.md
Fill in: Problem, Goal, API Contract, Acceptance Criteria, Edge Cases
Write to branch root as SPEC.md

Step 2: Council on Spec (Stage 1 variant)

Run the 4-persona Council but evaluate the spec quality, not the feature itself:

Chucky: Are edge cases covered? Missing failure modes?
OSS Killer: Is the goal measurable? Will this deliver user value?
Archi: Is the API contract consistent with existing patterns? Breaking changes?
Better Call Saul: Security considerations complete? PII/GDPR noted?

Threshold: >= 7.0 to proceed. Below 7.0: revise spec first.

Step 3: Generate Failing Tests

From each acceptance criterion, generate a test:

Python (api): test_spec_ac1_<description>() in tests/test_spec_<ticket>.py
TypeScript (ui/portal): describe('spec/CAB-XXXX', () => { it('AC1: ...') }) in src/__tests__/spec/
Rust (gateway): fn spec_ac1_description() in inline #[cfg(test)] mod tests

All tests MUST fail (red) at this stage. If any passes, the criterion is already met or the test is wrong.

Step 4: Implement

Write code to make all tests pass. Standard Pattern 3 workflow.

Step 5: Verify

All spec tests green
No other tests broken
SPEC.md stays in the branch (committed with the PR) as documentation

Rules

Spec lives in branch root, committed in the same PR as the implementation
Council scores the spec, not the implementation plan
Every acceptance criterion = exactly one test
Edge cases table = additional tests (tagged @edge-case)
If spec changes during implementation, re-run Council
.spec.md = technical only. Business data → stoa-strategy (private repo)