@superspec/cli 1.1.1 → 1.2.1

package/prompts/rules.md

@@ -15,25 +15,40 @@ alwaysApply: true
 
 **CLI:** `superspec create <feature>` (`-b` boost, `-c` creative, `--no-branch` skip branch)
 
+> CLI only creates folder + git branch. AI reads `{specDir}/templates/` as structural reference, then generates artifacts with real content on demand.
+
+**Strategy priority**: user input `-c` > config default
+
 **Standard steps:**
-1. Run `superspec create <feature>` → creates folder + proposal.md + tasks.md templates
-2. Read frontmatter → check `strategy`
-3. If `follow`: read `context` files → constrain to project patterns
+1. Parse user input → extract feature, intent type, developer, lang; **preserve original input text**
+2. Determine strategy by priority
+3. Run `superspec create <feature> [--intent-type <type>] [-c]` → creates folder + branch
+4. If `follow`: read `context` files → constrain to project patterns
    If `create`: note `context` as awareness only
-4. Collect from user: Background, Goals, Solution overview, Impact scope
-5. `follow`: solution must align with existing architecture
+5. Collect from user: Background, Goals, Requirements, Technical Solution, Impact scope
+6. `follow`: solution must align with existing architecture
    `create`: may propose new architecture, must explain trade-offs
-6. Apply First Principles (brevity, intent-focused, required sections)
-7. Write `proposal.md` → status 🟢 Ready
-
-**Boost additional steps:**
-8. Read `proposal.md` → generate spec:
+7. Apply First Principles (brevity, intent-focused, required sections)
+8. Directly generate `proposal.md` (requirements + technical solution). Frontmatter `input` = user's original input
+9. **Auto-run checklist** (Standard checks, / 10): evaluate proposal quality
+10. Pass → generate `checklist.md`, prompt /ss-tasks; Fail → fix proposal, re-check
+
+**Boost steps:**
+1. Parse user input → extract feature, intent type, developer, lang; **preserve original input text**
+2. Determine strategy by priority
+3. Run `superspec create <feature> -b [--intent-type <type>] [-c]` → creates folder + branch
+4. Read frontmatter config → check `strategy`, context
+5. Directly generate `proposal.md` (focused on requirements background). Frontmatter `input` = user's original input
+6. Read `{specDir}/templates/spec.md` as structural reference
+7. Generate spec from proposal:
    - User stories + acceptance criteria (AC-x.x)
    - Functional requirements + priority (P0/P1/P2) + dependencies
    - Non-functional requirements, Data model / API design, Edge cases
-9. Validate: every proposal goal → at least one user story
-10. Write `spec.md` → status 🟢 Ready
-11. Write `checklist.md` skeleton
+8. Validate: every proposal goal → at least one user story
+9. Directly generate `spec.md` with real content
+10. **Auto complexity assessment**: split spec if multi-capability / > 300 lines; generate design.md if cross-system / major architecture decisions
+11. **Auto-run checklist** (Boost checks, / 25): evaluate all artifacts
+12. Pass → generate `checklist.md`, prompt /ss-tasks; Fail → fix, re-check
 
 ## /ss-tasks
 
@@ -41,7 +56,7 @@ alwaysApply: true
 1. Read frontmatter → check `strategy`
 2. Standard: read `proposal.md` as input
    Boost: read `proposal.md` + `spec.md` as input
-3. Read `{specDir}/changes/<name>/tasks.md` template
+3. Read `{specDir}/templates/tasks.md` as **structural reference**
 4. Break into phased tasks:
    - Phase 1: Infrastructure / setup
    - Phase 2: Core implementation
@@ -52,7 +67,7 @@ alwaysApply: true
 7. Granularity: flexible (standard) / < 1h (boost)
 8. Checkpoints per phase
 9. Boost: validate every spec requirement → at least one task
-10. Write `tasks.md` → status 🟢 Ready
+10. Directly generate `tasks.md` with real content → status 🟢 Ready
 
 ## /ss-apply
 
@@ -74,13 +89,16 @@ alwaysApply: true
 **Steps:**
 1. Locate current change folder in `{specDir}/changes/`
 2. Run `superspec sync <name>` to collect latest git changes into context.md
