@jtf19/vibecoding-kit 0.1.0

package/skills/vibe-subagent-driven-development/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: vibe-subagent-driven-development
+description: Use after parallel work and workspace isolation checks when independent task briefs are ready and you need to decide whether subagent execution is allowed, safe, and reviewable without introducing automatic runtime orchestration.
+---
+
+# Vibe Subagent Driven Development
+
+## 目标
+
+在任务 brief 已经拆清、工作区边界已经确认、用户明确允许的前提下，判断是否可以建议使用 subagent 执行，并明确 subagent brief、任务级 review、最终 review 和回退路径。
+
+本 skill 只做 subagent 执行 gate、handoff 和 review 检查点设计，不自动调用 subagent，不选择模型，不生成 review package，不维护 progress ledger runtime，不引入 MCP、agent graph 或后台 worker。
+
+## Gate Contract
+
+```text
+gate_kind: subagent_review_gate
+must_not_skip: when_subagent_or_parallel_execution_is_requested
+approval_required_before: subagent_execution
+terminal_next_skill: vibe-verification-before-completion | vibe-dispatching-parallel-work | vibe-writing-plans | vibe-workspace-isolation | vibe-test-driven-development | vibe-executing-plans | vibe-receiving-code-review | vibe-systematic-debugging | none
+review_blocker_stops_next_task: true
+completion_requires_evidence: true
+```
+
+## 适用场景
+
+- `vibe-dispatching-parallel-work` 已确认任务独立，并产出自包含任务 brief。
+- `vibe-workspace-isolation` 已确认当前工作区可原地工作、已隔离，或用户已明确确认隔离策略。
+- 用户明确允许考虑 subagent、外部 agent 或人工并行执行。
+- 任务需要在执行前明确任务级 review gate 和最终 review gate。
+- 需要判断是否回退到 `vibe-executing-plans` 顺序执行。
+
+## 输入
+
+- 实施计划和任务 brief。
+- 每个任务的目标、范围、输入证据、禁止修改、依赖、预期输出、验证方式和完成后回报。
+- 当前工作区隔离判断结果。
+- 用户是否允许 subagent 或并行执行。
+- 平台是否实际支持 subagent；不确定时按不支持处理。
+- review 要求、验收标准、提交边界和停止条件。
+
+## 前置条件
+
+建议进入 subagent 执行前必须同时满足：
+
+- 用户明确允许使用 subagent、外部 agent 或人工并行执行。
+- 每个任务 brief 自包含，不依赖完整聊天历史。
+- 每个任务文件范围清楚，且不会同时写同一文件、同一状态或同一临时目录。
+- 每个任务都有独立验证方式和完成后回报格式。
+- 工作区边界已经由 `vibe-workspace-isolation` 确认。
+- 任务级 review gate 和最终 review gate 已明确。
+- 失败、阻塞、范围变化和用户确认路径清楚。
+
+任一条件不满足，都不能建议 subagent 执行。
+
+## 工作流
+
+1. 复核 `vibe-dispatching-parallel-work` 输出的任务 brief 是否完整、自包含、可独立验证。
+2. 复核工作区隔离结果是否允许继续执行。
+3. 确认用户是否明确允许 subagent；未明确允许时停止或回退顺序执行。
+4. 为每个候选任务列出 subagent 执行前必须包含的 brief 字段。
+5. 定义任务级 review gate：规格符合、范围未越界、验证证据存在、无 Critical / Important 阻塞。
+6. 定义最终 review gate：跨任务冲突、共享入口一致性、验证证据汇总、未处理风险。
+7. 判断后续策略：建议 subagent、回退顺序执行、重新拆分或停止等待确认。
+8. 输出下一步 skill 和 `Workflow Handoff`。
+
+## Progress Ledger Discipline
+
+- 开始前先读取已有 progress ledger、任务记录或人工任务清单；没有 ledger 时显式说明基线为空。
+- 已完成、已派发或已 review clean 的任务不能重复派发；需要重跑时必须说明原因和新边界。
+- 任一任务 review 出现 Critical / Important 阻塞时，不进入下一任务；先进入 fixer / feedback 处理路径，再重新 review。
+- ledger 只能作为人工/本地合同输入；本 skill 不创建 runtime ledger，不写 `.vibecoding-state/`，不调用 subagent。
+
+## 输出
+
+必须输出：
+
+- subagent gate 结论：建议 subagent / 回退顺序执行 / 重新拆分 / 等待确认。
+- 用户许可状态。
+- 工作区边界状态。
+- 任务 brief 完整性检查。
+- 任务级 review gate。
+- 最终 review gate。
+- 回退路径。
+- 下一步 skill。
+- `Workflow Handoff`。
+
+## Subagent brief 最小结构
+
+```text
+任务名称：
+目标：
+范围：
+输入证据：
+禁止修改：
+依赖：
+预期输出：
+验证方式：
+完成后回报：
+review gate：
+stop condition：
+```
+
+## Implementer report artifact 最小结构
+
+SDD adapter result 交回 runtime 前，必须有本地 report 文件绑定：
+
+```text
+artifact_kind: sdd-implementer-report
+task_id:
+brief_digest:
+status: DONE | QUESTIONS | BLOCKED
+commits:
+tests:
+self_review:
+concerns:
+questions:
+```
+
+`DONE` 需要 test summary 和 self-review summary，且 review gate clean 后才允许推进下一 task。`QUESTIONS` 和 `BLOCKED` 都保留 active task，不触发后续 task。
+
+## Review gate
+
+任务级 review gate 至少包含：
+
+- 是否满足任务 brief。
+- 是否越过文件或状态边界。
+- 是否给出验证命令、人工检查或未验证原因。
+- 是否存在 Critical / Important 阻塞。
+- 是否需要回到 `vibe-receiving-code-review`、`vibe-test-driven-development` 或 `vibe-systematic-debugging`。
+
+最终 review gate 至少包含：
+
+- 多任务改动是否冲突。
+- 共享入口、模板、文档和 doctor marker 是否一致。
+- 验证证据是否覆盖整体交付。
+- 未处理风险是否可接受。
+- 是否可以进入 `vibe-verification-before-completion`。
+
+## 与其他 skill 的关系
+
+- `vibe-dispatching-parallel-work` 负责判断任务独立性和产出任务 brief。
+- `vibe-workspace-isolation` 负责判断当前工作区是否安全或需要用户确认隔离。
+- `vibe-subagent-driven-development` 负责判断是否允许把 brief 交给 subagent 执行，并定义 review gate。
+- `vibe-executing-plans` 负责不使用 subagent 时的顺序执行。
+- `vibe-requesting-code-review` 和 `vibe-review` 负责正式 review 请求和审查行为。
+- `vibe-receiving-code-review` 负责处理 review feedback。
+
+## 禁止事项
+
+- 不要自动调用 subagent。
+- 不要声称已经并行执行。
+- 不要选择模型或生成模型策略。
+- 不要生成 review package、diff 文件或 reviewer prompt 文件。
+- 不要维护 progress ledger runtime。
+- 不要在用户未明确允许时建议 subagent 执行。
+- 不要让 subagent brief 依赖完整聊天历史。
+- 不要跳过 `vibe-dispatching-parallel-work` 的任务独立性判断。
+- 不要跳过 `vibe-workspace-isolation` 的工作区边界判断。
+- 不要把 subagent-driven development 写成默认必经链路。
+- 不要引入 MCP、agent graph、后台 worker 或平台私有 runtime。
+
+## 下一步调用
+
+- brief 完整、用户允许、工作区边界清楚，且后续执行和 review gate 已完成：`next_skill: vibe-verification-before-completion`。
+- brief 不完整或任务边界不清：`next_skill: vibe-dispatching-parallel-work` 或 `next_skill: vibe-writing-plans`。
+- 工作区边界未确认：`next_skill: vibe-workspace-isolation`。
+- 用户不允许 subagent、平台不支持或任务强耦合但可顺序执行：`next_skill: vibe-test-driven-development` 或 `next_skill: vibe-executing-plans`。
+- review feedback 需要处理：`next_skill: vibe-receiving-code-review`。
+- 验证失败且原因不明：`next_skill: vibe-systematic-debugging`。
+- 缺少关键输入或必须等待用户确认：`next_skill: none`。
+
+## 示例输出结构
+
+```text
+subagent gate：
+用户许可：
+工作区边界：
+brief 完整性：
+任务级 review gate：
+最终 review gate：
+回退路径：
+下一步：
+
+## Workflow Handoff
+
+current_skill: vibe-subagent-driven-development
+next_skill: vibe-verification-before-completion | vibe-dispatching-parallel-work | vibe-writing-plans | vibe-workspace-isolation | vibe-test-driven-development | vibe-executing-plans | vibe-receiving-code-review | vibe-systematic-debugging | none
+reason:
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition:
+```

