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.4---56**Language: Always interact with the user in 日本語.**78# spec-gen-en910Actively discuss with the user to resolve unknowns, presenting reference ideas to solidify specifications.1112## Prerequisites1314- Claude Code environment15- `gh` CLI (for GitHub Issue mode)1617## Arguments1819- No arguments: Create a full set of design documents for a new project20- Path specified: Append/update to an existing specification document2122## Documents to Generate (Default Paths)2324| Document | Default File | Content |25|----------|------|---------|26| **Functional requirements** | `docs/requirements/functional.md` | Use cases, feature list, screen/operation flows |27| **Non-functional requirements** | `docs/requirements/non-functional.md` | Performance, security, availability, scalability |28| **Architecture design** | `docs/architecture/overview.md` | Overall structure, tech stack, layer architecture, communication flows |29| **ER / Data model** | `docs/architecture/er.md` | Overall ER diagram, per-table ER diagrams, table definitions, constraints, indexes |30| **API specification** | `docs/api/endpoints.md` | Endpoints, request/response, auth, errors |31| **Component design** | `docs/components/overview.md` | Component breakdown, responsibilities, dependencies, interfaces |3233- **These are default paths. If an existing spec directory is found, use that instead (see "Discovery" below)**3435## Phase 1: Assess Current State and Decide Direction3637#### 1-0: Discover Existing Specs (Required — Run First)3839**If a path is specified as argument:**40- Read the file/directory at that path directly41- Also check related files in the same directory4243**If no argument:**44Search for existing specs using Glob:45```46**/spec/**/*.md47**/specs/**/*.md48**/docs/**/*.md49**/specifications/**/*.md50**/design/**/*.md51```5253**Based on discovery results:**54- **Existing specs found**: Record the directory structure and file paths as the base map. Place new documents within this structure. Do NOT use default paths55- **No specs found**: Use default paths (`docs/` subtree)5657**Important: Always Read discovered spec files to understand current specifications before proceeding.**5859#### Output Destination6061Confirm with `AskUserQuestion`:62- **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 end63- **Local only**: Work on current branch without creating Issues or branches6465#### For New Projects661. Interview about overview, purpose, and background672. Present similar projects and tech stack direction683. Agree on document scope694. **GitHub Issue mode**: Record base branch -> **create placeholder Issue** -> create `feat/#<issue-number>` branch -> add branch name to Issue70 - **Issue title must be `feat: <feature-name>`** (the feature to implement). Never use document-centric titles like "Create design documents"71 - **Body is a placeholder at this point** (e.g., `仕様策定中(spec-gen 実行中)。完了後に実装内容を追記する。`). Phase 3 rewrites it as the implementation Issue72 - 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 target735. Create tasks with TaskCreate7475#### For Appending to Existing Specs761. **Using 1-0 discovery results**, Read all existing spec files to understand current specifications772. Interview about additions783. Present existing feature reuse/change proposals794. Agree on direction805. **GitHub Issue mode**: Same as above (Issue title describes the feature to add; body is a placeholder)816. Create tasks with TaskCreate8283## Phase 2: Document Creation Cycle (repeat per document)8485#### 2-1: Interview86- Gather information needed for the document in **a single `AskUserQuestion` call**87- Include pros/cons and reference ideas in option `description` fields8889#### 2-2: Write90- Create based on interview results. Use Mermaid for diagrams (see `references/mermaid-guide.md`)91- Include revision history (see format at end of `references/mermaid-guide.md`)9293#### 2-3: Review94- Present to user and confirm with `AskUserQuestion` (include "No issues" option)9596#### 2-4: Improvement Cycle97- If feedback -> revise -> update revision history -> re-confirm -> repeat until satisfied9899#### 2-5: Format & Lint100- Run if settings exist. Skip otherwise101102#### 2-6: Commit103- Commit following CLAUDE.md conventions104105## Phase 3: Finalize and Push1061071. Confirm all documents are complete1082. Cross-document consistency check (ER vs API, components vs functional requirements, etc.)1093. **GitHub Issue mode**: Push -> **rewrite the Issue body as the implementation Issue** -> report summary (including Issue URL)110 - Replace the placeholder body of the Issue created in Phase 1 with the implementation Issue contents, following `templates/impl-issue.md`111 - Include: 概要 (overview), spec file links to consult during implementation, 受け入れ条件 (acceptance criteria), base branch112 - Acceptance criteria must be extracted from the spec docs as concrete completion conditions (avoid vague "implement it")113 - Write the new body to a temp file and apply with `gh issue edit <number> --body-file <temp-file>`, then delete the temp file114 - Keep the Issue open (do not close). It can be passed directly to `/impl #<number>`1154. **Local mode**: Report summary (file path list)116117## Rules118119- Never guess unknowns; always confirm with user120- **Always use `AskUserQuestion` with options for questions.** Never ask via text alone121- Max 4 questions per round122- Include reference ideas in each option's `description`123- When appending to existing specs, prioritize reuse/modification of existing features124- Always add revision history when updating documents125- Track progress with TaskCreate/TaskUpdate126- **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**127- **When updating existing files, use Edit to modify them in place. Never create duplicate files in a different location**