-3. Read `context.md` (single file, minimal tokens)
-4. Cross-reference: Git Changes vs Progress → infer what's done, what's pending, what's unplanned
+3. Read `context.md` only (single file, minimal tokens, contains goals/progress/strategy/input/git changes)
+4. Determine behavior mode from `strategy` (follow / create)
 5. Report: goals, progress, git changes, affected files
-6. Ask user: what needs fixing / adjusting?
-7. Fix with spec context in mind, respect `strategy`
-8. After fix: update tasks.md checkbox if applicable
-9. Run `superspec sync <name>` to refresh context.md
+6. **Ask user whether to read additional docs**, list available files, suggest priority:
+   - ✅ `tasks.md` (recommended) → `proposal.md` → `spec.md` → `design.md` → `checklist.md` → `clarify.md`
+7. Read selected files based on user's choice
+8. Ask user: what needs fixing / adjusting?
+9. Fix respecting `strategy` (follow = obey conventions / create = explore)
+10. After fix: update tasks.md checkbox if applicable
+11. Run `superspec sync <name>` to refresh context.md
 
 ## /ss-clarify
 
@@ -98,14 +116,17 @@ Run CLI: `superspec archive <name>`.
 
 ## /ss-checklist
 
-**Boost mode only.** Quality gate before `/ss-apply`.
+Quality gate for both modes. Auto-invoked by `/ss-create`; also callable manually.
 
 **Steps:**
-1. Read ALL artifacts
-2. Evaluate: requirements completeness, proposal quality, spec consistency, task executability, cross-validation, implementation readiness
-3. ✅ passing / annotate failures
-4. Score (X / 25) + recommendations
-5. Must pass before `/ss-apply`
+1. Read ALL existing artifacts
+2. Read `{specDir}/templates/checklist.md` as **structural reference**
+3. Determine mode: Standard → Standard checks (/ 10); Boost → Boost checks (/ 25)
+4. If checklist.md doesn't exist → directly generate with real evaluation results
+5. If checklist.md exists → read and update evaluation results
+6. ✅ passing / annotate failures
+7. Score + recommendations
+8. Fail → report failing items, suggest fixes; Pass → prompt next step
 
 ## /ss-status
 

package/templates/en/checklist.md

@@ -8,9 +8,32 @@ depends_on: []
 # Quality Checklist: {{name}}
 
 > Created: {{date}}
-> Mode: Boost
 
-## Requirements Completeness
+<!-- Use Standard checks (after proposal) or Boost checks (after spec). AI selects based on mode. -->
+
+## Standard Mode Checks (after proposal, score / 10)
+
+### Proposal Quality
+
+- [ ] Background and motivation are clear
+- [ ] Goals are measurable
+- [ ] Non-goals are explicit
+- [ ] Risks identified with mitigations
+- [ ] Impact scope assessed
+
+### Requirements & Technical Solution
+
+- [ ] Requirements are specific and splittable into tasks
+- [ ] Boundary conditions identified
+- [ ] Technical solution is concrete (modules/files specified)
+- [ ] Dependencies are clear
+- [ ] No blocking open questions (or marked non-blocking)
+
+---
+
+## Boost Mode Checks (after spec, score / 25)
+
+### Requirements Completeness
 
 - [ ] All user stories have clear acceptance criteria
 - [ ] Functional requirements cover all user stories
@@ -18,7 +41,7 @@ depends_on: []
 - [ ] Edge cases identified and documented
 - [ ] Data model changes described
 
-## Proposal Quality
+### Proposal Quality
 
 - [ ] Background and motivation are clear
 - [ ] Goals are measurable
@@ -26,7 +49,7 @@ depends_on: []
 - [ ] Risks identified with mitigations
 - [ ] Impact scope assessed
 
-## Spec Consistency
+### Spec Consistency
 
 - [ ] Spec aligns with proposal goals
 - [ ] User stories cover all proposal goals
@@ -34,7 +57,7 @@ depends_on: []
 - [ ] No contradicting requirements
 - [ ] Dependencies are clear
 
-## Task Executability
+### Task Executability
 
 - [ ] Task granularity is reasonable (each < 2h)
 - [ ] Dependencies are correct
@@ -42,14 +65,14 @@ depends_on: []
 - [ ] File paths specified
 - [ ] Checkpoints are reasonable
 
-## Cross Validation
+### Cross Validation
 
 - [ ] proposal → spec: All goals have corresponding requirements
 - [ ] spec → tasks: All requirements have corresponding tasks
 - [ ] tasks → spec: No tasks beyond spec scope
 - [ ] clarify → all: All clarifications reflected in documents
 
-## Implementation Readiness
+### Implementation Readiness
 
 - [ ] Technical approach is feasible
 - [ ] No blocking dependencies
@@ -58,5 +81,5 @@ depends_on: []
 
 ---
 
-**Score**: _ / 25
+**Score**: _ / _
 **Status**: 🟡 Pending Review

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

@@ -2,15 +2,20 @@
 name: /ss-checklist
 id: ss-checklist
 category: SuperSpec
-description: Quality gate before apply (boost mode)
+description: Quality gate (Standard: after proposal / Boost: after spec)
 ---
 <!-- SUPERSPEC:START -->
 **Guardrails**
-- Only applicable in boost mode
-- Validate all quality criteria before implementation
+- Available in both Standard and Boost modes
+- Auto-invoked during `/ss-create` flow; can also be called manually at any time
 
 **Steps**
-1. Read `{specDir}/changes/<name>/checklist.md`
-2. Verify each checklist item
-3. Address any failing checks before /ss-apply
+1. Read all existing artifacts (proposal.md, spec.md, etc.)
+2. Read `{specDir}/templates/checklist.md` as **structural reference**
+3. Determine mode: Standard → use Standard checks (score / 10); Boost → use Boost checks (score / 25)
+4. If checklist.md doesn't exist → **directly generate** it (with real evaluation results)
+5. If checklist.md already exists → read and update evaluation results
+6. Verify each checklist item, mark pass/fail
+7. Fail → report failing items, suggest fixes
+8. Pass → prompt to run /ss-tasks (or /ss-apply)
 <!-- SUPERSPEC:END -->

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

@@ -2,7 +2,7 @@
 name: /ss-create
 id: ss-create
 category: SuperSpec
-description: Create or update the feature specification from a natural language feature 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 + design + checklist)
 ---
 <!-- SUPERSPEC:START -->
 ## User Input
@@ -58,7 +58,7 @@ If user provides custom `--branch-prefix`, prepend to template.
 **CLI Command Structure**
 ```bash
 superspec create <feature> [options]
-  -b, --boost                          Boost mode (spec + checklist)
+  -b, --boost                          Boost mode (spec + design + checklist)
   -c, --creative                       Creative mode (explore new solutions)
   -d, --description <desc>             Change description
   --no-branch                          Skip git branch creation
@@ -92,11 +92,37 @@ When a change involves multiple independent capabilities, split by domain:
 ```
 Each spec.md < 300 lines. Outline domains in proposal.md, group tasks by domain in tasks.md.
 
