spec-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Spec Generator

规格文档生成器

Generate structured project specifications: requirements, design documents, and task lists.

生成结构化项目规格文档：需求文档、设计文档和任务列表。

⚠️ CRITICAL: First Steps (ALWAYS EXECUTE)

⚠️ 重要提示：初始步骤（必须执行）

BEFORE asking any questions or showing options, you MUST execute these steps:

Check current directory:
- Run
```
pwd
```
  to see where you are
- Run
```
ls -la
```
  to see directory contents
- Understand the project context
Detect existing source code:
bash
```
find . -maxdepth 3 -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.go" -o -name "SKILL.md" \) 2>/dev/null | head -20
```
- Note what kind of project this is
- Check for
```
skills/
```
  directory → might be adding a new skill
- Check for existing application code → might be documenting existing features
Check for .specs/ directory:
bash
```
ls -d .specs/ 2>/dev/null && ls -1 .specs/ 2>/dev/null
```
- If exists → list existing projects
- If not exists → this is a new spec workflow
Check for coding-rules.md:
- Check
```
docs/coding-rules.md
```
  (default path)
- If not found, check CLAUDE.md / AGENTS.md for alternative path
- If found → load and use as design constraint during design phase
Analyze context and decide:
- If in a skills repository (has
```
skills/
```
  directory) → User likely wants to document a new skill
- If .specs/ has projects → Ask user to select existing or create new
- If no .specs/ and no clear context → Ask what they want to create

Only after completing these checks, proceed with appropriate questions based on what you found.

在提出任何问题或展示选项之前，必须执行以下步骤：

检查当前目录:
- 执行
```
pwd
```
  查看当前位置
- 执行
```
ls -la
```
  查看目录内容
- 了解项目上下文

检测现有源代码:

bash

find . -maxdepth 3 -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.go" -o -name "SKILL.md" \) 2>/dev/null | head -20

记录项目类型
检查是否存在
```
skills/
```
目录 → 可能需要添加新Skill
检查是否存在现有应用代码 → 可能需要为现有功能编写文档

检查 .specs/ 目录:
bash
```
ls -d .specs/ 2>/dev/null && ls -1 .specs/ 2>/dev/null
```
- 若存在 → 列出现有项目
- 若不存在 → 这是新的规格生成流程
检查 coding-rules.md:
- 检查默认路径
```
docs/coding-rules.md
```
- 若未找到，检查 CLAUDE.md / AGENTS.md 寻找替代路径
- 若找到 → 在设计阶段加载并将其作为设计约束
分析上下文并决策:
- 若处于Skill仓库（存在
```
skills/
```
  目录）→ 用户可能需要为新Skill编写文档
- 若 .specs/ 中有项目 → 询问用户选择现有项目还是创建新项目
- 若没有 .specs/ 且上下文不明确 → 询问用户想要创建什么文档

仅在完成上述检查后，根据发现的信息提出合适的问题。

Language Rules

语言规则

Auto-detect input language → output in the same language
Japanese input → Japanese output, use
```
references/*.ja.md
```
as phase references
English input → English output, use
```
references/*.md
```
as phase references
Explicit override takes priority (e.g., "in English", "日本語で")

Reference file selection: Based on the detected output language, use the corresponding reference files:

English →

references/init.md

references/design.md

references/tasks.md

Japanese →

references/init.ja.md

references/design.ja.md

references/tasks.ja.md

自动检测输入语言 → 输出与输入语言一致
日语输入 → 日语输出，使用
```
references/*.ja.md
```
作为阶段参考
英语输入 → 英语输出，使用
```
references/*.md
```
作为阶段参考
显式优先级覆盖（例如 "in English", "日本語で"）

参考文件选择：根据检测到的输出语言，使用对应的参考文件:

英语 →

references/init.md

references/design.md

references/tasks.md

日语 →

references/init.ja.md

references/design.ja.md

references/tasks.ja.md

Phases

阶段

Phase	Output	Trigger Examples
init	requirement.md	"Create requirements", "要件定義を作って"
design	design.md	"Create design doc", "設計書を作って"
tasks	tasks.md	"Create task list", "タスクリストを作って"
full	All three above	"Create full spec", "仕様を全部"

阶段	输出	触发示例
init	requirement.md	"Create requirements", "要件定義を作って"
design	design.md	"Create design doc", "設計書を作って"
tasks	tasks.md	"Create task list", "タスクリストを作って"
full	上述全部三个文档	"Create full spec", "仕様を全部"

