@zmice/zc 0.1.0 → 0.2.0

package/vendor/packages/toolkit/src/content/skills/spec-driven-development/body.md

@@ -0,0 +1,49 @@
+# 规格驱动开发
+
+## 何时使用
+
+- 启动新项目或新功能
+- 需求不完整、存在歧义或只有模糊想法
+- 变更会影响多个文件、模块或接口边界
+- 需要先把“完成标准”说清楚再进入实现
+
+不适用于单行修复、拼写修改或完全自包含的小改动。
+
+## 输入前提
+
+- 已知道当前要解决的大致问题
+- 愿意先澄清假设，而不是边写边猜
+- 接受规格会成为后续计划、实现和审查的共同事实来源
+
+## 执行步骤
+
+1. 先列出假设，显式暴露你准备默认成立的前提
+2. 把模糊需求重写成具体、可验证的成功标准
+3. 编写结构化规格，至少覆盖：
+   - Objective
+   - Commands
+   - Project Structure
+   - Code Style
+   - Testing Strategy
+   - Boundaries
+4. 标记开放问题和风险点，等待人类确认
+5. 规格确认后，再进入 `planning-and-task-breakdown`
+
+## 成功标准
+
+- 规格能清楚回答“做什么、为什么做、怎么判定完成”
+- 假设和边界是显式的，而不是藏在正文里
+- 成功标准是可测试的，不是感受性描述
+- 人类可以基于规格明确批准或驳回方案
+
+## 相关原则
+
+- 先澄清假设，再写规格
+- 规格先于实现，不接受“先写后补”
+- 范围边界必须写出来，不能靠默契
+
+## 与其他技能的衔接
+
+- 与 `engineering-principles` 配合，约束规格阶段的工作方式
+- 规格确认后交给 `planning-and-task-breakdown`
+- 实现阶段由 `incremental-implementation` 和 `test-driven-development` 消费规格

package/vendor/packages/toolkit/src/content/skills/spec-driven-development/meta.yaml

@@ -0,0 +1,20 @@
+kind: skill
+name: spec-driven-development
+title: 规格驱动开发
+description: 先写规格，再写代码。适用于启动新项目、新功能或重大变更，且尚未存在规格说明的场景；也适用于需求不清晰、存在歧义或只有模糊想法的情况。
+tier: core
+audience: default
+stability: stable
+suggests:
+  - skill:engineering-principles
+platforms:
+  - qwen
+  - codex
+  - qoder
+source:
+  upstream: agent-skills
+  strategy: adapted
+  origin_name: spec-driven-development
+  origin_path: skills/spec-driven-development/SKILL.md
+  origin_id: skill:spec-driven-development
+  notes: 规格先行的主工作流来自上游方法论，并按本仓库术语重写

package/vendor/packages/toolkit/src/content/skills/sprint-retrospective/body.md

