@jtf19/vibecoding-kit 0.1.0

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

@@ -0,0 +1,107 @@
+---
+name: vibe-product-discovery
+description: Use when a product idea, user need, or feature request needs problem framing, target users, scenarios, value hypothesis, success metrics, and product decision before writing a spec or planning implementation.
+---
+
+# Vibe Product Discovery
+
+## 目标
+
+把模糊需求或产品想法收敛成可判断的产品问题定义，先证明“为什么做、为谁做、怎样算有价值”，再进入规格、UI 或架构阶段。
+
+本 skill 只做产品发现和方向判断，不写 PRD 细节、不做 UI 设计、不拆工程任务、不进入编码。
+
+## 适用场景
+
+- 用户提出产品想法，但用户、场景、价值或成功标准不清。
+- 功能请求可能有多种产品切片，需要先判断 MVP 范围。
+- 需要区分用户问题、业务目标、非目标和风险假设。
+- 进入 `vibe-product-spec` 前，需要先明确产品方向是否值得继续。
+
+## 输入
+
+- 用户原始想法或需求。
+- 目标用户、业务背景或当前项目上下文。
+- 已知约束、竞品或替代方案线索。
+- 现有验收口径、风险或不做范围。
+
+## 工作流
+
+1. 用一句话定义用户问题，不把解决方案当问题。
+2. 明确目标用户、使用场景和触发时刻。
+3. 梳理用户当前替代方案和失败点。
+4. 提出价值假设和最小可验证切片。
+5. 定义成功指标、反指标和可观察信号。
+6. 列出非目标、风险假设和需要用户确认的决策。
+7. 如果产品方向仍不清，不进入规格或实现阶段。
+
+## 输出
+
+必须输出标准 artifact，并优先使用 `templates/product-discovery.md` 作为结构基线。
+
+Artifact contract：
+
+- frontmatter 必须包含 `artifact_kind: product-discovery`、`version: 1`、`source_skill: vibe-product-discovery`、`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`。
+
+必须填充：
+
+- `problem`：要解决的用户问题。
+- `target_users`：目标用户或角色。
+- `scenarios`：关键使用场景。
+- `current_alternatives`：用户当前替代方案或绕路方式。
+- `value_hypothesis`：价值假设。
+- `success_metrics`：成功指标和观察信号。
+- `anti_metrics`：反指标或不希望发生的结果。
+- `mvp_slice`：最小可验证产品切片。
+- `non_goals`：本阶段不做范围。
+- `risks`：产品风险和假设。
+- `decision`：继续、暂停或需要补充信息。
+- `Evidence`：证据来源和未验证项。
+- `Workflow Handoff`。
+
+## 禁止事项
+
+- 不要直接输出实现计划或文件清单。
+- 不要把“用户想要某功能”当作用户问题。
+- 不要在目标用户、场景或成功指标不清时进入实现。
+- 不要引入大型调研、MCP、外部数据源或 subagent，除非用户明确要求并授权。
+- 不要把 UI 交互细节塞进产品发现；UI 细节交给 `vibe-ui-design`。
+
+## 下一步调用
+
+- 产品问题、用户、场景和指标明确：`next_skill: vibe-product-spec`。
+- 发现无需产品规格、只是明确小工程任务：`next_skill: vibe-planning`。
+- 问题或价值假设仍不清：`next_skill: none`。
+- 原始目标需要重新定义：`next_skill: vibe-brainstorming`。
+
+## 示例输出结构
+
+```text
+problem:
+target_users:
+scenarios:
+current_alternatives:
+value_hypothesis:
+success_metrics:
+anti_metrics:
+mvp_slice:
+non_goals:
+risks:
+decision:
+
+## Workflow Handoff
+
+current_skill: vibe-product-discovery
+next_skill: vibe-product-spec
+reason: 产品问题、目标用户和 MVP 切片已明确，可以进入产品规格。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```

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