-**Steps**
-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
+**On-demand Artifact Generation**
+- CLI `superspec create` **only creates folder + git branch**, no artifact files
+- AI reads templates from `{specDir}/templates/` as **structural reference**, then directly generates artifacts with real content
+- Only generate files when the current step requires them, never pre-create empty templates
+
+**Strategy Priority** (highest to lowest)
+1. `-c`/`--creative`/`creative` flag in user input
+2. `strategy` default in `superspec.config.json`
+
+**Standard vs Boost Content Focus**
+- **Standard**: proposal.md is self-contained with requirements + technical solution, sufficient to directly split into tasks (no spec.md needed)
+- **Boost**: proposal.md focuses on requirements background (Background, Goals, Non-Goals, Impact, Risks); spec.md carries requirement details and interactions (US/FR/AC/Edge Cases); design.md optionally carries architecture decisions
+
+**Steps (Standard mode)**
+1. Parse user input → extract feature (camelCase), intent type, developer, lang; **preserve original user input text**
+2. Determine strategy (by priority): user input `-c` → config default
+3. Run: `superspec create <feature> --intent-type <type> [--lang <lang>] [--user <user>] [-c]` (creates folder + branch)
+4. Pre-task review: read project context, check existing changes, understand dependencies
+5. Read `{specDir}/templates/proposal.md` as structural reference → **directly generate** proposal.md (with requirements + technical solution, must be concrete enough to split into tasks). Fill frontmatter `input` field with user's original input
+6. **Auto-run checklist check** (Standard checks, score / 10): read `{specDir}/templates/checklist.md`, evaluate proposal quality
+7. Pass → generate checklist.md, prompt to run /ss-tasks; Fail → fix proposal and re-check
+
+**Steps (Boost mode)**
+1. Parse user input → extract feature (camelCase), intent type, developer, lang; **preserve original user input text**
+2. Determine strategy (by priority): user input `-c` → config default
+3. Run: `superspec create <feature> --intent-type <type> [--lang <lang>] [--user <user>] -b [-c]` (creates folder + branch)
+4. Pre-task review: read project context, check existing changes, understand dependencies
+5. Read `{specDir}/templates/proposal.md` as structural reference → **directly generate** proposal.md (focused on requirements background). Fill frontmatter `input` field with user's original input
+6. Read `{specDir}/templates/spec.md` as structural reference → **directly generate** spec.md (requirement details + interactions)
+7. **Auto complexity assessment**: whether to split spec (multi-capability / spec > 300 lines), whether design.md is needed (cross-system / major architecture decisions)
+8. If needed → split spec into `specs/<capability>/spec.md`; if needed → read design template and generate design.md
+9. **Auto-run checklist check** (Boost checks, score / 25): read `{specDir}/templates/checklist.md`, evaluate all existing artifacts
+10. Pass → generate checklist.md, prompt to run /ss-tasks; Fail → fix and re-check
 <!-- SUPERSPEC:END -->

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

@@ -7,11 +7,24 @@ description: Restore spec context for vibe coding
 <!-- SUPERSPEC:START -->
 **Guardrails**
 - Use when returning to a change after a break
-- Read context.md first if it exists
+- Read only context.md by default (minimal tokens), other docs are user's choice
 
 **Steps**
-1. Run `superspec sync` to collect git diff into context.md
-2. Read `{specDir}/changes/<name>/context.md`
-3. Read current proposal.md and tasks.md to understand state
-4. Identify incomplete tasks and continue implementation
+1. Locate current change folder: `{specDir}/changes/`
+2. Run `superspec sync <name>` to collect latest git changes into context.md
+3. Read `context.md` (single file, contains: goals, progress, strategy, input, git changes)
+4. Determine behavior mode from `strategy` in context.md (follow / create)
+5. Report current state: goals, progress, git changes, affected files
+6. **Ask user whether to read additional docs**, list available files in change dir, suggest priority:
+   - ✅ `tasks.md` (recommended, task details and dependencies)
+   - `proposal.md` (requirements and solution review)
+   - `spec.md` (Boost mode, requirement details)
+   - `design.md` (architecture decisions)
+   - `checklist.md` (quality check results)
+   - `clarify.md` (historical Q&A)
+7. Read selected files based on user's choice
+8. Ask user: what needs fixing / adjusting?
+9. Fix respecting `strategy` (follow = obey conventions / create = may explore new approaches)
+10. After fix: update tasks.md checkbox if applicable
+11. Run `superspec sync <name>` to refresh context.md
 <!-- SUPERSPEC:END -->

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

@@ -14,6 +14,7 @@ description: Generate task list from proposal
 **Steps**
 1. Read `{specDir}/changes/<name>/proposal.md`
 2. If boost mode, also read `spec.md`
-3. Generate tasks.md with phased implementation steps
-4. Each task should have: clear description, file paths, dependencies, verification criteria
+3. Read `{specDir}/templates/tasks.md` as **structural reference**
+4. **Directly generate** tasks.md (with real task content, not template placeholders)
+5. Each task should have: clear description, file paths, dependencies, verification criteria
 <!-- SUPERSPEC:END -->

package/templates/en/proposal.md

@@ -3,6 +3,7 @@ name: {{name}}
 status: draft
 strategy: {{strategy}}
 depends_on: []
+input: {{input}}
 ---
 
 # Proposal: {{name}}
@@ -24,9 +25,20 @@ depends_on: []
 
 <!-- What is explicitly out of scope -->
 
-## Solution Overview
+<!-- ===== Standard mode: use these two sections ===== -->
 