package/skills/vibe-systematic-debugging/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: vibe-systematic-debugging
+description: Use when there is a bug, failure, flaky behavior, or unexpected result and root cause must be established before fixing.
+---
+
+# Vibe Systematic Debugging
+
+## 目标
+
+在修复前先建立可复现证据和根因判断，避免猜测式修改、症状修补和大范围误改。
+
+## 适用场景
+
+- 测试失败。
+- 构建失败。
+- 功能行为异常。
+- 性能或集成异常。
+- 多次修复无效。
+- `vibe-executing-plans` 或 `vibe-verification` 发现失败且原因不明。
+
+## 输入
+
+- 现象。
+- 复现步骤。
+- 错误信息。
+- 最近变更。
+- 相关文件、配置、日志或命令输出。
+- 已尝试但失败的修复。
+
+## 工作流
+
+1. 明确现象和期望行为。
+2. 获取稳定复现路径；无法复现时停止，不进入修复。
+3. 阅读完整错误和关键日志，不跳过上下文。
+4. 检查最近变更和影响范围。
+5. 追踪输入、状态、输出的最短链路。
+6. 提出单一根因假设。
+7. 一次只改变一个变量验证假设。
+8. 根因成立后先明确测试或验证策略，再进入实现修复。
+
+## 输出
+
+- 现象。
+- 复现路径。
+- 证据。
+- 根因假设。
+- 验证结果。
+- 修复范围。
+- 下一步 skill。
+
+## Root Cause Gate
+
+进入修复前必须满足以下 gate：
+
+- `reproduced`：稳定复现，或明确说明不可复现及需要继续收集的数据。
+- `evidence`：错误信息、日志、命令输出、状态差异或最小复现输入。
+- `data_flow`：从输入到异常点的最短链路。
+- `hypothesis`：单一根因假设，不能同时押多个方向。
+- `hypothesis_test`：一次只改变一个变量的验证方式。
+- `root_cause_status`：`confirmed`、`rejected` 或 `unknown`。
+- `fix_scope`：只覆盖根因所需范围，不顺手重构无关模块。
+
+`root_cause_status` 不是 `confirmed` 时，不能进入 `vibe-implementation`；只能继续 debugging、补证据、回 planning 或停止。
+
+## 禁止事项
+
+- 未复现不要修。
+- 未定位根因不要修。
+- 不要一次改多个变量来验证假设。
+- 不要用“看起来像”代替证据。
+- 不要为了快速通过而掩盖错误。
+
+## 示例输出结构
+
+```text
+现象：
+复现：
+证据：
+根因假设：
+验证：
+修复范围：
+下一步：
+```
+
+## 下一步调用
+
+- 根因明确且修复范围清楚：`next_skill: vibe-test-driven-development`。
+- 根因明确且已有计划任务：`next_skill: vibe-test-driven-development`。
+- 无法复现或证据不足：`next_skill: none`。
+- 发现需求或验收不清：`next_skill: vibe-planning`。
+
+## Workflow Handoff
+
+```text
+current_skill: vibe-systematic-debugging
+next_skill: vibe-test-driven-development | vibe-planning | none
+reason:
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition:
+```

package/skills/vibe-test-driven-development/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: vibe-test-driven-development
+description: Use before implementing a feature, bug fix, refactor, or behavior change to define test-first or verification-first evidence before production changes.
+---
+
+# Vibe Test Driven Development
+
+## 目标
+
+在实现前先建立验证纪律：先说明要证明什么，再修改实现。
+
+本 skill 借鉴 TDD 的 red-green-refactor，但保持跨项目轻量语义。项目有测试框架时优先写可失败的自动化测试；没有测试框架时，必须给出可复现的替代验证路径和风险。
+
+## Gate Contract
+
+```text
+gate_kind: verification_strategy_gate
+must_not_skip: before_behavior_change_without_validation_strategy
+approval_required_before: implementation
+terminal_next_skill: vibe-executing-plans | vibe-implementation | vibe-planning | none
+review_blocker_stops_next_task: false
+completion_requires_evidence: true
+```
+
+## 适用场景
+
+- 计划已经拆成任务，准备实现。
+- 明确小任务准备修改行为。
+- bug 根因已明确，准备修复。
+- refactor 需要防止行为回归。
+
+## 输入
+
+- 当前任务或计划项。
+- 预期行为和验收标准。
+- 项目可用的测试命令或验证方式。
+- 相关文件、模块和风险。
+
+## 工作流
+
+1. 写清楚本次要证明的行为。
+2. 判断是否存在可运行测试框架。
+3. 有测试框架时，先定义应该失败的最小测试，并说明预期失败原因。
+4. 没有测试框架时，先定义可复现验证步骤、输入、输出和局限。
+5. 实现阶段只做让验证通过的最小修改。
+6. 通过后再做必要整理，并确认验证仍然通过。
+
+## 输出
+
+必须输出：
+
+- 行为验收。
+- 测试或验证策略。
+- 预期失败信号。
+- 通过信号。
+- 无测试框架时的替代验证和风险。
+- `Workflow Handoff`。
+
+## Red / Green Evidence Gate
+
+实现前必须先记录验证闭环：
+
+- `behavior`：本次只证明一个明确行为或回归点。
+- `red_signal`：预期失败的测试、命令、输入输出或人工复现信号。
+- `red_observed`：已经观察到的失败证据；若尚未运行，必须说明后续第一步是验证失败。
+- `green_signal`：实现后通过的命令、输出或人工验收信号。
+- `refactor_boundary`：通过后允许整理的范围，不能顺手扩大行为。
+- `fallback_verification`：无自动测试时的替代验证步骤、局限和风险。
+- `traceability_binding`：如存在 `delivery-traceability.yaml`，说明本验证策略回填哪个 `test_evidence_ref`，以及覆盖哪个 requirement/product/UI/architecture/task link。
+- `implementation_task_binding`：如存在 `implementation-plan.md` 的 `Implementation Task Registry`，本地测试证据必须绑定相关 `task_refs[]`；`test_required=true` 或 `risk=high` 的 task 不能只绑定 scenario，必须能被 passing run 覆盖。
+- `test_evidence_envelope`：不声称 runtime 已跑测试；本地证据必须绑定 `command`、`exit_code`、`timestamp`、`output_digest`、`task_refs[]`、`scenario_refs[]` 和 `boundary_assertions.command_execution=false/test_execution=false`。
+
+如果无法定义 red/green 或替代验证，不能进入实现，应回到 `vibe-planning` 或停止澄清。
+
+## 禁止事项
+
+- 不要在没有验收口径时开始实现。
+- 不要声称运行了未运行的测试。
+- 不要把“稍后补测试”当成完成条件。
+- 不要因为没有测试框架就跳过验证说明。
+- 不要为了测试纪律引入大型工具链，除非用户明确批准。
+
+## 下一步调用
+
+- 验证策略明确且来自计划执行：`next_skill: vibe-executing-plans`
+- 验证策略明确且是明确小任务：`next_skill: vibe-implementation`
+- 验收或行为不清：`next_skill: vibe-planning`
+- 无法定义可靠验证且阻塞：`next_skill: none`
+
+## 示例输出结构
+
+```text
+行为验收：
+测试/验证策略：
+预期失败信号：
+通过信号：
+替代验证与风险：
+
+## Workflow Handoff
+
+current_skill: vibe-test-driven-development
+next_skill: vibe-executing-plans
+reason: 任务级验证策略已明确，可以按计划执行。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```