@@ -0,0 +1,105 @@
+---
+name: vibe-product-spec
+description: Use when product discovery has clarified the problem and the work needs a PRD or capability spec with user stories, requirements, acceptance criteria, priority, release slice, and out-of-scope boundaries before UI or architecture planning.
+---
+
+# Vibe Product Spec
+
+## 目标
+
+把产品发现结果转成可被 UI、架构和工程计划消费的产品规格，明确用户故事、功能要求、非功能要求、验收条件和发布切片。
+
+本 skill 只定义产品规格和验收契约，不做架构设计、不拆工程任务、不写代码。
+
+## 适用场景
+
+- `vibe-product-discovery` 已明确问题、用户、场景和 MVP 切片。
+- 产品目标清楚，但需要转成 PRD / capability spec。
+- 需要在 UI 设计和架构计划之前稳定验收标准。
+- 需要判断哪些要求属于本次发布，哪些应延后。
+
+## 输入
+
+- 产品发现输出。
+- 目标用户和关键场景。
+- MVP 切片、成功指标和非目标。
+- 业务、平台、合规、性能或可用性约束。
+
+## 工作流
+
+1. 确认产品发现结论是否足够支撑规格编写。
+2. 写出用户故事和关键场景流程。
+3. 列出功能要求，避免把实现方案写成需求。
+4. 列出非功能要求，例如性能、可访问性、安全、可观测性或兼容性。
+5. 定义验收标准和不通过条件。
+6. 标记优先级、发布切片和延后范围。
+7. 判断是否需要 UI 设计；无 UI 影响时可直接进入架构规划。
+
+## 输出
+
+必须输出标准 artifact，并优先使用 `templates/product-spec.md` 作为结构基线。
+
+Artifact contract：
+
+- frontmatter 必须包含 `artifact_kind: product-spec`、`version: 1`、`source_skill: vibe-product-spec`、`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`。
+
+必须填充：
+
+- `product_goal`：产品目标。
+- `users_and_scenarios`：用户与场景。
+- `user_stories`：用户故事。
+- `functional_requirements`：功能要求。
+- `non_functional_requirements`：非功能要求。
+- `acceptance_criteria`：产品验收标准。
+- `priority`：优先级和理由。
+- `release_slice`：本次发布切片。
+- `out_of_scope`：明确不做范围。
+- `open_questions`：待确认问题。
+- `Evidence`：证据来源和未验证项。
+- `Workflow Handoff`。
+
+## 禁止事项
+
+- 不要把技术实现步骤伪装成产品需求。
+- 不要在验收标准缺失时进入 UI 或架构阶段。
+- 不要把 UI 组件结构写死；UI contract 交给 `vibe-ui-design`。
+- 不要把工程任务拆解塞进规格；任务拆解交给 `vibe-writing-plans`。
+- 不要默认启用 subagent、MCP 或外部产品管理工具。
+
+## 下一步调用
+
+- 有界面、交互、文案或体验影响：`next_skill: vibe-ui-design`。
+- 无 UI 影响且规格清楚：`next_skill: vibe-planning`。
+- 产品问题或切片不清：`next_skill: vibe-product-discovery`。
+- 缺少关键决策：`next_skill: none`。
+
+## 示例输出结构
+
+```text
+product_goal:
+users_and_scenarios:
+user_stories:
+functional_requirements:
+non_functional_requirements:
+acceptance_criteria:
+priority:
+release_slice:
+out_of_scope:
+open_questions:
+
+## Workflow Handoff
+
+current_skill: vibe-product-spec
+next_skill: vibe-ui-design
+reason: 产品规格已明确，且存在界面或交互影响，需要进入 UI/UX contract。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```

