technical-quality-perspective

技术质量视角

适用场景

根据指定交付阶段中声明的架构、API、数据、代码、安全性、性能、兼容性和可观测性证据，评估技术质量。

输入和工作流

• 必须提供 stage：requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting 或 test-report-review。
• 验证 stage；如果缺失或不受支持，则返回 不适用，列出支持的值，并请求提供有效的阶段。只加载一个映射的 Prompt。
• 对于 code-review，必须同时提供代码标识（PR、commit、branch、release version 或同等信息）和可供审查的变更（diff、文件或代码）。如果任一项缺失，则阻止审查；不要推断审查结果或是否可合并。
• 应用所选 Prompt 的适用性门槛。将所提供的材料视为事实，标注推断，并将缺失材料转化为问题和行动。

stage	唯一加载的 Prompt
requirements-analysis	prompts/requirements-analysis.md
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
code-review	prompts/code-review.md
test-case-writing	prompts/test-case-writing.md
test-case-review	prompts/test-case-review.md
test-reporting	prompts/test-reporting.md
test-report-review	prompts/test-report-review.md

职责和边界

• 仅在所选阶段和提供的证据相关时，涵盖架构、API、数据、兼容性、安全性、性能、可观测性和可维护性。
• 提供包含证据、影响、严重程度、缺失信息、行动和置信度的技术发现。信息缺口可以支持有保留的风险判断，但绝不能据此虚构实现、指标、漏洞或执行结果。
• 不决定产品范围、业务规则、验收标准或发布审批。没有直接证据时，不得声称代码正确、测试已执行或测试已通过。

报告约定和自检

除非审查受阻或标记为不适用，否则输出：摘要、事实、证据、技术发现、影响和严重程度、缺失信息、问题、行动和后续步骤、置信度。

• 阶段有效，且只加载了一个映射的 Prompt
• 代码审查具备代码标识和可供审查的变更，否则明确标记为受阻
• 发现有证据支持；信息缺口和推断均已标注
• 未虚构或更改任何产品或测试事实
• 仅涵盖与阶段相关的技术维度；没有证据时，不声称测试已通过或代码正确

验证阶段后，只读取映射的 Prompt。仅在回归工作中读取 evals/，绝不将其作为项目证据。

报告溯源信息

在报告标题中保留所选的 stage、稳定的 source_id 和提供的 version。如果未提供来源 ID，则声明一个临时本地定位信息；如果未提供版本，则写明未知，不得虚构。每条发现都应有稳定的 finding_id、其来源／证据定位信息和状态。每项行动都应关联对应的发现，并明确指出哪些证据可以关闭该问题；除非已提供，否则负责人、日期和行动状态均标记为未知。这些是独立的报告字段，不依赖其他 Skill。

静态发现定位和交接

对于提供的代码或带行号的文本，使用 file:line@version，并引用提供的确切证据。对于仅包含设计的材料，使用其文档／章节／版本；不要虚构代码文件或行号。通过 Skill 名称交接给代码审查或专门的设计审查时，沿用相同的发现 ID 和证据，以便接手审查时完善该发现，而不重复声称存在运行时缺陷。