@@ -0,0 +1,336 @@
+# Sprint Retrospective
+
+## Overview
+
+The retrospective closes the feedback loop: **Think → Plan → Build → Review → Reflect**. Without it, you repeat mistakes, forget wins, and let process drift go unnoticed.
+
+A good retro is not a blame session. It's a data-driven inspection of what happened, why it happened, and what concrete actions follow. The output is a short list of improvements with owners and deadlines — not a philosophical essay about team culture.
+
+**The standard:** Every retro produces at least one measurable action item that changes how the next cycle works. If a retro produces zero changes, it was theater.
+
+## When to Use
+
+- After completing an SDD+TDD cycle (the natural "Reflect" phase)
+- After finishing a week-long development sprint
+- After a project milestone is delivered
+- After a production incident or major unexpected change
+- When you notice recurring friction but can't pinpoint the cause
+- Before starting a new major initiative (retrospect on the last one first)
+
+## The Retrospective Flow
+
+### Step 1: Data Collection — Git & Project Metrics
+
+Start with facts, not feelings. Gather quantitative data before any discussion.
+
+**Git statistics to collect:**
+```
+git log --oneline --since="<sprint-start>" --until="<sprint-end>" | wc -l   # commit count
+git diff --stat <start-sha>..<end-sha>                                       # files changed, insertions/deletions
+git shortlog -sn --since="<sprint-start>"                                    # commits per author/agent
+```
+
+**Key metrics to extract:**
+```
+SPRINT DATA COLLECTION:
+- Total commits: ___
+- Files changed: ___
+- Lines added: ___
+- Lines deleted: ___
+- Net LOC change: ___ (added minus deleted)
+- Test files added/modified: ___
+- Spec files created/updated: ___
+- Number of PRs/merges: ___
+- Average PR size (lines changed): ___
+```
+
+**Automation tip:** If using a monorepo, scope stats to the relevant package or directory. Noise from unrelated areas corrupts the analysis.
+
+**Test coverage delta:**
+```
+Coverage at sprint start: ___%
+Coverage at sprint end:   ___%
+Delta:                    ___% (positive = improvement)
+```
+
+### Step 2: What Went Well
+
+Identify decisions, practices, and patterns that worked. Be specific — "good teamwork" is useless; "splitting the auth module into three focused PRs made review 3x faster" is actionable.
+
+**Questions to answer:**
+- Which technical decisions paid off? Why?
+- Which process practices saved time or caught issues early?
+- Were there moments where TDD or spec-first approach prevented bugs?
+- Did any tool, pattern, or convention prove especially valuable?
+- What would you deliberately repeat in the next cycle?
+
+**Format each item as:**
+```
+✓ [What happened] → [Why it worked] → [How to reinforce it]
+Example:
+✓ Writing integration tests before refactoring the payment module
+  → Caught 3 regression bugs during refactoring that unit tests missed
+  → Continue requiring integration tests for any module with external dependencies
+```
+
+### Step 3: What Didn't Go Well
+
+Identify problems, bottlenecks, surprises, and friction. No blame — focus on systemic causes, not individual mistakes.
+
+**Questions to answer:**
+- Where did you spend time that didn't produce value?
+- What tasks took significantly longer than estimated? Why?
+- Were there repeated context switches or interruptions?
+- Did any technical decision create unexpected problems?
+- Were there communication gaps (unclear specs, missing context)?
+- Did any dependency or external factor block progress?
+
+**Format each item as:**
+```
+✗ [What happened] → [Root cause] → [Impact]
+Example:
+✗ Database migration failed in staging after passing locally
+  → Root cause: local DB had stale test data that masked a constraint violation
+  → Impact: 4 hours debugging + delayed the release by 1 day
+```
+
+**The Five Whys:** For significant problems, ask "why" five times to find the root cause. Surface symptoms hide systemic issues.
+
+### Step 4: Spec Drift Check
+
+Compare the final deliverable against the original specification. Drift is normal — unacknowledged drift is dangerous.
+
+```
+SPEC DRIFT ANALYSIS:
+- Original spec items:        ___
+- Delivered as specified:      ___
+- Delivered with modifications: ___
+- Deferred to next cycle:      ___
+- Added (not in original spec): ___
+- Dropped (decided not to do):  ___
+
+Drift rate: (modified + deferred + added + dropped) / original × 100 = ___%
+```
+
+**Acceptable drift:** 10–20% is normal for a healthy cycle. Scope adjustments happen.
+
+**Warning signs:**
+- Drift > 30%: Specs are not detailed enough, or requirements changed mid-cycle without formal acknowledgment
+- Many "added" items: Scope creep — features being added without cutting something else
+- Many "deferred" items: Over-commitment — planning more than capacity allows
+- Modifications without spec updates: The spec is now a lie — update it or delete it
+
+### Step 5: Process Health Metrics
+
+Evaluate how well the development process itself performed.
+
+```
+PROCESS HEALTH:
+- TDD compliance rate:    ___% (changes with tests written first / total changes)
+- Spec coverage:          ___% (features with specs / total features)
+- Review pass rate:       ___% (PRs approved on first review / total PRs)
+- Build stability:        ___% (green builds / total builds)
+- Verification pass rate: ___% (changes passing verification on first attempt)
+- Avg time from PR open to merge: ___
+- Rework rate:            ___% (commits that fix issues in same-sprint code)
+```
+
+**Healthy benchmarks:**
+| Metric | Healthy | Warning | Critical |
+|--------|---------|---------|----------|
+| TDD compliance | >80% | 50–80% | <50% |
+| Review pass rate | >60% | 30–60% | <30% |
+| Build stability | >90% | 70–90% | <70% |
+| Spec drift | <20% | 20–30% | >30% |
+| Rework rate | <15% | 15–30% | >30% |
+
+### Step 6: Action Items
+
+The most important step. Every problem identified must either get an action item or an explicit "accepted — not worth fixing."
+
+**Each action item must have:**
+```
+ACTION ITEM:
+- What:     [Specific, measurable change]
+- Why:      [Which problem from Steps 3–5 does this address]
+- Owner:    [Who is responsible for implementing this]
+- Deadline: [When will this be done — must be before next retro]
+- Success:  [How do we know it worked]
+```
+
+**Rules for action items:**
+1. **Maximum 3–5 items per retro.** More than 5 means nothing gets done. Prioritize ruthlessly.
+2. **Must be specific.** "Improve testing" is not an action item. "Add integration tests for all payment endpoints by Friday" is.
+3. **Must have an owner.** Unowned items are wishes, not actions.
+4. **Must have a deadline.** Items without deadlines drift indefinitely.
+5. **Review last retro's items first.** Before creating new items, check: did last cycle's actions get completed? If not, why?
+
+**Anti-patterns in action items:**
+| Bad | Good |
+|-----|------|
+| "Write more tests" | "Achieve 80% coverage on `src/core/` by end of next sprint" |
+| "Improve code review" | "Add a review checklist to the PR template by Wednesday" |
+| "Be more careful with migrations" | "Add a staging migration dry-run step to CI pipeline by Friday" |
+| "Communicate better" | "Write a 3-line summary in each PR description explaining the 'why'" |
+
+### Step 7: Knowledge Capture
+
+Record lessons that have value beyond this sprint. These become organizational memory.
+
+**What to capture:**
+- Technical discoveries (performance tricks, library gotchas, infrastructure quirks)
+- Process insights (what made this cycle smoother or harder than usual)
+- Decision rationale (why did we choose approach A over B — future you will ask)
+- Reusable patterns (solutions that should become templates or utilities)
+
+**Format:**
+```
+LESSON LEARNED:
+- Context: [Situation that triggered the learning]
+- Insight: [What we now know]
+- Application: [How to apply this going forward]
+- Tags: [Keywords for future retrieval]
+```
+
+**Where to store:** Use the AI memory system, project wiki, or ADR (Architecture Decision Records) depending on the type of knowledge. Technical decisions → ADR. Process insights → retro archive. Reusable code patterns → shared utilities.
+
+## Output Template
+
+```markdown
+# Sprint Retrospective: [Sprint Name / Date Range]
+
+## Period
+- Start: YYYY-MM-DD
+- End: YYYY-MM-DD
+
+## Metrics Summary
+| Metric | Value | Trend |
+|--------|-------|-------|
+| Commits | ___ | ↑/↓/→ |
+| Lines added | ___ | |
+| Lines deleted | ___ | |
+| Net LOC | ___ | |
+| Test coverage | ___% | |
+| PR count | ___ | |
+| Avg PR size | ___ lines | |
+
+## What Went Well
+1. ...
+2. ...
+
+## What Didn't Go Well
+1. ...
+2. ...
+
+## Spec Drift
+- Drift rate: ___%
+- Key deviations: ...
+
+## Process Health
+| Metric | Value | Status |
+|--------|-------|--------|
+| TDD compliance | ___% | ✓/⚠/✗ |
+| Review pass rate | ___% | ✓/⚠/✗ |
+| Build stability | ___% | ✓/⚠/✗ |
+| Rework rate | ___% | ✓/⚠/✗ |
+
+## Previous Action Items Review
+- [ ] [Item from last retro] — Status: Done/In Progress/Not Started
+
+## New Action Items
+1. **[What]** — Owner: ___ — Deadline: ___ — Addresses: [problem ref]
+2. ...
+3. ...
+
+## Lessons Learned
+1. ...
+```
+
+## Quantitative Indicators to Track Over Time
+
+Track these across sprints to spot trends:
+
+**Velocity indicators:**
+- Commits per sprint (is pace sustainable?)
+- Net LOC change (is codebase growing/shrinking appropriately?)
+- Features delivered vs. planned (commitment accuracy)
+
+**Quality indicators:**
+- Test coverage trend (improving or degrading?)
+- Rework rate (are we fixing our own bugs within the sprint?)
+- Review pass rate (is code quality at submission improving?)
+- Build break frequency (is CI staying green?)
+
+**Process indicators:**
+- Spec drift rate (are we getting better at planning?)
+- TDD compliance (are we actually doing what we say we do?)
+- Time from PR open to merge (is review a bottleneck?)
+- Action item completion rate from previous retros (do retros actually change anything?)
+
+## Red Flags
+
+These signals mean the process needs immediate attention:
+
+- **Retro produces no action items** — The retro was performative, not useful
+- **Same problems appear in consecutive retros** — Action items aren't working or aren't being implemented
+- **Action item completion rate < 50%** — You're creating items you can't or won't do
+- **Spec drift > 40%** — Planning is disconnected from reality
+- **Rework rate > 30%** — Quality at first submission is too low
+- **Test coverage declining sprint over sprint** — Technical debt is accumulating
+- **Build stability < 70%** — The CI pipeline is unreliable and people stop trusting it
+- **No one can name what went well** — Morale problem or lack of awareness of team wins
+- **Retro skipped "because we're too busy"** — The team most needing reflection is avoiding it
+- **All action items are vague or lack owners** — The retro is generating wishes, not commitments
+
+## Integration with SDD+TDD Workflow
+
+The retrospective is **Phase 5: Reflect** in the full development cycle:
+
+```
+Phase 1: Spec    → Define what to build (spec-driven-development)
+Phase 2: Design  → Design the solution (sdd-tdd-workflow)
+Phase 3: Build   → Implement with TDD (test-driven-development)
+Phase 4: Review  → Verify quality (code-review-and-quality)
+Phase 5: Reflect → Retrospect and improve (this skill)
+    │
+    └──→ Feed improvements back into Phase 1 of the next cycle
+```
+
+**What flows from retro back into the next cycle:**
+- Spec drift insights → Better spec writing in Phase 1
+- Review feedback patterns → Updated review checklists in Phase 4
+- TDD compliance gaps → Adjusted TDD practices in Phase 3
+- Process bottlenecks → Workflow changes for the next sprint
+- Technical lessons → Updated conventions and patterns
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "We don't have time for retros" | You don't have time to keep making the same mistakes. A 30-minute retro saves hours of repeated friction. |
+| "Everything went fine, nothing to discuss" | No sprint is perfect. If you can't find improvements, you're not looking hard enough. |
+| "We already know what to improve" | Knowing and doing are different. The retro creates accountability through action items with owners. |
+| "Metrics don't apply to our work" | If you can't measure it, you can't improve it. Even rough numbers beat no numbers. |
+| "Action items from last retro weren't relevant anymore" | Then the retro failed at creating durable improvements. Make items smaller and more immediate. |
+
+## See Also
+
+- For spec-driven development workflow, see `spec-driven-development`
+- For TDD practices, see `test-driven-development`
+- For code review process, see `code-review-and-quality`
+- For SDD+TDD combined workflow, see `sdd-tdd-workflow`
+- For task planning and breakdown, see `planning-and-task-breakdown`
+
+## Verification
+
+After completing a retrospective:
+
+- [ ] Git metrics collected and documented
+- [ ] What went well — at least 3 specific items identified
+- [ ] What didn't go well — root causes analyzed (not just symptoms)
+- [ ] Spec drift calculated and analyzed
+- [ ] Process health metrics computed against benchmarks
+- [ ] Previous retro's action items reviewed for completion
+- [ ] New action items created (3–5 max, each with owner + deadline)
+- [ ] Lessons captured in appropriate knowledge stores
+- [ ] Retro report saved in project archive