package/skills/vibe-receiving-code-review/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: vibe-receiving-code-review
+description: Use when receiving review feedback to understand, verify, classify, and decide each item before implementing changes.
+---
+
+# Vibe Receiving Code Review
+
+## 目标
+
+处理 review feedback 时先理解和验证，再决定修复、拒绝、澄清或重新规划，避免盲修和表演式认同。
+
+本 skill 不直接修复问题；它先把 feedback 转成可执行、可验证、可拒绝或需澄清的决策清单。
+
+## 适用场景
+
+- 用户或 reviewer 给出 review feedback。
+- feedback 包含多个条目，需要排序和澄清。
+- feedback 可能与当前架构、范围或用户决策冲突。
+- 需要判断哪些反馈是阻塞，哪些只是可选建议。
+
+## 输入
+
+- review feedback 原文。
+- feedback 来源：用户、人工 reviewer、agent reviewer 或外部系统。
+- 当前目标、计划和验收标准。
+- 当前代码/文档现实。
+- 已有验证证据和未验证项。
+
+## 工作流
+
+1. 完整读取 feedback，不立即实现。
+2. 按条目拆分，并标记来源和优先级。
+3. 对每条 feedback 复述技术要求或提出澄清问题。
+4. 对照当前项目现实验证是否成立。
+5. 分类为：必须修复、可接受但非阻塞、技术性拒绝、需要澄清。
+6. 若存在不清楚条目，先停止并要求澄清。
+7. 若需要修复，按阻塞优先、简单优先、复杂后置排序。
+8. 输出下一步的测试/验证策略或排查路径。
+
+## 输出
+
+必须输出：
+
+- feedback 来源。
+- feedback 条目清单。
+- 分类结果。
+- 每条的证据或待验证点。
+- 需要澄清的问题。
+- 修复顺序。
+- 技术性拒绝理由。
+- `Workflow Handoff`。
+
+## Feedback Decision Gate
+
+每条 feedback 必须先决策、再实现：
+
+- `item`：原始反馈或准确复述。
+- `source`：用户、人工 reviewer、agent reviewer 或外部系统。
+- `understanding`：当前理解的技术要求。
+- `evidence_check`：项目现实、代码、artifact、测试或日志是否支持该反馈。
+- `classification`：`must_fix`、`non_blocking`、`reject` 或 `needs_clarification`。
+- `decision_reason`：接受、拒绝或要求澄清的技术理由。
+- `verification_after_fix`：若修复，完成后如何验证。
+
+存在 `needs_clarification` 时不要批量修复；存在与架构或用户决策冲突的反馈时，应回到 `vibe-planning` 或请求用户裁决。
+
+## 禁止事项
+
+- 不要在理解前说“你说得对”。
+- 不要在验证前直接实现 feedback。
+- 不要批量修复未澄清的反馈。
+- 不要忽略 Critical / Important 反馈。
+- 不要把 reviewer 建议当作自动成立的需求变更。
+- 不要绕过 `vibe-test-driven-development` 直接进入实现。
+
+## 下一步调用
+
+- feedback 明确且需要修复：`next_skill: vibe-test-driven-development`。
+- feedback 需要先复现或定位根因：`next_skill: vibe-systematic-debugging`。
+- feedback 涉及需求、范围或架构冲突：`next_skill: vibe-planning`。
+- feedback 无需处理或已给出技术性拒绝理由：`next_skill: vibe-verification-before-completion`。
+- feedback 不清楚或缺少关键上下文：`next_skill: none`。
+
+## 示例输出结构
+
+```text
+feedback 来源：
+条目：
+  - 内容：
+    分类：必须修复 | 非阻塞 | 拒绝 | 需澄清
+    证据：
+    决策：
+需澄清：
+修复顺序：
+技术性拒绝：
+
+## Workflow Handoff
+
+current_skill: vibe-receiving-code-review
+next_skill: vibe-test-driven-development
+reason: feedback 已分类，存在明确需要修复的条目。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```

package/skills/vibe-requesting-code-review/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: vibe-requesting-code-review
+description: Use before requesting review or merge checks to package the goal, scope, evidence, risks, and review expectations without automatically dispatching a reviewer.
+---
+
+# Vibe Requesting Code Review
+
+## 目标
+
+在请求 review 前整理评审输入，让 review 聚焦真实风险、验收标准和当前证据。
+
+本 skill 只准备 review 请求，不自动派发 reviewer，不调用 subagent，不创建 PR，不执行平台 API。
+
+## 适用场景
+
+- 用户要求 review、检查质量或合并前审查。
+- 一个实现批次已完成，需要明确评审范围。
+- 准备把计划、diff 或验证证据交给人工或 agent 审查。
+- 需要避免 reviewer 缺上下文、误判范围或重复检查无关内容。
+
+## 输入
+
+- 用户目标。
+- 改动范围。
+- 相关计划、需求或验收标准。
+- 当前 diff、文件清单或基准状态。
+- 已运行验证和未验证项。
+- 已知风险和需要重点检查的问题。
+
+## 工作流
+
+1. 明确 review 要判断什么。
+2. 收敛 review 范围，排除无关文件和无关建议。
+3. 整理需求、计划和验收依据。
+4. 整理当前验证证据和未验证风险。
+5. 明确希望 reviewer 重点检查的行为、边界、兼容和交付风险。
+6. 输出 review 请求包后，进入 `vibe-review`。
+
+## 输出
+
+必须输出：
+
+- review 目标。
+- review 范围。
+- 依据。
+- 当前证据。
+- 未验证项。
+- 重点风险。
+- reviewer 需要回答的问题。
+- `Workflow Handoff`。
+
+## Review Package Gate
+
+review 请求包必须让 reviewer 能独立判断风险，而不是重新猜上下文：
+
+- `goal`：本次 review 要判断的交付目标。
+- `scope`：纳入 review 的文件、artifact、任务或阶段。
+- `out_of_scope`：明确不评审的范围，避免漂移。
+- `basis`：需求、计划、验收、runtime artifact 或用户决策依据。
+- `evidence`：已运行检查、关键输出、digest-bound artifact 或人工验收信号。
+- `unverified`：没有覆盖的检查和原因。
+- `risk_focus`：希望优先检查的行为、边界、兼容或安全风险。
+- `questions`：需要 reviewer 回答的具体问题。
+
+缺少目标、范围、依据或当前证据时，不能把 review 请求包标记为 ready。
+
+## 禁止事项
+
+- 不要自动派发 reviewer subagent。
+- 不要声称已经完成 review。
+- 不要把缺少验证证据的工作包装成可交付。
+- 不要让 reviewer 审查无关范围。
+- 不要复制参考项目的 review package 脚本或 reviewer 模板作为 runtime 资产。
+
+## 下一步调用
+
+- review 输入完整：`next_skill: vibe-review`。
+- 缺少完成前验证证据：`next_skill: vibe-verification-before-completion`。
+- review 范围或验收依据不清：`next_skill: vibe-planning`。
+- 缺少关键输入：`next_skill: none`。
+
+## 示例输出结构
+
+```text
+review 目标：
+review 范围：
+依据：
+当前证据：
+未验证项：
+重点风险：
+需要 reviewer 回答：
+
+## Workflow Handoff
+
+current_skill: vibe-requesting-code-review
+next_skill: vibe-review
+reason: review 输入已整理完毕，可以进入审查。
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition: none
+```

