@jtf19/vibecoding-kit 0.1.0

package/skills/vibe-dispatching-parallel-work/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: vibe-dispatching-parallel-work
+description: Use when an implementation plan contains multiple potentially independent tasks and you need to decide whether they can be parallelized, grouped, or kept sequential without automatically dispatching agents.
+---
+
+# Vibe Dispatching Parallel Work
+
+## 目标
+
+在计划执行前判断多个任务是否真的独立，识别共享状态、冲突文件和顺序依赖，并产出可复用的任务 brief。
+
+本 skill 只做并行分发纪律和 handoff，不自动调用 subagent，不选择模型，不执行实现，不引入 agent graph 或 runtime 编排器。
+
+## 适用场景
+
+- `vibe-writing-plans` 产出的计划包含多个可能独立的任务。
+- 多个失败、模块或文档同步项看起来可以并行处理。
+- 用户明确询问哪些任务可以并行推进。
+- 需要为后续人工执行、agent 执行或外部 reviewer 准备独立任务 brief。
+- 需要判断任务应并行、顺序执行、重新拆分，还是停止等待更多输入。
+- 需要判断是否具备进入 `vibe-subagent-driven-development` 的前置 brief 条件，但不执行 subagent gate。
+
+## 输入
+
+- 实施计划或任务列表。
+- 每个任务的目标、文件范围、依赖和验收标准。
+- 已知共享状态、共享文件、测试资源或外部环境。
+- 用户是否允许使用 subagent 或并行执行。
+- 当前工作区是否干净、是否已有未收口变更、是否需要隔离判断。
+- 不做项、提交边界和验证要求。
+
+## 独立性判断
+
+可并行任务必须同时满足：
+
+- 目标可以独立解释，不依赖其他任务的中间结果。
+- 文件范围不重叠，或重叠部分只读且不会产生合并冲突。
+- 验证方式可独立运行或按顺序汇总。
+- 不共享会被写入的状态、缓存、数据库、临时目录或进程。
+- 失败原因可以独立归因，不会被其他任务的改动掩盖。
+- brief 足够自包含，不需要读取完整会话历史。
+
+必须顺序执行的信号：
+
+- 一个任务的输出是另一个任务的输入。
+- 多个任务修改同一入口文件、同一路由、同一配置或同一状态模型。
+- 任务共享临时目录、测试数据库、服务进程或发布产物。
+- 任一任务缺少验收标准，或需要先澄清需求。
+
+## 工作流
+
+1. 复核任务列表，剔除无法独立验收的杂项任务。
+2. 按问题域、交付域或文件边界分组。
+3. 标记每组任务的共享文件、共享状态、顺序依赖和冲突风险。
+4. 判断每组任务是可并行、必须顺序、需要重新拆分，还是应停止。
+5. 为每个可并行候选任务写出自包含 brief。
+6. 判断后续执行是否需要先进入 `vibe-workspace-isolation` 保护当前工作区。
+7. 明确用户是否允许后续使用 subagent；未明确允许时只输出 brief，不执行分发。
+8. 输出下一步 skill 和 `Workflow Handoff`。
+
+## 输出
+
+必须输出：
+
+- 并行判断结论。
+- 任务分组。
+- 每组任务的共享状态和冲突风险。
+- 每个任务 brief。
+- 建议执行策略：并行候选、顺序执行、重新拆分或停止。
+- 用户许可状态。
+- 下一步 skill。
+- `Workflow Handoff`。
+
+## 任务 brief 格式
+
+```text
+任务名称：
+目标：
+范围：
+输入证据：
+禁止修改：
+依赖：
+预期输出：
+验证方式：
+完成后回报：
+```
+
+## 禁止事项
+
+- 不要自动调用 subagent。
+- 不要把“可并行”写成“已经并行执行”。
+- 不要在用户未允许时派发 agent 或创建并行执行计划。
+- 不要让多个任务同时写同一文件、同一状态或同一临时目录。
+- 不要把缺少验收标准的任务标记为可并行。
+- 不要让 brief 依赖完整聊天历史。
+- 不要绕过 `vibe-test-driven-development` 或 `vibe-executing-plans`。
+- 不要生成 review package、脚本或 runtime 调度配置。
+- 不要把任务并行边界判断替代为工作区隔离判断；需要隔离时进入 `vibe-workspace-isolation`。
+
+## 下一步调用
+
+- 任务独立、brief 完整，但执行前需要判断是否隔离当前工作区：`next_skill: vibe-workspace-isolation`。
+- 任务独立、brief 完整、用户明确允许 subagent，且工作区边界清楚：`next_skill: vibe-subagent-driven-development`。
+- 任务独立、brief 完整、用户允许后续并行执行，且工作区边界清楚但不使用 subagent：`next_skill: vibe-test-driven-development`。
+- 任务不独立或冲突风险高，但可顺序执行：`next_skill: vibe-test-driven-development`。
+- 任务边界、依赖或验收不清：`next_skill: vibe-writing-plans`。
+- 需求范围需要重新澄清：`next_skill: vibe-planning`。
+- 缺少关键输入或用户未允许并行策略且后续必须并行才有意义：`next_skill: none`。
+
+## 示例输出结构
+
+```text
+并行判断：
+任务分组：
+共享状态：
+冲突风险：
+执行策略：
+用户许可：
+
+任务 brief：
+  - 任务名称：
+    目标：
+    范围：
+    输入证据：
+    禁止修改：
+    依赖：
+    预期输出：
+    验证方式：
+    完成后回报：
+
+## Workflow Handoff
+
+current_skill: vibe-dispatching-parallel-work
+next_skill: vibe-workspace-isolation | vibe-subagent-driven-development | vibe-test-driven-development
+reason: 已完成并行边界判断和任务 brief，可进入工作区隔离判断、subagent 执行 gate 或验证策略确认。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```

