spec-rules-init

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

spec-rules-init — Coding Rules Generator

spec-rules-init —— 编码规则生成工具

Extract project conventions and generate a unified

coding-rules.md

for use as a quality gate during implementation.

提取项目规范并生成统一的

coding-rules.md

文件，作为实施阶段的质量门禁使用。

Language Rules

语言规则

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

自动检测输入语言 → 输出与输入语言保持一致
日文输入 → 日文输出，使用
```
references/rules-template.ja.md
```
模板
英文输入 → 英文输出，使用
```
references/rules-template.md
```
模板
显式指定优先级更高（例如："in English"、"日本語で"）

Execution Flow

执行流程

Step 0: Initial Context Check

步骤0：初始上下文检查

BEFORE any interaction, execute these checks:

Check current directory:
bash
```
pwd
ls -la
```

Detect convention files (parallel where possible):

bash

# Convention files
ls CLAUDE.md src/CLAUDE.md AGENTS.md test/CLAUDE.md 2>/dev/null
ls -d .claude/ 2>/dev/null

# Config files
ls package.json go.mod requirements.txt Cargo.toml 2>/dev/null
ls .eslintrc* biome.json tsconfig.json .prettierrc* 2>/dev/null

Detect existing source code:

bash

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

Scan installed skills:

bash

ls ~/.claude/skills/*/SKILL.md .claude/skills/*/SKILL.md 2>/dev/null

Check for existing coding-rules.md:

bash

find . -name "coding-rules.md" -type f 2>/dev/null

在任何交互之前，执行以下检查：

检查当前目录:
bash
```
pwd
ls -la
```

检测规范文件（尽可能并行执行）:

bash

# 规范文件
ls CLAUDE.md src/CLAUDE.md AGENTS.md test/CLAUDE.md 2>/dev/null
ls -d .claude/ 2>/dev/null

# 配置文件
ls package.json go.mod requirements.txt Cargo.toml 2>/dev/null
ls .eslintrc* biome.json tsconfig.json .prettierrc* 2>/dev/null

检测现有源代码:

bash

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

扫描已安装的Skill:

bash

ls ~/.claude/skills/*/SKILL.md .claude/skills/*/SKILL.md 2>/dev/null

检查是否存在现有coding-rules.md:

bash

find . -name "coding-rules.md" -type f 2>/dev/null

Step 1: Rule Extraction from Convention Files

步骤1：从规范文件中提取规则

Read detected convention files and extract rules by category.

Detection targets (by priority):

File	Content to Extract	Priority
`CLAUDE.md` (root)	Project-wide rules	High
`src/CLAUDE.md`	Source-specific rules	High
`AGENTS.md`	Agent-oriented rules	High
`.claude/` contents	Project settings	Medium
`package.json`	lint/test script presence	Medium
`test/CLAUDE.md`	Test-specific rules	Medium
`.eslintrc*` / `biome.json`	Lint rules	Low
`tsconfig.json`	TypeScript strict settings	Low
`.prettierrc*`	Format settings	Low

Extraction categories and keywords:

Testing Standards: "coverage", "test", "spec", "E2E", "カバレッジ", "テスト"
Code Quality: "lint", "typecheck", "strict", "import", "naming", "命名"
Error Handling: "try/catch", "Logger", "error", "throw", "例外"
Documentation: "JSDoc", "TSDoc", "@ApiProperty", "comment", "コメント"
Security: "secret", "password", "hash", "HTTPS", "ログに出力しない"
Git: "commit", "branch", "コミットメッセージ", "feature branch"

For each extracted rule, record:

Category (one of the 6 above)
Content (the rule text)
Severity:
```
[MUST]
```
(explicit requirement),
```
[SHOULD]
```
(recommended),
```
[MAY]
```
(optional)
Source file and line reference

Rules from CLAUDE.md / AGENTS.md are Priority 1 and default to

[MUST]

读取检测到的规范文件，按类别提取规则。

