Wrapup

Wrapup — Session Close Procedure

Every step below is mandatory unless explicitly marked optional. Skipping a mandatory step and reporting SHIP is a protocol violation. The wrapup exists to produce a faithful, verifiable record of the session and deliver it to the destinations the user configured — nothing more, nothing less.

Core principles

1. Fidelity first. The summary reflects what actually happened. Do not smooth over failures, abandoned approaches, or unresolved blockers.
2. Configured, not assumed. Destinations, paths, and formats come from config/wrapup.config.json. If a destination is not configured and enabled, it does not exist for this run.
3. Evidence over claims. Completion is proven with returned links, file paths, or API confirmations per destination — not with "done."
4. User-agnostic. This skill ships with no personal names, no machine paths, and no references to any individual's infrastructure. Everything personal lives in config.

Configuration

File layout

wrapup/
├── SKILL.md
├── config/
│   └── wrapup.config.json          # active config (generated by onboard.py or hand-edited)
└── templates/
    └── destinations.example.json   # schema + example, ships with the skill

Destination schema

Each destination in wrapup.config.json has exactly these fields:

Exactly one of path or endpoint is required per destination, matching its type. templates/destinations.example.json contains a fully commented example of every supported type and is the schema reference. Validate any hand edit against it before running the wrapup.

Marker block

The active destinations are stored in config/wrapup.config.json — the single source of truth. An optional marker block in this file mirrors the config for human readability when onboard.py is present:

Rules:

• config/wrapup.config.json is the single source of truth. The marker block is a convenience mirror only.
• Only onboard.py (or an equivalent onboarding tool) writes between the markers. Agents read config directly; they do not edit this block.
• If config/wrapup.config.json is missing, load templates/destinations.example.json, treat every destination as disabled except a single local file archive (id: "transcript-archive", type: "file", path: ~/session-transcripts/), and warn the user once.

Onboarding (ask the user)

If onboard.py is present, it asks three questions at setup time:

1. "Where should your session transcripts be archived?" (default: a placeholder path the user replaces)
2. "Which services should your wrapup push to?" (multi-select: Notion, NotebookLM, Obsidian, file ledger, webhook, none)
3. "How do you want each formatted?" (per-destination format from the schema above)

Answers are written into config/wrapup.config.json and mirrored into the marker block. If onboard.py is not present, the skill degrades gracefully: the agent points the user at templates/destinations.example.json, and the user copies it to config/wrapup.config.json and edits by hand.

Workflow

Step 0 — Capture the session transcript

Export the full session transcript to the destination whose type is file and id carries transcript responsibility (convention: id: "transcript-archive"). This is the most frequently skipped step — do it first, before any summarization, so the raw record exists even if everything after fails.

• Format: raw-transcript unless the config says otherwise.
• Filename should include the session identifier and an ISO-8601 timestamp with timezone.
• Verify the file exists and is non-empty before continuing.

Step 1 — Review the session

Read the transcript end to end. Produce working notes (not yet the summary) covering: the original goal, what was delivered, what failed or was abandoned, decisions made and who made them, open blockers, and any promises still owed.

Step 1.5 — Detect recurring correction patterns (optional)

Skip if the session had fewer than 2 user corrections total. Scan for moments where the user corrected the agent more than once on the same theme. Recurring corrections are durable lessons — candidates for memory or a skill update, per the user's information-routing rules. One-off corrections stay in the session record only.

Step 1.6 — Shortcut-pattern audit (optional)

Skip if the session was read-only (no writes, no builds, no deploys). Check the session for skipped verification, unverified claims of completion, fabricated output, or steps done out of order. Record each finding honestly in the summary. This audit exists so patterns surface across sessions instead of repeating silently.

Step 2 — Save memories

