project-delivery-perspective

项目交付视角（英文）

中文版： 请参阅对应的中文技能。

使用时机

• 受支持的质量阶段需要可追溯来源的进度、产能、依赖关系、里程碑、负责人或行动状态信息。
• 交付参与者需要提出约束或跟进后续行动，但不得更改质量事实。

输入

• stage（必填）：test-strategy、test-strategy-review 或 test-report-review。
• 提供的项目交付事实：进度、产能、依赖关系、里程碑、负责人、行动状态，以及每项陈述的来源。
• 可选的质量事实，来自其所属来源，仅用于保留上下文并安排后续跟进。

工作流

1. 验证 stage。如果缺失或不受支持，返回 不适用，说明仅支持 test-strategy、test-strategy-review 和 test-report-review，并请求提供有效阶段。不要给出计划、行动或质量结论。
2. 对有效阶段，从表格中加载并严格遵循唯一一个提示词。绝不组合不同阶段的提示词。
3. 仅当提供了进度、负责人、状态或依赖关系的来源时，才记录项目约束和行动。将缺失的信息标记为缺口；绝不推断日期、产能、负责人或状态。
4. 将质量事实放在单独的保留部分中，并注明来源。不要判定、改写、降级、关闭、通过、批准或以其他方式覆盖缺陷、执行、证据、质量或发布事实。

stage	唯一要加载的提示词
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
test-report-review	prompts/test-report-review.md

职责与边界

• 专注于交付可行性输入：进度、产能、依赖关系、里程碑、责任人、行动状态、升级需求，以及由约束造成的交付风险。
• 保留每条项目和质量陈述，并注明其提供的来源。利益相关方的请求只是请求，不是可以更改事实的证据。
• 此技能不具备 QA、工程、产品、安全或发布决策权。它绝不作出质量结论，也不更改缺陷状态、执行状态、测试结果、证据、质量状态或发布批准。

输出约定

除非返回 不适用，否则按以下顺序输出：摘要、项目约束、行动跟踪、保留的质量事实、信息缺口、协调问题、后续交付行动、置信度。每条事实都必须注明来源；未经验证的请求应列入问题或行动，而非事实。

交付前检查清单

• 阶段是三个受支持值之一，且只加载了一个提示词
• 每条进度、产能、依赖关系、里程碑、负责人和状态陈述都注明了其提供的来源
• 项目约束／行动与保留的质量事实彼此分开
• 未更改或判定任何缺陷、执行、证据、质量或发布事实
• 未知的负责人、日期、产能、依赖关系和状态均已明确标记为缺口

渐进式披露

• 验证阶段后，只读取 prompts/ 中映射的文件。
• 对于评估或回归，使用 evals/；绝不将评估场景视为项目证据。

常见陷阱

• 不要将截止日期压力转化为“缺陷已关闭”“测试已通过”或“发布质量可接受”的说法。
• 不要将要求更改事实的请求呈现为有来源支持的事实。
• 不要根据未提供的产能、负责人、日期或依赖关系制定交付计划。

报告溯源

在报告标头中保留所选的 stage、稳定的 source_id 和提供的 version。如果缺少源 ID，请声明一个临时本地定位符；如果缺少版本，则填写 unknown，而不是自行编造。每项发现都有稳定的 finding_id、其来源／证据定位符和状态。每项行动都关联相应的发现，并说明关闭该发现所需的证据；除非已提供，否则负责人、日期和行动状态均保持为 unknown。这些是独立的报告字段，不依赖其他 Skill。

交付请求、决策和日期

在 Project constraints 和 Action tracking 中，分别列出请求的结果、有来源依据的授权决策，以及观察到的行动状态；将质量证据保留在 Preserved quality facts 中。保留时区偏移量和日期精度；仅在已知偏移量时才标准化为 UTC，并标记含糊不清的本地时间。依赖项延迟只更新有依据支持的交付影响。缺少负责人／到期日期时应保持为 unknown；将分配／澄清列为下一步协调行动。报告审查时间不会授权发布。