检测目标（按优先级排序）:

文件	提取内容	优先级
根目录 `CLAUDE.md`	项目级规则	高
`src/CLAUDE.md`	源码专属规则	高
`AGENTS.md`	Agent相关规则	高
`.claude/` 目录内容	项目设置	中
`package.json`	lint/测试脚本存在性	中
`test/CLAUDE.md`	测试专属规则	中
`.eslintrc*` / `biome.json`	代码检查规则	低
`tsconfig.json`	TypeScript严格模式设置	低
`.prettierrc*`	格式化设置	低

提取类别及关键词:

测试标准: "coverage"、"test"、"spec"、"E2E"、"カバレッジ"、"テスト"
代码质量: "lint"、"typecheck"、"strict"、"import"、"naming"、"命名"
错误处理: "try/catch"、"Logger"、"error"、"throw"、"例外"
文档规范: "JSDoc"、"TSDoc"、"@ApiProperty"、"comment"、"コメント"
安全规范: "secret"、"password"、"hash"、"HTTPS"、"ログに出力しない"
Git规范: "commit"、"branch"、"コミットメッセージ"、"feature branch"

对于每条提取的规则，记录以下信息:

类别（上述6类之一）
内容（规则文本）
严重程度:
```
[MUST]
```
（明确要求）、
```
[SHOULD]
```
（推荐）、
```
[MAY]
```
（可选）
源文件及行号引用

来自CLAUDE.md / AGENTS.md的规则为优先级1，默认标记为

[MUST]

。

Step 2: Codebase Analysis

步骤2：代码库分析

If source code exists, analyze the codebase to detect implicit conventions. Skip this step entirely if no source files are found (new project).

2a. Directory structure analysis:

Scan directory tree (up to 3 levels deep)
Detect patterns: feature-based (
```
modules/{feature}/
```
), layer-based (
```
controllers/
```
,
```
services/
```
), co-located tests vs separate
```
tests/
```
directory

2b. File naming convention detection:

Collect file names under
```
src/
```
(or primary source directory)
Classify each name: kebab-case, camelCase, PascalCase, snake_case
If one pattern is 60%+ of files → propose as
```
[MUST]
```
Minority patterns → propose as
```
[SHOULD]
```
for unification

2c. Library analysis:

Read dependency file (
```
package.json
```
,
```
go.mod
```
,
```
requirements.txt
```
, etc.)
Identify major libraries:
- Frameworks: NestJS, Next.js, Express, Fastify, Django, Flask, Gin, etc.
- Testing: Jest, Vitest, Playwright, pytest, etc.
- Validation: Zod, class-validator, Joi, etc.
- ORM: Prisma, TypeORM, Drizzle, SQLAlchemy, GORM, etc.
- Linters: ESLint, Biome, ruff, golint, etc.
Add library-specific best practice recommendations as
```
[SHOULD]
```
rules
- Example: Prisma detected →
```
[SHOULD] Use Prisma Client for all DB access
```
- Example: Zod detected →
```
[SHOULD] Use Zod for runtime validation
```

2d. Code pattern analysis (if code intelligence tools are available):

Import style: relative (
```
./
```
) vs path alias (
```
@/
```
)
Export style: named exports vs default exports
Error handling patterns in use

2e. Shared utility and library detection:

Scan the codebase for shared utility modules, helper functions, and internal libraries:
- Look for directories named
```
utils/
```
  ,
```
helpers/
```
  ,
```
lib/
```
  ,
```
shared/
```
  ,
```
common/
```
- Identify frequently imported internal modules
Cross-reference with dependency file to identify commonly used libraries

Present a summary of detected shared utilities and libraries to the user:

Detected shared utilities and libraries:
  Internal: utils/logger.ts, lib/validation.ts, helpers/date.ts
  External: Zod (validation), Prisma (DB), date-fns (dates)

For each detected shared utility or library, generate a

[SHOULD]

rule:

Example:

[SHOULD] Use lib/validation.ts for input validation

Example:
```
[SHOULD] Use Zod for runtime validation
```

Example:

[SHOULD] Use utils/logger.ts instead of console.log

Include the detected list in the generated coding-rules.md under a "Shared Utilities" section

Codebase analysis results are Priority 2 and assigned

[MUST]

(for 60%+ majority patterns) or

[SHOULD]

如果存在源代码，分析代码库以检测隐含规范。如果未找到源文件（新项目），则完全跳过此步骤。

2a. 目录结构分析:

扫描目录树（最多3层深度）
检测模式：基于功能的结构（
```
modules/{feature}/
```
）、基于分层的结构（
```
controllers/
```
、
```
services/
```
）、测试与代码同目录 vs 独立
```
tests/
```
目录

2b. 文件命名规范检测:

收集
```
src/
```
（或主源码目录）下的文件名
对每个名称进行分类：kebab-case、camelCase、PascalCase、snake_case
如果某一模式占比60%以上 → 提议标记为
```
[MUST]
```
少数派模式 → 提议标记为
```
[SHOULD]
```
以统一规范

2c. 依赖库分析:

读取依赖文件（
```
package.json
```
、
```
go.mod
```
、
```
requirements.txt
```
等）
识别主要依赖库:
- 框架：NestJS、Next.js、Express、Fastify、Django、Flask、Gin等
- 测试工具：Jest、Vitest、Playwright、pytest等
- 验证工具：Zod、class-validator、Joi等
- ORM：Prisma、TypeORM、Drizzle、SQLAlchemy、GORM等
- 代码检查工具：ESLint、Biome、ruff、golint等
添加库专属的最佳实践建议，标记为
```
[SHOULD]
```
规则
- 示例：检测到Prisma →
```
[SHOULD] 所有数据库访问使用Prisma Client
```
- 示例：检测到Zod →
```
[SHOULD] 使用Zod进行运行时验证
```

2d. 代码模式分析（如果代码智能工具可用）:

导入风格：相对路径（
```
./
```
）vs 路径别名（
```
@/
```
）
导出风格：命名导出 vs 默认导出
当前使用的错误处理模式

2e. 共享工具与依赖库检测:

扫描代码库中的共享工具模块、辅助函数及内部依赖库:
- 查找名为
```
utils/
```
  、
```
helpers/
```
  、
```
lib/
```
  、
```
shared/
```
  、
```
common/
```
  的目录
- 识别频繁导入的内部模块
与依赖文件交叉对比，识别常用外部依赖库

向用户展示检测到的共享工具与依赖库摘要:

检测到的共享工具与依赖库:
  内部: utils/logger.ts, lib/validation.ts, helpers/date.ts
  外部: Zod（验证）, Prisma（数据库）, date-fns（日期处理）

为每个检测到的共享工具或依赖库生成

[SHOULD]

规则:

示例:

[SHOULD] 使用lib/validation.ts进行输入验证

示例:
```
[SHOULD] 使用Zod进行运行时验证
```

示例:

[SHOULD] 使用utils/logger.ts替代console.log

在生成的coding-rules.md的「共享工具」章节中包含检测到的列表

代码库分析结果为优先级2，标记为

[MUST]

（占比60%以上的多数模式）或

[SHOULD]

。

Step 3: Installed Skills Analysis

步骤3：已安装Skill分析

Scan installed skills for framework-specific best practices.

3a. Skill detection:

Scan
```
~/.claude/skills/
```
(global skills)
Scan
```
.claude/skills/
```
(project skills)
Read each
```
SKILL.md
```
frontmatter description and body

3b. Framework match: Compare detected project tech stack (from Steps 1-2) with skill keywords:

Project Tech	Matching Keywords
Next.js	`next` , `next.js` , `vercel` , `react` , `RSC` , `server component`
NestJS	`nest` , `nestjs` , `express` , `fastify` , `typescript backend`
React	`react` , `hooks` , `component` , `jsx` , `tsx`
Go	`go` , `golang` , `goroutine`
Python	`python` , `django` , `flask` , `fastapi`