Interaction Policy: AskUserQuestion

交互策略：AskUserQuestion

Use AskUserQuestion for all user decisions. Present structured choices rather than free-form questions.

所有用户决策均使用AskUserQuestion。提供结构化选项而非开放式问题。

Decision Flow

决策流程

Skill Invoked
    ↓
Check .specs/ directory
    ↓
┌───────────────────┐
│ Existing projects │
│ found?            │
└─────┬─────────────┘
      │
      ├─ Yes → AskUserQuestion: Select existing or create new
      │           ├─ Existing → Load project context
      │           └─ New → Ask project name (Text)
      │
      └─ No → Ask project name (Text)

    ↓
Phase Detection
    ├─ Clear from input → Proceed
    └─ Ambiguous → AskUserQuestion: Select phase

    ↓
Dialogue Mode
    ├─ Quick mode (--quick) → Generate directly
    └─ Dialogue → AskUserQuestion: Gather requirements

    ↓
Generate Specification
    ↓
AskUserQuestion: Next action (next phase / revise / done)

Skill被调用
    ↓
检查 .specs/ 目录
    ↓
┌───────────────────┐
│ 是否找到现有项目 │
└─────┬─────────────┘
      │
      ├─ 是 → AskUserQuestion: 选择现有项目或创建新项目
      │           ├─ 现有项目 → 加载项目上下文
      │           └─ 新项目 → 询问项目名称（文本输入）
      │
      └─ 否 → 询问项目名称（文本输入）

    ↓
阶段检测
    ├─ 输入明确 → 继续执行
    └─ 输入模糊 → AskUserQuestion: 选择阶段

    ↓
对话模式
    ├─ 快速模式 (--quick) → 直接生成
    └─ 对话模式 → AskUserQuestion: 收集需求

    ↓
生成规格文档
    ↓
AskUserQuestion: 选择下一步操作（进入下一阶段 / 修改 / 完成）

When to Use AskUserQuestion vs Text Questions

AskUserQuestion与文本问题的使用场景

Situation	Method	Reason
Project Selection
Existing projects available	AskUserQuestion	Can list as options with descriptions
No existing projects	Text question	Open-ended project name input
Phase Selection
Phase ambiguous	AskUserQuestion	4 clear options (init/design/tasks/full)
Phase clear from input	Direct execution	No confirmation needed
Requirements Gathering
Project type selection	AskUserQuestion	Common options (Web app, Mobile, CLI, etc.)
Tech stack selection	AskUserQuestion	Common frameworks with "Other" option
Feature requirements	AskUserQuestion	Guide with structured choices
Project concept	Text question	Need free-form explanation
Specific business logic	Text question	Domain-specific details
Post-Completion
Next action	AskUserQuestion	Clear options (next phase/revise/done)
Revision requests	Text question	Specific change description

场景	方法	原因
项目选择
存在现有项目	AskUserQuestion	可列出带描述的选项
无现有项目	文本问题	需要开放式项目名称输入
阶段选择
阶段模糊	AskUserQuestion	有4个明确选项（init/design/tasks/full）
阶段明确	直接执行	无需确认
需求收集
项目类型选择	AskUserQuestion	常见选项（Web应用、移动应用、CLI等）
技术栈选择	AskUserQuestion	常见框架+“其他”选项
功能需求	AskUserQuestion	提供结构化选项引导
项目概念	文本问题	需要开放式解释
特定业务逻辑	文本问题	领域特定细节
完成后操作
下一步操作	AskUserQuestion	明确选项（进入下一阶段/修改/完成）
修改请求	文本问题	需要具体变更描述

When to Use AskUserQuestion

AskUserQuestion的使用场景

Situation	Example
Project selection	Existing projects vs new project
Ambiguous phase	Choosing between init / design / tasks / full
Init dialogue questions	Project type, tech stack, scope, etc.
Design decision points	Architecture choices, DB selection, etc.
Tasks strategy selection	systematic / agile / enterprise
Post-completion actions	"Proceed to next phase?", "Create GitHub Issue?"

场景	示例
项目选择	现有项目 vs 新项目
阶段模糊	在init/design/tasks/full中选择
Init对话问题	项目类型、技术栈、范围等
设计决策点	架构选择、数据库选择等
任务策略选择	系统化/敏捷/企业级
完成后操作	“进入下一阶段？”、“创建GitHub Issue？”