Write durable facts (preferences, environment facts, corrections, conventions) to the configured memory location — the destination whose id carries memory responsibility, or the agent runtime's native memory mechanism if none is configured. If no memory destination is configured, write a simple markdown log to ~/session-logs/ (or the user-configured default path). This ensures every user has a working log system without any external dependencies. Each session log file is named YYYY-MM-DD_HHMM_session-summary.md and contains: date, goal, what was accomplished, decisions, open threads, and lessons learned.

Do not store task progress, session outcomes, or anything stale within a week; those belong in the session summary, not memory.

Step 3 — Draft the session summary with the fidelity checklist

Draft the summary from Step 1's notes. Then run the four-line fidelity checklist against the draft — every line must be YES:

1. Does the summary state the original goal accurately?
2. Does it report what actually happened, including failures and blockers?
3. Is every claim backed by evidence in the transcript (file path, command output, returned link)?
4. Is it free of Personally Identifiable Information (PII), secrets, and client-identifying details that should not leave the session?

If any line is NO, fix the draft and re-check before proceeding.

Step 3.5 — Review pass

Exactly one of the two paths runs, chosen by what is configured. The fidelity checklist runs once here (after any edits), not repeated from Step 3.

Path A — Self-review (default, no MOE team required). Re-read the draft with fresh attention. Verify every file path cited in the summary actually exists. Re-check for PII and secrets. If any check fails, fix and re-check until all pass. This is the standard behavior for any user without a review team.

Path B — Mixture-of-Experts (MOE) Kaizen handoff (only if an MOE build team is configured). Pass the draft to the team's Kaizen voice using whatever dispatch mechanism the user's MOE infrastructure provides. Kaizen returns PASS-AS-IS or PASS-WITH-EDITS. Apply any edits, then re-run the fidelity checklist once. Record which path ran and the verdict in the evidence table.

Step 4 — Archive to configured destinations

Iterate over every destination in config/wrapup.config.json where enabled: true, excluding the transcript-archive destination (already written in Step 0):

1. Render the summary into that destination's format.
2. Push to the destination's path or endpoint.
3. Capture the returned evidence: file path, page URL, API response ID, or webhook acknowledgment.
4. On failure: record the failure and the error, continue with remaining destinations, and surface every failure in the evidence table. A failed destination blocks SHIP (see completion gate).

Never invent a confirmation. If a push could not be verified, the table says so.

Step 5 — Confirm with an evidence table

Close the wrapup by presenting the evidence table:

Plus one row recording the Step 3.5 review path (self-review or MOE Kaizen) and its verdict.

Completion gate

The wrapup is complete when for every enabled destination, the artifact was pushed and the returned link or evidence is recorded in the evidence table. All four fidelity checklist lines are YES, and the Step 3.5 review pass has a recorded verdict. Any failed or unverified destination means the wrapup is not complete — report what failed and why instead of reporting SHIP.

Optional integrations

These run only when the corresponding destination or team is present in config. None are required for a valid wrapup:

• Fresh-eyes verification — an independent agent re-checks the summary against the transcript. Only when a multi-agent team is configured.
• Knowledge roll-up — appending session lessons to a standing knowledge-base destination. Only when such a destination is enabled.
• Bridge ledger / continuity markers — writing handoff or session-continuity markers for a paired workspace. Only when configured.
• Independent fidelity pass — a second, separate review of the fidelity checklist by another team voice. Only when an MOE team is configured.

Relationship to other skills

• onboard.py — owns the three setup questions and writes config/wrapup.config.json and the marker block. Wrapup consumes that config read-only.
• information-routing — governs what Step 2 is allowed to store as memory versus what stays in the session record.
• handoff / session-continuity skills — consume the archived transcript and summary this skill produces.
• MOE build team — supplies the Kaizen reviewer when configured. Wrapup runs fully without it via self-review.
• skill patching — procedural lessons found in Step 1.5 become skill patches, not memories.
• This skill supersedes any predecessor wrapup procedure that hard-coded personal destinations or required a fixed review team. Those concerns now live in config.