3c. User confirmation (if matching skills found):

Use AskUserQuestion:

question: "The following installed skills were detected. Use them for rule extraction?" / "以下のインストール済みスキルが検出されました。ルール抽出に使用しますか？"
header: "Skills"
multiSelect: true
options:
  - "{skill-name} — {description} (Recommended)" / "{skill-name} — {説明}"

3d. Priority mapping:

Skill-derived rules are Priority 3 →
```
[SHOULD]
```
or
```
[MAY]
```
If a skill rule contradicts Priority 1 or 2 rules → keep higher priority, show warning
Record source as
```
Source: skill/{skill-name}
```
in coding-rules.md

3e. No matching skills: If no matching skills are installed, optionally inform the user:

"Matching skills may be available on skills.sh for your tech stack.
Install and re-run to incorporate best practices."
/ "技術スタックに適合するスキルが skills.sh にある可能性があります。
インストール後に再実行すると、ベストプラクティスを取り込めます。"

扫描已安装的Skill，提取框架专属的最佳实践。

3a. Skill检测:

扫描
```
~/.claude/skills/
```
（全局Skill）
扫描
```
.claude/skills/
```
（项目Skill）
读取每个
```
SKILL.md
```
的前置描述与正文内容

3b. 框架匹配: 将检测到的项目技术栈（来自步骤1-2）与Skill关键词进行匹配:

项目技术栈	匹配关键词
Next.js	`next` , `next.js` , `vercel` , `react` , `RSC` , `server component`
NestJS	`nest` , `nestjs` , `express` , `fastify` , `typescript backend`
React	`react` , `hooks` , `component` , `jsx` , `tsx`
Go	`go` , `golang` , `goroutine`
Python	`python` , `django` , `flask` , `fastapi`

3c. 用户确认（如果找到匹配的Skill）:

使用AskUserQuestion:

question: "检测到以下已安装的Skill。是否用于规则提取？" / "以下のインストール済みスキルが検出されました。ルール抽出に使用しますか？"
header: "Skill列表"
multiSelect: true
options:
  - "{skill-name} — {description} (推荐)" / "{skill-name} — {説明}"

3d. 优先级映射:

从Skill提取的规则为优先级3 → 标记为
```
[SHOULD]
```
或
```
[MAY]
```
如果Skill规则与优先级1或2的规则冲突 → 保留更高优先级规则，并显示警告
在coding-rules.md中记录来源为
```
Source: skill/{skill-name}
```

3e. 无匹配Skill: 如果未安装匹配的Skill，可选择性告知用户:

"你的技术栈对应的匹配Skill可能在skills.sh上可用。
安装后重新运行即可整合最佳实践。"
/ "技術スタックに適合するスキルが skills.sh にある可能性があります。
インストール後に再実行すると、ベストプラクティスを取り込めます。"

Step 4: Interactive Dialogue

步骤4：交互式对话

4a. Present extraction results:

Display detected rules summary by category:

Extraction Results:
  Testing Standards:    {n} rules
  Code Quality:         {n} rules
  Error Handling:       {n} rules
  Documentation:        {n} rules
  Security:             {n} rules
  Git:                  {n} rules
  Total:                {total} rules (Priority 1: {n}, Priority 2: {n}, Priority 3: {n})

If any category has 0 rules, highlight it for user attention.

4b. Output path selection (AskUserQuestion):

question: "Where to save coding-rules.md?" / "coding-rules.md の出力先は？"
header: "Output"
options:
  - "docs/coding-rules.md (Recommended)" / "docs/coding-rules.md（推奨）"
  - "docs/development/coding-rules.md"

If user selects "Other", accept any valid file path.

4c. Rule supplementation (AskUserQuestion):

For categories with missing or insufficient rules, ask targeted questions:

question: "Any additional testing rules?" / "テスト基準について追加ルールはありますか？"
header: "Testing"
options:
  - "Require 80%+ coverage (Recommended)" / "カバレッジ80%以上を必須にする"
  - "Specify E2E test patterns" / "E2Eテストパターンを指定する"
  - "No additions needed" / "追加不要"

question: "Commit message language?" / "コミットメッセージの言語は？"
header: "Git"
options:
  - "Japanese only" / "日本語のみ"
  - "English only" / "英語のみ"
  - "Conventional Commits (English)" / "Conventional Commits（英語）"

Suggest project-type-specific rules based on detected frameworks. Refer to the Project-Type Recommendations section in the reference template.

4a. 展示提取结果:

按类别显示检测到的规则摘要:

提取结果:
  测试标准:    {n} 条规则
  代码质量:    {n} 条规则
  错误处理:    {n} 条规则
  文档规范:    {n} 条规则
  安全规范:    {n} 条规则
  Git规范:     {n} 条规则
  总计:        {total} 条规则（优先级1: {n}, 优先级2: {n}, 优先级3: {n}）

如果任何类别规则数量为0，高亮显示以引起用户注意。

4b. 输出路径选择（AskUserQuestion）:

question: "coding-rules.md保存到哪里？" / "coding-rules.md の出力先は？"
header: "输出设置"
options:
  - "docs/coding-rules.md (推荐)" / "docs/coding-rules.md（推奨）"
  - "docs/development/coding-rules.md"

如果用户选择“其他”，接受任何有效的文件路径。

4c. 规则补充（AskUserQuestion）:

对于规则缺失或不足的类别，提出针对性问题:

question: "是否需要添加额外的测试规则？" / "テスト基準について追加ルールはありますか？"
header: "测试标准补充"
options:
  - "要求80%+覆盖率 (推荐)" / "カバレッジ80%以上を必須にする"
  - "指定E2E测试模式" / "E2Eテストパターンを指定する"
  - "无需添加" / "追加不要"

question: "提交信息使用哪种语言？" / "コミットメッセージの言語は？"
header: "Git规范补充"
options:
  - "仅日文" / "日本語のみ"
  - "仅英文" / "英語のみ"
  - "Conventional Commits（英文）" / "Conventional Commits（英語）"

根据检测到的框架，建议项目类型专属规则。参考参考模板中的「项目类型推荐」章节。

Step 5: Existing File Detection and Idempotency

步骤5：现有文件检测与幂等性

If an existing

coding-rules.md

was found in Step 0:

Read the existing file
Compare with newly extracted rules (additions, changes, removals)

Use AskUserQuestion:

question: "Existing coding-rules.md found. How to proceed?" / "既存の coding-rules.md が見つかりました。どうしますか？"
header: "Existing File"
options:
  - "Overwrite" / "上書きする"
  - "Merge differences" / "差分のみマージ"
  - "Cancel" / "キャンセル"

If "Cancel" → exit without changes

如果在步骤0中找到现有的

coding-rules.md

读取现有文件
与新提取的规则进行对比（新增、修改、删除）

使用AskUserQuestion:

question: "找到现有coding-rules.md文件。如何处理？" / "既存の coding-rules.md が見つかりました。どうしますか？"
header: "现有文件处理"
options:
  - "覆盖" / "上書きする"
  - "仅合并差异" / "差分のみマージ"
  - "取消" / "キャンセル"

如果选择“取消” → 不做任何修改直接退出

Step 6: Generate coding-rules.md

步骤6：生成coding-rules.md

Load the appropriate reference template (based on Language Rules)
Fill in extracted rules by category
Apply severity tags:
```
[MUST]
```
,
```
[SHOULD]
```
,
```
[MAY]
```
Add source attribution for each rule
Include the Sources summary table at the end
Create output directory if it does not exist
Write the file