-<!-- High-level solution description -->
+## Requirements
+
+<!-- Functional requirements, interaction logic, boundary conditions -->
+
+## Technical Solution
+
+<!-- Architecture, key implementation approach, modules/files involved. Must be concrete enough to split into tasks -->
+
+<!-- ===== Boost mode: replace above two sections with this one ===== -->
+
+<!-- ## Solution Overview -->
+<!-- High-level solution description. Detailed requirements and interactions go in spec.md -->
 
 ## Impact Scope
 

package/templates/zh/checklist.md

@@ -8,9 +8,32 @@ depends_on: []
 # 质量检查清单: {{name}}
 
 > 创建日期: {{date}}
-> 模式: 增强 (boost)
 
-## 需求完整性
+<!-- 根据模式选择检查项：Standard（proposal 后）或 Boost（spec 后）。AI 根据模式自动选择。 -->
+
+## Standard 模式检查项（proposal 后，满分 / 10）
+
+### 提案质量
+
+- [ ] 背景和动机清晰
+- [ ] 目标可衡量
+- [ ] 非目标明确
+- [ ] 风险已识别并有缓解措施
+- [ ] 影响范围已评估
+
+### 需求与技术方案
+
+- [ ] 需求明确且可拆分为任务
+- [ ] 边界条件已识别
+- [ ] 技术方案具体（模块/文件已明确）
+- [ ] 依赖关系清楚
+- [ ] 无阻塞性开放问题（或已标记为非阻塞）
+
+---
+
+## Boost 模式检查项（spec 后，满分 / 25）
+
+### 需求完整性
 
 - [ ] 所有用户故事都有明确的验收标准
 - [ ] 功能需求覆盖了所有用户故事
@@ -18,7 +41,7 @@ depends_on: []
 - [ ] 边界情况已识别并记录
 - [ ] 数据模型变更已描述
 
-## 提案质量
+### 提案质量
 
 - [ ] 背景和动机清晰
 - [ ] 目标可衡量
@@ -26,7 +49,7 @@ depends_on: []
 - [ ] 风险已识别并有缓解措施
 - [ ] 影响范围已评估
 
-## 规格一致性
+### 规格一致性
 
 - [ ] spec 与 proposal 目标一致
 - [ ] 用户故事覆盖 proposal 中所有目标
@@ -34,7 +57,7 @@ depends_on: []
 - [ ] 无矛盾需求
 - [ ] 依赖关系明确
 
-## 任务可执行性
+### 任务可执行性
 
 - [ ] 任务粒度合理（每个 < 2h）
 - [ ] 依赖关系正确
@@ -42,14 +65,14 @@ depends_on: []
 - [ ] 文件路径明确
 - [ ] 检查点设置合理
 
-## 交叉验证
+### 交叉验证
 
 - [ ] proposal → spec: 所有目标都有对应需求
 - [ ] spec → tasks: 所有需求都有对应任务
 - [ ] tasks → spec: 没有超出 spec 范围的任务
 - [ ] clarify → all: 所有澄清结果已更新到相关文档
 
-## 实现就绪度
+### 实现就绪度
 
 - [ ] 技术方案可行
 - [ ] 无阻塞依赖
@@ -58,5 +81,5 @@ depends_on: []
 
 ---
 
-**总分**: _ / 25
+**总分**: _ / _
 **状态**: 🟡 待检查

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

@@ -2,15 +2,20 @@
 name: /ss-checklist
 id: ss-checklist
 category: SuperSpec
-description: apply 前的质量门（boost 模式）
+description: 质量门检查（Standard: proposal 后 / Boost: spec 后）
 ---
 <!-- SUPERSPEC:START -->
 **Guardrails**
-- 仅在 boost 模式下适用
-- 执行前验证所有质量标准
+- Standard 和 Boost 模式均可使用
+- `/ss-create` 流程中会自动调用；也可手动随时调用
 
 **Steps**