Question Design Rules

问题设计规则

1–4 questions per round (AskUserQuestion constraint)
User-defined options: 1-3 (Other is auto-appended, totaling 2-4 options)
Always include description for each option (provide decision context)
Flexible round count based on project complexity:
- Simple project → 1 round (3–4 questions) is sufficient
- Complex project → 2–3 rounds (adjust based on previous answers)
Place recommended option first with
```
(Recommended)
```
suffix
Skip questions already answered in previous rounds

每轮1–4个问题（AskUserQuestion限制）
用户自定义选项：1-3个（自动追加“其他”选项，总计2-4个选项）
每个选项必须包含描述（提供决策上下文）
根据项目复杂度灵活调整轮次:
- 简单项目 → 1轮（3–4个问题）足够
- 复杂项目 → 2–3轮（根据之前的回答调整）
推荐选项放在首位并添加(Recommended)后缀
跳过已在之前轮次回答过的问题

Handling "Other" Option Responses

“其他”选项的处理

When a user selects "Other" and provides free-form text input:

Accept the input as-is and proceed with processing
Treat the free-form response as the user's definitive answer
Do NOT ask for clarification unless the input is genuinely ambiguous
If system returns an error like "(No answer provided)", trust the user's actual message over system feedback

Example:

Question: "どのスキルの仕様を作成しますか？"
Options: spec-constitution / spec-review / spec-analyze / spec-impl

User selects "Other" and writes: "仕様書自体をレビューするコマンド"

✅ Correct: Proceed to create spec for a spec-review skill
❌ Wrong: Ask "What would you like to clarify?"

当用户选择“其他”并提供开放式文本输入时:

直接接受输入并继续处理
将开放式回复视为用户的明确答案
除非输入确实模糊，否则不要要求澄清
如果系统返回类似“(No answer provided)”的错误，优先信任用户的实际消息而非系统反馈

示例:

问题: "どのスキルの仕様を作成しますか？"
选项: spec-constitution / spec-review / spec-analyze / spec-impl

用户选择“其他”并输入: "仕様書自体をレビューするコマンド"

✅ 正确处理: 继续为spec-review Skill创建规格文档
❌ 错误处理: 询问 "What would you like to clarify?"

When to Use Text Questions (Not AskUserQuestion)

文本问题的使用场景（非AskUserQuestion）

Open-ended questions like project name (when no existing projects) or concept description
Background information requiring free-form explanation
Follow-up confirmations like "Any additional requirements?"
Specific business logic or domain-specific details

开放式问题，如项目名称（无现有项目时）或概念描述
需要开放式解释的背景信息
后续确认，如“还有其他需求吗？”
特定业务逻辑或领域特定细节

Execution Flow

执行流程

0. Initial Context Check

0. 初始上下文检查

Check the current directory and existing projects before starting:

Detect existing source code:

bash

find . -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.go" \) | head -20

If source files found: Note for potential
```
--analyze
```
mode
If no source files: Standard new project flow

Check for .specs/ directory:
bash
```
ls -d .specs/ 2>/dev/null
```
List existing projects (if .specs/ exists):
bash
```
ls -1 .specs/
```

Project selection:

Existing projects found: Use AskUserQuestion:

question: "既存プロジェクトが見つかりました。どうしますか？" / "Found existing projects. What would you like to do?"
options:
  - "既存プロジェクトを選択 / Select existing project" → List projects as options
  - "新規プロジェクトを作成 / Create new project" → Ask project name

No existing projects: Ask for project name (text question):

"プロジェクト名を教えてください（例: TODOアプリ、株価分析ツール）"
"What's the project name? (e.g., todo app, stock analyzer)"

Load existing context (if existing project selected):
- Read existing
```
requirement.md
```
  ,
```
design.md
```
  ,
```
tasks.md
```
  if they exist
- Use as context for updates or next phase generation

开始前检查当前目录和现有项目:

检测现有源代码:

bash

find . -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.go" \) | head -20

若找到源文件: 记录以支持潜在的
```
--analyze
```
模式
若无源文件: 标准新项目流程

检查 .specs/ 目录:
bash
```
ls -d .specs/ 2>/dev/null
```
列出现有项目（若 .specs/ 存在）:
bash
```
ls -1 .specs/
```

项目选择:

找到现有项目: 使用AskUserQuestion:

question: "既存プロジェクトが見つかりました。どうしますか？" / "Found existing projects. What would you like to do?"
options:
  - "既存プロジェクトを選択 / Select existing project" → 列出项目作为选项
  - "新規プロジェクトを作成 / Create new project" → 询问项目名称

无现有项目: 询问项目名称（文本问题）:

"プロジェクト名を教えてください（例: TODOアプリ、株価分析ツール）"
"What's the project name? (e.g., todo app, stock analyzer)"

加载现有上下文（若选择现有项目）:
- 读取现有
```
requirement.md
```
  ,
```
design.md
```
  ,
```
tasks.md
```
  （若存在）
- 将其作为更新或下一阶段生成的上下文

1. Phase Detection

1. 阶段检测

Determine the phase from the user's request:

"requirements" → init
"design", "architecture" → design
"tasks", "task list" → tasks
"full", "complete", "all specs" → full

If ambiguous, confirm with AskUserQuestion:

question: "Which specification do you want to generate?"
options:
  - "Requirements document (requirement.md)" → init
  - "Design document (design.md)" → design
  - "Task list (tasks.md)" → tasks
  - "All three documents" → full

从用户请求中确定阶段:

"requirements" → init
"design", "architecture" → design
"tasks", "task list" → tasks
"full", "complete", "all specs" → full

若模糊不清，使用AskUserQuestion确认:

question: "Which specification do you want to generate?"
options:
  - "Requirements document (requirement.md)" → init
  - "Design document (design.md)" → design
  - "Task list (tasks.md)" → tasks
  - "All three documents" → full

2. Project Context Gathering

2. 项目上下文收集

Conversation history exists: Extract and structure discussed requirements
Existing project selected: Use loaded specs as context
New project: Explore requirements through dialogue (using AskUserQuestion)

存在对话历史: 提取并整理已讨论的需求
选择现有项目: 使用加载的规格文档作为上下文
新项目: 通过对话收集需求（使用AskUserQuestion）

3. Phase Execution

3. 阶段执行

Refer to the appropriate reference file (based on Language Rules):

init:
```
references/init.md
```
/
```
references/init.ja.md
```
— Requirements generation

design:

references/design.md

references/design.ja.md

— Design document generation

design (with coding-rules.md): If
```
docs/coding-rules.md
```
exists, read it and ensure:
- Naming conventions in design match
```
[MUST]
```
  naming rules
- Test strategy satisfies coverage requirements from coding-rules
- Technology choices align with recommended libraries
- File/directory structure follows detected patterns
- Skill-derived
```
[SHOULD]
```
  rules (e.g., framework-specific conventions from
```
Source: skill/*
```
  ) are considered as design recommendations

tasks:

references/tasks.md

references/tasks.ja.md

— Task list generation

参考对应语言的参考文件（根据语言规则）:

init:
```
references/init.md
```
/
```
references/init.ja.md
```
— 生成需求文档

design:

references/design.md

references/design.ja.md

— 生成设计文档

design（存在coding-rules.md时）: 若
```
docs/coding-rules.md
```
存在，读取并确保:
- 设计中的命名规范符合
```
[MUST]
```
  命名规则
- 测试策略满足coding-rules中的覆盖率要求
- 技术选择与推荐库一致
- 文件/目录结构遵循检测到的模式
- Skill衍生的
```
[SHOULD]
```
  规则（如来自
```
Source: skill/*
```
  的框架特定约定）作为设计建议

tasks:

references/tasks.md

references/tasks.ja.md

— 生成任务列表

4. Output Directory

4. 输出目录

.specs/[project-name]/
├── requirement.md  (init)
├── design.md       (design)
└── tasks.md        (tasks)

Project names are converted to English kebab-case:

"TODO app" →
```
todo-app
```
"株価分析ツール" →
```
stock-analysis-tool
```
"Stock analysis tool" →
```
stock-analysis-tool
```

.specs/[project-name]/
├── requirement.md  (init)
├── design.md       (design)
└── tasks.md        (tasks)

项目名称转换为英文短横线格式:

"TODO app" →
```
todo-app
```
"株価分析ツール" →
```
stock-analysis-tool
```
"Stock analysis tool" →
```
stock-analysis-tool
```

Options

选项

Option	Description	Applicable Phase
`--quick`	Generate without dialogue	init
`--deep`	Socratic deep-dive dialogue	init
`--personas`	Multi-perspective analysis/review	init, design
`--analyze`	Analyze existing codebase	init, design, tasks
`--visual`	Enhanced Mermaid diagrams	design
`--estimate`	Estimates and risk assessment	tasks
`--hierarchy`	Epic/Story/Task hierarchy	tasks