加载对应的参考模板（根据语言规则）
按类别填充提取的规则
应用严重程度标签:
```
[MUST]
```
、
```
[SHOULD]
```
、
```
[MAY]
```
为每条规则添加来源归因
在末尾添加来源汇总表
如果输出目录不存在则创建
写入文件

Step 7: Update AGENTS.md / CLAUDE.md References

步骤7：更新AGENTS.md / CLAUDE.md引用

After generating coding-rules.md, append a reference to project convention files.

Procedure:

Check if
```
AGENTS.md
```
exists at project root
Check if
```
CLAUDE.md
```
exists (skip if it is a symlink to AGENTS.md)

Use AskUserQuestion:

question: "Add reference to coding-rules.md in AGENTS.md / CLAUDE.md?" / "AGENTS.md / CLAUDE.md に coding-rules.md の参照を追記しますか？"
header: "Update"
options:
  - "Yes, add reference (Recommended)" / "はい、追記する（推奨）"
  - "No, skip" / "いいえ、スキップ"

If approved, append to the end of each file (or after an existing "Coding Rules" section):

English version:

markdown

## Coding Rules

Follow the coding rules in this file during implementation:
- [{output_path}]({output_path}) — Quality rules generated by spec-rules-init

Japanese version:

markdown

## コーディングルール

実装時のコーディングルールは以下のファイルに従ってください:
- [{output_path}]({output_path}) — spec-rules-init で生成された品質ルール集

If neither file exists → skip with a warning message:

"Warning: No AGENTS.md or CLAUDE.md found. Skipping reference update."
/ "警告: AGENTS.md も CLAUDE.md も見つかりません。参照追記をスキップします。"

生成coding-rules.md后，在项目规范文件中追加引用。

操作流程:

检查项目根目录是否存在
```
AGENTS.md
```
检查是否存在
```
CLAUDE.md
```
（如果是AGENTS.md的符号链接则跳过）

使用AskUserQuestion:

question: "在AGENTS.md / CLAUDE.md中添加coding-rules.md的引用？" / "AGENTS.md / CLAUDE.md に coding-rules.md の参照を追記しますか？"
header: "引用更新"
options:
  - "是，添加引用 (推荐)" / "はい、追記する（推奨）"
  - "否，跳过" / "いいえ、スキップ"

如果用户同意，追加到每个文件的末尾（或现有「编码规则」章节之后）:

英文版本:

markdown

## Coding Rules

实施期间请遵循本文件中的编码规则:
- [{output_path}]({output_path}) — spec-rules-init生成的质量规则集

日文版本:

markdown

## コーディングルール

実装時のコーディングルールは以下のファイルに従ってください:
- [{output_path}]({output_path}) — spec-rules-init で生成された品質ルール集

如果两个文件都不存在 → 跳过并显示警告消息:

"警告：未找到AGENTS.md或CLAUDE.md文件。跳过引用更新。"
/ "警告: AGENTS.md も CLAUDE.md も見つかりません。参照追記をスキップします。"

Step 8: spec-series Integration Notice

步骤8：Spec系列工具集成通知

After completing generation, inform the user about integration with other spec-series skills:

"coding-rules.md has been generated. The following spec-series skills now reference it:
- spec-generator: Uses coding-rules.md as design constraints during the design phase
- spec-inspect: Checks [MUST] rules in Check 13 (Project Rule Compliance)
- spec-implement: Uses coding-rules.md as a quality gate during implementation"
/ "coding-rules.md を生成しました。以下の spec-series スキルが参照するようになっています:
- spec-generator: design フェーズで coding-rules.md を設計制約として使用
- spec-inspect: Check 13（プロジェクトルール準拠）で [MUST] ルールをチェック
- spec-implement: 実装時の品質ゲートとして coding-rules.md を使用"

完成生成后，告知用户与其他spec系列Skill的集成情况:

"已生成coding-rules.md文件。以下spec系列Skill现在会引用它:
- spec-generator: 在设计阶段将coding-rules.md作为设计约束
- spec-inspect: 在检查13（项目规则合规性）中检查[MUST]规则
- spec-implement: 在实施阶段将coding-rules.md作为质量门禁"
/ "coding-rules.md を生成しました。以下の spec-series スキルが参照するようになっています:
- spec-generator: design フェーズで coding-rules.md を設計制約として使用
- spec-inspect: Check 13（プロジェクトルール準拠）で [MUST] ルールをチェック
- spec-implement: 実装時の品質ゲートとして coding-rules.md を使用"

Options

选项

Option	Description
`--force`	Overwrite existing coding-rules.md without confirmation
`--category <name>`	Generate rules for a specific category only (e.g., `--category testing` )

选项	描述
`--force`	无需确认直接覆盖现有coding-rules.md
`--category <name>`	仅生成特定类别的规则（例如： `--category testing` ）

Error Handling

错误处理

Convention file unreadable: Warn and skip the file, continue with remaining files

"Warning: Could not read {filename}. Skipping."
/ "警告: {filename} を読み取れません。スキップします。"

Output directory does not exist: Create it automatically
bash
```
mkdir -p {output_directory}
```

Write permission denied: Show error and suggest an alternative path

"Error: Cannot write to {path}. Try a different location."
/ "エラー: {path} に書き込めません。別のパスを指定してください。"

No convention files found: Fall back to dialogue-only mode

"No convention files (CLAUDE.md, AGENTS.md, etc.) found. Proceeding with dialogue-only mode."
/ "規約ファイル（CLAUDE.md, AGENTS.md等）が見つかりません。対話のみモードで進みます。"

规范文件无法读取: 发出警告并跳过该文件，继续处理剩余文件

"警告：无法读取{filename}文件。已跳过。"
/ "警告: {filename} を読み取れません。スキップします。"

输出目录不存在: 自动创建目录
bash
```
mkdir -p {output_directory}
```

写入权限被拒绝: 显示错误并建议替代路径

"错误：无法写入到{path}。请尝试其他位置。"
/ "エラー: {path} に書き込めません。別のパスを指定してください。"

未找到规范文件: 回退到仅对话模式

"未找到规范文件（CLAUDE.md、AGENTS.md等）。将以仅对话模式继续。"
/ "規約ファイル（CLAUDE.md, AGENTS.md等）が見つかりません。対話のみモードで進みます。"

Usage Examples

使用示例

undefined

undefined

Generate coding rules from project conventions

从项目规范生成编码规则

"Generate coding rules" 「コーディングルールを生成して」

Create coding-rules.md with forced overwrite

强制覆盖创建coding-rules.md

"Create coding-rules.md --force" 「coding-rules.md を作成 --force」

Extract rules for a specific category

提取特定类别的规则

"Extract project rules --category testing" 「テストルールだけ抽出して」

After generating, re-run to update

生成后重新运行以更新

"Update coding-rules.md" 「coding-rules.md を更新して」

undefined

"Update coding-rules.md" 「coding-rules.md を更新して」

undefined

Post-Completion Actions

完成后操作

After generating coding-rules.md, suggest next actions with AskUserQuestion:

question: "coding-rules.md generated. What's next?" / "coding-rules.md を生成しました。次のアクションは？"
header: "Next"
options:
  - "Generate specifications (spec-generator)" / "仕様書を生成する（spec-generator）"
  - "Set up development workflow (spec-workflow-init)" / "開発ワークフローを設定する（spec-workflow-init）"
  - "Done for now" / "完了"

生成coding-rules.md后，使用AskUserQuestion建议后续操作:

question: "已生成coding-rules.md。下一步操作？" / "coding-rules.md を生成しました。次のアクションは？"
header: "后续步骤"
options:
  - "生成规格文档 (spec-generator)" / "仕様書を生成する（spec-generator）"
  - "设置开发工作流 (spec-workflow-init)" / "開発ワークフローを設定する（spec-workflow-init）"
  - "暂时完成" / "完了"