@superspec/cli 1.0.0 → 1.1.1

package/templates/en/commands/ss-create.md

@@ -2,18 +2,101 @@
 name: /ss-create
 id: ss-create
 category: SuperSpec
-description: Create a new change with proposal (boost mode adds spec + checklist)
+description: Create or update the feature specification from a natural language feature with proposal (boost mode adds spec + checklist)
 ---
 <!-- SUPERSPEC:START -->
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+The text the user typed after `/ss-create` **is** the feature description. Do not ask the user to repeat it unless they provided an empty command.
+
 **Guardrails**
-- Read `superspec.config.json` first to get `lang`, `specDir`, `boost`, `strategy`, `context`
-- Check existing changes in `{specDir}/changes/` to avoid duplicates
-- Never create change folders manually — use `superspec create <name>` CLI
+- Read `superspec.config.json` first → get `lang`, `specDir`, `boost`, `strategy`, `context`, `branchPrefix`, `branchTemplate`, `changeNameTemplate`
+- **Pre-task review** (refer to AGENTS.md "Before ANY Task"):
+  - Read `context` files, README, architecture docs
+  - Inspect `{specDir}/changes/` → avoid duplicate changes via `depends_on`
+- Never create change folders manually — use `superspec create <feature>` CLI
 - Do not write any code during the proposal stage. Only create design documents
 
+**Input Parsing Rules**
+
+From user input, extract: **mode flags**, **feature name**, **intent type**, **developer**, **lang**.
+
+| Extract | Rule | Example |
+|---------|------|---------|
+| Mode flags | Detect `-b`/`--boost`/`boost` → boost mode; `-c`/`--creative`/`creative` → creative mode; `--no-branch` → skip branch; flags can be combined | `/ss-create -b add auth` → boost; `/ss-create -b -c refactor login` → boost+creative |
+| Feature name | Remove flags from input, convert remainder to camelCase. Chinese → translate to English first | "add user auth" → `addUserAuth`; "添加用户认证" → `addUserAuth` |
+| Intent type | Semantic inference from input | add/new/implement → `feature`; fix/bug/hotfix → `hotfix`; refactor/optimize → `refactor`; docs → `docs`; test → `test`; build/deps → `chore`; default → `feature` |
+| Developer | "@username" or "Developer: xxx" → extract (remove "@"). Fallback: git user name | "添加todolist @jay" → user=`jay` |
+| Lang | CJK chars → `zh`; explicit "zh"/"中文" → `zh`; "en"/"English" → `en`; fallback: config `lang` | "添加todolist" → `zh` |
+
+**Naming Templates**
+
+Config supports custom templates with variables `{date}`, `{feature}`, `{user}`, `{intentType}`, `{prefix}`:
+- `branchTemplate` (default: `{intentType}-{date}-{feature}-{user}`)
+- `changeNameTemplate` (default: `{intentType}-{date}-{feature}-{user}`)
+
+```bash
+# "添加todolist @jay" → feature=addTodolist, user=jay, intentType=feature, lang=zh
+superspec create addTodolist --intent-type feature --lang zh
+# Branch: feature-20260212-addTodolist-jay
+
+# "fix login bug" → feature=fixLoginBug, intentType=hotfix, user=<git username>
+superspec create fixLoginBug --intent-type hotfix
+# Branch: hotfix-20260212-fixLoginBug-gitusername
+```
+
+If user provides custom `--branch-prefix`, prepend to template.
+
+**CLI Command Structure**
+```bash
+superspec create <feature> [options]
+  -b, --boost                          Boost mode (spec + checklist)
+  -c, --creative                       Creative mode (explore new solutions)
+  -d, --description <desc>             Change description
+  --no-branch                          Skip git branch creation
+  --spec-dir <dir>                     Custom spec folder
+  --branch-prefix <prefix>             Custom branch prefix
+  --branch-template <template>         Override branch name template
+  --change-name-template <template>    Override folder name template
+  --intent-type <type>                 Intent type (feature, hotfix, bugfix, refactor, chore)
+  --feature <feature>                  Feature name
+  --user <user>                        Developer identifier
+  --lang <lang>                        SDD Document Language (en, zh)
+```
+
+**When to use design.md** (optional, boost mode):
+- Solution spans multiple systems or introduces new architectural patterns
+- Major architectural decisions with significant trade-offs
+- Cross-team architecture alignment needed
+
+**Spec Capability Splitting** (recommended for large changes):
+When a change involves multiple independent capabilities, split by domain:
+```
+{specDir}/changes/<name>/
+├── proposal.md
+├── design.md      (optional)
+├── specs/
+│   ├── auth/spec.md
+│   ├── api/spec.md
+│   └── ui/spec.md
+├── tasks.md
+└── checklist.md
+```
+Each spec.md < 300 lines. Outline domains in proposal.md, group tasks by domain in tasks.md.
+
 **Steps**