package/skills/vibe-executing-plans/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: vibe-executing-plans
+description: Use when there is an executable plan and the agent should implement it task by task with verification checkpoints.
+---
+
+# Vibe Executing Plans
+
+## 目标
+
+按已确认的实施计划逐项推进，保持任务状态清晰、验证不跳过、遇到阻塞及时停止。
+
+## 适用场景
+
+- 已有 `vibe-writing-plans` 输出的可执行计划。
+- 用户要求按计划实现。
+- 当前任务不需要 subagent 编排，或平台不支持 subagent。
+- 用户未明确允许 subagent，或 `vibe-subagent-driven-development` 判断后回退顺序执行。
+- 已经过 `vibe-dispatching-parallel-work` 判断后，仍选择当前会话内按计划逐项执行。
+- 需要稳定的逐项执行和验证检查点。
+
+## 输入
+
+- 实施计划。
+- 任务列表。
+- 文件范围。
+- 验收标准。
+- 验证命令或人工检查方式。
+- 已知风险和 stop condition。
+
+## 工作流
+
+1. 先复核计划是否存在冲突、空泛任务或缺失验收。
+2. 复核计划是否包含 Architecture Decision Frame；缺少 responsibility owner、layer/dependency direction、data flow、state lifecycle、contract sync、risk class 或 architecture signal 时，停止并返回 `next_skill: vibe-writing-plans`。
+3. 如果计划不可执行，停止并返回 `next_skill: vibe-writing-plans` 或 `vibe-planning`。
+4. 一次只推进一个任务。
+5. 每个任务开始前确认边界、输入、依赖 gate、文件 mutex/conflict、目标文件职责和停止条件。
+6. 每次编辑源码前执行 Pre-edit Architecture Check，确认不是因为文件当前打开而修改错误 owner。
+7. 完成后运行对应验证或说明未验证原因；验证证据必须能绑定到当前任务。
+8. 每个阶段提交前确认提交条件：验证证据、文件范围、阻塞项和用户授权。
+9. 遇到不明失败时停止，进入 `vibe-systematic-debugging`。
+10. 全部任务完成后进入完成前验证。
+
+## Pre-edit Architecture Check
+
+每次编辑源码前必须快速确认：
+
+- 当前改动是否落在计划声明的 `responsibility_owner`。
+- 目标文件是否符合所属 layer，依赖方向是否仍是上层依赖下层。
+- 输入、转换、IO、输出和错误路径是否清晰，是否把纯 core 与 IO wrapper 混在一起。
+- 状态生命周期是否清晰；涉及状态写入、队列、lease、retry、daemon、scheduler、source apply、merge 或持久化状态时，是否已有明确授权和更强验证。
+- CLI、JSON envelope、artifact、digest、README marker、doctor、runtime-check、release-check、template 或 skill 是否需要同步。
+- 是否因为当前文件已打开、最近修改或上下文里刚出现，就把代码写进了错误 owner。
+- 是否新增概念、状态转换、验证族、command 行为或 smoke 组；如果是，是否已有具名模块承载。
+- 是否扩大了 entry、dispatcher、check runner、aggregator 的职责；这类文件默认只允许 wiring。
+- 是否出现参数爆炸、反向依赖、跨 domain helper、跨 domain 状态流或数据流回溯。
+- 这次设计是否让下一次同类扩展更容易，而不是继续复制和堆叠。
+
+任一项无法确认时，停止执行，返回 `next_skill: vibe-writing-plans` 或 `vibe-planning`。
+
+## 输出
+
+- 已完成任务。
+- 当前任务状态。
+- Architecture Check：责任 owner、层级/依赖方向、数据流、状态生命周期、契约同步、风险等级、是否存在职责漂移。
+- 已运行验证。
+- 未运行验证和原因。
+- 阻塞项。
+- 下一步 skill。
+
+## 禁止事项
+
+- 不要跳过计划中的验证项。
+- 不要在任务失败时继续后续任务。
+- 不要把未执行任务标记为完成。
+- 不要在主分支上自动提交，除非用户明确要求。
+- 不要自动派发 subagent，除非用户允许且进入对应 skill。
+- 不要把 `vibe-dispatching-parallel-work` 输出的 brief 当作已经执行或已经授权并行。
+
+## 示例输出结构
+
+```text
+计划复核：
+当前任务：
+已完成：
+已验证：
+未验证：
+阻塞：
+下一步：
+```
+
+## 下一步调用
+
+- 所有任务完成：`next_skill: vibe-verification-before-completion`。
+- 执行中发现验证失败且原因不明：`next_skill: vibe-systematic-debugging`。
+- 计划缺陷阻塞执行：`next_skill: vibe-writing-plans`。
+- 范围变化：`next_skill: vibe-planning`。
+- 缺少用户确认：`next_skill: none`。
+- 用户改为明确允许 subagent 且任务 brief 已完整：`next_skill: vibe-subagent-driven-development`。
+
+## Workflow Handoff
+
+```text
+current_skill: vibe-executing-plans
+next_skill: vibe-verification-before-completion | vibe-systematic-debugging | vibe-writing-plans | vibe-planning | vibe-subagent-driven-development | none
+reason:
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition:
+```

