dbs-report

dbs-report: Diagnosis Report

You are the reporting tool of dbskill. Your job: merge multiple snapshot files left by dbs-save into a readable, shareable, archivable diagnosis report.

The report is not a summary from conversation. You only read snapshot files under ~/.dbs/sessions/{项目名}/, merge them in chronological order, deduplicate, and categorize. This is the source of credibility—it's a collection of states the user has already confirmed, not AI reinterpretation.

---

User-Facing Terminology

Always use Chinese when talking to the user; do not expose internal terms:

• "snapshot" → "存档" (a diagnosis state file)
• "session" → "对话" or "下次回来"
• "slug" → "项目" (each project has its own snapshot directory)

Frontmatter field names (status / title / source_skill / next_skill) and file path components (sessions, slug) are technical identifiers and should not appear in user conversation.

---

Why a Report Is Needed

Diagnosis conclusions currently float in chat. If a client wants to share with a partner, review three weeks later, or reconcile with an external consultant, they have to screenshot and copy manually.

The report solidifies accumulated snapshots into a single Markdown document with dates, versions, and an index. This is how dbskill upgrades from a "one-off tool" to "deliverable consulting."

---

Trigger Methods

Command	Behavior
/dbs-report	Merge all snapshots under the current project
/dbs-report --since YYYY-MM-DD	Merge only snapshots after that date
/dbs-report --slug <项目名>	Specify a project
/dbs-report --slug <项目名> --since YYYY-MM-DD	Both
"出报告" "打包" "整理一份" "给合伙人看的"	Equivalent to /dbs-report

---

Workflow

Step 1: Confirm Data Exists

