# Session Summarize

> Review the current chat session and persist its valuable takeaways — business facts/rules, validated SQL, metric/model definitions, durable preferences, project conventions, reusable workflows — by classifying each via storage-classify and routing it to the right store. Present a Summary Manifest and STOP for confirmation before any heavy generation. Use at the end of a working session or when the user asks to capture what was learned.

- Skill: `datus-ai/session-summarize` (Agent Skill)
- Install (CLI): `npx skillmds@latest add datus-ai/session-summarize`
- Raw SKILL.md: https://api.skillmd.com/api/skills/datus-ai/session-summarize/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: datus-ai (https://skillmd.com/u/datus-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/datus-ai/session-summarize

---


# Session Summarize

You are wrapping up the **current chat session**: harvest everything worth keeping from the conversation, classify each piece, and persist it into the right store. You are a curator of session takeaways, not a generator.

You run in the main agent context, so you may call `task`, `load_skill`, `todo_write`/`todo_list`/`todo_update`, `add_memory`/`edit_memory`, the filesystem tools (`glob`, `grep`, `read_file`, `write_file`, `edit_file`), and the search tools (`search_semantic_model`, `search_metrics`, `search_reference_sql`).

**Routing authority is `storage-classify`.** This skill decides *what to harvest from the session*; the `storage-classify` skill owns *which content goes to which store, written with which mechanism*. Do NOT re-invent storage routing rules here — load and follow `storage-classify` in Step 2.

**Two-phase contract (important).** Heavy generation (`semantic_modeling` / `gen_sql_summary` / `gen_skill` / `extract-knowledge`) costs tokens and writes real files. So there is a hard **turn boundary** after classification: you produce a Summary Manifest and then **end your turn**. Do NOT call `ask_user` for this confirmation — just present the manifest and stop. The user confirms or corrects it in their next message; only then do you run Step 3.

---

## Step 1 — Harvest Candidates from the Session

Review the **current session's conversation** (the transcript already in your context) and collect every piece that *might* be worth persisting. Look for:

- **Business facts / rules** surfaced during the session — field encodings / enums / status codes, mandatory constant filters, join traps (must go through a mapping table), boundary traps (strict vs non-strict inequality), business-term-to-field mappings, same-name-field divergence.
- **Validated SQL** — a complete query the user ran and accepted (plus the business question it answered), worth indexing for future few-shot reuse.
- **Metric / model definitions** produced or refined this session — a named metric and its measure, or a table's identifiers / measures / dimensions.
- **Durable preferences or working context** the agent should remember next session (≤ 2000 bytes, bound to one agent).
- **Project conventions / overview** facts that belong in `AGENTS.md`.
- **Reusable, multi-step workflows** the session repeated and that will recur.

**Exclude (do NOT persist):** one-shot exploration, anything inferable from `INFORMATION_SCHEMA` / table comments / column names, generic SQL knowledge, presentation/answer conventions (those are taught by `reference_sql` examples, not knowledge), or facts that mechanically compose from existing facts. When in doubt, drop it — Step 2 re-checks against `storage-classify`'s "When NOT to pick a store".

**Record with todos when the harvest is large (> 3 candidates):** `todo_write` one todo per candidate (`title` = a short label, `content` = the raw content + where it came from). Skip todos for small sessions.

---

## Step 2 — Classify Each Candidate

`load_skill("storage-classify")` and treat its **Decision Tree** + **Per-Store Reference** + **Disambiguation** as the routing authority. For each candidate, walk the decision tree top-to-bottom (first match wins) and record a verdict:

```
candidate
  → store: semantic_models | metrics | reference_sql | knowledge | skills | memory | AGENTS.md | none
    → ref: the table / SQL / file / fact it refers to
       rationale: one line — the decision-tree branch that matched and why
       prompt-seed: the self-contained seed to hand the downstream mechanism — the ref PLUS the context the generator needs (datasource, the business question, the rule that explains it): e.g. table names + column encodings for semantic_modeling; the full SQL + the question it answered for gen_sql_summary; the atomic fact + its source for extract-knowledge
```

A single `(question, gold_sql)` pair may route to **both** `reference_sql` (the example) and `knowledge` (the atomic rule mined from *why* the SQL is written that way) — record both.

---

## Turn Boundary — Emit the Summary Manifest, then STOP

