p7

p7 skill 概览

p7 skill 适合解决什么问题

p7 skill 是一种面向代码工作的“高级工程师执行模式”：它的目标不是直接甩出代码，而是先接住一个边界明确的实现任务，先设计方案、评估影响，再动手写代码，最后补上一段简短的自检。通俗地说，如果你需要的是更有纪律的 Code Generation 流程，而不是一句“直接写代码”，那 p7 就是为这种场景准备的。

谁适合使用 p7 skill

p7 很适合这类用户：已经有任务负责人、架构方向，或者有一个上层 agent 在拆解任务，现在只需要一个稳定的执行者来完成明确的子任务。尤其是在多 agent 协作流程里，或者你希望代码生成前先有显式计划时，p7 skill 会更贴合。

用户真正想完成的事是什么

大多数考虑使用 p7 skill 的用户，本质上是在降低实现阶段的猜测成本。它的价值不只是“生成代码”。更核心的工作是：把一个边界清晰的需求转成可执行方案，提前想清楚可能影响哪些地方，完成实现，然后用一轮紧凑的自检去给结果做压力测试。

p7 与普通 coding prompt 的真正区别

p7 最大的差异在于工作流形态。它并不是一个广义上的自治架构师，而是一个处于 P8 监督下的执行角色，遵循“方案驱动”的模式，并且要求按固定格式收尾。也就是说，它比泛化的“把这个功能做出来”型 prompt 更有结构，但又比顶层规划 agent 更聚焦、更收敛。

仓库里实际提供了什么

从仓库现有信息看，证据不多，但已经足够明确：SKILL.md 定义了角色、触发短语、输出预期，并引用了一个外部协议文件。对安装决策来说，这意味着 p7 skill 很容易快速看懂，但一些实际运行细节依赖更大的 /pua 系统，以及它引用的协议内容。

一眼看懂：适合与不适合的场景

在下面这些情况下，用 p7：

• 你希望“实现 + 推理”按固定顺序输出
• 任务可以作为子任务委派出去
• 你在意代码修改前先做影响分析

在下面这些情况下，建议跳过 p7：

• 你首先需要的是产品范围界定或架构主导
• 你想要的是开放式发散 brainstorming
• 你手头上下文不足，没法把子任务定义清楚

如何使用 p7 skill

安装 p7 skill

一个比较直接的安装方式是：

npx skills add tanweai/pua --skill p7

安装完成后，如果你的环境会按仓库结构镜像本地文件，可以先打开 skills/p7/SKILL.md；或者直接去 GitHub 仓库里的 skills/p7/SKILL.md 查看上游内容。

建议先读这些文件

对于 p7 skill，最值得优先阅读的顺序是：

1. skills/p7/SKILL.md
2. 仓库级别的 /pua core skill（如果你的环境里可用）
3. references/p7-protocol.md（如果安装后本地存在）

为什么这个顺序重要：SKILL.md 本身很短，关键行为有一部分被委托给协议文件和 /pua 的核心规则。如果你只扫一眼顶部文件，很容易漏掉真正影响执行方式的重要约束。

p7 在实际使用中怎么触发

源码里写得很明确：当用户说出 P7模式、方案驱动 这类短语时，或者当 p7 被 P8 作为子任务执行器拉起时，就会进入这个模式。实际使用时，最稳妥的做法是直接点名这个模式，并给它一个边界明确的实现任务，而不是丢给它一个开放式战略问题。

想让 p7 工作得好，需要提供哪些输入

p7 skill 在以下信息齐全时效果最好：

• 目标仓库或具体代码区域
• 明确的功能、修复或重构目标
• 语言、框架、代码风格、禁改区域等约束
• 你期望的输出形式
• 希望在影响分析里重点检查的风险点

如果这些信息缺失，p7 依然可以响应，但“方案驱动”这一步会变得更泛，实用性也会明显下降。

如何把一个模糊目标改写成高质量的 p7 prompt

较弱的输入：

• “Use p7 to improve auth.”

更强的输入：

• “Use p7 for Code Generation on the login flow. In a Next.js app, add refresh-token rotation for existing JWT auth. Do not change database schema unless necessary. First propose the implementation plan and impact analysis, then implement server and client changes, then finish with a 3-question self-review.”

为什么后者更适合 p7 skill：它同时给了任务范围、技术栈、边界限制和输出顺序，能让 p7 更稳定地按预期执行。

一个实用的 p7 工作流

比较理想的操作顺序是：

1. 先把子任务定义得尽量窄
2. 先让 p7 给出实现方案
3. 审查影响分析里有没有高风险假设
4. 确认范围，或进一步调整范围
5. 再让 p7 生成代码
6. 最后检查它的自检结果，看是否还有缺口、回归风险或未解决问题

相比一上来就要求直接出代码，这种流程更符合 p7 skill 的设计价值。

预期输出模式

仓库描述里说明，p7 会产出：

• implementation plan
• code
• 3-question self-review
• 通过 [P7-COMPLETION] 交付

如果你的工具链支持结构化的 agent 交接，最好保留这个 completion marker；如果不支持，也建议至少保留相同的内容区块，这样 p7 skill 仍然能尽量贴合它原本的协议设计。

如何把 p7 用在 Code Generation 上

在 Code Generation 场景里，p7 最擅长的是那些“设计选择会直接影响实现质量”的任务：比如需要跨多个文件修改、会改变行为且影响下游模块、或者容易牵连相邻模块的重构。反过来说，如果只是很小的一行修复，前置规划的额外开销可能未必划算，这时 p7 的优势就没那么明显。

