prizmkit 1.0.20 → 1.0.22

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.0.20",
-  "bundledAt": "2026-03-15T16:09:11.089Z",
-  "bundledFrom": "4f7e6fe"
+  "frameworkVersion": "1.0.22",
+  "bundledAt": "2026-03-15T16:54:30.454Z",
+  "bundledFrom": "7e2197a"
 }

package/bundled/agents/prizm-dev-team-coordinator.md

@@ -1,6 +1,6 @@
 ---
 name: prizm-dev-team-coordinator
-description: PrizmKit-integrated dev team coordinator. Orchestrates 7-phase pipeline (init → specify+plan+tasks → analyze → implement → review → summarize → commit), manages 4 checkpoints, coordinates PM/Dev/Reviewer agents.
+description: PrizmKit-integrated dev team coordinator. Orchestrates 6-phase pipeline (init → specify+plan → analyze → implement → review → summarize → commit), manages 4 checkpoints, coordinates PM/Dev/Reviewer agents.
 tools: Read, Write, Edit, Bash, Glob, Grep, TaskCreate, TaskGet, TaskUpdate, TaskList, SendMessage
 model: inherit
 skills: prizmkit-init, prizmkit-summarize, prizmkit-committer, prizmkit-retrospective
@@ -27,7 +27,7 @@ skills: prizmkit-init, prizmkit-summarize, prizmkit-committer, prizmkit-retrospe
 | 路径 | 用途 |
 |------|------|
 | `.prizm-docs/` | 项目知识层 — 项目结构、规则、模式 |
-| `.prizmkit/specs/###-feature-name/` | 功能制品 — spec.md / plan.md / tasks.md |
+| `.prizmkit/specs/###-feature-name/` | 功能制品 — spec.md / plan.md（含 Tasks section） |
 | `.prizmkit/config.json` | PrizmKit 配置 |
 | `.prizmkit/specs/REGISTRY.md` | 已完成功能注册表 |
 
@@ -66,34 +66,34 @@ C-09: committer 完成后验证 git status 为干净状态，确保下一个 fea
 C-10: bug 修复不得触发 prizmkit.summarize，不得在 REGISTRY.md 中创建新条目；bug 是现有功能的完善，不是新功能
 ```
 
-### 统一流水线（7 阶段）
+### 统一流水线（6 阶段）
 
 ```
 Phase 0: 项目引导 (Coordinator)
   - prizmkit.init（首次运行时）
   → CP-0: .prizm-docs/root.prizm + .prizmkit/config.json 存在
 
-Phase 1-3: 需求规划 (PM, 一次调用)
-  - PM 连续执行 prizmkit.specify → prizmkit.plan → prizmkit.tasks
-  - 产出 spec.md, plan.md, tasks.md
-  → CP-1: 三个文件都存在
+Phase 1-2: 需求规划 (PM, 一次调用)
+  - PM 连续执行 prizmkit.specify → prizmkit.plan
+  - 产出 spec.md, plan.md（含 Tasks section）
+  → CP-1: 两个文件都存在
 
-Phase 4: 交叉校验 (Reviewer)
+Phase 3: 交叉校验 (Reviewer)
   - prizmkit.analyze → 交叉一致性检查
   - 如有 CRITICAL 问题，退回 PM 修复（最多 1 轮）
   → CP-2: 无 CRITICAL 问题
 
-Phase 5: 实现 (Dev)
-  - prizmkit.implement（TDD，标记 tasks.md [x]）
+Phase 4: 实现 (Dev)
+  - prizmkit.implement（TDD，标记 plan.md Tasks section [x]）
   → 所有任务 [x]，测试通过
 
-Phase 6: 评审 (Reviewer)
+Phase 5: 评审 (Reviewer)
   - prizmkit.code-review（规格合规 + 代码质量）
   - 集成测试
   - 如有 CRITICAL 问题，退回 Dev 修复（最多 3 轮）
   → CP-3: 评审通过，测试通过
 
-Phase 7: 归档与提交 (Coordinator)
+Phase 6: 归档与提交 (Coordinator)
   - prizmkit.summarize → REGISTRY.md
   - prizmkit.committer → git commit
   - 验证: git status 确认工作区干净（无未提交变更）
@@ -108,14 +108,13 @@ Phase 7: 归档与提交 (Coordinator)
 
 **CP-1** (PM 规划完成后):
 - `.prizmkit/specs/###-feature-name/spec.md` 存在
-- `.prizmkit/specs/###-feature-name/plan.md` 存在
-- `.prizmkit/specs/###-feature-name/tasks.md` 存在
+- `.prizmkit/specs/###-feature-name/plan.md` 存在（含 Tasks section）
 
 **CP-2** (交叉校验后):
 - prizmkit.analyze 报告无 CRITICAL 问题
 
 **CP-3** (评审后):
-- 所有任务标记 `[x]`
+- 所有任务标记 `[x]`（在 plan.md Tasks section 中）
 - 测试通过
 - 评审判定非 NEEDS_FIXES
 

package/bundled/agents/prizm-dev-team-dev.md

@@ -1,6 +1,6 @@
 ---
 name: prizm-dev-team-dev
-description: PrizmKit-integrated module implementer (multi-instance). Follows prizmkit.implement workflow with TDD, marks tasks [x] in tasks.md, works within assigned Git worktrees. Use when implementing specific feature modules.
+description: PrizmKit-integrated module implementer (multi-instance). Follows prizmkit.implement workflow with TDD, marks tasks [x] in plan.md Tasks section, works within assigned Git worktrees. Use when implementing specific feature modules.
 tools: Read, Write, Edit, Bash, Glob, Grep, TaskCreate, TaskGet, TaskUpdate, TaskList, SendMessage
 model: inherit
 skills: prizmkit-implement, prizmkit-prizm-docs
@@ -11,9 +11,9 @@ skills: prizmkit-implement, prizmkit-prizm-docs
 ### 核心身份
 
 你是团队的"建筑工人"——严格按图纸施工，使用 PrizmKit 的 implement 工作流作为执行引擎，专注于：
-- 按照 tasks.md 和 plan.md 中的接口设计逐任务实现功能模块
+- 按照 plan.md Tasks section 和接口设计逐任务实现功能模块
 - 遵循 TDD 方式开发（测试先行）
-- 完成后立即标记 tasks.md 中的 `[x]`
+- 完成后立即标记 plan.md Tasks section 中的 `[x]`
 - 产出代码和单元测试
 
 ### 项目上下文
@@ -25,7 +25,7 @@ skills: prizmkit-implement, prizmkit-prizm-docs
 | 路径 | 用途 |
 |------|------|
 | `.prizm-docs/` | 项目知识层 — 规则、模式、已知陷阱 |
-| `.prizmkit/specs/###-feature-name/` | 功能制品 — spec.md / plan.md / tasks.md |
+| `.prizmkit/specs/###-feature-name/` | 功能制品 — spec.md / plan.md（含 Tasks section） |
 
 ### 必须做 (MUST)
 
@@ -33,8 +33,8 @@ skills: prizmkit-implement, prizmkit-prizm-docs
 2. 遵循 TDD 方式：先写测试，再实现，再验证
 3. 产出的代码必须通过本模块的单元测试
 4. 发现接口设计歧义时，立即通过 Coordinator 上报 PM（不自行假设）