-1. Run `superspec create <name> [-b] [-c] [-d <description>]` to scaffold the change
-2. If boost mode (-b), also generate spec.md and checklist.md
-3. Read the generated proposal.md and understand the change scope
-4. Wait for user confirmation before proceeding to /ss-tasks
+1. Parse user input → extract feature (camelCase), intent type, developer, lang
+2. Run: `superspec create <feature> --intent-type <type> [--lang <lang>] [--user <user>]`
+3. Pre-task review: read project context, check existing changes, understand dependencies
+4. Assess complexity: if multiple independent capability domains → consider splitting spec
+5. Read generated proposal.md → understand scope; if design.md needed → clarify architectural decisions
+6. Wait for user confirmation before proceeding to /ss-tasks
 <!-- SUPERSPEC:END -->

package/templates/en/commands/ss-link.md

@@ -5,7 +5,17 @@ category: SuperSpec
 description: Add spec dependency
 ---
 <!-- SUPERSPEC:START -->
+**Input Parsing Rules**
+
+From user input, extract: **change name**, **dependency target**.
+
+| Extract | Rule | Example |
+|---------|------|---------|
+| Change name | First argument or text before `--on` | `/ss-link addAuth --on addDB` → name=`addAuth` |
+| Dependency target | `--on <other>`/`depends on <other>`/`→ <other>` → extract target name | `/ss-link addAuth --on addDB`; `/ss-link addAuth depends on addDB` |
+
 **Steps**
-1. Run `superspec link <name> --depends-on <other>`
-2. This updates the frontmatter: `depends_on: [other]`
+1. Parse user input → extract change name and dependency target
+2. Run `superspec deps add <name> --on <other>`
+3. Verify: `superspec deps list <name>`
 <!-- SUPERSPEC:END -->

package/templates/en/commands/ss-search.md

@@ -5,8 +5,17 @@ category: SuperSpec
 description: Full-text search across changes
 ---
 <!-- SUPERSPEC:START -->
+**Input Parsing Rules**
+
+From user input, extract: **search query**, **optional flags**.
+
+| Extract | Rule | Example |
+|---------|------|---------|
+| Search query | Remaining text after removing flags | `/ss-search user auth` → query=`user auth` |
+| Include archived | `--archived`/`archived`/`include archived`/`all` → add `--archived` | `/ss-search auth --archived`; `/ss-search auth archived` |
+| Filter type | `--artifact <type>`/`type:<type>` → add `--artifact <type>`; type: `proposal`/`spec`/`tasks`/`clarify`/`checklist` | `/ss-search auth --artifact spec`; `/ss-search auth type:proposal` |
+
 **Steps**
-1. Run `superspec search <query>`
-2. Use `--archived` to include archived changes
-3. Use `--artifact <type>` to filter by artifact type
+1. Parse user input → extract search query and flags
+2. Run `superspec search "<query>" [--archived] [--artifact <type>]`
 <!-- SUPERSPEC:END -->

package/templates/en/commands/ss-specs.md

@@ -0,0 +1,54 @@
+---
+name: /ss-specs
+id: ss-specs
+category: SuperSpec
+description: Create multi-capability spec structure for large changes
+---
+<!-- SUPERSPEC:START -->
+**Purpose**
+When spec.md may exceed 300 lines due to multiple independent capability domains, split into capability-specific spec files.
+
+**When to Split**
+- Change spans multiple system modules (e.g., auth + API + UI)
+- Single spec.md expected to exceed 300 lines
+- Need parallel development of independent capabilities
+
+**When NOT to Split**
+- Single module change or spec.md < 200 lines
+- Capabilities are tightly coupled
+- Rapid prototyping or experimental changes
+
+**Capability Domain Types**
+`auth` (authentication/authorization) · `api` (REST/GraphQL) · `ui` (frontend) · `data` (models/schema) · `workflow` (business processes) · `integration` (external systems) · `infra` (deployment)
+
+**Spec Template**
+```markdown
+---
+name: <name>-<capability>
+status: draft
+strategy: {{strategy}}
+depends_on: []
+capability: <capability-name>
+---
+# Spec: <name> - <Capability>
+
+## Capability Scope
+## User Stories
+### US-<capability>-1: [Title]
+## Functional Requirements
+### FR-<capability>-1: [Title]
+## Cross-Capability Dependencies
+- Depends on `auth/spec.md` FR-auth-2
+- Provides API-1 for `ui/spec.md`
+## Edge Cases
+```
+
+**ID Convention**: `US-<cap>-<n>`, `FR-<cap>-<n>`, `AC-<cap>-<n>.<sub>`
+
+**Steps**
+1. Identify 2-5 independent capability domains in proposal.md
+2. Create `specs/<capability>/spec.md` for each, using template above
+3. Document splitting rationale in design.md
+4. Group tasks by capability in tasks.md
+5. Validate: clear boundaries, explicit dependencies, each spec < 300 lines, IDs follow convention
+<!-- SUPERSPEC:END -->

