product-dev

name

product-dev

description

Use for repository-aware product engineering from an accepted requirement to a focused implementation and evidence-backed handoff. Covers repository intake, architecture decisions and spikes, implementation planning, feature work, bug repair, refactoring, engineering tests, code review, migration and dependency safety, debugging, and completion verification. Do not use for vague product discovery, disposable demos, product-level acceptance criteria alone, or repository-maintainer operations.

产品研发

把已经明确的产品行为或工程问题转成可审查的技术决策、聚焦代码变更、工程验证和真实交付证据。本 skill 负责工程执行纪律；产品方向探索、一次性 demo、产品级验收定义和 GitHub 维护分别交给对应能力。

何时使用

• 从 PRD、issue、设计或明确目标实现功能。
• 修复 bug、失败测试、CI/build、性能或回归问题。
• 做有行为约束的重构、代码评审或技术方案审查。
• 需要 ADR、spike/POC、迁移、兼容性、依赖或回滚决策。
• 实现后需要工程测试、diff 自审和可审计交付。

不要用于仍缺核心用户、问题或成功标准的产品探索；不要把产品验收场景等同于工程自动化测试；不要自动提交、推送、发布或操作外部系统。

边界先行

• 如果目标用户、核心问题、期望结果或成功证据仍是产品选择，不编造推荐 MVP、PRD、功能范围、架构或代码；只指出最小缺口，并路由到产品需求分析。
• 如果用户明确要一次性、可丢弃、用于理解度或想法验证的 demo，不生成实现工件，也不套用生产研发流程；把时间盒、可点击性、可丢弃性和验证问题原样交给原型验证能力。
• 只有当行为或工程问题明确到可以从仓库继续求证时，才进入下面的研发主线。

Finite Input Fast Path

当任务只有用户明确列出的有限输入文件、确定的输出路径，且不要求代码或仓库行为变更时，按材料处理快速路径执行：

1. 读取一次本 skill 后，直接按工具上限批量读取全部指定输入；多个独立批次尽量在同一模型轮并行发出。
2. 写入指定交付物，只回读该交付物一次做聚焦验证，然后结束。
3. Skip generic repository discovery：不搜索仓库规则、manifest/CI，不运行 Git/分支/基线/diff 探测，也不扩展到未指定文件。
4. 不用 manage_execution_plan 叙述有限批次的进度；只有存在真实依赖链、跨边界实现或高风险决策时才建计划。

这个快速路径只减少与任务无关的工程仪式，不跳过用户指定输入、输出验证或安全边界。

执行主线

1. 建立工程合同：区分 feature、bug/test failure、refactor、review-only、performance、decision/spike、CI/build；明确目标、非目标、不变量和完成证据。
2. 先建立仓库地图：读取 references/repository-intake.md，确认规则、脏工作区、构建测试入口、相关符号/调用路径和现有模式。
3. 先决策后编辑：存在关键取舍时读取 ADR、spike 或 decision review；多文件/跨边界任务先写短计划，小修复直接给出最小变更路径。