运行 PlanetScale 清点与审查技能后，生成可执行…

已有 PlanetScale 数据库与可选连接仓库的清查/审查证据后，按固定 Markdown 结构产出客户最佳实践评估，隔离运行错误与发现，并将建议与已批准变更分开。

适用场景

解决思路

1. 撰写报告时，面向客户数据库和可选连接仓库，产出清晰、可执行、证据支撑且安全的评估；将建议与已应用变更分开。
2. 使用技术、陈述式语气，定位为工程师评估而非营销文案；报告目的是准确评估并帮助客户从其运行的平台获得完整价值；功能采用建议只跟随证据，不跟随修辞框架。
3. 将未使用功能表述为带量化影响的能力缺口；不要写 “off (good)”、“not enabled (safe)” 或以其他方式把未采用呈现为正面发现；正确形式是当前状态、该功能提供什么、它对应的实测发现，例如 “Raw query collection: disabled. Enabling it exposes literal parameter values per execution; applicable to Q1 (38% of total query time), where the pattern-level data is insufficient to isolate the triggering invocation.”
4. 不使用热情标记；不要使用 “earning its keep”、“paying off”、“easy to adopt”、“cutting root-cause time from hours to minutes” 或任何感叹号；陈述机制和测量值，让数字承担论证。
5. 将运营成本作为事实内联陈述，不软化；例如 “literal values become visible to the observability pipeline” 是该功能的一种属性，只陈述一次，不作安慰性说明。
6. 每条建议都引用它针对的具体发现——fingerprint、metric、event count、time window；没有附测量的建议是不完整的。
7. 对已启用功能进行评估而非赞美；如果功能已启用，用可测量术语报告它当前在做什么，例如 “anomaly detection flagged the connection spike 9 times in 7 days; no delivery channel is configured”，并报告其配置是否完整。
8. 把契合度作为分析的一部分；如果证据不支持该客户使用某功能，明确说明。
9. 用变更提供什么来表述建议，而不是用当前状态的威胁；写 “a dedicated application role scopes credentials per service and enables rotation without downtime”，不写 “limits the blast radius of credential compromise”；避免戏剧化词汇：“blast radius”、“unprotected”、“exposed”、“public-by-default”、“at risk”；真实风险仍作为事实陈述，例如 “the production branch runs zero replicas; recovery from a primary failure requires a restore” 是一条发现，应留在报告中；排除的是戏剧化，不是披露。
10. 用已验证语义报告平台行为，不作假设；当两个 API 表面显示不同值时，它们通常是不同设置——查阅文档并报告有效状态；不要在未验证假设上把平台行为标为不一致、矛盾或有 bug；若语义无法验证，陈述每个表面报告什么而不下结论，并将问题转给 PlanetScale support；若已验证的平台行为确实错误，按事实报告并转给 PlanetScale support——这是平台问题，不是客户配置发现。
11. 将评估工具的运行机制与发现分开；HTTP 状态码、MCP 错误、CLI 失败、token scope 问题、超时、endpoint probes 描述的是运行，不是数据库，应放入 run log，而不是 findings。
12. 对无法收集证据的地方，报告写 “not assessed in this run”，不附带错误机制。
13. evidence appendix 包含已收集的证据。
14. run log（工具错误、尝试路径、访问缺口）随报告提供，并可供运行评估的人使用；不隐藏任何内容；分离的原因是工具错误不能说明客户数据库情况。
15. 绝不因调用失败就断定功能未配置；“Not configured” 需要成功调用并返回空结果。
16. 报告使用 plain markdown：带标题的章节、散文和 pipe tables；这是基线，必须始终完整产出——它在任何 agent、terminal 或 chat surface 都可用；若宿主 agent 提供更丰富渲染（Cursor canvas、HTML preview、dashboard），可以额外使用，绝不能替代 markdown 报告。
17. 按固定报告格式开头写 “# PlanetScale best-practices assessment”。
18. 写 “## Scope” 并列出：Organization、Database、Branches reviewed、Engine、Repository reviewed、Interfaces used、Time window、Changes applied: none。
19. 写 “## Executive summary”，写 3-7 个 bullet；第一个 bullet 事实且带测量地说明平台当前为该数据库做什么，例如 replica topology and failover posture、backup cadence and last successful backup、Insights collection volume、safety features active；这不是赞美，而是报告其余部分构建所依据的运行基线。
20. 继续 Executive summary 的 bullets：最高风险安全缺口、最高价值可观测性改进、最高价值自动化机会、引擎特定工作流缺口、仓库埋点缺口。
21. 写 “## Current state”；在其中写 “### Database and branch topology”，并包含证据。
22. 写 “### Safety workflow”；对 Vitess 检查并报告：Safe migrations、Deploy requests、Approval requirements、Gated deployment usage、Schema revert runbook。
23. 对 Postgres 检查并报告：Branch migration workflow、Roles、pg_strict、Traffic Control、Backups/PITR、Connection pooling、Private connectivity and IP restrictions。
24. 写 “### Observability”；报告 Query Insights state、Anomalies、Query tags、Raw query collection posture、Schema recommendations。
25. 写 “### Automation”；报告 Webhooks、Agent loops、CI/PR workflows、Incident routing。
26. 写 “### Repository instrumentation”；报告 Frameworks and ORMs detected、Current SQL comments or tracing、Recommended SQLCommenter package/path、Tag schema。
27. 写 “## Recommendations”，使用表格结构：| ID | Recommendation | Target | Benefit | Risk | Approval needed | Test first? | Evidence |。
28. 使用推荐 ID 前缀：OBS-* 用于 Insights/query tags；VIT-* 用于 Vitess safety/deploy workflow；PG-* 用于 Postgres roles、pg_strict、Traffic Control、PITR、network；WEB-* 用于 webhooks and automation；APP-* 用于 repository instrumentation；AGENT-* 用于 MCP/agent workflows。
29. 写 “## Proposed change set requiring approval”；对每个提议变更包含：ID、Exact target、Exact change、Interface to use、Why it is recommended、Expected effect、Possible availability impact、Test plan、Rollback plan、Whether it changes production。
30. 写 “## Changes intentionally not applied”，明确说明：No PlanetScale settings changed；No schema changed；No traffic controls changed；No roles or credentials changed；No webhooks changed；No code changed；No branches, backups, restores, deploy requests, or migrations created。
31. 写 “## Evidence appendix”；对每条证据包含：Source、Command/API/MCP/repository path、Timestamp、Value、Notes。
32. 最后以指定句子结尾：“No changes have been applied. Approve specific change IDs before any mutation.”

适用边界 · 注意事项

• 不适用于非 PlanetScale 数据库、没有 PlanetScale 组织/数据库访问权限或未运行相应 inventory/review 技能的评估。
• 不适用于要求直接应用变更或自动修改生产配置的报告；该模板只产出建议和待批准变更，并明确不应用变更。
• 不适用于需要营销式、鼓励式、淡化风险或把未采用功能包装为正面发现的文案。