1实现原理 · 为什么它能做到
纯 prompt 编排的「产物生成器」：输入是 dbs-save 落盘的存档 markdown，输出是一份带时间戳的新报告 markdown，全程只做读取、合并、分类、搬运
skills/dbs-report/SKILL.md
报告内容必须来自 `{存档根目录}/sessions/{项目名}/` 下的存档文件。
仓库 README.md 把它定位为「记录、复盘长期决策 | /dbs-decision、/dbs-save、/dbs-restore、/dbs-report」。
与 dbs-save/dbs-restore 共用同一套存档根目录解析规则（.dbs/config.json 的 default/project/custom 三模式），且三者都只读配置、不写配置
skills/dbs-report/SKILL.md
`dbs-report` 只读取配置，不修改配置。
解析失败/路径指向 / 或家目录或项目根时「停止生成报告并说明配置问题」，不静默退回默认位置。
可信度靠「可追溯」而非「总结得好」：核心原则第一条禁止从对话凭空总结，每条内容必须能指回具体存档的具体字段
skills/dbs-report/SKILL.md
**不从对话凭空总结**。报告内容必须能追溯到具体存档文件的具体字段。这是报告的可信度
因此报告六段中五段是搬运 + 去重 + 分类，只有「用户主诉的演进」一段允许做简短总结。
多次运行永不覆盖并靠时间戳留出「诊断快照对比」能力
skills/dbs-report/SKILL.md
每次新生成一份，**永不覆盖**。文件名带时间戳，方便对比不同时点的诊断快照。
路径规则 {存档根目录}/reports/{项目名}/{YYYYMMDD-HHMMSS}-{项目名}.md，目录不存在先 mkdir -p。
结论冲突不做仲裁：新旧两条都列，新的在前，旧的标「（已被后续诊断修正）」
skills/dbs-report/SKILL.md
如果一条结论在后续存档里被推翻或修正，**两条都列出来**，新的在前，旧的在后并加 `（已被后续诊断修正）` 标注。
「多份存档之间结论冲突 → 都列出来」被再次写进边界情况。
刻意不做脱敏：存档里的敏感数字与客户名原样进入报告，脱敏责任被推回 dbs-save 阶段
skills/dbs-report/SKILL.md
存档文件里有用户标的「敏感信息」（比如真实收入、客户名字）→ 报告原样保留。不做脱敏。
skill 的理由是「这是用户自己存进去的」，并把格式产出也收窄：不主动出 PDF/HTML。
数据量起点有门槛：0 份直接拒绝、1 份先劝阻并询问是否强制、≥2 份才进入合并（--since 过滤后同样按此判定）
skills/dbs-report/SKILL.md
0 个文件 → 「`{项目名}` 下还没有可汇总的存档。
避免产出无信息量的空报告或单文件报告的伪合并产物。
与 dbs-wechat-html 的衔接是有条件的：仅在用户确有发布需求时提示一次，无需求时不提
skills/dbs-report/SKILL.md
想发公众号或群里，可以用 `/dbs-wechat-html` 把这份 markdown 转成微信后台粘贴版。
原文前置条件：「如果用户需要把报告发布到公众号或群里，加一句」；后置「用户没有发布需求时不加」。
2核心能力
01多存档合并：按 YYYYMMDD-HHMMSS 时间正序读取、解析 frontmatter 与 body 六段
02报告六段结构：主诉演进 / 已确认结论 / 已否决方向 / 当前未解决问题 / 推荐下一步 / 存档索引表
03结论去重与修正标注（语义相近合并、按时间倒序、被推翻的两条都留）
04日期过滤 --since 与项目切换 --slug
05未解决问题汇总：合并 in-progress 存档的待验证假设 + 最早存档提出却从未被处理的方向
06下一步优先级排序（最新优先 / 反复出现但未走 / 已被替代的标注）
07状态字段中文化展示（in-progress/resolved/abandoned → 进行中/已结论/已放弃）
08不跨目录搜索私人文件：只在当前配置指向的 sessions 目录内工作
4管控建议与判定依据
建议配套管控措施
面向 Agent
声明可访问域名与密钥范围
面向管理者
密钥最小权限，保留请求日志
判定依据（文件路径与关键语句摘要）
- 环境变量 / API Key: 读取厂商服务密钥: 读取 .dbs/config.json 以解析存档根目录（mode=default/project/custom + root）——这是用户自己的配置
- 本地工作目录: 文件读写与工件输出: {存档根目录}/reports/{项目名}/{YYYYMMDD-HHMMSS}-{项目名}.md（新报告，永不覆盖；目录不存在时 mkdir -p）
审计说明： 。判级对象是本 skill 自身目录：无脚本、无网络端点、无凭证读取，但 SKILL.md 明确要求 agent 读取本地存档并写出新报告文件（{存档根目录}/reports/…md），属「仅本地读写、无外发」档。注意点集中在隐私而非代码执行：报告刻意不脱敏（收入、客户名字原样保留），且产物是「可分享材料」——一旦把报告发出去，等于把存档里的敏感细节一并交出；skill 在边界情况里已显式声明该立场。
5第二遍独立确认
- [ok] 外部资源/工具：是否存在未声明的依赖或格式转换器 — 无 URL、无包、无 CLI 调用；PDF/HTML 相关语句只有禁止性的（不主动出 PDF / HTML / 其他格式）。external_deps 空数组成立。
- [ok] 安全结论：写入面是否只有报告文件 — 全文写入只有 mkdir -p 与报告文件生成；明确不修改 .dbs/config.json（「只读取配置，不修改配置」），不删除任何存档，不改写原始 sessions 文件。
- [ok] 实现原理是否成立：报告能否真正做到「每条可追溯」 — 六段中五段规定逐条携带来源（「· 出自 {对应存档的标题} · {对应日期}」）、附录给出文件名索引表，「结论冲突两条都列」避免丢失信息。机制可核查。
- [ok] 功能声明 vs 实际能力是否存在夸大 — description 只说「合并成可交付的 Markdown 报告」，未承诺分析深度或结论质量；SKILL.md 亦把「总结」限制到一段。一致。
- [unlocatable] 证据定位：仓库级元数据（stars/last_push）与 installs — stars=10121、last_push=2026-09-07 来自站点池 data/pool.json（GitHub API 采集），pin 本地副本无法逐字定位；installs 未采集记 null。license 可在仓库根 LICENSE 逐字命中。
6结论
适合： 适合长期做同一个项目诊断、需要把分散结论整理成对外材料的用户：给合伙人/顾问/客户的对账文档、周期性复盘、跨月追踪结论演进。与 dbs-save / dbs-restore 组成「存—续—出」的完整链路。
不适合： 不适合没有存档就想让 AI「总结一下聊过什么」的场景（skill 明确禁止凭空总结，会先拒绝）；不适合需要脱敏后对外发布的流程（它刻意不脱敏）；不适合需要 PDF/HTML/PPT 等成品的交付需求（只出 markdown，且明确不主动转格式）；不适合只想看单份存档的场景（1 份会被劝阻合并）。
Install Agent-Ready
① Verified Mirror 2026-09-15
Option A · Direct DownloadDownload dbs-report.tar.gz
sha256:
Option B · Copy Guide for Agent1daf478be83e49ea…agent 读 JSON 指南后会自动从本站下载安装，无需更多说明。
② Upstream GitHub
GitHub Repo ↗
Pinned to commit 8b8e33f1ec.