选项	描述	适用阶段
`--quick`	无需对话直接生成	init
`--deep`	苏格拉底式深度对话	init
`--personas`	多视角分析/评审	init, design
`--analyze`	分析现有代码库	init, design, tasks
`--visual`	增强型Mermaid图	design
`--estimate`	估算与风险评估	tasks
`--hierarchy`	Epic/Story/Task层级结构	tasks

Execution Modes

执行模式

Dialogue Mode (default)

对话模式（默认）

When invoked without parameters or continuing from conversation:

Collect necessary information through questions
Clarify requirements through user interaction
Generate specification after confirmation

无参数调用或从对话继续时:

通过问题收集必要信息
通过用户交互澄清需求
确认后生成规格文档

Quick Mode (--quick)

快速模式 (--quick)

Generate from a brief project description:

Infer typical requirements from the description
Generate based on best practices
Complete without dialogue

通过简短项目描述生成:

从描述中推断典型需求
基于最佳实践生成
无需对话直接完成

Full Workflow (full)

完整工作流 (full)

Generate all three documents sequentially:

Generate requirement.md
Read requirement.md → generate design.md
Read design.md → generate tasks.md

按顺序生成全部三个文档:

生成 requirement.md
读取 requirement.md → 生成 design.md
读取 design.md → 生成 tasks.md

Requirement ID System

需求ID体系

Specifications use the following ID prefixes:

```
[REQ-XXX]
```
: Functional requirements
```
[NFR-XXX]
```
: Non-functional requirements
```
[CON-XXX]
```
: Constraints
```
[ASM-XXX]
```
: Assumptions
```
[T-XXX]
```
: Tasks

These IDs ensure traceability across documents.

规格文档使用以下ID前缀:

```
[REQ-XXX]
```
: 功能需求
```
[NFR-XXX]
```
: 非功能需求
```
[CON-XXX]
```
: 约束条件
```
[ASM-XXX]
```
: 假设条件
```
[T-XXX]
```
: 任务

这些ID确保文档间的可追溯性。

YAGNI Principle

YAGNI原则

Do not include unless explicitly requested or discussed:

除非明确要求或讨论过，否则不要包含以下内容:

❌ Authentication & Authorization

❌ 认证与授权

Complex permission management (when basic auth suffices)
Role-based access control with multiple roles (admin/user is usually enough)
Social login integration (when basic email/password auth is sufficient)
Fine-grained permission systems

复杂权限管理（基础认证足够时）
多角色的基于角色的访问控制（通常admin/user足够）
社交登录集成（基础邮箱/密码认证足够时）
细粒度权限系统

❌ Analytics & Monitoring

❌ 分析与监控

Advanced analytics/reporting dashboards
Detailed audit logging (unless compliance requirements exist)
Real-time metrics and monitoring
User behavior tracking
A/B testing infrastructure

高级分析/报告仪表盘
详细审计日志（除非有合规要求）
实时指标与监控
用户行为追踪
A/B测试基础设施

❌ Infrastructure & Scalability

❌ 基础设施与可扩展性

Multi-tenant support (unless explicitly required)
API versioning (unless external integration requirements exist)
Async processing (unless performance requirements demand it)
Batch processing/scheduled jobs (unless specified)
Auto-scaling infrastructure
Load balancing configuration

多租户支持（除非明确要求）
API版本控制（除非有外部集成需求）
异步处理（除非性能要求需要）
批处理/定时任务（除非指定）
自动扩缩容基础设施
负载均衡配置

❌ User Experience

❌ 用户体验

Real-time notifications/updates (unless explicitly required)
Advanced search/filtering (when basic search suffices)
Data export features (PDF, Excel, etc.)
Offline mode support
Push notifications

实时通知/更新（除非明确要求）
高级搜索/过滤（基础搜索足够时）
数据导出功能（PDF、Excel等）
离线模式支持
推送通知

❌ Development & Operations

❌ 开发与运维

Data migration plans (for brand new projects)
Multi-language/i18n support (unless specified)
Admin dashboards (when simple CRUD interfaces suffice)
Complex deployment pipelines
Automated backup systems

数据迁移计划（全新项目）
多语言/i18n支持（除非指定）
管理后台（简单CRUD界面足够时）
复杂部署流水线
自动备份系统