Aggregate every verdict, **dedupe** refs that appear more than once, and build a **Summary Manifest** grouped by store, rendered as a Markdown table:

| Item | Store | Refs | Mechanism | Summary |
|------|-------|------|-----------|---------|
| order status encoding | knowledge | `orders.status` enum | `extract-knowledge` (lite) | atomic field-encoding fact |
| top-SKU ranking query | reference_sql | the validated SQL | `task(gen_sql_summary)` | reusable ranking example |
| GMV metric | metrics | GMV on `orders` | `task(semantic_modeling)` | built on orders measures |
| prefers DuckDB dialect | memory | — | `add_memory` | session preference (≤ 2000 B) |

**STOP here.** After printing the manifest, **end your turn**. Do **NOT** call any generation `task`, `extract-knowledge`, `gen_skill`, `add_memory`, or write any store yet. Do **NOT** call `ask_user`. State plainly: *"Reply to confirm, or correct / drop any row, and I'll persist the rest."* Wait for the user's next message.

If the harvest produced **nothing** worth persisting, say so plainly (*"Nothing in this session needs persisting — it was all one-shot / inferable."*) and stop. No manifest, no next step.

---

## Step 3 — Route & Generate (next turn, after confirmation; concurrency ≤ 3)

Once the user confirms or corrects the manifest:

1. Treat `storage-classify`'s **Decision Tree** + **Per-Store Reference** + **Context Handoff to Subagents** as the routing authority for every item.
2. **Make every delegated prompt self-contained (see storage-classify's *Context Handoff*).** Each generator runs in a fresh context and sees none of this session — so inline the **datasource (+ dialect)**, the **business intent / question** the session established, and the **rules/encodings surfaced this session** that the artifact must honor. Use the `prompt-seed` you recorded in Step 2 as the carrier, not a bare ref. Route each item with the prescribed mechanism:
   - **Light items** → write directly: `memory` via `add_memory` / `edit_memory` (≤ 2000 bytes); small `AGENTS.md` notes via `edit_file` (never overwrite `## Knowledge` entries owned by `extract-knowledge`).
   - **Heavy items** → delegate (placeholders are the *minimum* each prompt must carry):
     - semantic_models / metrics → `task(type="semantic_modeling", prompt="<datasource> · table(s) · metric definitions if any · intent · known column encodings, join-key traps, and mandatory filters>")`
     - reference_sql → `task(type="gen_sql_summary", prompt="<datasource/dialect> · the complete SQL · the business question it answered · why it is written this way>")` — one call per SQL (instruct the generator: when the original question is known, use it verbatim as `search_text`)
     - skills → `task(type="gen_skill", prompt="<skill intent + the concrete steps the session repeated>")`
     - knowledge → run `extract-knowledge` in **lite** mode (do NOT trigger its deep blind-SQL flow); pass the **source and the specific fact to mine**, plus the datasource it applies to
3. **Grouping:** default to one coherent `semantic_modeling` request per business domain, including dependent datasets, relationships, and metrics. Follow an explicit user grouping instead. When a `reference_sql` item comes from a `(question, gold_sql)` pair, also feed that pair to `extract-knowledge` (lite): one source, two stores (the example teaches answer shape; the mined rule teaches *why*).
4. **Concurrency ≤ 3:** dispatch heavy `task` calls in batches of at most 3, waiting for each batch. Update each item's todo (`in_progress` → `completed` / `failed`) as you go.

End with a short human-readable summary: how many items were persisted, where each was routed (or why it was dropped), and any item still awaiting user confirmation.

---

## Forbidden

- Do not hand-write `semantic_models` / `metrics` / `reference_sql` YAML or vector-store rows — always delegate to the matching `task` subagent.
- Do not run `extract-knowledge` in deep mode — use lite.
- Do not exceed the 2000-byte `memory` cap, and do not write `memory` with any tool other than `add_memory` / `edit_memory`.
- Do not overwrite `## Knowledge` entries in `AGENTS.md` — those are owned by `extract-knowledge`.
- Do not persist one-shot content, generic SQL knowledge, presentation/answer conventions, or anything inferable from `INFORMATION_SCHEMA` / table comments / column names.
- Do not generate the artifact's content yourself — your job is to harvest, classify, and route, not to author.
- Do not run any generation before the user confirms the manifest.