-1. 读取 `{specDir}/changes/<name>/checklist.md`
-2. 验证每个检查项
-3. 在 /ss-apply 前解决所有失败检查
+1. 读取所有已有 artifacts（proposal.md, spec.md 等）
+2. 读取 `{specDir}/templates/checklist.md` 作为**结构参考**
+3. 判断模式：Standard → 使用 Standard 检查项（满分 10）；Boost → 使用 Boost 检查项（满分 25）
+4. 如果 checklist.md 不存在 → **直接生成**（包含真实评估结果）
+5. 如果 checklist.md 已存在 → 读取并更新评估结果
+6. 验证每个检查项，标注通过/失败
+7. 不通过 → 报告失败项，建议修复方向
+8. 通过 → 提示可执行 /ss-tasks（或 /ss-apply）
 <!-- SUPERSPEC:END -->

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

@@ -58,7 +58,7 @@ superspec create fixLoginBug --intent-type hotfix
 **CLI 命令结构**
 ```bash
 superspec create <feature> [options]
-  -b, --boost                          增强模式（spec + checklist）
+  -b, --boost                          增强模式（spec（支持拆分子 spec ）+ design + checklist）
   -c, --creative                       创造模式（探索新方案）
   -d, --description <desc>             变更描述
   --no-branch                          跳过 git 分支创建
@@ -92,11 +92,37 @@ superspec create <feature> [options]
 ```
 每个 spec.md < 300 行。在 proposal.md 中概述能力域，tasks.md 按能力域分组。
 
-**Steps**
-1. 解析用户输入 → 提取功能名（camelCase）、意图类型、开发者、语言
-2. 执行: `superspec create <feature> --intent-type <type> [--lang <lang>] [--user <user>]`
-3. 前置审查: 读取项目上下文、检查现有变更、理解依赖关系
-4. 评估复杂度: 如涉及多个独立能力域 → 考虑拆分 spec
-5. 读取生成的 proposal.md → 理解范围; 如需 design.md → 明确架构决策
-6. 等待用户确认后再继续 /ss-tasks
+**Artifact 按需生成原则**
+- CLI `superspec create` **只创建文件夹 + git 分支**，不生成任何 artifact 文件
+- AI 读取 `{specDir}/templates/` 下的模板作为**结构参考**，直接生成包含真实内容的 artifact
+- 只在当前步骤需要时才生成对应文件，不预先创建空模板
+
+**Strategy 优先级**（从高到低）
+1. 用户输入中的 `-c`/`--creative`/`创造` 标志
+2. `superspec.config.json` 中的 `strategy` 默认值
+
+**Standard 与 Boost 内容定位**
+- **Standard**: proposal.md 自含需求 + 技术方案，足以直接拆分 task（无需 spec.md）
+- **Boost**: proposal.md 聚焦需求背景（Background, Goals, Non-Goals, Impact, Risks）；spec.md 承载需求细节和交互（US/FR/AC/Edge Cases）；design.md 可选承载架构决策
+
+**Steps（Standard 模式）**
+1. 解析用户输入 → 提取功能名（camelCase）、意图类型、开发者、语言；**保留用户原始输入文本**
+2. 确定 strategy（按优先级）：用户输入 `-c` → config 默认值
+3. 执行: `superspec create <feature> --intent-type <type> [--lang <lang>] [--user <user>] [-c]`（只创建文件夹 + 分支）
+4. 前置审查: 读取项目上下文、检查现有变更、理解依赖关系
+5. 读取 `{specDir}/templates/proposal.md` 作结构参考 → **直接生成** proposal.md（含需求描述 + 技术方案，必须具体到可拆分 task）。frontmatter `input` 字段填入用户原始输入
+6. **自动执行 checklist 检查**（Standard 检查项，满分 10）：读取 `{specDir}/templates/checklist.md`，评估 proposal 质量
+7. 通过 → 生成 checklist.md，提示可执行 /ss-tasks；不通过 → 修复 proposal 后重新检查
+
+**Steps（Boost 模式）**
+1. 解析用户输入 → 提取功能名（camelCase）、意图类型、开发者、语言；**保留用户原始输入文本**
+2. 确定 strategy（按优先级）：用户输入 `-c` → config 默认值
+3. 执行: `superspec create <feature> --intent-type <type> [--lang <lang>] [--user <user>] -b [-c]`（只创建文件夹 + 分支）
+4. 前置审查: 读取项目上下文、检查现有变更、理解依赖关系
+5. 读取 `{specDir}/templates/proposal.md` 作结构参考 → **直接生成** proposal.md（聚焦需求背景）。frontmatter `input` 字段填入用户原始输入
+6. 读取 `{specDir}/templates/spec.md` 作结构参考 → **直接生成** spec.md（需求细节 + 交互）
+7. **自动复杂度评估**：是否需要拆分 spec（多能力域 / spec > 300 行）、是否需要 design.md（跨系统 / 重大架构决策）
+8. 如需 → 拆分 spec 到 `specs/<capability>/spec.md`；如需 → 读取 design 模板生成 design.md
+9. **自动执行 checklist 检查**（Boost 检查项，满分 25）：读取 `{specDir}/templates/checklist.md`，评估所有已有 artifacts
+10. 通过 → 生成 checklist.md，提示可执行 /ss-tasks；不通过 → 修复后重新检查
 <!-- SUPERSPEC:END -->

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