✅ Include by Default

✅ 默认包含

Basic authentication (email/password)
Simple CRUD operations
Basic error handling and validation
Essential security (HTTPS, password hashing, input sanitization)
Core business logic only
Simple, clear user interfaces
Basic data persistence

When in doubt: Ask via AskUserQuestion rather than assuming the feature is needed.

基础认证（邮箱/密码）
简单CRUD操作
基础错误处理与验证
基本安全措施（HTTPS、密码哈希、输入清理）
仅核心业务逻辑
简洁清晰的用户界面
基础数据持久化

存疑时: 使用AskUserQuestion询问，而非假设需要该功能。

Optional Enhancements

可选增强功能

When advanced analysis tools are available in your environment, consider using them for:

Systematic analysis of complex, interconnected requirements
Framework-specific best practices and pattern lookup
Existing codebase semantic analysis and symbol navigation
UI/UX pattern recommendations

当环境中存在高级分析工具时，可考虑用于:

复杂关联需求的系统分析
框架特定最佳实践与模式查找
现有代码库的语义分析与符号导航
UI/UX模式推荐

Post-Completion Actions

完成后操作

After each phase, suggest next actions with AskUserQuestion:

After init:

question: "Requirements document generated. What's next?"
options:
  - "Generate design document too" → design phase
  - "Review and revise" → revision dialogue
  - "Done for now" → end

After design:

question: "Design document generated. What's next?"
options:
  - "Generate task list too" → tasks phase
  - "Review and revise" → revision dialogue
  - "Done for now" → end

After tasks:

question: "Task list generated. What's next?"
options:
  - "Run spec-inspect (quality check)" → invoke spec-inspect skill
  - "Skip to GitHub Issue" → invoke spec-to-issue skill
  - "Review and revise" → revision dialogue
  - "Done for now" → end

After full:

question: "All three spec documents are complete."
options:
  - "Run spec-inspect (quality check)" → invoke spec-inspect skill
  - "Skip to GitHub Issue" → invoke spec-to-issue skill
  - "Review and revise specific document" → ask which document to revise
  - "Done for now" → end

每个阶段完成后，使用AskUserQuestion建议下一步操作:

init阶段完成后:

question: "Requirements document generated. What's next?"
options:
  - "Generate design document too" → 进入design阶段
  - "Review and revise" → 进入修改对话
  - "Done for now" → 结束

design阶段完成后:

question: "Design document generated. What's next?"
options:
  - "Generate task list too" → 进入tasks阶段
  - "Review and revise" → 进入修改对话
  - "Done for now" → 结束

tasks阶段完成后:

question: "Task list generated. What's next?"
options:
  - "Run spec-inspect (quality check)" → 调用spec-inspect Skill
  - "Skip to GitHub Issue" → 调用spec-to-issue Skill
  - "Review and revise" → 进入修改对话
  - "Done for now" → 结束

full阶段完成后:

question: "All three spec documents are complete."
options:
  - "Run spec-inspect (quality check)" → 调用spec-inspect Skill
  - "Skip to GitHub Issue" → 调用spec-to-issue Skill
  - "Review and revise specific document" → 询问要修改的文档
  - "Done for now" → 结束

Usage Examples

使用示例

undefined

undefined

New project - dialogue mode

新项目 - 对话模式

"Create requirements for a todo app" "要件定義を作って" → detects existing projects, asks to select or create new

"Create requirements for a todo app" "要件定義を作って" → 检测现有项目，询问选择现有项目或创建新项目

Existing project - update/add phases

现有项目 - 更新/添加阶段

"Create design document for todo-app" → uses existing requirement.md as context 「todo-appのタスクリストを作って」 → uses existing design.md as context

"Create design document for todo-app" → 使用现有requirement.md作为上下文「todo-appのタスクリストを作って」 → 使用现有design.md作为上下文

Full specification

完整规格文档

"Create full spec for an e-commerce platform" 「ECサイトの仕様を全部作って」

Requirements from conversation

从对话生成需求

"Turn this into a requirements document" → structures previous discussion

"Turn this into a requirements document" → 整理之前的讨论内容

Quick mode

快速模式

"Create requirements for a blog platform --quick"

Analysis mode

分析模式

"Create requirements --analyze" → analyzes existing codebase first

undefined

"Create requirements --analyze" → 先分析现有代码库

undefined