package/skills/vibe-review/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: vibe-review
+description: Use when reviewing implementation quality, architecture boundaries, delivery readiness, or risks before merging or shipping.
+---
+
+# Vibe Review
+
+## 目标
+
+从行为、边界、风险和交付角度审查改动，优先发现会阻塞交付的问题。
+
+## 适用场景
+
+- 用户要求 review。
+- 用户要求请求 review、检查质量或合并前审查。
+- 合并前检查。
+- 完成较大改动后。
+- 需要判断方案是否过度设计。
+- 需要检查跨平台兼容风险。
+
+## 职责边界
+
+- `vibe-requesting-code-review` 负责准备 review 目标、范围、依据和证据。
+- `vibe-review` 负责审查行为、边界、风险和交付质量。
+- `vibe-receiving-code-review` 负责处理 review feedback。
+- 本 skill 不自动派发 reviewer，不自动执行修复。
+
+## 输入
+
+- 用户目标。
+- 改动范围。
+- 相关 diff 或文件。
+- 验收标准。
+- 平台适配要求。
+
+## 审查维度
+
+1. 需求是否满足。
+2. 模块边界是否清晰。
+3. 数据流 / 状态流是否合理。
+4. 错误处理是否完整。
+5. 是否存在过度设计。
+6. 是否引入安全风险。
+7. 是否破坏平台兼容。
+8. 是否具备可验证路径。
+
+## 输出优先级
+
+1. 阻塞问题。
+2. 高风险问题。
+3. 中低风险改进。
+4. 可选建议。
+
+## Review Finding Gate
+
+每条 review finding 必须是可验证的技术判断，不能是泛泛偏好。字段至少包括：
+
+- `severity`：`blocking`、`high-risk`、`improvement` 或 `optional`。
+- `evidence`：具体文件、artifact、命令输出、验收项或行为证据。
+- `impact`：会造成的行为风险、边界破坏、回归或交付风险。
+- `required_change`：阻塞项必须说明解除阻塞所需条件。
+- `verification`：修复后应如何验证。
+- `scope`：确认该问题属于本次 review 范围。
+
+没有证据的项只能作为问题或待查事项，不能标为 blocking。与用户已确认范围冲突的建议必须进入 `vibe-receiving-code-review` 判断，不直接要求修改。
+
+## 禁止事项
+
+- 不要为了显得全面而堆砌无关建议。
+- 不要只讲代码风格，不讲行为风险。
+- 不要没有证据就断言问题。
+- 不要把个人偏好包装成阻塞问题。
+
+## 示例输出结构
+
+```text
+阻塞：
+高风险：
+改进：
+可选：
+结论：
+```
+
+## 下一步调用
+
+- 存在阻塞或高风险且需要先处理 feedback：`next_skill: vibe-receiving-code-review`。
+- 存在阻塞或高风险且修复路径明确：`next_skill: vibe-test-driven-development`。
+- 没有阻塞但需要交付前确认：`next_skill: vibe-verification-before-completion`。
+- 审查结论完整且无需继续：`next_skill: none`。
+- 问题来自需求或边界不清：`next_skill: vibe-planning`。
+
+## Workflow Handoff
+
+```text
+current_skill: vibe-review
+next_skill: vibe-receiving-code-review | vibe-test-driven-development | vibe-verification-before-completion | vibe-planning | none
+reason:
+handoff:
+  goal:
+  scope:
+  key_decisions:
+  files:
+  risks:
+  acceptance:
+stop_condition:
+```