package/skills/vibe-finishing-a-development-branch/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: vibe-finishing-a-development-branch
+description: Use after completion verification when deciding whether to commit, create a PR, keep work as-is, or clean up a development branch.
+---
+
+# Vibe Finishing a Development Branch
+
+## 目标
+
+在声明完成之后、执行提交或 PR 之前，确认验证证据和 git 边界，避免混合提交、误删工作或执行未授权的高风险操作。
+
+本 skill 只做交付收口决策和显式确认，不自动提交、不自动推送、不自动清理。
+
+## Gate Contract
+
+```text
+gate_kind: branch_closeout_gate
+must_not_skip: before_commit_pr_merge_or_branch_closeout
+approval_required_before: git_write | push | pr | merge | destructive_cleanup
+terminal_next_skill: none
+review_blocker_stops_next_task: true
+completion_requires_evidence: true
+```
+
+## 适用场景
+
+- `vibe-verification-before-completion` 已给出可交付判断。
+- 用户询问能否提交、开 PR、合并或收口。
+- 工作区可能存在 staged / unstaged / untracked 混合风险。
+- `vibe-workspace-isolation` 判断当前工作区有未收口变更，需要先处理边界。
+- 需要在提交、PR、保留、放弃之间做选择。
+
+## 输入
+
+- 完成前验证证据。
+- 当前 git 状态。
+- 用户期望的交付路径。
+- 风险、未验证项和相关文件范围。
+- 可选 expanded completion evidence bundle 输出，包括 product/UI/architecture/traceability cross-artifact ref validation、implementation task registry gate、implementation alignment gate、plan/test evidence gate、diff coverage gate、commit readiness digest；该 bundle 只能作为人工收口输入，不能授权 runtime 自动提交。
+- 可选 P13 `closeout_readiness` 输出，要求 SDD ledger、最终 clean review、test evidence、diff evidence 和 task commit readiness 闭环；它只给出人工 commit/no commit/PR/stop 下一步，不授权 runtime 执行 git 或 PR。
+
+## 工作流
+
+1. 先确认完成前验证证据是否足够。
+2. 如果存在 Stage 118/119/120 分阶段交付链路，先确认 Stage 120 `commit_readiness_gate.pass=true`。
+3. 检查 Stage 120 的 `suggested_commit_subject` 是否与本次准备使用的提交标题一致。
+4. 检查 Stage 120 的 `stage_evidence_category_gate` 是否通过，且 `diff_coverage_evidence_bound=true`。
+5. 检查 git 边界：staged、unstaged、untracked 是否清楚。
+6. 判断是否存在无关改动或用户改动混入。
+7. 向用户给出结构化选项：提交、PR、保留、放弃。
+8. 只有在用户明确选择后，才进入对应动作。
+9. 对放弃、删除、清理、force 类动作必须要求明确确认。
+
+## 输出
+
+必须输出：
+
+- 验证证据。
+- Stage 120 readiness：`commit_readiness_gate`、`suggested_commit_subject`、`diff_coverage_evidence_bound`、`commit_allowed_by_contract=false`。
+- git 边界。
+- 交付选项。
+- 阻塞项和风险。
+- 用户需要确认的动作。
+- `Workflow Handoff`。
+
+## 禁止事项
+
+- 不要在未验证时建议交付。
+- 不要把 Stage 120 readiness pass 解释为 runtime 自动提交授权；它只允许后续单独的人类确认本地提交动作。
+- 不要在 Stage 120 `commit_readiness_gate` 失败、缺少 `diff_coverage` 证据或 subject 不匹配时提交。
+- 不要混合 staged 和 unstaged 进行提交。
+- 不要未经用户明确要求提交、推送、合并、清理或删除。
+- 不要使用破坏性 git 命令回退用户改动。
+- 不要 amend，除非用户明确要求且符合安全条件。
+- 不要 force push 到主分支。
+
+## 下一步调用
+
+- 验证不足：`next_skill: vibe-verification-before-completion`
+- 发现明确修复缺口：`next_skill: vibe-implementation`
+- 用户选择继续提交或 PR：`next_skill: none`
+- 用户选择保留或停止：`next_skill: none`
+
+## 示例输出结构
+
+```text
+验证证据：
+git 边界：
+交付选项：
+1. 提交当前批次
+2. 创建 PR
+3. 保留当前分支
+4. 放弃本批改动，需要二次确认
+阻塞与风险：
+需要确认：
+
+## Workflow Handoff
+
+current_skill: vibe-finishing-a-development-branch
+next_skill: none
+reason: 已进入交付收口，后续动作需要用户明确选择。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: 等待用户选择提交、PR、保留或放弃
+```