package/templates/en/commands/ss-validate.md

@@ -5,11 +5,21 @@ category: SuperSpec
 description: Cross-reference consistency check (boost mode)
 ---
 <!-- SUPERSPEC:START -->
+**Input Parsing Rules**
+
+From user input, extract: **change name**, **optional flags**.
+
+| Extract | Rule | Example |
+|---------|------|---------|
+| Change name | Remaining text after removing flags; if empty, use current active change | `/ss-validate addUserAuth` → name=`addUserAuth` |
+| Check deps | `--check-deps`/`check deps`/`dependencies` → add `--check-deps` | `/ss-validate --check-deps`; `/ss-validate check deps` |
+
 **Guardrails**
 - Validate US↔FR↔AC↔tasks consistency
 - Only applicable in boost mode
 
 **Steps**
-1. Run `superspec validate [name]`
-2. Fix any consistency errors reported
+1. Parse user input → extract change name and flags
+2. Run `superspec validate [name] [--check-deps]`
+3. Fix any consistency errors reported
 <!-- SUPERSPEC:END -->

package/templates/en/design.md

@@ -0,0 +1,126 @@
+---
+name: {{name}}
+status: draft
+strategy: {{strategy}}
+depends_on: []
+---
+
+# Architecture Design: {{name}}
+
+> Created: {{date}}
+
+## Design Goals
+
+<!-- Describe the core objectives of this architectural design -->
+
+## System Scope
+
+<!-- Define system/module boundaries affected by this change -->
+
+- **Affected Systems**:
+- **Affected Modules**:
+- **Out of Scope**:
+
+## Architecture Decisions
+
+### Decision 1: [Decision Title]
+
+**Context**: Why is this decision needed?
+
+**Options Considered**:
+- **Option A**: [Description]
+  - Pros:
+  - Cons:
+- **Option B**: [Description]
+  - Pros:
+  - Cons:
+
+**Decision**: [Chosen option]
+
+**Rationale**: [Why this option was chosen]
+
+### Decision 2: [Decision Title]
+
+**Context**:
+
+**Options Considered**:
+- **Option A**:
+- **Option B**:
+
+**Decision**:
+
+**Rationale**:
+
+## Architecture Diagram
+
+<!-- Use mermaid or text to describe key architecture -->
+
+```mermaid
+graph TD
+    A[Component A] --> B[Component B]
+    B --> C[Component C]
+```
+
+## Data Flow
+
+<!-- Describe critical data flow paths -->
+
+1. User Request →
+2. Processing Layer →
+3. Storage Layer →
+4. Response
+
+## Technology Stack
+
+<!-- If introducing new technologies, explain rationale -->
+
+| Technology | Version | Purpose | Rationale |
+|------------|---------|---------|-----------|
+| |  |  |  |
+
+## Performance Impact
+
+- **Expected Performance Changes**:
+- **Potential Bottlenecks**:
+- **Optimization Strategies**:
+
+## Security Considerations
+
+- **Authentication**:
+- **Authorization**:
+- **Data Encryption**:
+- **Audit Logging**:
+
+## Scalability Considerations
+
+- **Horizontal Scaling**:
+- **Vertical Scaling**:
+- **Future Evolution Path**:
+
+## Migration Strategy
+
+<!-- If major architectural changes, describe migration steps -->
+
+1. **Phase 1**:
+2. **Phase 2**:
+3. **Phase 3**:
+
+**Rollback Plan**:
+
+## Risks & Mitigation
+
+| Risk | Impact | Probability | Mitigation |
+|------|--------|-------------|------------|
+| | | | |
+
+## Dependencies
+
+<!-- Dependencies of this architectural design -->
+
+- **Dependent Changes**:
+- **External System Dependencies**:
+- **Dependents**:
+
+---
+
+**Status**: 🟡 Draft

