| name | wrap-up |
| description | Wrap up an OpenCode memhub session; run the binary-rendered policy, draft updates, get per-item approval, write, and render. |
| compatibility | opencode |
Skill: wrap-up
Summarize the session, propose durable memory updates, and render after approved writes. Memhub's SQLite database is the source of truth; the rendered markdown files are local output of memhub render, not a parallel narrative — do not invent project history.
This is a thin executor (Q10, issue #99): the full policy — detection, read window, draft assembly, approval gate — is rendered from one canonical source in the binary by memhub wrapup-policy, not duplicated here.
Workflow:
- Pre-flight: confirm
.memhub/ exists and memhub is on PATH (as /check-init does); stop and say so if either is missing. Schema currency is checked by the policy text itself, not here.
- Run
memhub wrapup-policy --json (CLI only, no MCP equivalent) and parse the wrapped {"wrapup_policy": {"verbosity": ..., "instructions": "..."}} object. Follow instructions for detection, the read window, the draft-assembly items for this repo's configured level, and the approval-gate rule — it supersedes anything remembered from a previous session or a different repo.
- Layer these repo-specific refinements onto its draft assembly (it doesn't know about them yet): always draft a one-sentence
--summary paraphrase alongside any decision (decision 72 — lifted Recall@3 on jargon-titled decisions 76.5%→100% on memhub's own golden set; facts have no --summary field, don't add one there); a build/test/run/lint command actually executed this session with an observed exit code is a verified command, not a fact (Q11 — go-forward only, do not backfill existing command-shaped facts); a durable spec/design doc authored or materially revised this session is a docs candidate; and — only when the user explicitly frames an item as machine-wide during approval — a fact or decision can be staged for the global store instead of written repo-scoped (never infer this yourself; one bad global write pollutes every repo). These four refinements only apply where the policy actually drafts decisions/facts at all — at minimal it drafts neither (state + task closures only), so none apply there.
- Approval gate is non-negotiable at every verbosity level: show every draft grouped by kind, wait for explicit per-item approval or a clear "all good", drop anything rejected without retrying.
- This ordered list is not a second, competing policy — it's the concrete command mechanics for whatever the policy text and the approved drafts actually called for (skip any step nothing was drafted for). Write approved items in this order, halting on the first failure and reporting which command failed: (1)
memhub state set "<body>" --json --actor opencode:wrap-up if changed; (2) memhub review accept <id> --json --actor opencode:wrap-up / memhub review reject <id> --reason "<reason>" --json --actor opencode:wrap-up for pending-write triage, including any global proposal from step 3 once confirmed; (3) repo-scoped decisions via memhub decision add "<title>" --rationale "<rationale>" --summary "<summary>" --source user+agent:opencode --json --actor opencode:wrap-up; (4) tasks via memhub.task_add / memhub.task_done (MCP; CLI fallback memhub task add "<title>" --notes "<notes>" --json --actor opencode:wrap-up / memhub task done <id> --json --actor opencode:wrap-up); (5) repo-scoped facts via memhub fact add "<key>" "<value>" [--kind gotcha|env|preference|command|constraint] --source user+agent:opencode --json --actor opencode:wrap-up; (6) verified commands via memhub.record_command (MCP; CLI fallback memhub command verify <build|test|run|lint|other> "<cmdline>" --exit-code <n>, no --json/--actor on that one); (7) new/revised docs via memhub.doc_add (MCP; CLI fallback memhub doc add "<path>" [--title "<title>"] --json --actor opencode:wrap-up); (8) the session summary via memhub.log_session_note (MCP; CLI fallback memhub note add "<summary>" --json --actor opencode:wrap-up), always unless the user rejected it, length following the resolved verbosity level; (9) architecture via memhub arch set "<body>" --json --actor opencode:wrap-up, only if approved this session; (10) stale-fact re-verifications, one memhub fact verify <id> --json --actor opencode:wrap-up per approved fact, never a bulk pass. For multi-line state/arch bodies use --from-file <path> instead of inlining.
- Global items: never write
--global directly (same rule as /global). Stage with memhub.propose_fact(key=..., value=..., rationale=..., kind=..., global=true) / memhub.propose_decision(title=..., rationale=..., global=true), then accept via step 2 above once confirmed, and only while this repo still has memhub global enabled. propose_decision has no --summary field yet — backfill an approved one after acceptance with memhub decision set-summary <id> "<summary>" --json --actor opencode:wrap-up. Docs have no agent-mediated global path at all (no global on doc_add); tell the user to run memhub doc add <path> --global (or /global) themselves instead.
- After writes succeed, follow the policy text's own Render and cross-machine-sync steps: run
memhub render --actor opencode:wrap-up (or memhub.render over MCP, where client identity supplies attribution). If render fails, stop before sync. When all approved DB writes already succeeded, resume at render after fixing the cause; do not repeat draft assembly or durable writes. If sync is enabled, memhub.sync_check then memhub.sync_snapshot + memhub.sync_commit (MCP; CLI fallback memhub sync check|snapshot|commit) unless the verdict is drive-ahead/diverged, in which case stop and /catch-up first instead of pushing.
- Never run
git commit — that is the user's call, regardless of verbosity level. End with what was recorded, what was skipped, and any pending review items (including newly staged global proposals).