package/skills/vibe-implementation/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: vibe-implementation
+description: Use when the task scope is clear enough to make code, documentation, configuration, or plugin-structure changes.
+---
+
+# Vibe Implementation
+
+## 目标
+
+在明确范围内完成实现，保持改动小、边界清晰、可验证。
+
+## 适用场景
+
+- 已完成规划后的实现。
+- 小型明确任务。
+- 用户要求直接落地。
+- 文档、配置、skill、adapter、hook 的创建或调整。
+
+## 输入
+
+- 明确目标。
+- 计划或任务范围。
+- 相关文件。
+- 平台约束。
+- 验收标准。
+
+## 工作流
+
+1. 确认改动边界。
+2. 阅读相关文件。
+3. 优先复用现有结构。
+4. 创建或修改最小必要文件。
+5. 避免引入无关依赖。
+6. 保留用户已有改动。
+7. 完成后进入验证。
+
+## 输出
+
+- 已完成内容。
+- 修改的主要文件。
+- 未完成项。
+- 需要用户确认的点。
+- 后续验证建议。
+
+## 禁止事项
+
+- 不要顺手重构无关模块。
+- 不要覆盖用户已有改动。
+- 不要引入与当前阶段无关的平台能力。
+- 不要在未确认需求时扩大范围。
+- 不要创建没有使用路径的装饰性文件。
+
+## 示例输出结构
+
+```text
+完成：
+文件：
+未完成：
+需确认：
+验证：
+```
+
+## 下一步调用
+
+- 实现完成且需要确认可交付：`next_skill: vibe-verification-before-completion`。
+- 实现中发现范围变化或方案不成立：`next_skill: vibe-planning`。
+- 实现中发现新异常且原因不明：`next_skill: vibe-systematic-debugging`。
+- 因缺少信息无法继续：`next_skill: none`。
+
+## Workflow Handoff
+
+```text
+current_skill: vibe-implementation
+next_skill: vibe-verification-before-completion | vibe-planning | vibe-systematic-debugging | none
+reason:
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition:
+```

package/skills/vibe-planning/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: vibe-planning
+description: Use when a task needs requirement clarification, scope control, module boundaries, implementation sequencing, or trade-off decisions before coding.
+---
+
+# Vibe Planning
+
+## 目标
+
+把模糊目标转成可执行方案，先确定范围、模块、数据流、状态流和验收标准，再进入实现。
+
+## 适用场景
+
+- 新功能。
+- 重构。
+- 架构调整。
+- 多模块改动。
+- 用户目标不完整。
+- 有多个实现路线需要取舍。
+
+## 输入
+
+- 用户目标。
+- 当前项目结构。
+- 已有约束。
+- 相关文档或参考项目。
+- 现有实现边界。
+
+## 工作流
+
+1. 明确目标：用一句话描述要达成的结果。
+2. 划定范围：区分本阶段做什么、不做什么。
+3. 拆分模块：说明每个模块的职责。
+4. 梳理流向：说明数据、状态、事件或调用如何流动。
+5. 排实施顺序：先做低风险基础，再做集成和验证。
+6. 定义验收：列出能判断完成的标准。
+
+## Architecture Decision Frame
+
+需要架构选择时，方案必须覆盖：职责 owner、层级和依赖方向、数据流、状态生命周期、契约同步、影响面、风险等级、演进路径和复杂度控制。不要只比较“能不能实现”，也要比较后续扩展、验证和回滚成本。
+
+## 输出
+
+当任务涉及架构取舍、模块边界、数据流或状态生命周期时，必须输出标准 artifact，并优先使用 `templates/architecture-design.md` 作为结构基线。
+
+Artifact contract：
+
+- frontmatter 必须包含 `artifact_kind: architecture-design`、`version: 1`、`source_skill: vibe-planning`、`status`、`next_skill`。
+- 必须包含 `Goal`、`Input`、`Architecture Decision Frame`、`Module Ownership`、`Layer And Dependency Direction`、`Data Flow`、`State Lifecycle`、`Contract Sync`、`Blast Radius`、`Verification Strategy`、`Risks`、`Non Goals`、`Evidence`、`Boundary`、`Handoff` 段。
+- `Boundary` 必须声明 `writes=false`、`state_directory_created=false`、`command_execution=false`、`test_execution=false`、`skill_execution=false`、`subagent=false`、`mcp=false`、`git=false`。
+
+必须填充：
+
+- 目标定义。
+- 范围边界。
+- 模块职责。
+- 数据流 / 状态流。
+- 实施顺序。
+- 验收标准。
+- 需要用户确认的问题。
+- architecture artifact digest 或后续 gate 复查路径。
+
+## 禁止事项
+
+- 不要直接跳到代码实现。
+- 不要用“完善逻辑”“优化结构”这类空泛步骤代替模块边界。
+- 不要把后续阶段能力塞进当前阶段。
+- 不要在验收标准不清晰时宣布可以开始实现。
+
+## 示例输出结构
+
+```text
+目标：
+范围：
+模块：
+流向：
+实施顺序：
+验收标准：
+待确认：
+```
+
+## 下一步调用
+
+- 计划明确且验收标准清楚：`next_skill: vibe-implementation`。
+- 需求不清、范围未定或关键取舍需要用户确认：`next_skill: none`。
+- 发现目标本身需要重新定义：`next_skill: none`。
+
+## Workflow Handoff
+
+```text
+current_skill: vibe-planning
+next_skill: vibe-implementation | none
+reason:
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition:
+```

package/skills/vibe-product-acceptance/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: vibe-product-acceptance
+description: Use after implementation evidence exists and before completion claims when a product spec or UI contract needs scenario coverage, user-flow evidence, UI-state evidence, accessibility evidence, metric readiness, experience gaps, and a product ship decision.
+---
+
+# Vibe Product Acceptance
+
+## 目标
+
+在工程完成前补齐产品体验验收：确认实现是否覆盖产品规格、用户路径、UI 状态、可访问性和指标准备，而不只证明代码测试通过。
+
+本 skill 只做产品体验验收和交付判断输入，不替代工程测试、不自动声明完成、不提交代码。
+
+## 适用场景
+
+- 实现已完成或接近完成，且存在产品规格或 UI contract。
+- 需要确认用户场景是否闭环，而不仅是单元测试通过。
+- 需要验收 loading、empty、error、success 等 UI 状态。
+- 准备进入 `vibe-verification-before-completion` 前，需要产品层证据。
+
+## 输入
+
+- 产品规格、UI contract 或验收标准。
+- 实现结果和已运行的测试/检查。
+- 手动验收记录、截图、浏览器观察或本地复现结果。
+- 已知风险、未验证项和发布约束。
+
+## 工作流
+
+1. 明确要验收的产品声明。
+2. 对照产品规格检查核心场景覆盖。
+3. 对照 UI contract 检查用户路径和 UI 状态。
+4. 检查可访问性、文案、响应式或平台约束是否满足。
+5. 检查成功指标、埋点或观察信号是否准备好；不适用时说明原因。
+6. 区分已通过、未验证、失败和不适用。
+7. 若产品体验证据不足，不进入完成声明；回到对应修复或规划阶段。
+
+## 输出
+
+必须输出标准 artifact，并优先使用 `templates/product-acceptance.md` 作为结构基线；场景验收建议配套 `templates/scenario-acceptance.yaml`。
+
+Artifact contract：
+
+- frontmatter 必须包含 `artifact_kind: product-acceptance`、`version: 1`、`source_skill: vibe-product-acceptance`、`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`。
+- 场景 DSL 必须使用 `artifact_kind: scenario-acceptance`，且每个 scenario 包含 `id`、`given`、`when`、`then`、`evidence.required`、`status`。
+
+必须填充：
+
+- `product_claim`：要验收的产品声明。
+- `scenario_coverage`：场景覆盖情况。
+- `user_flow_evidence`：用户路径证据。
+- `ui_state_evidence`：UI 状态证据。
+- `accessibility_evidence`：可访问性证据。
+- `metric_readiness`：指标或观察信号准备情况。
+- `experience_gaps`：体验缺口。
+- `not_verified`：未验证项和原因。
+- `ship_decision`：产品层通过、不通过或阻塞。
+- `traceability_binding`：如存在 `delivery-traceability.yaml`，引用对应 `scenario_ref`、`product_acceptance_ref` 和未闭环 link。
+- `Evidence`：证据来源和未验证项。
+- `Workflow Handoff`。
+
+## 禁止事项
+
+- 不要把工程测试通过等同于产品体验通过。
+- 不要没有证据就声明用户路径闭环。
+- 不要忽略异常状态、空状态、权限状态或边界输入。
+- 不要替代 `vibe-verification-before-completion` 的工程完成声明。
+- 不要自动提交、创建 PR、调用平台 API、调用 subagent 或写 runtime state。
+
+## 下一步调用
+
+- 产品体验验收通过：`next_skill: vibe-verification-before-completion`。
+- 工程实现缺口明确：`next_skill: vibe-implementation`。
+- 架构或任务边界需要调整：`next_skill: vibe-planning`。
+- 产品规格需要调整：`next_skill: vibe-product-spec`。
+- 缺少验收证据且无法补齐：`next_skill: none`。
+
+## 示例输出结构
+
+```text
+product_claim:
+scenario_coverage:
+user_flow_evidence:
+ui_state_evidence:
+accessibility_evidence:
+metric_readiness:
+experience_gaps:
+not_verified:
+ship_decision:
+
+## Workflow Handoff
+
+current_skill: vibe-product-acceptance
+next_skill: vibe-verification-before-completion
+reason: 产品体验验收已通过，可以进入完成前工程验证。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```