Skip to content

Proposal: a wrap-up skill for the phase boundary that has no next phase #1076

Description

@kriegerlukas

The gap

Every flow in this repo ends at its own last artifact. implement ends at "commit your work". wayfinder charting ends at "Stop"; working the map has no ending step at all. grill-with-docs ends at the ADRs. handoff writes the file for the next session. Nothing owns the moment after that: the session is over, and what it leaves behind is whatever happened to be on disk and on the tracker when the human closed the window.

ask-matt's phase-boundary tree has five options, and all five assume a next phase in this or another window. The sixth case, "no next phase in this window", is the one that leaves debris, and the tree has nothing for it.

Evidence

I ran the skills on a ten-repo platform for 25 days, 2026-08-19 to 2026-09-12, and measured this in the session transcripts. Every number below is a count over those transcripts.

Sessions in the period 216
Sessions where I remembered to ask "can we close this session?" 115
Sessions that ended with nobody checking 101
Close requests in total 122
Answers that said something was still open or undone 45
Requests where the agent had to run checks before it could answer 89
Tool calls to answer, median 2
Tool calls to answer, maximum 44

So the question was worth asking better than one time in three, and answering it was real work, not a summary from memory. What the agent did once asked, counted per close request:

Action during the close-out Requests
Pulled a clone level with its remote after a squash merge 26
Deleted a branch whose PR had merged 19
Verified PR, CI or release state on the remote 17
Removed a leftover worktree 12
Filed a follow-up issue or corrected a comment it had written 7
Closed an issue the work had completed 7
Emptied its scratch directory 7
Removed test containers or images 2

Single cases worth naming, each invisible until the question was put:

None of this is a defect in any one skill. It is the absence of a step that runs after all of them.

What it costs to leave this manual

The 101 unchecked sessions are the cost. Their state is unknown, and by the time it matters the context that could tell scratch from real is gone.

  • Debris is silent. A branch, a worktree or a container announces nothing. It surfaces weeks later as a puzzling git branch listing or a full disk, and nobody can say which session made it or whether it is safe to delete.
  • The tracker lies. An open ticket for finished work, or a stale comment on a closed one, is read as truth by the next session. One /implement has no completion step, finished tickets are never marked done #508 commenter ran implement twice on the same ticket and the agent never noticed the work was already done.
  • Decisions evaporate. A choice made in conversation and recorded nowhere is remade, sometimes differently, next time.
  • Out-of-scope findings die with the window. Filing them costs a minute while the context is live and is impossible after.
  • The human is the trigger. It worked in 115 sessions because I remembered to ask. It failed in 101 because I did not. A trigger that depends on the human remembering to fire it at the moment of least attention, the end of the session, is the wrong trigger. That is the same argument Wayfinder never names the context window — and "Work through the map" never ends the session #716 makes for wayfinder and implement: define a safe incomplete-run handoff #723 for implement, and it holds for every skill.

Proposal

A wrap-up skill. It verifies and reports; it takes no destructive action on its own.

  1. Read the session's own primary sources: what it created, changed, or started. Branches, worktrees, files outside the repo, processes and containers, issues, PRs, comments, handoff files.
  2. Check each against its intended end state, live, and sort it: landed (merged, closed, released, verified on the remote), in flight (waiting on review, CI, a nightly, another party), debris (a branch after its merge, a worktree, a temp file, a stale comment the session wrote), decided but unrecorded (a decision from the conversation that landed nowhere durable), out of scope (a finding that deserves its own issue).
  3. Report the sorted list. Propose one action per item. Act only on what the user confirms; the repo's issue-tracker doc from setup-matt-pocock-skills decides how tracker state is written, so a team that closes tickets from the merge keeps doing that.
  4. End with the one line that opens the next session, naming the skill it should call.

Sketch, in the register of handoff:

---
name: wrap-up
description: Close out a session. Use when the user wants to end, close, or wrap up the session, or when a skill's last step is done and nothing follows in this window.
---

The session is ending. Everything it leaves behind is either **landed**, **in flight**, or **debris**, and the human is about to lose the context that tells which is which.

1. List what this session created, changed, or started: branches, worktrees, files outside the repo, processes, issues, PRs, comments, handoff files.
2. Verify each against its intended end state, live: the remote, the tracker, the filesystem. Do not report from memory.
3. Sort the list: landed, in flight (and on whom), debris, decided but recorded nowhere, surfaced but out of scope.
4. Report it. Propose one action per item and act on what the user confirms. Tracker state follows the repo's issue-tracker doc.
5. End with one line that opens the next session, naming the skill to call.

Invocation

Two options. I lean to the first.

Model-invoked. The test in .agents/invocation.md is "could the model usefully reach for this autonomously?". It could: #716 wants wayfinder to end the session after a resolution, and #723 wants implement to exit cleanly when it cannot finish. A user-invoked skill can never be reached by either, so each would have to inline its own copy of the close-out. Model-invoked, both become one line: call the Skill tool with wrap-up. The risk of a spurious auto-fire is one unwanted report, since the skill acts only on what the user confirms. The decision that the session is over stays with the human either way; the skill never clears or compacts.

User-invoked. Keeps the repo's stance from #906 that boundaries are the user's decision, at the cost of #716 and #723 each carrying their own ending.

Redundancy check

Out of scope

Acceptance criteria

  • skills/productivity/wrap-up/SKILL.md exists with the steps above and an agents/openai.yaml beside it.
  • Run after a session that merged a PR from a scratch worktree, it reports the worktree and branch as debris and the PR as landed, verified against the remote.
  • Run after a session that decided something in conversation only, it lists the decision under "decided but unrecorded" with a proposed home.
  • It writes nothing to the tracker and deletes nothing without a confirmation.
  • Its last line is a runnable prompt for the next session naming a skill.
  • ask-matt's phase-boundaries section names it as the option for the boundary with no next phase.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions