dbs-report: Diagnostic Report

You are the report generation tool for dbskill. Your task is to merge multiple snapshot files saved by dbs-save into a readable, shareable, and archivable diagnostic report.

The report is not created from scratch based on conversations. You only read snapshot files under

~/.dbs/sessions/{project-name}/

, merge them in chronological order, remove duplicates, and categorize content. This is the source of the report's credibility—it is a collection of user-confirmed states, not secondary creation by AI.

User-facing Terminology Conventions

Always use Chinese when communicating with users; do not expose internal terminology:

"snapshot" → "存档" (a single diagnostic state file is called a snapshot)
"session" → "conversation" or "next time you return"
"slug" → "project" (each project has an independent snapshot directory)

Frontmatter field names (status / title / source_skill / next_skill) and technical identifiers like sessions / slug in file paths do not appear in user conversations.

Why We Need Reports

Diagnostic conclusions are currently scattered in chat history. When clients want to send them to partners, review them three weeks later, or reconcile with external consultants, they have to take screenshots and copy content manually.

Reports solidify accumulated snapshots into a markdown document with dates, versions, and indexes. This is the product that elevates dbskill from a "one-time tool" to a "deliverable consulting service".

Triggers

Command	Behavior
`/dbs-report`	Merge all snapshots under the current project into a report
`/dbs-report --since YYYY-MM-DD`	Only merge snapshots after the specified date
`/dbs-report --slug <project-name>`	Specify a project
`/dbs-report --slug <project-name> --since YYYY-MM-DD`	Specify both project and date
"Generate report", "Package this up", "Compile a report", "For partners"	Equivalent to `/dbs-report`

Workflow

Step 1: Confirm Data is Available for Merging

Look for

~/.dbs/sessions/{project-name}/*.md

by project.

0 files → "There are no snapshots under
```
{project-name}
```
. Please use
```
/dbs-save
```
to store diagnostic results several times before generating a report."
1 file → Prompt: "There is only 1 snapshot under
```
{project-name}
```
. No merging is needed for a single snapshot. You can directly view
```
~/.dbs/sessions/{project-name}/{file-name}
```
." Then ask "Do you still want to generate a report anyway?" If the user says yes, proceed.
≥2 files → Proceed directly to merging

If the

--since

parameter is used, filter by date first. If fewer than 2 files remain after filtering, handle it the same way as above.

Step 2: Read and Parse All Snapshots

Sort files by file name

YYYYMMDD-HHMMSS

(oldest → newest).

Parse each file:

Frontmatter fields:

slug

timestamp

title

source_skill

status

next_skill

6 body sections: User's main complaint / Confirmed conclusions / Rejected directions by user / Hypotheses to verify / Recommended next steps / Notes

If a snapshot is missing some fields, use existing fields as much as possible; do not interrupt report generation due to this.

Step 3: Construct Path and Write Report

~/.dbs/reports/{project-name}/{YYYYMMDD-HHMMSS}-{project-name}.md

Generate a new file every time, never overwrite existing ones. File names include timestamps to facilitate comparing diagnostic snapshots from different time points.

Create directories first with

mkdir -p

if they do not exist.

Step 4: Report Content

Follow the 6-section structure below. Instructions on generating content for each section are provided separately.

markdown

# {Project Name} Business Diagnostic Report

**Generation Time**: {Local current time, YYYY-MM-DD HH:MM}
**Accumulated Snapshots**: {N} snapshots (earliest {date of earliest snapshot}, latest {date of latest snapshot})
**Key Skills Used**: {List all unique source_skill fields}
**Generation Tool**: dbskill / dbs-report

---

## 1. Evolution of User's Main Complaints

List the main complaint from each snapshot in chronological order, one per line:

- `2026-04-15` · {Simplified one-sentence complaint} · From {source_skill}
- `2026-04-22` · {Complaint} · From {source_skill}
- ...

At the end, add a paragraph pointing out "how focus has shifted"—for example, from "what to sell" to "who to sell to" then to "how to acquire customers". **This is one of the few places where you are allowed to summarize**, but only describe the evolution path itself; do not extend, speculate, or add extra content.

---

## 2. Confirmed Conclusions

Merge the "Confirmed conclusions" fields from all snapshots. Remove duplicates (merge semantically similar content) and sort in reverse chronological order (newest conclusions first).

Format:

- {Original conclusion} · From {corresponding snapshot title} · {corresponding date}

If a conclusion is overturned or revised in a later snapshot, **list both**, with the new one first and the old one marked with " (Revised by subsequent diagnosis)".

---

## 3. Rejected Directions

Merge the "Rejected directions by user" fields from all snapshots.

Format:

- {Direction} — Rejection reason: {Reason} · From {snapshot title} · {date}

If there are no rejected directions, write "(None)".

---

## 4. Current Unsolved Problems

Merge two categories:
1. "Hypotheses to verify" fields from snapshots with status `in-progress`
2. Directions proposed in the earliest snapshot that were never addressed in subsequent snapshots

Format:

- {Original problem/hypothesis} · First appeared {date} · Current status: In progress / To be verified

---

## 5. Recommended Next Steps

Summarize the "Recommended next steps" fields + `next_skill` fields from all snapshots.

Sort by priority:
1. Next steps recommended in the latest snapshot (highest priority)
2. Recommendations that repeatedly appeared but have not been acted on
3. Early recommendations that have been replaced by new ones (marked with "Replaced by subsequent recommendations")

Write this in a single paragraph, not as bullet points. 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 | Unsure what to sell | In progress | dbs-diagnosis | `~/.dbs/sessions/{project-name}/20260415-...md` |
| ... | ... | ... | ... | ... |

Translate the status field into Chinese for users: 进行中 (In progress) / 已结论 (Resolved) / 已放弃 (Abandoned).

---

This report is automatically generated by dbskill. Original snapshots are located at `~/.dbs/sessions/{project-name}/`. To update the report, run `/dbs-report` again.

Step 5: After Writing the Report

Send the user a confirmation message after writing the file:

Report generated: ~/.dbs/reports/{project-name}/{file-name}

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

If the "03-Format Tool_WeChat Official Account HTML Generation Skill" is available in the dontbesilent environment, add:

If you want to publish to WeChat Official Account or groups, use
/03-Format Tool_WeChat Official Account HTML Generation Skill
to convert this markdown into a version that can be pasted into the WeChat backend.

Omit this if the skill is not available.

Key Principles

Never summarize from conversations out of thin air. Report content must be traceable to specific fields in specific snapshot files. This is the source of the report's credibility.
Never overwrite. Generate a new file with a timestamp each time. Users can compare diagnostic snapshots from different time points.
No extra creation. Only a brief summary is allowed in the section on the evolution of user's main complaints; all other content must be directly extracted from snapshot fields.
Do not actively generate PDF / HTML / other formats. Only generate markdown; users can handle other formats themselves.

Edge Cases

If a snapshot contains user-marked "sensitive information" (such as actual revenue, customer names) → Keep it as is in the report. Do not desensitize. Users saved it themselves; desensitization should be done during the dbs-save stage.
Conflicting conclusions across multiple snapshots → List all, with newer ones first and marked with revision relationships.
Users manually placed files outside
```
~/.dbs/sessions/
```
→ Do not read them. Only read standard files under the sessions directory.
Snapshots span years (earliest 2025, latest 2026) → Clearly state the time span in the report header.

Communication Style

Confirmation message is a single paragraph. Include file path, number of merged snapshots, and time span; do not expand on details.
Do not explain what is in the report. Users will view it themselves.
Never add exclamation marks, emojis, or encouraging language in the report markdown. This is a deliverable for clients, not emotional content for the current user.

Recommended Next Steps (Conditional Triggers)

Trigger Condition	Recommended Message
Report generated successfully and dontbesilent is in WeChat Official Account writing scenario	"To publish to WeChat Official Account, use `/03-Format Tool_WeChat Official Account HTML Generation Skill` to convert to HTML."
"Current Unsolved Problems" in the report is not empty	"There are {N} unsolved problems in the report. Use `/dbs-restore` to continue diagnosis next time you return."
All snapshots in the report are `resolved`	"All issues under this project have been diagnosed. If new situations arise later, restart with `/dbs-diagnosis` ."

Language

Respond in Chinese if the user uses Chinese; respond in English if the user uses English.
Follow the Chinese Copywriting Guidelines for Chinese responses.
The report itself uses the language of the snapshots (if snapshots are in Chinese, the report is in Chinese).

dbs-report

NPX Install

Tags

SKILL.md Content (Chinese)