package/templates/zh/commands/ss-archive.md

@@ -5,11 +5,21 @@ category: SuperSpec
 description: 归档已完成的变更
 ---
 <!-- SUPERSPEC:START -->
+**输入解析规则**
+
+从用户输入中提取：**变更名称**或**全部标志**。
+
+| 提取项 | 规则 | 示例 |
+|--------|------|------|
+| 变更名称 | 移除标志后的剩余文本；为空时使用当前活跃变更 | `/ss-archive addUserAuth` → name=`addUserAuth` |
+| 归档全部 | `--all`/`全部`/`所有` → 添加 `--all` | `/ss-archive --all`; `/ss-archive 全部` |
+
 **Guardrails**
 - 只有所有任务都 COMPLETE 后才能归档
 - 归档前确保测试通过
 
 **Steps**
-1. 确认 tasks.md 中所有任务都标记为 COMPLETE
-2. 运行 `superspec archive <name>` 或 `superspec archive --all`
+1. 解析用户输入 → 提取变更名称或 `--all` 标志
+2. 确认 tasks.md 中所有任务都标记为 COMPLETE
+3. 运行 `superspec archive <name>` 或 `superspec archive --all`
 <!-- SUPERSPEC:END -->

package/templates/zh/commands/ss-create.md

@@ -2,18 +2,101 @@
 name: /ss-create
 id: ss-create
 category: SuperSpec
-description: 创建变更 + 生成 proposal（boost 模式额外生成 spec + checklist）
+description: 创建变更 + 生成 proposal（boost 模式额外生成 spec + design(当你需要) + checklist）
 ---
 <!-- SUPERSPEC:START -->
+## 用户输入
+
+```text
+$ARGUMENTS
+```
+
+你**必须**在继续之前考虑用户输入（如果非空）。
+
+## 概述
+
+用户在 `/ss-create` 后输入的文本**就是**功能描述。除非用户提供了空命令，否则不要要求用户重复输入。
+
 **Guardrails**
-- 首先读取 `superspec.config.json` 获取 `lang`, `specDir`, `boost`, `strategy`, `context`
-- 检查 `{specDir}/changes/` 中现有变更，避免重复
-- 永远不要手动创建变更文件夹 —— 使用 `superspec create <name>` CLI
+- 首先读取 `superspec.config.json` → 获取 `lang`, `specDir`, `boost`, `strategy`, `context`, `branchPrefix`, `branchTemplate`, `changeNameTemplate`
+- **执行前置审查**（参考 AGENTS.md "Before ANY Task"）:
+  - 读取 `context` 文件、README、架构文档
+  - 查看 `{specDir}/changes/` → 通过 `depends_on` 避免重复变更
+- 永远不要手动创建变更文件夹 —— 使用 `superspec create <feature>` CLI
 - 在提案阶段不要编写任何代码，只创建设计文档
 