@@ -7,11 +7,24 @@ description: 恢复 spec 上下文（用于 vibe coding）
 <!-- SUPERSPEC:START -->
 **Guardrails**
 - 中断后返回工作时使用
-- 优先读取 context.md（如果存在）
+- 默认只读 context.md（最小 token），其他文档由用户按需选择
 
 **Steps**
-1. 运行 `superspec sync` 将 git 变更收集到 context.md
-2. 读取 `{specDir}/changes/<name>/context.md`
-3. 读取当前的 proposal.md 和 tasks.md 了解状态
-4. 识别未完成的任务并继续执行
+1. 定位当前变更文件夹: `{specDir}/changes/`
+2. 运行 `superspec sync <name>` 将最新 git 变更收集到 context.md
+3. 读取 `context.md`（单文件，包含：goals、progress、strategy、input、git changes）
+4. 根据 context.md 中的 `strategy` 确定行为模式（follow / create）
+5. 汇报当前状态：目标、进度、git 变更、受影响文件
+6. **询问用户是否需要读取其他文档**，列出变更目录中的可用文件，建议优先级：
+   - ✅ `tasks.md`（推荐，了解任务明细和依赖）
+   - `proposal.md`（需求和方案回顾）
+   - `spec.md`（Boost 模式，需求细节）
+   - `design.md`（架构决策）
+   - `checklist.md`（质量检查结果）
+   - `clarify.md`（历史 Q&A）
+7. 根据用户选择读取对应文件
+8. 询问用户：需要修复/调整什么？
+9. 修复时遵循 `strategy`（follow 遵循规范 / create 可探索新方案）
+10. 修复后更新 tasks.md 对应的 checkbox
+11. 运行 `superspec sync <name>` 刷新 context.md
 <!-- SUPERSPEC:END -->

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

@@ -14,6 +14,7 @@ description: 从 proposal 生成任务清单
 **Steps**
 1. 读取 `{specDir}/changes/<name>/proposal.md`
 2. 如果是 boost 模式，同时读取 `spec.md`
-3. 生成 tasks.md，包含分阶段的实现步骤
-4. 每个任务应包含：清晰描述、文件路径、依赖关系、验证标准
+3. 读取 `{specDir}/templates/tasks.md` 作为**结构参考**
+4. **直接生成** tasks.md（包含真实任务内容，不是模板占位符）
+5. 每个任务应包含：清晰描述、文件路径、依赖关系、验证标准
 <!-- SUPERSPEC:END -->

package/templates/zh/proposal.md

@@ -3,6 +3,7 @@ name: {{name}}
 status: draft
 strategy: {{strategy}}
 depends_on: []
+input: {{input}}
 ---
 
 # 提案: {{name}}
@@ -30,9 +31,20 @@ depends_on: []
 
 <!-- 明确不在范围内的内容 -->
 
-## 方案概述
+<!-- ===== Standard 模式：使用以下两段 ===== -->
 
-<!-- 高层级的解决方案描述 -->
+## 需求描述
+
+<!-- 功能需求、交互逻辑、边界条件 -->
+
+## 技术方案
+
+<!-- 架构设计、关键实现思路、涉及的模块/文件。必须具体到可拆分 task -->
+
+<!-- ===== Boost 模式：替换上面两段为以下一段 ===== -->
+
+<!-- ## 方案概述 -->
+<!-- 高层级的解决方案描述。详细需求和交互由 spec.md 承载 -->
 
 ## 影响范围