wrap-up

name	wrap-up
description	Use when the user explicitly asks to wrap up or formally close the workday or current session. Do not use for status or completeness questions such as “anything else remaining?” or “are we done here?”, ordinary task completion, or a handoff-only request.

Generated from blueprint.yaml. Do not edit this block by hand.

Executable Interfaces:

Call famulus.invoke with required caller (caller skill), interface, version, and arguments; optional dry_run defaults to false. Compact uses ordered positionals plus an option mapping; ordered raw argv uses positionals: [] plus every argv token in list options. Never mix forms.

• find-handoff-candidates._rtx.interface.scan — Scan session transcripts across every configured host (default: trailing 2 days), and report sessions whose conversation since their last completed handoff exceeds a per-host threshold, using mechanical extraction only (no LLM judgment).
  • Caller: wrap-up
  • Version: 1
  • Alternative: default Arguments JSON (replace labels with actual values). Omit optional positionals and options that are not needed. {"options": {"--date": "YYYY-MM-DD", "--days": "N", "--min-gap-chars": "N"}, "positionals": [], "stdin": null} Required options: []; positional arity: 0..0; stdin: forbidden

Instruction Interfaces:

These are LLM-readable instruction surfaces. Read and follow them directly; do not invoke the MCP server for them.

• daily-plan.interface.default@1 — Primary LLM-facing skill instructions.
• list-manager.interface.default@1 — Primary LLM-facing skill instructions.
• prepare-handoff.interface.default@1 — Review recent work, obtain approval, encode project-local continuity, and close with exact machine-readable sentinels.

When this skill is used, begin with:

Skill: wrap-up

0. Overview

End-of-day review. Reads today's plan, surfaces incomplete actions, collects completions and notes from the user in a single prompt, then updates the plan and lists accordingly.

1. Read today's plan

Invoke daily-plan.interface.default in output mode ("show my plan") to read today's plan. If no plan exists, note that and skip to step 3.

2. Extract incomplete actions

From the ## Actions section, collect all lines matching - [ ] .... Present them numbered (without the surrounding plan) so the user can reference them by number.

3. Ask all questions in one message

Send a single message asking all of the following:

1. Completions: Which of the incomplete actions (listed by number) were actually completed today? ("all", "none", numbers/descriptions, or partial — e.g. "action 2: finished the tests but not the docs".)
2. Unplanned work: Did you do anything else today that wasn't on the plan? (These will be added to the plan as completed items.)
3. Calendar notes: Any notes, outcomes, or follow-ups from calendar events today worth capturing?
4. New items: Any new tasks or items to add to a list (todo, groceries, etc.)?
5. Reminder: Is there any code or work in a done state that hasn't been committed/pushed yet? If so, do that before wrapping up.

Wait for the user's full response before doing anything else.

4. Add unplanned completed work to the plan

For each item the user did that wasn't on the plan, invoke daily-plan.interface.default to append an ## Unplanned Actions section at the end of the plan (if it doesn't already exist), then add each item as a numbered completed entry:

## Unplanned Actions
1. [x] <description>
2. [x] <description>

If the section already exists, append to it (continuing the numbering).

5. Mark planned completions

For each planned action the user says was completed:

1. Invoke daily-plan.interface.default to change [ ] → [x] on that action's line.
2. Invoke list-manager.interface.default to check off the matching todo item — fuzzy-match the action text (before —) against unchecked - [ ] items on the todo list. If no confident match is found, say so rather than guessing wrong.

Partial completions

If the user says part X of an action was done and part Y remains, instead of marking the action done or leaving it untouched:

1. Invoke daily-plan.interface.default to replace the action's line with the original parent line (kept as - [ ], since it isn't fully done) followed by two indented sub-items:

   - [ ] <original action text>
     - [x] <completed part X>
     - [ ] <remaining part Y>
   

2. Invoke list-manager.interface.default to apply the same split to the matching todo item: identify the matching todo item and ask the interface to split it into the parent plus completed and remaining sub-items. wrap-up must not reconstruct item metadata or representation details; leave that behavior behind list-manager.interface.default.

6. Add new list items

For each new item the user provided, invoke list-manager.interface.default to add it to the appropriate list. Infer the list from context; default to todo.

7. Flag sessions needing handoff

Invoke find-handoff-candidates._rtx.interface.scan (default: trailing 2 days, so a session touched yesterday still surfaces even if this didn't run yesterday) to get a JSON array of session records. Every record returned already needs attention — the scan decides this via the gap-since-last-handoff threshold, including sessions with handoff_status: complete that had substantial new work afterward. Do not re-filter by handoff_status, and do not open, read, or summarize any flagged session's transcript content; this step is a pure relay of the interface's structured output, not an LLM judgment call.

Before adding anything, invoke list-manager.interface.default to read the current triage list and collect every session_id already present in an existing entry's description (any state — undecided, accepted, or rejected). Because the scan window overlaps across days, the same session can appear in more than one day's scan; skip any record whose session_id is already in that set — do not create a second triage entry for a session already tracked there.

For each remaining record, invoke list-manager.interface.default to add a triage entry:

• title: a short pointer, e.g. "handoff check: <source> session <session_id> (<project>)".
• deadline: tomorrow's local date.
• description: every field from the record, plainly listed (session_id, source, project, start_time, last_activity, line_count, gap_net_chars, handoff_status, handoff_started_at, resume_hint) — do not summarize or drop fields; the description is the only place this information persists, and it must be enough for whoever reviews the triage item to resume the session and invoke prepare-handoff.interface.default there without re-scanning. Always include session_id even though it's also in the title, since the dedup check above depends on finding it in the description.

If nothing remains after dedup, skip this step silently — do not create empty or placeholder triage entries.

8. Confirm

Reply with a brief summary:

• Which actions were checked off (and which todo items matched).
• Any items that couldn't be matched (if any).
• Which new items were added and to which list.
• How many triage entries were added in step 7 (if none, omit this line).

Do not redisplay the full plan unless asked.