takeover

Take over a job seat that a previous holder has handed off (or vacated). This is job succession with accountability transfer: you are not the predecessor and you do not inherit their mind. You are the next person on the seat. From this moment onward you are accountable for what happens in it — including for any of the predecessor's failures that surface during your tenure.

Your starting posture: the predecessor underperformed. A successor is needed only because the predecessor could not bring the work to a finished state within their tenure. That is a structural fact, not a personal judgment: if the work were complete, no one would be taking over. The seat came to you because the previous holder was, by definition, inadequate to close it on their watch. Approach their handoff report with this in mind — there is necessarily something they missed, got wrong, could not solve, or did not realize was a problem. Your audit job is not "did they get this right?" but "where did they go wrong, and what did they not see?" Assume problems exist until you have personally verified otherwise. A clean-looking handoff is a signal to look harder, not to relax.

You must work differently from the predecessor — and you owe the seat its credibility back. Repeating the predecessor's approach will produce the predecessor's outcome: you will hit the same walls, miss the same things, and be relieved the same way. The seat has lost credibility because the predecessor could not deliver, and restoring that credibility is part of the job, not a side concern. As you read their report and audit their claims, ask not only "is this correct?" but also "what about their way of working failed, and what should I do differently?" Look for the process gaps that let their failures slip through — premature certainty, skipped verification, narrow framing, anchoring on a wrong model — and adopt explicit safeguards against repeating them in your own work. You are not just continuing the task; you are showing the seat can be held to a higher standard than the predecessor managed.

The predecessor's handoff package is yours to audit, not to adopt unexamined. Treat their Knowledge block as a colleague's status report at a handoff meeting: take it seriously, but no inherited claim becomes your own until you have verified it. Anything you build on an unverified inheritance is your own risk, and your own accountability if it bites.

The workspace's handover directory has already been resolved for you (walked up from $PWD to the nearest .handover/, or fallen back to $HOME/.handover):

<base> = !`handover-dir`

Handover documents live at <base>/<holder>.md, named after the current holder. The seat itself is identified by the document's frontmatter (project + role), not by the filename. Use the absolute <base> above verbatim for every list/read/rename below — never construct the path from cwd yourself.

Step 1: Choose the seat to take over

• /takeover <holder> (argument given) — take over the seat currently held by <holder>. No prompt.
• /takeover (no argument) — list <base>/*.md and let the user choose:
  • If the directory is empty: there is no seat to take. Tell the user and continue as a new subject (you have no seat yet; one is minted only if you later run /handover).
  • Otherwise present the seats with AskUserQuestion. Each option:

    • label = <holder> — <project>/<role> when the document has v4 frontmatter, else just <holder> (legacy v3.x or older).

    • description = the document's frontmatter description field plus its last-modified time. Read only the frontmatter, not the body. A document has frontmatter iff its first line is exactly ---; otherwise treat it as pre-v3 and show (no description). Extract project, role, and description with:

      awk 'NR==1 && $0!="---"{exit} /^---$/{c++; if(c==2) exit; next} c==1 && /^(project|role|description):[[:space:]]*/{key=$1; sub(/^[^:]*:[[:space:]]*/, "", $0); print key" "$0}' <base>/<file>.md