+**输入解析规则**
+
+从用户输入中提取：**模式标志**、**功能名称**、**意图类型**、**开发者**、**语言**。
+
+| 提取项 | 规则 | 示例 |
+|--------|------|------|
+| 模式标志 | 识别 `-b`/`--boost`/`boost`/`增强` → 增强模式; `-c`/`--creative`/`creative`/`创造` → 创造模式; `--no-branch`/`不建分支` → 跳过分支; 可组合使用 | `/ss-create -b 添加认证` → boost; `/ss-create -b -c 重构登录` → boost+creative |
+| 功能名称 | 移除标志后剩余文本，转为 camelCase。中文 → 先翻译为英文 | "add user auth" → `addUserAuth`; "添加用户认证" → `addUserAuth` |
+| 意图类型 | 语义推断 | add/new/implement/新增/添加 → `feature`; fix/bug/hotfix/修复 → `hotfix`; refactor/optimize/重构 → `refactor`; docs → `docs`; test → `test`; build/deps → `chore`; 默认 → `feature` |
+| 开发者 | "@username" 或 "Developer: xxx" → 提取（移除"@"）。回退: git 用户名 | "添加todolist @jay" → user=`jay` |
+| 语言 | CJK 字符 → `zh`; 显式 "zh"/"中文" → `zh`; "en"/"English" → `en`; 回退: 配置 `lang` | "添加todolist" → `zh` |
+
+**命名模板**
+
+配置支持使用变量 `{date}`, `{feature}`, `{user}`, `{intentType}`, `{prefix}` 的自定义模板:
+- `branchTemplate`（默认: `{intentType}-{date}-{feature}-{user}`）
+- `changeNameTemplate`（默认: `{intentType}-{date}-{feature}-{user}`）
+
+```bash
+# "添加todolist @jay" → feature=addTodolist, user=jay, intentType=feature, lang=zh
+superspec create addTodolist --intent-type feature --lang zh
+# 分支: feature-20260212-addTodolist-jay
+
+# "fix login bug" → feature=fixLoginBug, intentType=hotfix, user=<git用户名>
+superspec create fixLoginBug --intent-type hotfix
+# 分支: hotfix-20260212-fixLoginBug-gitusername
+```
+
+如果用户提供自定义 `--branch-prefix`，添加到模板前面。
+
+**CLI 命令结构**
+```bash
+superspec create <feature> [options]
+  -b, --boost                          增强模式（spec + checklist）
+  -c, --creative                       创造模式（探索新方案）
+  -d, --description <desc>             变更描述
+  --no-branch                          跳过 git 分支创建
+  --spec-dir <dir>                     自定义 spec 文件夹
+  --branch-prefix <prefix>             自定义分支前缀
+  --branch-template <template>         覆盖分支名模板
+  --change-name-template <template>    覆盖文件夹名模板
+  --intent-type <type>                 意图类型（feature, hotfix, bugfix, refactor, chore）
+  --feature <feature>                  功能名称
+  --user <user>                        开发者标识
+  --lang <lang>                        SDD 文档语言（en, zh）
+```
+
+**何时使用 design.md**（boost 模式可选）:
+- 方案跨越多个系统或引入新架构模式
+- 重大架构决策且有显著权衡
+- 需要跨团队架构对齐
+
+**Spec 能力域拆分**（推荐用于大型变更）:
+当变更涉及多个独立能力时，按能力域拆分:
+```
+{specDir}/changes/<name>/
+├── proposal.md
+├── design.md      （可选）
+├── specs/
+│   ├── auth/spec.md
+│   ├── api/spec.md
+│   └── ui/spec.md
+├── tasks.md
+└── checklist.md
+```
+每个 spec.md < 300 行。在 proposal.md 中概述能力域，tasks.md 按能力域分组。
+
 **Steps**
-1. 运行 `superspec create <name> [-b] [-c] [-d <description>]` 创建变更结构
-2. 如果是 boost 模式 (-b)，额外生成 spec.md 和 checklist.md
-3. 读取生成的 proposal.md 理解变更范围
-4. 等待用户确认后再继续 /ss-tasks
+1. 解析用户输入 → 提取功能名（camelCase）、意图类型、开发者、语言
+2. 执行: `superspec create <feature> --intent-type <type> [--lang <lang>] [--user <user>]`
+3. 前置审查: 读取项目上下文、检查现有变更、理解依赖关系
+4. 评估复杂度: 如涉及多个独立能力域 → 考虑拆分 spec
+5. 读取生成的 proposal.md → 理解范围; 如需 design.md → 明确架构决策
+6. 等待用户确认后再继续 /ss-tasks
 <!-- SUPERSPEC:END -->

package/templates/zh/commands/ss-link.md

@@ -5,7 +5,17 @@ category: SuperSpec
 description: 添加 spec 依赖
 ---
 <!-- SUPERSPEC:START -->
+**输入解析规则**
+
+从用户输入中提取：**变更名称**、**依赖目标**。
+
+| 提取项 | 规则 | 示例 |
+|--------|------|------|
+| 变更名称 | 第一个参数或 `--on` 之前的文本 | `/ss-link addAuth --on addDB` → name=`addAuth` |
+| 依赖目标 | `--on <other>`/`依赖 <other>`/`→ <other>` → 提取目标名 | `/ss-link addAuth --on addDB`; `/ss-link addAuth 依赖 addDB` |
+
 **Steps**
-1. 运行 `superspec link <name> --depends-on <other>`
-2. 这会更新 frontmatter: `depends_on: [other]`
+1. 解析用户输入 → 提取变更名称和依赖目标
+2. 运行 `superspec deps add <name> --on <other>`
+3. 验证: `superspec deps list <name>`
 <!-- SUPERSPEC:END -->

package/templates/zh/commands/ss-search.md

@@ -5,8 +5,17 @@ category: SuperSpec
 description: 全文搜索变更
 ---
 <!-- SUPERSPEC:START -->
