@superspec/cli 1.1.0 → 1.2.0

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-archive.md

@@ -5,11 +5,21 @@ category: SuperSpec
 description: Archive completed change
 ---
 <!-- SUPERSPEC:START -->
+**Input Parsing Rules**
+
+From user input, extract: **change name** or **all flag**.
+
+| Extract | Rule | Example |
+|---------|------|---------|
+| Change name | Remaining text after removing flags; if empty, use current active change | `/ss-archive addUserAuth` → name=`addUserAuth` |
+| Archive all | `--all`/`all` → add `--all` | `/ss-archive --all`; `/ss-archive all` |
+
 **Guardrails**
 - Only archive when all tasks are COMPLETE
 - Ensure tests pass before archiving
 
 **Steps**
-1. Verify all tasks in tasks.md are marked COMPLETE
-2. Run `superspec archive <name>` or `superspec archive --all`
+1. Parse user input → extract change name or `--all` flag
+2. Verify all tasks in tasks.md are marked COMPLETE
+3. Run `superspec archive <name>` or `superspec archive --all`
 <!-- SUPERSPEC:END -->

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
@@ -27,11 +27,12 @@ The text the user typed after `/ss-create` **is** the feature description. Do no
 
 **Input Parsing Rules**
 
-From user input, extract three things: **feature name**, **intent type**, **developer**, **lang**.
+From user input, extract: **mode flags**, **feature name**, **intent type**, **developer**, **lang**.
 
 | Extract | Rule | Example |
 |---------|------|---------|
-| Feature name | Convert to camelCase. Chinese → translate to English first | "add user auth" → `addUserAuth`; "添加用户认证" → `addUserAuth` |
+| 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` |
@@ -57,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
@@ -91,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-link.md

@@ -5,8 +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 deps add <name> --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-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-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-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/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/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-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-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 -->