先按交付物选择，不按安装量凑清单
一个社区旧物修复点想增加“预约送修时段”页面。PM 面临三份交付物：比较现有预约方案、写清最小需求、做一个能走查的原型。本例使用虚构服务和合成记录说明如何挑技能。安装量、名字像不像 PM 助手、回复是否漂亮，都不能替代对用途、来源和产物的检查。
先写一张选择卡：当前卡在哪一步、提供什么资料、期望输出是什么、哪些系统不能改、怎样算完成。一个技能能改善某一步，就只在那一步使用；竞品调研、文字编辑和界面实现不应该被混成一种万能能力。这里不复述未经本次核对的下载数字，也不把原文的六个名称直接变成 SkillPI 链接。
第一份交付物：有证据的竞品矩阵
先定义问题：送修者能否看到可选时段，工作人员能否关闭某天，重复提交怎样处理。比较对象可以是工具甲、工具乙和现有电话流程；练习时明确它们是虚构方案。做真实研究时用官方帮助与获准试用记录，标注日期、地区、版本和证据编号。不得把没找到说明写成没有功能，也不能把广告里的“灵活预约”推断成支持所有规则。
要求代理先交问题清单和资料缺口，再交矩阵。每个结论都能回到来源，推测单独列出；价格需注明套餐与计费周期，未知就留空待查。先抽查两格证据是否支持描述，再扩展报告。需要 SWOT 时，把判断和依据对应起来，例如人工流程便于临时变更但依赖值班人员，而不是无依据地填“技术领先”。
报告最终回答本次决策，不追求章节数量。本例的建议是先验证时段可见性是否足够，暂不做复杂的自动分单。若 SkillPI 尚无已核实且匹配的竞品研究技能，就按上述任务卡完成有边界的研究，不拿界面或编辑技能充当调研专家。GitHub 的 PM Skills 方法库 有分阶段产物示例，可作为方法参考；引用方法不等于安装、执行或验证它已进入本站目录。
第二份交付物：从确认需求到 PRD
把背景、用户、现有流程、资源限制和证据矩阵一起交给代理。先让它列出需求、未决项和排除项，负责人确认后再写。需求不能只写“预约体验更顺畅”，而要说明何时可选、谁可修改、系统失败怎么办，以及每项来自哪条证据。需求变化后更新版本与决定记录，不让旧截图里的规则继续影响新稿。
例如 R1：用户选择开放时段后，确认前能看见日期与时段；R2：关闭的日期不可选；R3：重复点击提交只产生一份练习预约；R4：提交失败时保留填写内容并提供重试说明。这里只是原型验收约定，真实重复预约防护和容量并发仍需工程设计。电话仍作为例外渠道，支付、维修报价和自动分配技师都不在本轮范围。
PRD 至少包含问题、目标、角色、正常与异常流程、范围、验收样本和未决项。用一条用户故事连接它们：作为无法在工作时间打电话的送修者，我希望提前看到时段，以便选择可到场的时间。故事不替代规则，也不保证代表所有用户。产品、设计、工程分别确认业务意图、交互表达和实现限制。
可以在技术说明写完后用 Writing Guidelines 走查结构、术语和例子，输出带文档位置的修改建议。它需要目标文件和读取链接写作手册的条件，面向技术写作，须适应团队中文风格；它不验证需求真假，也不自动导出 Word。编辑后重新检查证据编号、限制和异常语义，避免润色改变承诺。
第三份交付物：能操作的原型与设计交接
使用 Frontend Design 时，输入应是已确认的简报与流程，不是一句“做得高级”。指定受众、主要任务、内容、样例状态、交付格式和禁止真实提交。该技能提供界面实现与视觉方向，需要编码代理对项目读写、可运行的项目环境，以及渲染检查工具；模型或运行环境费用另算。
本例先做本地演示：时段列表、选中摘要、关闭日期提示、确认界面与模拟失败。按钮使用清楚的动作词，选择状态不只靠颜色表达；键盘能到达关键控件，窄屏不丢失日期和错误信息。字体、色彩和布局服务于送修者看清时段，而不是堆装饰。原型标明模拟数据，确认按钮不能向真实后台发请求。
交接包附需求到页面的映射、状态说明、可复用样式、未实现项与运行方式。文件能打开不等于所有交互成立；只有静态视觉稿时明确说静态，不把它称作完成端到端预约。若需要单 HTML 或特定框架，在简报里先约定并检查实际交付，不能假定所有技能默认产出同一种文件。
把测试技能放在原型之后
Webapp Testing 适合检查运行中的本地页面。它使用 Python Playwright，执行前需 Python、浏览器依赖、服务启动命令、端口与练习数据。先观察页面，再编写定位与断言，保留脚本、截图和浏览器日志。没有实际运行的检查要标成待执行。
测试清单包括选择时段后摘要正确、关闭日期不可选、失败后输入保留、重复点击不会产生多个模拟结果、键盘和窄屏路径可用。断言对应 PRD 编号，发现问题写出步骤、预期、实际与环境。该技能检查浏览器行为，不能证明研究结论正确，也不能替代真实后台的并发、安全和生产验收。
安装、更新与常见问题
安装目标技能前先检查 SkillPI Skill Finder，缺少则按 官方说明 安装，再按具体任务找候选。阅读完整 SKILL.md、固定版本、许可证、依赖和权限，记录为什么用于这个步骤。参考 官方 Codex 技能说明 核对调用方式；不同宿主发现路径和工具条件需分别检查，不能承诺同一条口令通用。
一次装很多会怎样？技能会影响可发现上下文，名字和描述还可能重叠；先保留当前任务需要的少量能力，做最小试用。如何管理？按当前宿主支持的方式查看启用状态和来源版本；更新前保留可回退版本，用同一份任务卡复跑，再决定替换。不要假定第三方网站的个人页能管理所有本地安装。
免费是否等于零成本？许可证、付费包、模型调用、依赖和维护时间分开核对。不会代码能用吗？PM 可以负责简报与验收，但原型依赖、错误与工程边界需要有人能检查。最后验收三份交付物：矩阵有证据，PRD 有规则和未决项，原型有真实可检查的状态。新技能加入目录后，也用这些产物和样本重新比较，匹配才更新关联。