-5. 遵循 `prizmkit.implement` 工作流：读取 tasks.md + plan.md + spec.md，逐任务实现
-6. 每个任务完成后**立即**标记 tasks.md 中的 `[x]`（不批量标记）
+5. 遵循 `prizmkit.implement` 工作流：读取 plan.md（含 Tasks section）+ spec.md，逐任务实现
+6. 每个任务完成后**立即**标记 plan.md Tasks section 中的 `[x]`（不批量标记）
 7. 实现前读取 `.prizm-docs/` TRAPS 段避免已知陷阱
 8. 检查点任务须验证构建通过和测试通过后才能继续下一阶段
 9. 顺序任务按序执行，失败则停止；并行 `[P]` 任务可继续
@@ -46,7 +46,7 @@ skills: prizmkit-implement, prizmkit-prizm-docs
 - 不修改其他 Dev Agent 负责的模块代码
 - 不进行集成测试（Reviewer 的职责）
 - **不执行任何 git 操作**（git commit / git add / git reset / git push 均禁止 — 由 Orchestrator 通过 prizmkit.committer 统一提交）
-- 不修改 `.prizmkit/specs/` 中除 `tasks.md`（标记 [x]）以外的任何文件
+- 不修改 `.prizmkit/specs/` 中除 `plan.md`（标记 Tasks section [x]）以外的任何文件
 - 不为 bug 修复创建新的文档条目；bug 修复是现有功能的完善，应更新原始功能的文档而非在 REGISTRY.md 中创建新条目
 - 不使用 TaskCreate/TaskUpdate 创建或修改 Orchestrator 层的任务（Task 工具仅用于内部进度追踪，且任务 ID 在各 agent 子会话中互不共享）
 
@@ -60,7 +60,7 @@ DEV-04: 任务完成后必须运行全部本模块测试
 DEV-05: 代码提交信息遵循 Conventional Commits 格式（仅供参考，实际提交由 Orchestrator 执行）
 DEV-06: 不得引入未在任务描述中声明的外部依赖
 DEV-07: 遵循 prizmkit.implement 工作流
-DEV-08: 每个任务完成后立即标记 tasks.md [x]
+DEV-08: 每个任务完成后立即标记 plan.md Tasks section [x]
 DEV-09: TDD：先写测试 → 再实现 → 再验证
 DEV-10: 实现每个模块前必须读取 .prizm-docs/ TRAPS 段
 DEV-11: 检查点任务必须验证构建通过和测试通过
@@ -73,11 +73,11 @@ DEV-14: 若 `npm test` 中存在 pre-existing 失败，不得忽略——必须
 
 1. 接收任务分配
 2. 读取 `.prizm-docs/root.prizm` 和相关模块文档
-3. 读取 `.prizmkit/specs/###-feature-name/` 中的 `tasks.md`、`plan.md`、`spec.md`
-4. 对每个分配的任务，按 tasks.md 顺序执行：
+3. 读取 `.prizmkit/specs/###-feature-name/` 中的 `plan.md`（含 Tasks section）、`spec.md`
+4. 对每个分配的任务，按 plan.md Tasks 顺序执行：
    a. 读取目标文件模块的文档（检查 TRAPS 和 DECISIONS）
    b. TDD：基于验收标准编写测试 → 实现功能代码 → 运行测试验证
-   c. 在 tasks.md 中标记该任务为 `[x]`
+   c. 在 plan.md Tasks section 中标记该任务为 `[x]`
    d. 发送 STATUS_UPDATE 给 Coordinator
 5. 如遇检查点任务，验证构建通过和测试通过后才继续
 6. 遇到接口设计歧义，发送 ESCALATION（不自行假设）

package/bundled/agents/prizm-dev-team-pm.md

@@ -1,9 +1,9 @@
 ---
 name: prizm-dev-team-pm
-description: PrizmKit-integrated requirements analyst and task decomposition expert. Uses prizmkit.specify/clarify/plan/tasks to create structured specs, plans, and task breakdowns. Use when analyzing requirements and decomposing tasks.
+description: PrizmKit-integrated requirements analyst and task decomposition expert. Uses prizmkit.specify/clarify/plan to create structured specs, plans, and task breakdowns. Use when analyzing requirements and decomposing tasks.
 tools: Read, Write, Edit, Bash, Glob, Grep, TaskCreate, TaskGet, TaskUpdate, TaskList, SendMessage
 model: inherit
-skills: prizmkit-specify, prizmkit-clarify, prizmkit-plan, prizmkit-tasks, prizmkit-prizm-docs
+skills: prizmkit-specify, prizmkit-clarify, prizmkit-plan, prizmkit-prizm-docs
 ---
 
 你是 **PM Agent**，PrizmKit-integrated Multi-Agent 软件开发协作团队的需求分析与任务分解专家。
@@ -13,8 +13,7 @@ skills: prizmkit-specify, prizmkit-clarify, prizmkit-plan, prizmkit-tasks, prizm
 你是团队的"建筑设计师"——不砌砖但提供精确的施工图纸，使用 PrizmKit 的规格驱动工作流作为主要规格机制，专注于：
 - 分析用户需求，识别功能点和非功能性需求
 - 使用 `prizmkit.specify` 创建结构化功能规格
-- 使用 `prizmkit.plan` 生成技术实施计划（含接口设计和数据模型）
-- 使用 `prizmkit.tasks` 分解为可执行的任务清单
+- 使用 `prizmkit.plan` 生成技术实施计划（含接口设计、数据模型和可执行任务清单）
 - 为每个任务定义明确的输入、输出和验收标准
 
 ### 项目上下文
@@ -39,8 +38,7 @@ skills: prizmkit-specify, prizmkit-clarify, prizmkit-plan, prizmkit-tasks, prizm
 6. **在调用任何 skill 之前，先写 `context-snapshot.md`**（若不存在）
 7. 使用 `prizmkit.specify` 产出 `spec.md`
 8. 使用 `prizmkit.clarify` 解决所有 `[NEEDS CLARIFICATION]` 标记
-9. 使用 `prizmkit.plan` 生成 `plan.md`（含接口设计和数据模型）
-10. 使用 `prizmkit.tasks` 生成 `tasks.md`，格式为 `[T-NNN]`
+9. 使用 `prizmkit.plan` 生成 `plan.md`（含接口设计、数据模型和任务清单，格式为 `[T-NNN]`）
 11. 所有制品放在 `.prizmkit/specs/###-feature-name/`
 12. 规格中不应包含 bug 修复项；bug 修复属于现有功能的完善（使不完整的功能达到预期状态），不是新增功能，不应创建新的 spec/plan/tasks 或 REGISTRY.md 条目
 
@@ -62,14 +60,13 @@ PM-03: 任务粒度标准：单个 Dev Agent 可在 1 个 session 内完成
 PM-04: 必须为每个可并行的任务标记 [P] 标识
 PM-05: 使用 prizmkit.specify 作为需求捕获的主要工具
 PM-06: 使用 prizmkit.clarify 解决所有 [NEEDS CLARIFICATION] 标记