正式采用 p7 前要注意什么

有两个采用门槛比较明显：

• 一部分协议细节是被引用进来的，而不是完整写在 SKILL.md 里
• p7 依赖更大的 /pua 生态语境，包括核心 guardrails 和 narration protocol

所以如果你想要一个完全自包含的 skill，p7 可能会显得文档不够完整，除非你同时加载了它的上层系统上下文。

如何评估第一次运行的质量

第一次跑 p7 skill 时，建议重点看它是否做到下面几点：

• 是否把规划和实现明确分开
• 是否识别出了受影响的文件、模块或接口
• 是否遵守了你给出的约束
• 是否真的给出了有意义的自检，而不是走形式的 checklist

如果这些部分缺失，问题通常更可能出在触发方式或运行环境没有按预期加载 skill，而不一定是 p7 本身不可用。

p7 skill 常见问题

p7 对新手友好吗？

算是中等友好。p7 skill 本身不难理解，但它并不是为“从零教学”优化的。它默认你已经能够描述任务、审阅实现方案，并判断影响分析是否合理。

不依赖 P8，p7 还能用吗？

可以，但会有边界。源码定位里，p7 是处于 P8 监督下的执行角色，所以最理想的用法仍然是作为被委派的执行器。你也可以单独使用 p7，只要你模拟这种使用方式：给它边界清晰的子任务和明确约束即可。只是不要期待它承担顶层编排职责。

什么情况下 p7 比普通 prompt 更好用？

当你需要的是“纪律性更强的工程执行”时，p7 往往比普通 prompt 更合适。如果任务适合“先计划、再编码、最后复盘”这条路径，p7 skill 提供的结构化流程，正是普通 prompt 最容易跳过的部分。

什么情况下不该用 p7？

以下场景不建议用 p7：

• 模糊的产品创意发散
• 在需求不清晰前提下做大范围架构选型
• 任务高度依赖仓库特定协议，但你还没把这些上下文加载进来
• 修改非常琐碎，结构化规划只会增加延迟，却几乎不提升质量

p7 自带安装脚本或额外资源吗？

根据当前能看到的仓库信息，skill 目录视图里没有明显暴露额外脚本或打包好的支持文件。核心文件是 SKILL.md，并且它引用了 references/p7-protocol.md，所以安装后建议确认这个文件在你的环境里是否可用。

p7 对输出格式有明确要求吗？

有。skill 描述里指向了固定的 completion wrapper，以及一组特定的交付顺序。对于希望 agent 输出保持一致的团队来说，这很合适；但如果你更偏好自由对话式的 coding 方式，这种约束感可能就没那么理想。

如何改进 p7 skill 的使用效果

先把 p7 skill 的子任务边界收得更紧

想让 p7 出更好的结果，最快的办法就是把任务缩小。不要只说“重构支付模块”，而要明确到具体 endpoint、组件、模块，或者某种失败模式。p7 本质上是执行器；边界越清晰，Code Generation 质量通常越高。

明确点名要做哪些影响分析

不要只说“做一下 impact analysis”，最好直接指定要检查什么：

• API compatibility
• schema changes
• test impact
• performance risk
• migration needs
• rollback concerns

这样做会让 p7 skill 的规划阶段从“形式上有”变成“实质上有用”。

一开始就提供仓库线索

如果你已经知道大概率会涉及哪些文件，直接告诉 p7。比如：

• src/auth/session.ts
• app/api/login/route.ts
• tests/auth.spec.ts

对于规模较大的仓库，这一点尤其重要，因为 Code Generation 质量往往取决于它是否一开始就找对了修改表面，而不是在仓库里到处游走。

上下文不足时，先要求列出假设再写代码

一个常见失败模式是：在上下文很弱的情况下过早开始实现。如果你的说明还不完整，可以直接告诉 p7： “List assumptions and blockers before coding.” 这样能保留这个 skill 的“方案驱动”特性，而不是逼它产出低置信度代码。

把自检当成修订工具，而不是装饰

那段 3-question self-review 不应该只是摆设。建议重点从里面看：

• 是否暴露了隐藏假设
• 是否遗漏了边界情况处理
• 是否缺少测试或验证步骤

然后把这些缺口再喂回去，跑第二轮 p7。这是在不改动 skill 本身的前提下，提升 p7 使用效果最简单的方法之一。

用验收标准强化 p7 prompt

如果你想让 p7 在 Code Generation 上更稳定，最好把成功条件也一并写进去，比如：

• “existing tests must still pass”
• “no breaking API changes”
• “support both mobile and desktop UI”
• “keep public function signatures stable”

验收标准能把 p7 从“会写代码的执行者”进一步推向“更可靠的执行者”。

需要尽早识别的常见失败模式

建议尽早留意这些信号：

• 方案写得过于泛，无法真正指导实现
• 代码忽略了你已经声明的约束
• 自检没有提到真实存在的 tradeoff
• 方案默认依赖你并未提供的上层系统上下文

这些问题通常更像是 prompt 质量或上下文加载不足，而不是 p7 skill 本身不可用的证据。

作为一个 skill，p7 还能怎样变得更好

如果仓库能把更多协议内容直接内联展示，或者在 skill 文件夹里更直接地链接 supporting files，p7 skill 的上手门槛会低很多。除此之外，如果再补上更具体的调用示例、预期 completion 结构，以及脱离上层系统时的独立使用方式，新用户的安装和接入成本也会更低。