package/skills/vibe-ui-design/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: vibe-ui-design
+description: Use when a product spec affects screens, user flows, components, UI states, copy, interaction rules, responsive behavior, accessibility, or design acceptance before architecture and implementation planning.
+---
+
+# Vibe UI Design
+
+## 目标
+
+把产品规格转成可被架构和实现消费的 UI/UX contract，明确页面、用户路径、组件、状态、交互、文案、响应式和可访问性验收。
+
+本 skill 只定义 presentation / interaction contract，不写前端代码，不替代专业视觉设计工具，不引入大型设计系统。
+
+## 适用场景
+
+- 产品规格涉及页面、组件、表单、列表、导航或交互。
+- 需要明确 loading、empty、error、success 等 UI 状态。
+- 需要在编码前确认信息架构、文案、可访问性或响应式规则。
+- 需要给产品体验验收提供可检查的 UI contract。
+
+## 输入
+
+- 产品规格或用户故事。
+- 关键用户路径和场景。
+- 目标平台、设备、主题或设计约束。
+- 现有组件、样式、文案和可访问性约束。
+
+## 工作流
+
+1. 明确核心用户路径和关键屏幕。
+2. 定义每个屏幕的信息层级和主要操作。
+3. 拆出组件职责，但不指定具体实现文件。
+4. 覆盖 loading、empty、error、success、disabled、permission denied 等状态。
+5. 定义交互规则、文案规则和响应式约束。
+6. 定义可访问性要求，包括键盘、焦点、语义、对比度或屏幕阅读器要求。
+7. 输出设计验收标准，供 `vibe-product-acceptance` 和工程验证使用。
+
+## 输出
+
+必须输出标准 artifact，并优先使用 `templates/ui-design-contract.md` 作为结构基线。
+
+Artifact contract：
+
+- frontmatter 必须包含 `artifact_kind: ui-design-contract`、`version: 1`、`source_skill: vibe-ui-design`、`status`、`next_skill`。
+- 必须包含 `Goal`、`Input`、`Output Fields`、`Non Goals`、`Risks`、`Acceptance`、`Evidence`、`Boundary`、`Handoff` 段。
+- `Boundary` 必须声明 `writes=false`、`state_directory_created=false`、`command_execution=false`、`skill_execution=false`、`subagent=false`、`mcp=false`、`git=false`。
+
+必须填充：
+
+- `screens`：屏幕或页面列表。
+- `user_flow`：用户路径。
+- `information_architecture`：信息层级。
+- `components`：组件职责。
+- `ui_states`：UI 状态矩阵。
+- `copy_rules`：文案规则。
+- `interaction_rules`：交互规则。
+- `responsive_rules`：响应式规则。
+- `accessibility`：可访问性要求。
+- `design_acceptance`：设计验收标准。
+- `open_questions`：待确认问题。
+- `Evidence`：证据来源和未验证项。
+- `Workflow Handoff`。
+
+## 禁止事项
+
+- 不要写代码或指定具体实现方案。
+- 不要把 UI contract 扩张成架构计划。
+- 不要忽略异常状态、空状态或权限状态。
+- 不要用“美观”“现代化”替代可验收的设计标准。
+- 不要引入设计稿生成器、截图服务、视觉回归平台或外部工具，除非用户明确要求。
+
+## 下一步调用
+
+- UI contract 明确：`next_skill: vibe-planning`。
+- 产品规格不清：`next_skill: vibe-product-spec`。
+- 不存在 UI 影响：`next_skill: vibe-planning`。
+- 缺少关键视觉或交互决策：`next_skill: none`。
+
+## 示例输出结构
+
+```text
+screens:
+user_flow:
+information_architecture:
+components:
+ui_states:
+copy_rules:
+interaction_rules:
+responsive_rules:
+accessibility:
+design_acceptance:
+open_questions:
+
+## Workflow Handoff
+
+current_skill: vibe-ui-design
+next_skill: vibe-planning
+reason: UI/UX contract 已明确，可以进入架构和实现规划。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```