+**输入解析规则**
+
+从用户输入中提取：**搜索关键词**、**可选标志**。
+
+| 提取项 | 规则 | 示例 |
+|--------|------|------|
+| 搜索关键词 | 移除标志后的剩余文本 | `/ss-search 用户认证` → query=`用户认证` |
+| 包含归档 | `--archived`/`归档`/`包含归档`/`all` → 添加 `--archived` | `/ss-search 认证 --archived`; `/ss-search 认证 归档` |
+| 过滤类型 | `--artifact <type>`/`类型:<type>` → 添加 `--artifact <type>`; type: `proposal`/`spec`/`tasks`/`clarify`/`checklist` | `/ss-search 认证 --artifact spec`; `/ss-search 认证 类型:proposal` |
+
 **Steps**
-1. 运行 `superspec search <query>`
-2. 使用 `--archived` 包含已归档的变更
-3. 使用 `--artifact <type>` 按 artifact 类型过滤
+1. 解析用户输入 → 提取搜索关键词和标志
+2. 运行 `superspec search "<query>" [--archived] [--artifact <type>]`
 <!-- SUPERSPEC:END -->

package/templates/zh/commands/ss-specs.md

@@ -0,0 +1,54 @@
+---
+name: /ss-specs
+id: ss-specs
+category: SuperSpec
+description: 为大型变更创建多能力域 spec 结构
+---
+<!-- SUPERSPEC:START -->
+**用途**
+当 spec.md 因涉及多个独立能力域可能超过 300 行时，拆分为能力域维度的 spec 文件。
+
+**何时拆分**
+- 变更跨多个系统模块（如 auth + API + UI）
+- 单个 spec.md 预计超过 300 行
+- 需要并行开发多个独立能力
+
+**何时不拆分**
+- 单一模块变更或 spec.md < 200 行
+- 能力域之间高度耦合
+- 快速原型或实验性变更
+
+**能力域类型**
+`auth`（认证/授权）· `api`（REST/GraphQL）· `ui`（前端）· `data`（模型/schema）· `workflow`（业务流程）· `integration`（外部集成）· `infra`（部署）
+
+**Spec 模板**
+```markdown
+---
+name: <name>-<capability>
+status: draft
+strategy: {{strategy}}
+depends_on: []
+capability: <capability-name>
+---
+# Spec: <name> - <Capability>
+
+## 能力域范围
+## 用户故事
+### US-<capability>-1: [标题]
+## 功能需求
+### FR-<capability>-1: [标题]
+## 跨能力域依赖
+- 依赖 `auth/spec.md` 的 FR-auth-2
+- 为 `ui/spec.md` 提供 API-1
+## 边界情况
+```
+
+**ID 约定**: `US-<cap>-<n>`, `FR-<cap>-<n>`, `AC-<cap>-<n>.<sub>`
+
+**Steps**
+1. 在 proposal.md 中识别 2-5 个独立能力域
+2. 为每个能力域创建 `specs/<capability>/spec.md`，使用上述模板
+3. 在 design.md 中说明拆分理由
+4. 在 tasks.md 中按能力域分组任务
+5. 验证：边界清晰、依赖明确、每个 spec < 300 行、ID 遵循约定
+<!-- SUPERSPEC:END -->

package/templates/zh/commands/ss-validate.md

@@ -5,11 +5,21 @@ category: SuperSpec
 description: 交叉引用一致性检查（boost 模式）
 ---
 <!-- SUPERSPEC:START -->
+**输入解析规则**
+
+从用户输入中提取：**变更名称**、**可选标志**。
+
+| 提取项 | 规则 | 示例 |
+|--------|------|------|
+| 变更名称 | 移除标志后的剩余文本；为空时使用当前活跃变更 | `/ss-validate addUserAuth` → name=`addUserAuth` |
+| 检查依赖 | `--check-deps`/`检查依赖`/`依赖检查` → 添加 `--check-deps` | `/ss-validate --check-deps`; `/ss-validate 检查依赖` |
+
 **Guardrails**
 - 验证 US↔FR↔AC↔tasks 一致性
 - 仅在 boost 模式下适用
 
 **Steps**
-1. 运行 `superspec validate [name]`
-2. 修复报告的任何一致性错误
+1. 解析用户输入 → 提取变更名称和标志
+2. 运行 `superspec validate [name] [--check-deps]`
+3. 修复报告的任何一致性错误
 <!-- SUPERSPEC:END -->