package/vendor/packages/toolkit/src/content/skills/sprint-retrospective/meta.yaml

@@ -0,0 +1,17 @@
+kind: skill
+name: sprint-retrospective
+title: 迭代回顾
+description: 在开发周期结束后执行结构化 Sprint 回顾。适用于完成一轮 SDD+TDD、结束一周工作、达到里程碑或事故恢复后，通过 git 指标、Spec 偏差和瓶颈分析产出可执行改进项。
+tier: recommended
+audience: default
+stability: stable
+suggests:
+  - skill:documentation-and-adrs
+platforms:
+  - qwen
+  - codex
+  - qoder
+source:
+  upstream: toolkit-original
+  strategy: curated
+  notes: 本仓库为开发周期闭环补充的回顾能力。

package/vendor/packages/toolkit/src/content/skills/subagent-driven-development/body.md

@@ -0,0 +1,228 @@
+# Subagent-Driven Development
+
+## Overview
+
+通过为每个任务分派独立的子代理来执行实现计划，每个任务完成后进行两阶段审查：先验证规格合规性，再验证代码质量。
+
+**核心原则：每任务一个新子代理 + 两阶段审查 = 高质量 + 快速迭代**
+
+为什么要用子代理：你将任务委派给隔离上下文的专门代理。通过精心构造它们的指令和上下文，确保它们专注且成功。子代理不应继承你的会话上下文 — 你精确构造它们所需的一切。这也保护你自己的上下文用于协调工作。
+
+## When to Use
+
+决策树：
+
+```
+有实现计划？ ─── 否 ──→ 先用 /task-plan 或 brainstorming-and-design
+    │
+   是
+    ▼
+任务大多独立？ ─── 否（紧耦合）──→ 手动执行或串行构建
+    │
+   是
+    ▼
+需要并行执行？ ─── 否 ──→ subagent-driven-development（本技能）
+    │
+   是
+    ▼
+parallel-agent-dispatch
+```
+
+### vs 手动执行
+- 子代理自然遵循 TDD
+- 每任务新鲜上下文（无污染）
+- 子代理可以在开始前提问
+- 审查检查点自动化
+
+### vs parallel-agent-dispatch
+- 本技能：串行执行，同一会话，持续推进
+- parallel-agent-dispatch：并行执行，多代理同时工作
+
+## 执行流程
+
+```
+读取计划，提取所有任务
+    │
+    ▼
+┌─────────────────── 每个任务循环 ───────────────────┐
+│                                                      │
+│  1. 分派实现子代理（携带完整任务文本 + 上下文）      │
+│     │                                                │
+│     ├─ 子代理提问？ → 提供上下文，重新分派            │
+│     │                                                │
+│     └─ 子代理实现 → 测试 → 提交 → 自审               │
+│                                                      │
+│  2. 分派规格审查子代理                                │
+│     │                                                │
+│     ├─ 规格不合规？ → 实现者修复 → 重新审查           │
+│     │                                                │
+│     └─ 规格合规 ✓                                    │
+│                                                      │
+│  3. 分派代码质量审查子代理                            │
+│     │                                                │
+│     ├─ 质量不过关？ → 实现者修复 → 重新审查           │
+│     │                                                │
+│     └─ 质量通过 ✓                                    │
+│                                                      │
+│  4. 标记任务完成                                      │
+│                                                      │
+└──────────────── 更多任务？继续循环 ─────────────────┘
+    │
+    ▼
+分派最终代码审查子代理（整体实现）
+    │
+    ▼
+完成
+```
+
+## 三个角色
+
+### 实现者（Implementer）
+
+职责：按任务规格实现代码，遵循 TDD，提交变更。
+
+提示模板要点：
+```
+你是一个实现代理。你的任务是：
+- 严格按照给定的任务规格实现
+- 遵循 TDD：先写失败测试，再写最小实现
+- 完成后执行内联自审检查清单，修复发现的问题
+- 提交代码
+
+任务文本：[完整任务描述]
+相关上下文：[文件列表、模式示例、约束]
+项目约定：[命名、目录结构、测试框架]
+```
+
+**实现者内联自审检查清单**（提交前必做，替代部分审查子代理开销）：
+1. **规格覆盖扫描** — 逐条检查任务要求，确认每条都已实现，无遗漏无多余
+2. **占位符扫描** — 搜索 TODO、TBD、FIXME、空方法体、硬编码魔法值
+3. **一致性检查** — 命名是否与计划中其他任务一致？接口签名是否匹配？
+4. **简洁性检查** — 是否存在过度工程？能否用更少代码实现同样效果？
+
+### 规格审查员（Spec Reviewer）
+
+职责：验证实现是否完全匹配任务规格 — 不多不少。
+
+审查要点：
+```
+- 所有规格要求是否都已实现？
+- 是否有超出规格的额外实现？（over-building）
+- 接口是否与规格一致？
+- 测试是否覆盖规格中的验收条件？
+```
+
+### 代码质量审查员（Code Quality Reviewer）
+
+职责：检查实现的工程质量（不关心规格合规，那是上一步的事）。
+
+审查要点：
+```
+- 代码可读性和清晰度
+- 命名一致性
+- 错误处理完整性
+- 性能考量
+- 安全实践
+- 测试质量
+```
+
+## 子代理状态处理
+
+子代理报告四种状态之一：
+
+| 状态 | 含义 | 处理方式 |
+|------|------|---------|
+| **DONE** | 任务完成 | 进入规格审查 |
+| **DONE_WITH_CONCERNS** | 完成但有疑虑 | 先读取疑虑，评估后决定是否处理 |
+| **NEEDS_CONTEXT** | 需要更多信息 | 提供缺失上下文，重新分派 |
+| **BLOCKED** | 无法完成 | 评估阻塞原因（见下方） |
+
+**BLOCKED 的处理：**
+1. 如果是上下文问题 → 提供更多上下文，重新分派
+2. 如果任务需要更强推理 → 用更强模型重新分派
+3. 如果任务太大 → 拆分为更小的子任务
+4. 如果计划本身有问题 → 上报给人类
+
+**永远不要忽略阻塞或让同一模型不做任何改变就重试。** 如果子代理说卡住了，必须有所改变。
+
+## 审查策略选择
+
+并非所有任务都需要完整的三角色审查流。根据任务复杂度选择审查策略：
+
+| 任务特征 | 推荐审查策略 |
+|---------|------------|
+| 涉及 1-2 个文件，规格明确，机械性实现 | **轻量审查**：仅实现者自审 + 代码质量审查（跳过规格审查子代理） |
+| 涉及多文件，有接口/集成关注点 | **标准审查**：完整三角色（实现者自审 + 规格审查 + 质量审查） |
+| 涉及设计判断或广泛代码库理解 | **加强审查**：完整三角色 + 更强模型 |
+
+> **经验参考**：superpowers 项目实测发现，充分的实现者自审可替代大部分审查子代理的工作，将单任务审查时间从 ~25min 降至 ~30s，且缺陷捕获率相当。关键在于实现者自审检查清单的严格执行。
+
+## 模型选择指南
+
+用最经济的模型处理每个角色，节省成本提高速度。
+
+| 任务复杂度信号 | 推荐模型级别 |
+|--------------|------------|
+| 涉及 1-2 个文件，规格完整 | 快速/经济模型 |
+| 涉及多文件，有集成关注点 | 标准模型 |
+| 需要设计判断或广泛代码库理解 | 最强模型 |
+
+大多数实现任务在计划良好时都是机械性的 → 用快速模型。
+
+审查任务需要判断力 → 用标准或更强模型。
+
+## 示例工作流
+
+```
+控制器：按子代理驱动模式执行计划。
+
+[读取计划文件，提取全部 5 个任务的完整文本和上下文]
+[创建 TodoWrite 追踪所有任务]
+
+Task 1: 用户认证模块
+├─ [分派实现子代理 + 完整任务文本 + 上下文]
+├─ 实现者："开始前确认 — 密码哈希用 bcrypt 还是 argon2？"
+├─ 控制器："用 argon2，项目中已有依赖"
+├─ 实现者：实现完成，5/5 测试通过，已提交
+├─ [分派规格审查子代理]
+├─ 规格审查：✅ 所有要求满足，无额外内容
+├─ [分派代码质量审查子代理]
+├─ 质量审查：✅ 通过
+└─ [标记 Task 1 完成]
+
+Task 2: 会话管理
+├─ [分派实现子代理 + 完整任务文本 + 上下文]
+├─ 实现者：实现完成，8/8 测试通过
+├─ [分派规格审查子代理]
+├─ 规格审查：❌ 缺少"每100项报告进度"的要求
+├─ 实现者：修复，添加进度报告
+├─ 规格审查：✅ 合规
+├─ [分派代码质量审查子代理]
+├─ 质量审查：有 Magic Number (100)
+├─ 实现者：提取为 PROGRESS_INTERVAL 常量
+├─ 质量审查：✅ 通过
+└─ [标记 Task 2 完成]
+
+... 重复直到所有任务完成 ...
+
+[分派最终整体审查子代理]
+最终审查：✅ 所有要求满足，可合并
+完成！
+```
+
+## 与其他技能的衔接
+
+- **planning-and-task-breakdown** — 上游：生成子代理执行的任务计划
+- **test-driven-development** — 每个实现子代理内部遵循 TDD 循环
+- **verification-before-completion** — 每个审查阶段遵循验证铁律
+- **code-review-and-quality** — 最终整体审查使用五维度审查
+- **parallel-agent-dispatch** — 姊妹技能：并行版本的子代理调度
+
+## Red Flags
+
+- 控制器直接动手实现而不分派子代理
+- 跳过规格审查直接进入代码质量审查
+- 子代理报告 BLOCKED 后不做改变就重试
+- 所有任务用同一个最强模型（浪费资源）
+- 子代理间共享上下文（违背隔离原则）
+- 没有最终的整体审查就声明完成

package/vendor/packages/toolkit/src/content/skills/subagent-driven-development/meta.yaml

@@ -0,0 +1,19 @@
+kind: skill
+name: subagent-driven-development
+title: 子代理驱动开发
+description: 在执行实现计划且任务彼此独立时使用。为每个任务派发全新子代理，并配套规范符合性与代码质量两阶段审查，以提升迭代速度和上下文隔离质量。
+tier: recommended
+audience: advanced
+stability: stable
+suggests:
+  - skill:planning-and-task-breakdown
+  - skill:verification-before-completion
+  - skill:code-review-and-quality
+platforms:
+  - qwen
+  - codex
+  - qoder
+source:
+  upstream: toolkit-original
+  strategy: curated
+  notes: 本仓库围绕串行子代理开发流程整理的原生能力。