package/skills/vibe-verification/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: vibe-verification
+description: Use before declaring work complete, after implementation, after bug fixes, or when the user asks whether changes are ready to ship.
+---
+
+# Vibe Verification
+
+## 目标
+
+在交付前确认目标是否达成、检查是否必要、风险是否清楚、未验证项是否透明。
+
+## 适用场景
+
+- 实现完成后。
+- 修复完成后。
+- 准备交付前。
+- 用户要求确认能否交付。
+- 需要明确已验证和未验证内容。
+
+## 输入
+
+- 用户目标。
+- 修改范围。
+- 验收标准。
+- 已运行检查。
+- 未运行检查。
+- 已知风险。
+
+## 工作流
+
+1. 对照目标确认完成度。
+2. 对照验收标准确认覆盖度。
+3. 检查 lint / test / build / 文档诊断。
+4. 区分已验证和未验证。
+5. 记录阻塞项和剩余风险。
+6. 给出是否可交付判断。
+
+## 输出
+
+- 已验证项。
+- 未验证项。
+- 阻塞项。
+- 剩余风险。
+- 可交付判断。
+
+## 禁止事项
+
+- 不要声称运行过未运行的检查。
+- 不要把未验证项包装成已完成。
+- 不要忽略明显阻塞。
+- 不要输出泛泛建议列表。
+
+## 示例输出结构
+
+```text
+已验证：
+未验证：
+阻塞：
+风险：
+结论：
+```
+
+## 下一步调用
+
+- 验证通过且没有阻塞：`next_skill: none`。
+- 验证失败且原因不明：`next_skill: vibe-debugging`。
+- 验证失败但修复路径明确：`next_skill: vibe-implementation`。
+- 验收标准不清：`next_skill: vibe-planning`。
+
+## Workflow Handoff
+
+```text
+current_skill: vibe-verification
+next_skill: vibe-debugging | vibe-implementation | vibe-planning | none
+reason:
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition:
+```