Look for ~/.dbs/sessions/{项目名}/*.md.

• 0 files → "{项目名} has no snapshots. Use /dbs-save to save diagnosis results first, then generate a report."
• 1 file → "{项目名} has only 1 snapshot; no merge needed. View ~/.dbs/sessions/{项目名}/{文件名} directly." Ask "Do you still want to force a report?" If yes, continue.
• ≥2 files → Proceed to merge.

If --since is provided, filter by date first. If fewer than 2 files remain after filtering, handle the same way.

Step 2: Read and Parse All Snapshots

Sort by filename YYYYMMDD-HHMMSS (earliest → latest).

For each file, parse:

• Frontmatter fields: slug, timestamp, title, source_skill, status, next_skill
• Body sections: User Complaint, Confirmed Conclusions, Rejected Directions, Hypotheses to Verify, Recommended Next Steps, Notes

If a snapshot is missing fields, use what's available; do not abort report generation.

Step 3: Build Path and Write Report

~/.dbs/reports/{项目名}/{YYYYMMDD-HHMMSS}-{项目名}.md

Each run generates a new file, never overwrite. The filename includes a timestamp for comparing diagnosis snapshots across time.

If the directory doesn't exist, mkdir -p first.

Step 4: Report Content

Write the following 6 sections. How to generate each section is described below.

# {项目名} Business Diagnosis Report

**Generated**: {current local time, YYYY-MM-DD HH:MM}
**Snapshots merged**: {N} (earliest {earliest date}, latest {latest date})
**Skills used**: {deduplicated list of all source_skill values}
**Tool**: dbskill / dbs-report

---

## 1. Evolution of User Complaint

List each snapshot's complaint in chronological order, one per line:

- `2026-04-15` · {complaint summary, one sentence} · from {source_skill}
- `2026-04-22` · {complaint} · from {source_skill}
- ...

End with a short paragraph noting how the focus changed—e.g., from "what to sell" to "who to sell to" to "how to acquire customers." **This is one of the few places you are allowed to summarize**, but only describe the evolution path itself; do not extrapolate or speculate.

---

## 2. Confirmed Conclusions

Merge all "Confirmed Conclusions" fields from all snapshots. Deduplicate (merge semantically similar ones), sort by time descending (newest first).

Format:

- {conclusion text} · from {snapshot title} · {date}

If a conclusion is later overturned or corrected, **list both**, newest first, with the older one marked `（已被后续诊断修正）`.

---

## 3. Rejected Directions

Merge all "Rejected Directions" fields from all snapshots.

Format:

- {direction} — reason: {reason} · from {snapshot title} · {date}

If none, write "（暂无）".

---

## 4. Current Open Issues

Merge the following two categories:
1. "Hypotheses to Verify" fields from snapshots with status `in-progress`
2. Directions raised in the earliest snapshot but never addressed in later snapshots

Format:

- {issue/hypothesis text} · first appeared {date} · current status: {进行中 / 待验证}

---

## 5. Recommended Next Steps

Aggregate all "Recommended Next Steps" fields and `next_skill` fields from all snapshots.

Order by priority:
1. Latest snapshot's recommendation (highest priority)
2. Repeated but not yet executed recommendations
3. Early recommendations superseded by newer ones (mark "已被后续推荐替代")

Write as a single paragraph, not a list. Clearly state what to do next, why, and which skill to use.

---

## 6. Appendix: Snapshot Index

List all snapshot files in chronological order:

| Date | Title | Status | source_skill | File |
|---|---|---|---|---|
| 2026-04-15 | 卖什么没想清楚 | 进行中 | dbs-diagnosis | `~/.dbs/sessions/{项目名}/20260415-...md` |
| ... | ... | ... | ... | ... |

Translate status for user display: 进行中 / 已结论 / 已放弃.

---

Report auto-generated by dbskill. Original snapshots at `~/.dbs/sessions/{项目名}/`. To update, run `/dbs-report` again.

Step 5: After Writing

Give the user a receipt:

Report generated: ~/.dbs/reports/{项目名}/{文件名}

Merged {N} snapshots ({start date} → {end date}).

If the dontbesilent environment has a skill "03-格式工具_微信公众号HTML生成skill" available, add:

To post to WeChat Official Account or group, use /03-格式工具_微信公众号HTML生成skill to convert this Markdown to a WeChat paste-ready version.

Otherwise, omit.

---

Key Principles

1. Do not summarize from conversation. Report content must trace back to specific snapshot fields. This is the report's credibility.
2. Never overwrite. Each run generates a new file with a timestamp. Users can compare snapshots across time.
3. Do not extrapolate. The evolution paragraph is the only place for brief summary; everything else is direct field extraction.
4. Do not proactively generate PDF/HTML/other formats. Only generate Markdown; users can convert themselves.

---

Edge Cases

• Snapshot contains user-marked "sensitive information" (e.g., real revenue, client names) → Keep as-is. No sanitization. Users should sanitize at dbs-save stage.
• Conflicting conclusions across snapshots → List both, newest first, and note the correction.
• User manually places a file outside ~/.dbs/sessions/ → Ignore. Only read standard files under sessions.
• Snapshots span years (earliest 2025, latest 2026) → Clearly state the time span in the report header.

---

Tone

1. Receipt is one paragraph. File path + merge count + time span. No elaboration.
2. Do not explain what the report contains. Users will open it themselves.
3. Absolutely no exclamation marks, emojis, or encouragement in the report Markdown. This is a client-facing deliverable, not a pep talk.

---

Language

• If the user speaks Chinese, reply in Chinese; if English, reply in English.
• Chinese replies follow the "Chinese Copywriting Guide."
• The report itself uses the language of the snapshots (if snapshots are in Chinese, the report is in Chinese).

---

Not Sure Which Skill to Use Next?

Type /dbs.

This is the navigation entry for the business toolbox. It reads the current conclusions, selects the most worthwhile direction, and routes directly to the corresponding skill.

You can also just say what you want to do—e.g., "I want to find benchmarks" or "Break down this concept for me"—and /dbs will route to the appropriate skill.

Not familiar with all skills? No problem. When lost, return to /dbs.