Language: Always interact with the user in 日本語.
spec-gen-en
Actively discuss with the user to resolve unknowns, presenting reference ideas to solidify specifications.
Prerequisites
- Claude Code environment
gh CLI (for GitHub Issue mode)
Arguments
- No arguments: Create a full set of design documents for a new project
- Path specified: Append/update to an existing specification document
Documents to Generate (Default Paths)
| Document |
Default File |
Content |
| Functional requirements |
docs/requirements/functional.md |
Use cases, feature list, screen/operation flows |
| Non-functional requirements |
docs/requirements/non-functional.md |
Performance, security, availability, scalability |
| Architecture design |
docs/architecture/overview.md |
Overall structure, tech stack, layer architecture, communication flows |
| ER / Data model |
docs/architecture/er.md |
Overall ER diagram, per-table ER diagrams, table definitions, constraints, indexes |
| API specification |
docs/api/endpoints.md |
Endpoints, request/response, auth, errors |
| Component design |
docs/components/overview.md |
Component breakdown, responsibilities, dependencies, interfaces |
- These are default paths. If an existing spec directory is found, use that instead (see "Discovery" below)
Phase 1: Assess Current State and Decide Direction
1-0: Discover Existing Specs (Required — Run First)
If a path is specified as argument:
- Read the file/directory at that path directly
- Also check related files in the same directory
If no argument:
Search for existing specs using Glob:
**/spec/**/*.md
**/specs/**/*.md
**/docs/**/*.md
**/specifications/**/*.md
**/design/**/*.md
Based on discovery results:
- Existing specs found: Record the directory structure and file paths as the base map. Place new documents within this structure. Do NOT use default paths
- No specs found: Use default paths (
docs/ subtree)
Important: Always Read discovered spec files to understand current specifications before proceeding.
Output Destination
Confirm with AskUserQuestion:
- GitHub Issue + branch (recommended): Create the implementation Issue, then use its number for the work branch. The same Issue can be passed to
impl at the end
- Local only: Work on current branch without creating Issues or branches
For New Projects
- Interview about overview, purpose, and background
- Present similar projects and tech stack direction
- Agree on document scope
- GitHub Issue mode: Record base branch -> create placeholder Issue -> create
feat/#<issue-number> branch -> add branch name to Issue
- Issue title must be
feat: <feature-name> (the feature to implement). Never use document-centric titles like "Create design documents"
- Body is a placeholder at this point (e.g.,
仕様策定中(spec-gen 実行中)。完了後に実装内容を追記する。). Phase 3 rewrites it as the implementation Issue
- Spec creation itself is the work of this skill, not a separate Issue. The goal here is to reserve an Issue number that will be reused as the impl target
- Create tasks with TaskCreate
For Appending to Existing Specs
- Using 1-0 discovery results, Read all existing spec files to understand current specifications
- Interview about additions
- Present existing feature reuse/change proposals
- Agree on direction
- GitHub Issue mode: Same as above (Issue title describes the feature to add; body is a placeholder)
- Create tasks with TaskCreate
Phase 2: Document Creation Cycle (repeat per document)
2-1: Interview
- Gather information needed for the document in a single
AskUserQuestion call
- Include pros/cons and reference ideas in option
description fields
2-2: Write
- Create based on interview results. Use Mermaid for diagrams (see
references/mermaid-guide.md)
- Include revision history (see format at end of
references/mermaid-guide.md)
2-3: Review
- Present to user and confirm with
AskUserQuestion (include "No issues" option)
2-4: Improvement Cycle
- If feedback -> revise -> update revision history -> re-confirm -> repeat until satisfied
2-5: Format & Lint
- Run if settings exist. Skip otherwise
2-6: Commit
- Commit following CLAUDE.md conventions
Phase 3: Finalize and Push
- Confirm all documents are complete
- Cross-document consistency check (ER vs API, components vs functional requirements, etc.)
- GitHub Issue mode: Push -> rewrite the Issue body as the implementation Issue -> report summary (including Issue URL)
- Replace the placeholder body of the Issue created in Phase 1 with the implementation Issue contents, following
templates/impl-issue.md
- Include: 概要 (overview), spec file links to consult during implementation, 受け入れ条件 (acceptance criteria), base branch
- Acceptance criteria must be extracted from the spec docs as concrete completion conditions (avoid vague "implement it")
- Write the new body to a temp file and apply with
gh issue edit <number> --body-file <temp-file>, then delete the temp file
- Keep the Issue open (do not close). It can be passed directly to
/impl #<number>
- Local mode: Report summary (file path list)
Rules
- Never guess unknowns; always confirm with user
- Always use
AskUserQuestion with options for questions. Never ask via text alone
- Max 4 questions per round
- Include reference ideas in each option's
description
- When appending to existing specs, prioritize reuse/modification of existing features
- Always add revision history when updating documents
- Track progress with TaskCreate/TaskUpdate
- If an existing spec directory is found, use those paths — not the defaults (
docs/). Never create new subdirectories when existing ones already serve the same purpose
- When updating existing files, use Edit to modify them in place. Never create duplicate files in a different location
1---2name: spec-gen-en3description: Interactively create design documents for new projects. Also supports appending to existing specs.4user-invocable: true5---67**Language: Always interact with the user in 日本語.**89# spec-gen-en1011Actively discuss with the user to resolve unknowns, presenting reference ideas to solidify specifications.1213## Prerequisites1415- Claude Code environment16- `gh` CLI (for GitHub Issue mode)1718## Arguments1920- No arguments: Create a full set of design documents for a new project21- Path specified: Append/update to an existing specification document2223## Documents to Generate (Default Paths)2425| Document | Default File | Content |26|----------|------|---------|27| **Functional requirements** | `docs/requirements/functional.md` | Use cases, feature list, screen/operation flows |28| **Non-functional requirements** | `docs/requirements/non-functional.md` | Performance, security, availability, scalability |29| **Architecture design** | `docs/architecture/overview.md` | Overall structure, tech stack, layer architecture, communication flows |30| **ER / Data model** | `docs/architecture/er.md` | Overall ER diagram, per-table ER diagrams, table definitions, constraints, indexes |31| **API specification** | `docs/api/endpoints.md` | Endpoints, request/response, auth, errors |32| **Component design** | `docs/components/overview.md` | Component breakdown, responsibilities, dependencies, interfaces |3334- **These are default paths. If an existing spec directory is found, use that instead (see "Discovery" below)**3536## Phase 1: Assess Current State and Decide Direction3738#### 1-0: Discover Existing Specs (Required — Run First)3940**If a path is specified as argument:**41- Read the file/directory at that path directly42- Also check related files in the same directory4344**If no argument:**45Search for existing specs using Glob:46```47**/spec/**/*.md48**/specs/**/*.md49**/docs/**/*.md50**/specifications/**/*.md51**/design/**/*.md52```5354**Based on discovery results:**55- **Existing specs found**: Record the directory structure and file paths as the base map. Place new documents within this structure. Do NOT use default paths56- **No specs found**: Use default paths (`docs/` subtree)5758**Important: Always Read discovered spec files to understand current specifications before proceeding.**5960#### Output Destination6162Confirm with `AskUserQuestion`:63- **GitHub Issue + branch** (recommended): Create the implementation Issue, then use its number for the work branch. The same Issue can be passed to `impl` at the end64- **Local only**: Work on current branch without creating Issues or branches6566#### For New Projects671. Interview about overview, purpose, and background682. Present similar projects and tech stack direction693. Agree on document scope704. **GitHub Issue mode**: Record base branch -> **create placeholder Issue** -> create `feat/#<issue-number>` branch -> add branch name to Issue71 - **Issue title must be `feat: <feature-name>`** (the feature to implement). Never use document-centric titles like "Create design documents"72 - **Body is a placeholder at this point** (e.g., `仕様策定中(spec-gen 実行中)。完了後に実装内容を追記する。`). Phase 3 rewrites it as the implementation Issue73 - Spec creation itself is the work of this skill, not a separate Issue. The goal here is to reserve an Issue number that will be reused as the impl target745. Create tasks with TaskCreate7576#### For Appending to Existing Specs771. **Using 1-0 discovery results**, Read all existing spec files to understand current specifications782. Interview about additions793. Present existing feature reuse/change proposals804. Agree on direction815. **GitHub Issue mode**: Same as above (Issue title describes the feature to add; body is a placeholder)826. Create tasks with TaskCreate8384## Phase 2: Document Creation Cycle (repeat per document)8586#### 2-1: Interview87- Gather information needed for the document in **a single `AskUserQuestion` call**88- Include pros/cons and reference ideas in option `description` fields8990#### 2-2: Write91- Create based on interview results. Use Mermaid for diagrams (see `references/mermaid-guide.md`)92- Include revision history (see format at end of `references/mermaid-guide.md`)9394#### 2-3: Review95- Present to user and confirm with `AskUserQuestion` (include "No issues" option)9697#### 2-4: Improvement Cycle98- If feedback -> revise -> update revision history -> re-confirm -> repeat until satisfied99100#### 2-5: Format & Lint101- Run if settings exist. Skip otherwise102103#### 2-6: Commit104- Commit following CLAUDE.md conventions105106## Phase 3: Finalize and Push1071081. Confirm all documents are complete1092. Cross-document consistency check (ER vs API, components vs functional requirements, etc.)1103. **GitHub Issue mode**: Push -> **rewrite the Issue body as the implementation Issue** -> report summary (including Issue URL)111 - Replace the placeholder body of the Issue created in Phase 1 with the implementation Issue contents, following `templates/impl-issue.md`112 - Include: 概要 (overview), spec file links to consult during implementation, 受け入れ条件 (acceptance criteria), base branch113 - Acceptance criteria must be extracted from the spec docs as concrete completion conditions (avoid vague "implement it")114 - Write the new body to a temp file and apply with `gh issue edit <number> --body-file <temp-file>`, then delete the temp file115 - Keep the Issue open (do not close). It can be passed directly to `/impl #<number>`1164. **Local mode**: Report summary (file path list)117118## Rules119120- Never guess unknowns; always confirm with user121- **Always use `AskUserQuestion` with options for questions.** Never ask via text alone122- Max 4 questions per round123- Include reference ideas in each option's `description`124- When appending to existing specs, prioritize reuse/modification of existing features125- Always add revision history when updating documents126- Track progress with TaskCreate/TaskUpdate127- **If an existing spec directory is found, use those paths — not the defaults (`docs/`). Never create new subdirectories when existing ones already serve the same purpose**128- **When updating existing files, use Edit to modify them in place. Never create duplicate files in a different location**