-PM-07: 使用 prizmkit.plan 生成 plan.md 作为技术实施计划
-PM-08: 使用 prizmkit.tasks 生成 tasks.md，格式为 [T-NNN]
-PM-09: 修改文件时，Read 之后立即 Edit，中间不插入其他工具调用，避免 "file modified since read" 错误
+PM-07: 使用 prizmkit.plan 生成 plan.md 作为技术实施计划（含任务清单）
+PM-08: 修改文件时，Read 之后立即 Edit，中间不插入其他工具调用，避免 "file modified since read" 错误
 ```
 
 ### 工作流程
 
-PM 在一次会话中连续完成以下四步：
+PM 在一次会话中连续完成以下三步：
 
 #### Step 0: 写 Context Snapshot（仅首次，若不存在）
 
@@ -95,17 +92,13 @@ PM 在一次会话中连续完成以下四步：
    - 标记不明确处为 `[NEEDS CLARIFICATION]`（最多 3 个）
 3. 如有 `[NEEDS CLARIFICATION]` 标记，运行 `prizmkit.clarify`
 
-#### Step 2: 规划
+#### Step 2: 规划与任务分解
 
 1. 运行 `prizmkit.plan` → 创建 `plan.md`
    - 架构方案、组件设计、接口设计、数据模型、测试策略、风险评估
    - 每个用户故事映射到计划组件
    - 与 `.prizm-docs/` RULES 对齐
-
-#### Step 3: 任务分解
-
-1. 运行 `prizmkit.tasks` → 创建 `tasks.md`
-   - 格式: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
+   - Tasks section: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
    - 阶段结构: Setup(T-001~T-009) → Foundational(T-010~T-099) → User Stories(T-100+) → Polish(T-900+)
    - `[P]` 标记可并行任务
 2. 发送 COMPLETION_SIGNAL
@@ -116,8 +109,7 @@ PM 在一次会话中连续完成以下四步：
 |------|------|------|------|
 | prizmkit.specify | 从自然语言创建结构化功能规格 | 功能描述 | spec.md |
 | prizmkit.clarify | 交互式解决规格模糊点 | spec.md（含标记） | 更新后的 spec.md |
-| prizmkit.plan | 生成技术实施计划 | spec.md, .prizm-docs/ | plan.md（含接口设计和数据模型） |
-| prizmkit.tasks | 分解为可执行任务 | spec.md, plan.md | tasks.md |
+| prizmkit.plan | 生成技术实施计划（含任务清单） | spec.md, .prizm-docs/ | plan.md（含接口设计、数据模型和 Tasks section） |
 
 ### 异常处理
 

package/bundled/agents/prizm-dev-team-reviewer.md

@@ -23,7 +23,7 @@ skills: prizmkit-code-review, prizmkit-analyze, prizmkit-prizm-docs
 | 路径 | 用途 |
 |------|------|
 | `.prizm-docs/` | 项目知识层 — 规则、模式、已知陷阱 |
-| `.prizmkit/specs/###-feature-name/` | 功能制品 — spec.md / plan.md / tasks.md |
+| `.prizmkit/specs/###-feature-name/` | 功能制品 — spec.md / plan.md（含 Tasks section） |
 
 ### 必须做 (MUST)
 
@@ -62,10 +62,10 @@ REV-10: 禁止使用 timeout 命令（macOS 不兼容）。运行测试时直接
 
 ### Phase 4 工作流程：交叉校验
 
-**前置条件**: PM 已完成 spec.md / plan.md / tasks.md
+**前置条件**: PM 已完成 spec.md / plan.md（含 Tasks section）
 
 1. 调用 `prizmkit.analyze` skill（**不是 CLI 命令**，使用 Skill 工具或 `/prizmkit-analyze` 指令调用）
-   - 输入: spec.md, plan.md, tasks.md
+   - 输入: spec.md, plan.md（含 Tasks section）
    - 6 个检测通道: 重复检测、歧义检测、不完整检测、Prizm 规则对齐、覆盖缺口、不一致性
    - 输出: 一致性分析报告（仅对话输出）
    - 若 Skill 工具不可用，则根据 6 个检测通道手动执行交叉一致性分析

package/bundled/dev-pipeline/README.md

@@ -153,15 +153,14 @@ Each AI CLI session drives the prizm-dev-team through these phases. **All phases
 | Phase | Name | Agent | PrizmKit Skills | Artifacts |
 |-------|------|-------|----------------|-----------|
 | 0 | Init | Coordinator | `prizmkit-init` | `.prizm-docs/root.prizm`, `.prizmkit/config.json` |
-| 1 | Specify | PM | `prizmkit-specify`, `prizmkit-clarify` | `.prizmkit/specs/spec.md`, `.dev-team/specs/requirements.md` |
-| 2 | Plan | PM | `prizmkit-plan` | `.prizmkit/plans/plan.md`, `.dev-team/contracts/` |
-| 3 | Tasks | PM | `prizmkit-tasks` | `.prizmkit/tasks/tasks.md`, `.dev-team/tasks/` |
-| 4 | Analyze | PM | `prizmkit-analyze` | Analysis report (no CRITICAL issues) |
-| 5 | Schedule | Coordinator | — | TaskList entries assigned |
-| 6 | Implement | Dev x N | `prizmkit-implement` | Code + tests, tasks.md marked `[x]` |
-| 7 | Review | QA + Review | `prizmkit-code-review` | Integration tests, review report |
-| 8 | Fix Loop | Dev | — | Max 3 rounds of fixes |
-| 9 | Summarize & Commit | Coordinator | `prizmkit-summarize`, `prizmkit-committer`, `prizmkit-retrospective` | REGISTRY.md, git commit, .prizm-docs/ updated |
+| 1 | Specify | PM | `prizmkit-specify`, `prizmkit-clarify` | `.prizmkit/specs/spec.md` |
+| 2 | Plan + Tasks | PM | `prizmkit-plan` | `.prizmkit/specs/plan.md` (含 Tasks section) |
+| 3 | Analyze | PM | `prizmkit-analyze` | Analysis report (no CRITICAL issues) |
+| 4 | Schedule | Coordinator | — | TaskList entries assigned |
+| 5 | Implement | Dev x N | `prizmkit-implement` | Code + tests, plan.md Tasks marked `[x]` |
+| 6 | Review | QA + Review | `prizmkit-code-review` | Integration tests, review report |
+| 7 | Fix Loop | Dev | — | Max 3 rounds of fixes |
+| 8 | Summarize & Commit | Coordinator | `prizmkit-summarize`, `prizmkit-committer`, `prizmkit-retrospective` | REGISTRY.md, git commit, .prizm-docs/ updated |
 
 ### Feature Dependency Resolution
 

package/bundled/dev-pipeline/scripts/parse-stream-progress.py

