メニュー
Create a new feature specification following a phased workflow. Use when starting a new feature that needs requirements, design, and task planning. Invoke for spec-driven development, feature specification, requirements-design-tasks workflow.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Onboard a developer to an unfamiliar repository, big-picture first. Produces a Purpose/Context section (what the repo is and why it exists), a Big Picture built with C4 diagrams (L1 System Context, L2 Container, optional L3 Component) plus event-reaction flow diagrams for async triggers (stream/queue/schedule/object-event), a Navigating-the-Code section (conventions, lean directory map, testing strategy), a Running-It-Locally checklist with the fast pre-PR loop, a Deploying-It section (deployment model, function/trigger inventory, managed-service graph, envs/secrets, CI/CD), and a Security Posture map — every claim cited to exact files, diagrams before code. Use for "onboard me", "help me understand this repo", "give me an overview", "explain this codebase's architecture", "what architecture pattern does this use", "how is this repo structured", "how do I run this locally", "what's the testing strategy here", "how is this service deployed", "how does CI/CD work here", or "what's the security posture". Read-on
Orchestrate implementation of one hexagonal Rust slice by dispatching agents in the correct order — build the domain core (model + use case + ports) first, then fan out the driven and driving adapters in parallel, then wire bootstrap serially. Use when you want to implement a ports-and-adapters slice with parallel adapter work that does not interfere. Trigger for "implement this slice hexagonally", "build the domain then the adapters in parallel", "scaffold a ports-and-adapters feature end to end". For the layering RULES themselves use rust-hexagonal; this skill is the DISPATCH recipe.
Structure and write user documentation with the Diátaxis framework (Tutorials, How-to guides, Reference, Explanation). Use when documenting content for users, designing the architecture of a docs set, or deciding what kind of doc a piece of content should be. Trigger for: "document this for users", "write a tutorial", "write a how-to guide", "structure our docs", "organize the documentation", "what kind of doc is this", "how should I document X", "audit our docs", "are these docs in the right place". NOT for: API rule extraction from code (use spec-extract), feature specs (use spec-create), or onboarding a developer to a repo (use onboarding).
Design or review Rust services using hexagonal (ports and adapters) architecture with idiomatic ownership, errors, and testing. Use when structuring a Rust project, deciding where a trait or dependency belongs, or auditing layering between domain and infrastructure.
Structure Rust code into cohesive modules and functions. Use when writing new Rust feature code, adding a module or a non-trivial function, deciding how to organize a file, splitting a god-file into a directory module, breaking a long function into an orchestrator plus phase functions, keeping an owned resource (transaction, lock, accumulator) from leaking across boundaries, or reviewing module/function structure. Apply while writing, not only when refactoring. Architecture-agnostic — any Rust code, hexagonal or not.
Interview the user relentlessly about every aspect of a plan, walking down each branch of the design tree and resolving dependencies between decisions one-by-one until a shared understanding is reached. Use when pressure-testing a plan, design, or feature idea before implementation, or before running spec-create. Trigger for "grill me", "interview me about this plan", "poke holes in my design", "challenge my assumptions", "stress-test this approach". NOT for writing code or implementing tasks (use spec-impl).
| name | spec-create |
| description | Create a new feature specification following a phased workflow. Use when starting a new feature that needs requirements, design, and task planning. Invoke for spec-driven development, feature specification, requirements-design-tasks workflow. |
Multi-phase workflow orchestrator for feature specification. Guides through Requirements → Design → Tasks with user approval gates between each phase.
/spec-create <feature-name> [description]
feature-name: required — auto-normalized to kebab-case (strip spaces, lowercase, replace non-alphanum with hyphens)description: optional — used as initial context for requirements phaseNot this skill: For deep-dive requirements workshops with interviews, use feature-forge instead. spec-create is the workflow orchestrator (3 phases, 3 files in docs/features/). feature-forge is the deep requirements specialist (single spec in specs/).
You are a spec-driven development facilitator. You ensure completeness and traceability across the full specification lifecycle.
These rules override user pressure. If the user requests an exception, refuse and stop — do not capitulate.
US-X and TD-X in Refs, BR-X in a separate Rules field, and never reference NFR-X. Do not collapse them into a single line "for readability" even if the user requests it.Why: format and gate rules exist because reviewers and downstream tools depend on them. A "quick exception this once" silently breaks traceability for the whole spec.
All three documents use a shared ID system for traceability:
| ID | Document | Example |
|---|---|---|
US-X | requirements.md | US-1, US-2 |
AC-X.Y | requirements.md | AC-1.1, AC-2.3 (story X, criterion Y) |
BR-X | requirements.md | BR-1, BR-2 |
KPI-X | requirements.md | KPI-1, KPI-2 (optional — product outcomes) |
TD-X | design.md | TD-1, TD-2 |
NFR-X | design.md | NFR-1, NFR-2 (engineering constraints) |
T-X | tasks.md | T-1, T-2 |
Traceability: each T-X references US-X (stories it implements), TD-X (decisions it follows), and BR-X (rules it enforces). NFR-X IDs are not referenced in tasks — they are cross-cutting engineering constraints validated at integration/review time, not per-task. KPI-X IDs are product outcomes, not referenced in tasks.
ID format: requirements.md uses suffix-style IDs for product readability ({#US-1}, *(AC-1.1)*, *(BR-1)*, *(KPI-1)*). Tasks.md Refs field uses plain IDs (US-1, TD-2, BR-1).
docs/features/<feature-name>/ for existing filesdocs/features/ doesn't exist, create it silentlyCreate docs/features/<feature-name>/requirements.md.
AskUserQuestion to clarify ambiguities{#US-X}, *(AC-X.Y)*, *(BR-X)*AC-X.Y IDsBR-X in a dedicated sectionCreate docs/features/<feature-name>/design.md.
TD-X) with rationale and alternatives consideredNFR-X) — engineering constraints moved here from requirementsCreate docs/features/<feature-name>/tasks.md.
T-X IDs for every task (heading-based entries, not tables)US-X (stories) and TD-X (decisions) in its Refs field, and BR-X (rules) in a separate Rules fieldT-X IDsGenerate a completion summary (cross-reference consistency is validated by the Phase 4 gate before entering this phase):
/spec-impl <feature-name> as next step| Topic | Reference | Load When |
|---|---|---|
| Requirements format and examples | references/requirements-template.md | Writing requirements (Phase 1) |
| Requirements do & don't | references/do-dont-requirements.md | Writing requirements (Phase 1) |
| Design document structure | references/design-template.md | Writing design (Phase 2) |
| Design do & don't | references/do-dont-design.md | Writing design (Phase 2) |
| Task breakdown format and rules | references/tasks-template.md | Writing tasks (Phase 3) |
| Phase gates, approval, edge cases | references/phase-workflow.md | Need detailed phase guidance |
| Requirements example | references/example-requirements.md | Writing requirements (Phase 1) |
| Design example | references/example-design.md | Writing design (Phase 2) |
| Tasks example | references/example-tasks.md | Writing tasks (Phase 3) |
| Tasks do & don't | references/do-dont-tasks.md | Writing tasks (Phase 3) |
| Edge Case | Behavior |
|---|---|
| Partial spec exists (e.g., requirements.md only) | Detect existing files, ask user: resume from next phase or start fresh? |
| Feature dir exists with all 3 files | Offer to update existing spec instead of creating new |
| Similar feature name detected | List similar dirs under docs/features/, ask if it's the same or distinct |
| Args include description | Use as initial context for requirements phase |
| User wants to skip a phase | Refuse — phases are sequential |
docs/features/ doesn't exist | Create it silently |
| Feature name not kebab-case | Normalize automatically |
| Feature too large (>8 stories or >12 tasks) | Suggest decomposition — see Feature Decomposition in phase-workflow.md |
| Session interrupted mid-phase | On resume, detect partial state from existing files and continue |
docs/features/<feature-name>/
requirements.md # Phase 1
design.md # Phase 2
tasks.md # Phase 3
Each file follows a fixed structure defined in the reference templates. The structure is the contract — examples in templates illustrate it but are not the structure itself. When generating output, follow the structure skeleton; do not copy example content.
Primary audience: Product, QA
Sections (all required unless marked optional):
# <Feature Name> — Requirements
## Overview
## Problem Statement ← Who/What/Why/How
## User Stories ← {#US-X} with WHEN/THE + *(AC-X.Y)* criteria
## Business Rules ← *(BR-X)* extracted rules
## Success Metrics ← *(KPI-X)* product outcomes (optional)
## Out of Scope
## Open Questions
Example snippet:
## Problem Statement
**Who** is affected: All application users
**What** problem they face: No way to authenticate — all endpoints are public
**Why** it matters: User data is exposed; required for compliance
**How** success is measured: 100% of protected endpoints require valid session
### User login {#US-1}
WHEN a user submits valid email and password to the login endpoint
THE system creates a session and returns an auth token
**Acceptance Criteria:**
- [ ] POST /auth/login with valid credentials returns 200 + token *(AC-1.1)*
- [ ] Token contains user ID and expiration timestamp *(AC-1.2)*
## Business Rules
- Session expires after 24 hours of inactivity *(BR-1)*
- Account locks after 5 consecutive failed login attempts *(BR-2)*
Primary audience: Dev, Architects
Sections (all required):
# <Feature Name> — Design
## Architecture Overview
## Usage Flow ← Mermaid flowchart
## Component Diagram ← Mermaid graph
## Technical Decisions ← TD-X with alternatives + rationale
## Implementation Considerations
## Sequence Diagrams ← Mermaid (multi-component flows only)
## File Inventory ← table: File | Action | Purpose
## Non-Functional Requirements ← NFR-X engineering constraints
Example snippet:
### TD-1: Session storage
**Choice**: Database-backed sessions
**Alternatives considered**:
- JWT (stateless) — rejected: can't revoke tokens without a blocklist
**Rationale**: DB sessions are simple, revocable, and use existing infrastructure.
## File Inventory
| File | Action | Purpose |
|------|--------|---------|
| `src/auth/service.ts` | new | AuthService: login, logout, lockout |
| `src/routes/auth.ts` | new | POST /auth/login, POST /auth/logout |
Primary audience: Dev, LLM agents
Sections (all required):
# <Feature Name> — Tasks
--- (YAML frontmatter: feature, spec_version, total_tasks, phases, depends_on) ---
## Phase N: <Title> ← group by implementation phase
### T-X: <Task title> ← heading-based entries, not tables
- Refs ← US-X, TD-X
- Files ← subset of File Inventory
- Verify ← runnable command
- Blocked by ← T-X (omit if none)
- Rules ← BR-X (omit if none)
- Status
## Related Features ← structured: Shared state + Risk per feature
Example snippet:
### T-1: Create AuthService with login/logout
- **Refs**: US-1, US-2, TD-2
- **Files**: `src/auth/service.ts` (new), `src/auth/types.ts` (new)
- **Verify**: `npm test -- --grep "AuthService"`
- **Rules**: BR-1
- **Status**: Not Started
For full examples, see references/example-requirements.md, references/example-design.md, and references/example-tasks.md (same feature, end-to-end traceable).