@@ -28,8 +28,7 @@ from datetime import datetime, timezone
 # Phase keywords for detection
 PHASE_KEYWORDS = {
     "specify": ["prizmkit-specify", "spec.md", "specification", "gathering requirements"],
-    "plan": ["prizmkit-plan", "plan.md", "architecture", "design plan"],
-    "tasks": ["prizmkit-tasks", "tasks.md", "task checklist", "task breakdown"],
+    "plan": ["prizmkit-plan", "plan.md", "architecture", "design plan", "task checklist", "task breakdown", "tasks.md"],
     "analyze": ["prizmkit-analyze", "cross-check", "consistency", "analyzing"],
     "implement": ["prizmkit-implement", "implement", "TDD", "coding", "writing code"],
     "code-review": ["prizmkit-code-review", "code review", "review verdict", "reviewing"],

package/bundled/dev-pipeline/templates/bootstrap-tier3.md

@@ -36,8 +36,7 @@ You are the **session orchestrator**. Implement Feature {{FEATURE_ID}}: "{{FEATU
 ```
 .prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md  ← PM writes, all agents read
 .prizmkit/specs/{{FEATURE_SLUG}}/spec.md
-.prizmkit/specs/{{FEATURE_SLUG}}/plan.md
-.prizmkit/specs/{{FEATURE_SLUG}}/tasks.md
+.prizmkit/specs/{{FEATURE_SLUG}}/plan.md              ← includes Tasks section
 .prizmkit/specs/REGISTRY.md
 ```
 
@@ -111,14 +110,14 @@ python3 {{INIT_SCRIPT_PATH}} --project-root {{PROJECT_ROOT}} --feature-id {{FEAT
 After team setup: check `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` — if exists, all agents MUST use it. Read existing artifacts and resume from Phase {{RESUME_PHASE}}.
 {{END_IF_RESUME}}
 
-### Phase 1-3: Specify + Plan + Tasks — PM Agent
+### Phase 1-2: Specify + Plan — PM Agent
 
 Check existing artifacts first:
 ```bash
 ls .prizmkit/specs/{{FEATURE_SLUG}}/ 2>/dev/null
 ```
 
-- All three (spec.md, plan.md, tasks.md) exist → **SKIP to CP-1**
+- Both (spec.md, plan.md) exist → **SKIP to CP-1**
 - `context-snapshot.md` exists → PM reads it instead of re-scanning source files
 - Some missing → PM generates only missing files
 
@@ -148,12 +147,11 @@ If `EXISTING_CODE` is non-empty, append to prefix:
 
 **Step B — Planning Artifacts** (include only missing files):
 - spec.md missing: "Run prizmkit-specify → generate spec.md. Resolve any `[NEEDS CLARIFICATION]` markers using the feature description — do NOT pause for interactive input."
-- plan.md missing: "Run prizmkit-plan → generate plan.md (architecture, components, interface design, data model, testing strategy, risk assessment — all in one file)"
-- tasks.md missing: "Run prizmkit-tasks → generate tasks.md with `[ ]` checkboxes"
+- plan.md missing: "Run prizmkit-plan → generate plan.md (architecture, components, interface design, data model, testing strategy, risk assessment, and Tasks section with `[ ]` checkboxes)"
 
 > "All files go under `.prizmkit/specs/{{FEATURE_SLUG}}/`. Confirm each with `ls` after writing."
 
-Wait for PM to return. **CP-1**: All three files exist. If missing, diagnose from PM output — do NOT spawn another PM blindly.
+Wait for PM to return. **CP-1**: Both files exist. If missing, diagnose from PM output — do NOT spawn another PM blindly.
 
 ### Phase 4: Analyze — Reviewer Agent
 

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.0.20",
+  "version": "1.0.22",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",
@@ -30,28 +30,21 @@
       "hasScripts": false
     },
     "prizmkit-plan": {
-      "description": "Generate technical implementation plan from feature spec.",
-      "tier": "1",
-      "category": "prizmkit-skill",
-      "hasAssets": true,
-      "hasScripts": false
-    },
-    "prizmkit-tasks": {
-      "description": "Generate executable task breakdown from implementation plan.",
+      "description": "Generate technical implementation plan and executable task breakdown from feature spec.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": true,
       "hasScripts": false
     },
     "prizmkit-analyze": {
-      "description": "Cross-document consistency analysis for spec.md, plan.md, and tasks.md.",
+      "description": "Cross-document consistency analysis for spec.md and plan.md (including Tasks section).",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": false,
       "hasScripts": false
     },
     "prizmkit-implement": {
-      "description": "Execute implementation following tasks.md with TDD approach.",
+      "description": "Execute implementation following plan.md Tasks section with TDD approach.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": false,
@@ -198,7 +191,7 @@
       "hasScripts": false
     },
     "refactor-workflow": {
-      "description": "End-to-end refactor workflow: analyze → plan → tasks → implement → review → commit. Behavior-preserving.",
+      "description": "End-to-end refactor workflow: analyze → plan → implement → review → commit. Behavior-preserving.",
       "tier": "1",
       "category": "Custom-skill",
       "hasAssets": false,
@@ -254,7 +247,6 @@
         "prizmkit-specify",
         "prizmkit-clarify",
         "prizmkit-plan",
-        "prizmkit-tasks",
         "prizmkit-analyze",
         "prizmkit-implement",
         "prizmkit-code-review",
@@ -279,7 +271,6 @@
         "prizmkit-specify",
         "prizmkit-clarify",
         "prizmkit-plan",
-        "prizmkit-tasks",
         "prizmkit-analyze",
         "prizmkit-implement",
         "prizmkit-code-review",

package/bundled/skills/prizm-kit/SKILL.md

@@ -11,8 +11,7 @@ PrizmKit is a comprehensive, independent AI development toolkit that covers the
 ```
 /prizmkit-init          # Take over a project (scan, assess, generate docs)
 /prizmkit-specify       # Create feature specification
-/prizmkit-plan          # Generate implementation plan
-/prizmkit-tasks         # Break down into executable tasks
+/prizmkit-plan          # Generate implementation plan and task breakdown
 /prizmkit-analyze       # Cross-document consistency check (recommended)
 /prizmkit-implement     # Execute implementation
 /prizmkit-committer     # Commit with auto doc update
@@ -20,7 +19,7 @@ PrizmKit is a comprehensive, independent AI development toolkit that covers the
 
 ## When to Use the Full Workflow
 
-**Use full workflow (specify -> plan -> tasks -> implement):**
+**Use full workflow (specify -> plan -> implement):**
 - New features or user-facing capabilities
 - Multi-file coordinated changes
 - Architectural decisions
@@ -64,11 +63,10 @@ PrizmKit produces two complementary knowledge layers:
 - **prizmkit-init** — Project takeover: scan → assess → generate docs → initialize
 - **prizmkit-prizm-docs** — Prizm documentation framework: `prizmkit.doc.init`, `prizmkit.doc.update`, `prizmkit.doc.status`, `prizmkit.doc.rebuild`, `prizmkit.doc.validate`, `prizmkit.doc.migrate`
 
-### Spec-Driven Workflow (10)
+### Spec-Driven Workflow (9)
 - **prizmkit-specify** — Create structured feature specifications from natural language
 - **prizmkit-clarify** — Interactive requirement clarification
-- **prizmkit-plan** — Generate technical plan (with data model & API contracts as inline sections)
-- **prizmkit-tasks** — Break plan into executable task list
+- **prizmkit-plan** — Generate technical plan with data model, API contracts, and executable task breakdown (all in one plan.md)
 - **prizmkit-analyze** — Cross-document consistency analysis (spec ↔ plan ↔ tasks)
 - **prizmkit-implement** — Execute tasks following TDD approach
 - **prizmkit-code-review** — Review code against spec and plan
@@ -99,8 +97,8 @@ PrizmKit produces two complementary knowledge layers:
 - **prizmkit-tool-api-doc-generator** — [Tier 2] Extract API documentation from source code
 
 ### Pipeline & Companion (6)
-- **feature-workflow** — [Tier 1] End-to-end feature workflow: specify → plan → tasks → analyze → implement → review → commit
-- **refactor-workflow** — [Tier 1] End-to-end refactor workflow: analyze → plan → tasks → implement → review → commit
+- **feature-workflow** — [Tier 1] End-to-end feature workflow: specify → plan → analyze → implement → review → commit
+- **refactor-workflow** — [Tier 1] End-to-end refactor workflow: analyze → plan → implement → review → commit
 - **app-planner** — Interactive app planning that produces feature-list.json for dev-pipeline
 - **bug-planner** — Interactive bug planning that produces bug-fix-list.json for bugfix-pipeline
 - **dev-pipeline-launcher** — Launch and manage the dev-pipeline from within a CLI session

package/bundled/skills/prizm-kit/assets/claude-md-template.md

@@ -29,10 +29,10 @@ This project uses PrizmKit with the Prizm documentation system for AI-optimized
 Run `/prizm-kit` to see all available PrizmKit commands.
 
 ### Fast Path for Simple Changes
-Not every change needs the full spec -> plan -> tasks workflow. Use fast path for:
+Not every change needs the full spec -> plan workflow. Use fast path for:
 - Bug fixes with clear root cause, config tweaks, typo fixes, simple refactors
 - Documentation-only changes, test additions for existing code
 - Directly use `/prizmkit-implement` with inline task description, then `/prizmkit-committer`
 
-Use the full workflow (/prizmkit-specify -> /prizmkit-plan -> /prizmkit-tasks -> /prizmkit-analyze -> /prizmkit-implement) for:
+Use the full workflow (/prizmkit-specify -> /prizmkit-plan -> /prizmkit-analyze -> /prizmkit-implement) for:
 - New features, multi-file coordinated changes, architectural decisions, data model or API changes

package/bundled/skills/prizmkit-analyze/SKILL.md

@@ -8,8 +8,7 @@ description: "Cross-document consistency analysis for spec.md, plan.md, and task
 Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md before implementation. Identifies duplications, ambiguities, underspecified items, rule conflicts, and coverage gaps.
 
 ### When to Use
-- After `prizmkit.plan` to validate spec-plan alignment before task generation
-- After `prizmkit.tasks` to validate full spec-plan-tasks consistency before implementation
+- After `prizmkit.plan` to validate spec-plan-tasks alignment before implementation
 - User says "analyze", "check consistency", "validate spec", "review plan"
 - Before `prizmkit.implement` as a quality gate
 
@@ -19,7 +18,7 @@ Perform a non-destructive cross-artifact consistency and quality analysis across
 
 Cross-document consistency analysis.
 
-**PRECONDITION:** `spec.md` and `plan.md` exist in `.prizmkit/specs/###-feature-name/`. `tasks.md` is recommended but not required.
+**PRECONDITION:** `spec.md` and `plan.md` exist in `.prizmkit/specs/###-feature-name/`. `plan.md` must include a Tasks section.
 
 ## Operating Constraints
 
@@ -40,8 +39,6 @@ Derive absolute paths:
 
 Abort with an error message if spec.md or plan.md is missing — instruct the user to run the missing prerequisite command (`prizmkit.specify` or `prizmkit.plan`).
 
-If tasks.md is missing, proceed with spec+plan analysis only and note reduced coverage in the report.
-
 ### Step 2: Load Artifacts (Progressive Disclosure)
 
 Load only the minimal necessary context from each artifact:
@@ -61,12 +58,7 @@ Load only the minimal necessary context from each artifact:
 - API Contracts
 - Testing Strategy
 - Risk Assessment
-
-**From tasks.md (if exists):**
-- Task IDs and Descriptions
-- Phase grouping (Setup, Foundational, User Stories, Polish)
-- Parallel markers `[P]`
-- Referenced file paths
+- Tasks section (task IDs, phase grouping, parallel markers, file paths)
 
 **From .prizm-docs/root.prizm:**
 - RULES section (MUST/NEVER/PREFER directives)
@@ -79,7 +71,7 @@ Create internal representations (do not include raw artifacts in output):
 
 - **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug from imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`)
 - **User story/action inventory**: Discrete user actions with acceptance criteria
-- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
+- **Task coverage mapping**: Map each task (from plan.md Tasks section) to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
 - **Prizm rule set**: Extract MUST/NEVER/PREFER normative statements from root.prizm RULES
 
 ### Step 4: Detection Passes
@@ -106,7 +98,7 @@ Focus on high-signal findings. Limit to **50 findings total**; aggregate remaind
 - Tech stack inconsistencies between plan and root.prizm TECH_STACK
 
 #### E. Coverage Gaps
-- Requirements with zero associated tasks (if tasks.md loaded)
+- Requirements with zero associated tasks (from plan.md Tasks section)
 - Tasks with no mapped requirement/story ("orphan tasks")
 - Non-functional requirements not reflected in tasks (performance, security, etc.)
 - User stories without corresponding plan components
@@ -164,7 +156,7 @@ At end of report, output a concise Next Actions block:
 - If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
 - Provide explicit command suggestions:
   - "Run `prizmkit.specify` to refine requirements"
-  - "Run `prizmkit.plan` to adjust architecture"
+  - "Run `prizmkit.plan` to adjust architecture or tasks"
   - "Edit tasks.md to add coverage for requirement X"
   - "Proceed to `prizmkit.implement`" (if clean)
 
@@ -187,7 +179,7 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t
 - **Use examples over exhaustive rules** (cite specific instances, not generic patterns)
 - **Report zero issues gracefully** (emit success report with coverage statistics)
 
-**HANDOFF:** `prizmkit.implement` (if clean) or `prizmkit.specify` / `prizmkit.plan` / `prizmkit.tasks` (if issues found)
+**HANDOFF:** `prizmkit.implement` (if clean) or `prizmkit.specify` / `prizmkit.plan` (if issues found)
 
 ## Output
 

package/bundled/skills/prizmkit-implement/SKILL.md

@@ -13,18 +13,18 @@ Execute implementation by following the task breakdown in tasks.md. Respects tas
 
 Implement the feature by executing tasks from tasks.md.
 
-**PRECONDITION:** `tasks.md` exists in `.prizmkit/specs/###-feature-name/` with unchecked tasks
+**PRECONDITION:** `plan.md` exists in `.prizmkit/specs/###-feature-name/` with a Tasks section containing unchecked tasks
 
 **STEPS:**
 
-1. Read `tasks.md`, `plan.md`, `spec.md` for full context
+1. Read `plan.md` (including Tasks section), `spec.md` for full context
 2. Read relevant `.prizm-docs/` L1/L2 for affected modules (check TRAPS and DECISIONS sections)
 3. Check if checkpoint tasks are complete before proceeding to next phase
 4. For each unchecked task in order:
    a. If task has `[P]` marker and previous parallel tasks are running, can proceed in parallel
    b. Read L2 doc for target file's module (if exists)
    c. Implement following TDD: write test first if applicable
-   d. Mark task as `[x]` in `tasks.md`
+   d. Mark task as `[x]` in `plan.md` Tasks section
    e. If error occurs: for sequential tasks, stop and report; for parallel tasks, continue others
 5. At each checkpoint: verify build passes and tests pass
 6. After all tasks: run full test suite
@@ -36,12 +36,12 @@ Implement the feature by executing tasks from tasks.md.
 - Parallel tasks (`[P]` marker) MAY continue if one fails, but report all failures
 - TDD approach: write test first, then implement, then verify test passes
 - Read `.prizm-docs/` TRAPS section before implementing to avoid known pitfalls
-- Mark each task `[x]` in `tasks.md` immediately upon completion (not batched)
+- Mark each task `[x]` in `plan.md` Tasks section immediately upon completion (not batched)
 
 **HANDOFF:** `prizmkit.code-review`
 
 ## Output
 
-- Code files created/modified as specified in tasks.md
-- `tasks.md` updated with completion markers `[x]`
+- Code files created/modified as specified in plan.md Tasks section
+- `plan.md` Tasks section updated with completion markers `[x]`
 - Implementation summary output to conversation

package/bundled/skills/prizmkit-init/SKILL.md

@@ -34,16 +34,20 @@ BROWNFIELD WORKFLOW (existing project):
 
 **Step 1: Project Scanning**
 1. Detect tech stack from build files (`package.json`, `requirements.txt`, `go.mod`, `pom.xml`, `Cargo.toml`, etc.)
-2. Map directory structure — identify source directories, test directories, config files
+2. Map directory structure using a TWO-TIER model — do NOT flatten:
+   - TOP-LEVEL modules: directories directly under project root that contain source files or sub-directories with source files (e.g. `dev-pipeline/`, `src/`, `internal/`)
+   - SUB-MODULES: directories INSIDE a top-level module (e.g. `dev-pipeline/scripts/`, `dev-pipeline/lib/`)
+   - A sub-module is NEVER treated as a top-level module, even if it has many files
+   - Exclude: `.git/`, `node_modules/`, `vendor/`, `build/`, `dist/`, `__pycache__/`, `.claude/`, `.codebuddy/`, `.prizmkit/`, `.prizm-docs/`
 3. Identify entry points by language convention
 4. Catalog dependencies (external packages)
 5. Count source files per directory
 
 **Step 2: Prizm Documentation Generation**
-2a. Invoke prizmkit-prizm-docs `prizmkit.doc.init` algorithm:
-  - Create `.prizm-docs/` directory structure
-  - Generate `root.prizm` (L0) with project meta and module index
-  - Generate L1 docs for all discovered modules
+2a. Invoke prizmkit-prizm-docs `prizmkit.doc.init` algorithm, passing the two-tier module structure from Step 1:
+  - Create `.prizm-docs/` directory structure mirroring the source tree (sub-module dirs become subdirectories under `.prizm-docs/<top-level>/`)
+  - Generate `root.prizm` (L0) with project meta and MODULE_INDEX listing ONLY top-level modules
+  - Generate L1 docs for top-level modules at `.prizm-docs/<M>.prizm` and for sub-modules at `.prizm-docs/<M>/<S>.prizm`
   - Create `changelog.prizm`
   - Skip L2 (lazy generation)
 

package/bundled/skills/prizmkit-plan/SKILL.md

@@ -1,17 +1,17 @@
 ---
 name: "prizmkit-plan"
-description: "Generate technical implementation plan from feature spec. Creates plan.md, data-model.md, API contracts, and research docs. Invoke after 'specify' when ready to plan. (project)"
+description: "Generate technical implementation plan and executable task breakdown from feature spec. Produces plan.md with architecture, data model, API contracts, and a Tasks section. Invoke after 'specify' when ready to plan. (project)"
 ---
 
 # PrizmKit Plan
 
-Generate a comprehensive technical implementation plan from a feature specification. Produces plan.md with architecture approach, component design, data model, API contracts, testing strategy, and risk assessment.
+Generate a comprehensive technical implementation plan from a feature specification. Produces plan.md with architecture approach, component design, data model, API contracts, testing strategy, risk assessment, and an executable Tasks section.
 
 ## Commands
 
 ### prizmkit.plan
 
-Create a technical implementation plan for a specified feature.
+Create a technical implementation plan and task breakdown for a specified feature.
 
 **PRECONDITION:** `spec.md` exists in `.prizmkit/specs/###-feature-name/`, `.prizm-docs/root.prizm` exists
 
@@ -36,15 +36,27 @@ Create a technical implementation plan for a specified feature.
    - Risk assessment
 6. Cross-check plan against spec: every user story MUST map to plan components
 7. Check alignment with project rules from `.prizm-docs/root.prizm` RULES section
-8. Output: `plan.md` path and summary of design decisions
+
+**Phase 2 — Task Generation:**
+8. Ask user for implementation strategy (or infer from context): MVP-first / Incremental / Parallel
+9. Append `## Tasks` section to `plan.md` using the tasks template at the end of `${SKILL_DIR}/assets/plan-template.md`:
+   - Organized by phases: Setup(T-001~T-009) → Foundational(T-010~T-099) → User Stories(T-100+) → Polish(T-900+)
+   - Each task: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
+   - `[P]` marker for tasks that can run in parallel within their phase
+   - Checkpoint tasks between phases for validation
+10. Verify: every user story maps to at least one task; every task references a target file path
+11. Output: `plan.md` path, summary of design decisions, and task count
 
 **KEY RULES:**
-- Every user story in spec.md MUST have a corresponding component or task in the plan
+- Every user story in spec.md MUST have a corresponding component AND task in the plan
 - Architecture decisions MUST align with existing project patterns from `.prizm-docs/`
 - Risk assessment MUST include at least one risk with mitigation strategy
 - Supporting details (data model, interface design) are included as sections within plan.md, not as separate files
+- Task IDs use zero-padded numbering: `[T-001]`, `[T-010]`, `[T-100]`
+- Every task MUST reference a target file path
+- Each user story section MUST be independently testable
 
-**HANDOFF:** `prizmkit.tasks` or `prizmkit.code-review`
+**HANDOFF:** `prizmkit.analyze` or `prizmkit.implement`
 
 ## Template
 
@@ -53,4 +65,4 @@ The plan template is located at `${SKILL_DIR}/assets/plan-template.md`.
 ## Output
 
 All outputs are written to `.prizmkit/specs/###-feature-name/`:
-- `plan.md` — The implementation plan (includes architecture, component design, data model, interface design, testing strategy, risk assessment)
+- `plan.md` — The implementation plan (includes architecture, component design, data model, interface design, testing strategy, risk assessment, and Tasks section)

package/bundled/skills/prizmkit-plan/assets/plan-template.md

@@ -35,3 +35,25 @@
 - [ ] Data model reviewed
 - [ ] API contracts defined
 - [ ] Testing approach agreed
+
+## Tasks
+
+### Strategy: [MVP-first | Incremental | Parallel]
+
+### Phase: Setup
+- [ ] [T-001] Project scaffolding — file: [path]
+
+### Phase: Foundational
+- [ ] [T-010] [Data model / Schema changes] — file: [path]
+
+### Phase: User Story 1 — [Title]
+- [ ] [T-100] [P] [US1] [Task description] — file: [path]
+
+### Phase: Polish
+- [ ] [T-900] Final integration test
+- [ ] [T-901] Documentation update
+
+### Checkpoints
+- [ ] [CP-1] After Setup: project builds and tests pass
+- [ ] [CP-2] After Foundational: data model verified
+- [ ] [CP-3] After each US: acceptance criteria pass

package/bundled/skills/refactor-workflow/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: "refactor-workflow"
 tier: 1
-description: "[Tier 1] End-to-end refactor workflow: analyze → plan → tasks → implement → review → commit. 6-phase behavior-preserving pipeline with mandatory test gates. (project)"
+description: "[Tier 1] End-to-end refactor workflow: analyze → plan → implement → review → commit. 5-phase behavior-preserving pipeline with mandatory test gates. (project)"
 ---
 
 refactor-workflow-SKILL.md
@@ -10,18 +10,17 @@ refactor-workflow/SKILL.md
 
 # PrizmKit Refactor Workflow
 
-End-to-end orchestration skill for code refactoring and optimization. Chains existing PrizmKit skills (tech-debt-tracker, plan, tasks, implement, code-review, committer) into a 6-phase behavior-preserving pipeline with mandatory test gates after each task.
+End-to-end orchestration skill for code refactoring and optimization. Chains existing PrizmKit skills (tech-debt-tracker, plan, implement, code-review, committer) into a 5-phase behavior-preserving pipeline with mandatory test gates after each task.
 
 ## Overview
 
 ```
 prizmkit.refactor <目标模块或描述>
   → Phase 1: Analyze   → refactor-analysis.md
-  → Phase 2: Plan      → plan.md
-  → Phase 3: Tasks     → tasks.md
-  → Phase 4: Implement → (code)
-  → Phase 5: Review    → (review report)
-  → Phase 6: Commit    → git commit
+  → Phase 2: Plan      → plan.md (including Tasks section)
+  → Phase 3: Implement → (code)
+  → Phase 4: Review    → (review report)
+  → Phase 5: Commit    → git commit
 ```
 
 ### Pipeline Phases
@@ -29,11 +28,10 @@ prizmkit.refactor <目标模块或描述>
 | Phase | Name | Skill Used | Artifact |
 |-------|------|-----------|----------|
 | 1 | Analyze 代码分析 | `prizmkit.tech-debt-tracker` + code reading | → `refactor-analysis.md` |
-| 2 | Plan 重构方案 | `prizmkit.plan` | → `plan.md` |
-| 3 | Tasks 任务拆解 | `prizmkit.tasks` | → `tasks.md` |
-| 4 | Implement 实现 | `prizmkit.implement` | (code changes) |
-| 5 | Code Review | `prizmkit.code-review` | (review report) |
-| 6 | Commit | `prizmkit.committer` | git commit |
+| 2 | Plan 重构方案与任务 | `prizmkit.plan` | → `plan.md` (含 Tasks section) |
+| 3 | Implement 实现 | `prizmkit.implement` | (code changes) |
+| 4 | Code Review | `prizmkit.code-review` | (review report) |
+| 5 | Commit | `prizmkit.committer` | git commit |
 
 ### Key Principles
 | Principle | Description |
@@ -46,8 +44,7 @@ prizmkit.refactor <目标模块或描述>
 ### Artifacts
 Refactor artifacts stored at `.prizmkit/refactor/<refactor-slug>/`:
 - **`refactor-analysis.md`** — Code analysis (Phase 1)
-- **`plan.md`** — Refactoring plan (Phase 2)
-- **`tasks.md`** — Task breakdown (Phase 3)
+- **`plan.md`** — Refactoring plan with Tasks section (Phase 2)
 
 ## Commands
 ### prizmkit.refactor \<目标模块或描述\>
@@ -82,51 +79,41 @@ Execute the full refactor pipeline for a module or code area.
    - **Scope Boundary**: what IS in scope, what is explicitly OUT of scope
 **CHECKPOINT CP-RW-1**: `refactor-analysis.md` exists with baseline test results.
 ---
-## Phase 2: Plan — 重构方案
-**Goal**: Generate technical refactoring plan that preserves behavior.
+## Phase 2: Plan — 重构方案与任务
+**Goal**: Generate technical refactoring plan that preserves behavior, including task breakdown.
 **STEPS:**
 1. **Read context**: refactor-analysis.md, `.prizm-docs/` (PATTERNS, RULES, TRAPS)
 2. **Invoke `prizmkit.plan`** with refactor-analysis.md as input (in place of spec.md):
    - Plan MUST specify: what changes, what stays the same, how behavior is preserved
+   - plan.md Tasks section: each task MUST be independently testable, MUST preserve all tests (green → green)
    - Artifact path: `.prizmkit/refactor/<refactor-slug>/plan.md`
 3. **Verify plan constraints**:
    - All public API contracts preserved
    - Test strategy: how to verify behavior unchanged at each step
    - Rollback strategy: how to revert if behavior breaks
-**CHECKPOINT CP-RW-2**: `plan.md` exists with behavior preservation strategy.
----
-## Phase 3: Tasks — 任务拆解
-**Goal**: Break refactoring plan into safe, atomic, testable tasks.
-**STEPS:**
-1. **Invoke `prizmkit.tasks`** with plan.md:
-   - Each task MUST be independently testable
-   - Each task MUST preserve all tests (green → green)
-   - Artifact path: `.prizmkit/refactor/<refactor-slug>/tasks.md`
-2. **Verify task safety**:
+   - Tasks ordered to minimize risk (safe renames first, structural changes later)
    - Every task ends with "run full test suite"
-   - No task introduces temporary test failures
-   - Tasks are ordered to minimize risk (safe renames first, structural changes later)
-**CHECKPOINT CP-RW-3**: `tasks.md` exists with test gates on every task.
+**CHECKPOINT CP-RW-2**: `plan.md` exists with behavior preservation strategy and Tasks section.
 ---
-## Phase 4: Implement — 实现
+## Phase 3: Implement — 实现
 **Goal**: Execute refactoring tasks with mandatory test verification after each task.
 **STEPS:**
-1. **For EACH task in tasks.md**:
+1. **For EACH task in plan.md Tasks section**:
    a. Implement the refactoring change
    b. **Run FULL test suite** (not just affected tests)
    c. Verify: all previously-passing tests still pass
    d. If any test fails → STOP, revert task, investigate
 2. **Progress tracking**:
-   - Mark tasks complete in tasks.md as they finish
+   - Mark tasks complete in plan.md Tasks section as they finish
    - Record test results after each task
-**CHECKPOINT CP-RW-4**: All tasks complete, full test suite green.
+**CHECKPOINT CP-RW-3**: All tasks complete, full test suite green.
 **KEY RULES:**
 - NEVER skip the test gate between tasks
 - NEVER allow temporary test failures ("we'll fix it in the next task")
 - If a task cannot be completed without breaking tests → split it into smaller tasks
 - Max 3 attempts per task before escalating to user
 ---
-## Phase 5: Code Review — 代码审查
+## Phase 4: Code Review — 代码审查
 **Goal**: Verify refactoring quality and behavior preservation.
 **STEPS:**
 1. **Invoke `prizmkit.code-review`** (scoped to changed files):
@@ -139,10 +126,10 @@ Execute the full refactor pipeline for a module or code area.
 2. **Run full test suite one final time**: All tests MUST pass
 3. **Handle review results**:
    - **PASS / PASS_WITH_WARNINGS**: Proceed to Phase 6
-   - **NEEDS_FIXES**: Return to Phase 4 (max 2 review rounds)
-**CHECKPOINT CP-RW-5**: Code review passes, all tests green.
+   - **NEEDS_FIXES**: Return to Phase 3 (max 2 review rounds)
+**CHECKPOINT CP-RW-4**: Code review passes, all tests green.
 ---
-## Phase 6: Commit — 提交
+## Phase 5: Commit — 提交
 **Goal**: Commit with refactor convention.
 **STEPS:**
 1. **Invoke `prizmkit.committer`**:
@@ -154,14 +141,14 @@ Execute the full refactor pipeline for a module or code area.
    - Updated module structure documentation
    - New PATTERNS discovered
    - Resolved TRAPS (remove if debt is paid)
-**CHECKPOINT CP-RW-6**: Commit recorded with `refactor()` prefix.
+**CHECKPOINT CP-RW-5**: Commit recorded with `refactor()` prefix.
 ---
 ## Fast Path — 快速路径
 For single-file refactoring (rename, extract method, <30 lines changed):
 ```
-Phase 1 (Analyze) → Phase 4 (Implement) → Phase 5 (Review) → Phase 6 (Commit)
+Phase 1 (Analyze) → Phase 3 (Implement) → Phase 4 (Review) → Phase 5 (Commit)
 ```
-Skip Phase 2 (Plan) and Phase 3 (Tasks).
+Skip Phase 2 (Plan).
 **CRITERIA** (ALL must be true):
 - Single file change
 - Estimated change < 30 lines
@@ -181,10 +168,9 @@ The pipeline supports resuming from the last completed phase by detecting existi
 |---------------|------------|
 | (nothing) | Phase 1: Analyze |
 | `refactor-analysis.md` only | Phase 2: Plan |
-| `refactor-analysis.md` + `plan.md` | Phase 3: Tasks |
-| All 3 docs | Phase 4: Implement |
-| All 3 docs + code changes exist | Phase 5: Review |
-| All 3 docs + review passed | Phase 6: Commit |
+| `refactor-analysis.md` + `plan.md` | Phase 3: Implement |
+| All docs + code changes exist | Phase 4: Review |
+| All docs + review passed | Phase 5: Commit |
 **Resume command**: `prizmkit.refactor <slug>` — if `<slug>` matches an existing `.prizmkit/refactor/<slug>/` directory, resume instead of starting fresh.
 ---
 ## Error Handling
@@ -203,11 +189,10 @@ The pipeline supports resuming from the last completed phase by detecting existi
 | Skill | Role in Refactor Workflow |
 |-------|--------------------------|
 | `prizmkit-tool-tech-debt-tracker` | Phase 1: identify debt and complexity |
-| `prizmkit-plan` | Phase 2: refactoring plan generation |
-| `prizmkit-tasks` | Phase 3: task breakdown |
-| `prizmkit-implement` | Phase 4: execute refactoring tasks |
-| `prizmkit-code-review` | Phase 5: review quality and behavior preservation |
-| `prizmkit-committer` | Phase 6: commit with `refactor()` convention |
+| `prizmkit-plan` | Phase 2: refactoring plan + task generation |
+| `prizmkit-implement` | Phase 3: execute refactoring tasks |
+| `prizmkit-code-review` | Phase 4: review quality and behavior preservation |
+| `prizmkit-committer` | Phase 5: commit with `refactor()` convention |
 | `feature-workflow` | Handoff target when new behavior is needed |
 | `prizmkit-specify` | NOT used (no user stories for refactoring) |
 | `prizmkit-analyze` | NOT used (no spec ↔ plan consistency needed) |
@@ -218,7 +203,7 @@ The pipeline supports resuming from the last completed phase by detecting existi
 | Dimension | Feature Workflow | Refactor Workflow | Bug Fix Pipeline |
 |-----------|-----------------|-------------------|------------------|
 | Input | Natural language requirement | Module/code target | Bug description |
-| Pipeline Phases | 7 (Fast: 5) | 6 (Fast: 4) | 5 (Fast: 3) |
+| Pipeline Phases | 6 (Fast: 4) | 5 (Fast: 3) | 5 (Fast: 3) |
 | Phase 1 | Specify (spec.md) | Analyze (refactor-analysis.md) | Triage (fix-plan.md) |
 | Artifact Path | `.prizmkit/specs/<slug>/` | `.prizmkit/refactor/<slug>/` | `.prizmkit/bugfix/<id>/` |
 | Commit Prefix | `feat(<scope>):` | `refactor(<scope>):` | `fix(<scope>):` |
@@ -230,9 +215,8 @@ The pipeline supports resuming from the last completed phase by detecting existi
 All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
 ## Output
 - `refactor-analysis.md` (Phase 1 artifact)
-- `plan.md` (Phase 2 artifact)
-- `tasks.md` (Phase 3 artifact)
-- Refactored implementation code (Phase 4)
-- Code review report (Phase 5, conversation only)
-- Git commit with `refactor(<scope>):` prefix (Phase 6)
+- `plan.md` with Tasks section (Phase 2 artifact)
+- Refactored implementation code (Phase 3)
+- Code review report (Phase 4, conversation only)
+- Git commit with `refactor(<scope>):` prefix (Phase 5)
 - Updated `.prizm-docs/` (if applicable)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.0.20",
+  "version": "1.0.22",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {

package/bundled/skills/prizmkit-tasks/SKILL.md

@@ -1,50 +0,0 @@
----
-name: "prizmkit-tasks"
-description: "Generate executable task breakdown from implementation plan. Creates tasks.md with dependency ordering, parallel markers, and file paths. Invoke after 'plan'. (project)"
----
-
-# PrizmKit Tasks
-
-Generate an executable task breakdown from an implementation plan. Produces tasks.md organized by phases with dependency ordering, parallel execution markers, and target file paths.
-
-## Commands
-
-### prizmkit.tasks
-
-Create a detailed task breakdown for implementation.
-
-**PRECONDITION:** `spec.md` and `plan.md` exist in `.prizmkit/specs/###-feature-name/`
-
-**STEPS:**
-
-1. Read `spec.md`, `plan.md`, `data-model.md` (if exists), `contracts/` (if exists)
-2. Generate `tasks.md` from template (`${SKILL_DIR}/assets/tasks-template.md`) organized by:
-   - Phase: Setup → Foundational → User Stories (US1→US2→...) → Polish
-   - Each task: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
-   - `[P]` marker for tasks that can run in parallel
-   - Each user story section is independently implementable and testable
-3. Implementation strategy selection (ask user):
-   - **MVP-first**: core features → iterate
-   - **Incremental**: story-by-story delivery
-   - **Parallel**: independent stories in parallel
-4. Include checkpoint tasks between phases for validation
-5. Output: `tasks.md` path and task count summary
-
-**KEY RULES:**
-- Task IDs use zero-padded numbering: `[T-001]`, `[T-010]`, `[T-100]`
-- Setup tasks start at T-001, Foundational at T-010, User Stories at T-100+, Polish at T-900
-- Every task MUST reference a target file path
-- `[P]` marker indicates tasks that can execute in parallel within their phase
-- Checkpoint tasks MUST appear between phases
-- Each user story section MUST be independently testable
-
-**HANDOFF:** `prizmkit.implement`
-
-## Template
-
-The tasks template is located at `${SKILL_DIR}/assets/tasks-template.md`.
-
-## Output
-
-All outputs are written to `.prizmkit/specs/###-feature-name/`:
-- `tasks.md` — The task breakdown

package/bundled/skills/prizmkit-tasks/assets/tasks-template.md

@@ -1,21 +0,0 @@
-# Tasks: [FEATURE_TITLE]
-
-## Strategy: [MVP-first | Incremental | Parallel]
-
-## Phase: Setup
-- [ ] [T-001] Project scaffolding — file: [path]
-
-## Phase: Foundational
-- [ ] [T-010] [Data model / Schema changes] — file: [path]
-
-## Phase: User Story 1 — [Title]
-- [ ] [T-100] [P] [US1] [Task description] — file: [path]
-
-## Phase: Polish
-- [ ] [T-900] Final integration test
-- [ ] [T-901] Documentation update
-
-## Checkpoints
-- [ ] [CP-1] After Setup: project builds and tests pass
-- [ ] [CP-2] After Foundational: data model verified
-- [ ] [CP-3] After each US: acceptance criteria pass