handover-pack

---
name: handover-pack
description: Turns what one person knows about a job into a handover pack the next owner can run from day one. Use when someone leaves, changes role, or a job moves owner.
---

# Hand a job over without losing what is in your head

One pack: header, task register, in-flight items, access, and a step file per task, testable by someone who never did the job.

## Claude does

1. Collect six inputs; refuse to start without the first three: role and outgoing owner; incoming owner, a named person, never the team; handover date; recurring tasks with cadence; in-flight items with next action and date; contacts, systems.
2. Scope test: purpose in 1 to 2 sentences, scope in at most 3. If it will not fit, split it into separate packs.
3. Interview for the tacit part. Per task: what goes wrong, what you do about it, who you ask, what you check before sending. Record verbatim.
4. Task register row: name, trigger, cadence, deliverable, system, duration, new DRI, escalation threshold, escalation contact.
5. In-flight row: one named person, one deliverable, one date. Missing any of the three, mark it OPEN with who can answer.
6. Pick a format per task from four archetypes: simple checklist, complex linear checklist, watertight process, flow diagram.
7. Header carries version, date, named owner, reviews at day 1, day 30 and day 90.

## Then Codex does

Codex writes it out: one numbered procedure file per task, plus index, in-flight table, access matrix, gap report. Bulk formatting against one rule set.

```
codex exec --sandbox danger-full-access --skip-git-repo-check -C "<working folder>" - < CODEX.md
```

Fill in first: {HEADER} role, both owners, dates, reviews. {TASK_REGISTER} step 4 rows. {INFLIGHT} step 5 rows. {TACIT_NOTES} step 3 answers. {CONTACTS_ACCESS} contacts, systems, grantors.

## Claude checks

1. Every step starts with an imperative verb; any step joining two actions with "and" is split.
2. Every in-flight row has a named person, a deliverable and a date. State the count.
3. No password, key or token anywhere; access names the system and grantor only.
4. Every fact traces to the inputs. Delete anything Codex smoothed into a plausible detail: an invented handover reads best.
5. Fresh eyes: give the most frequent procedure to someone who never did the job. Where they stop, that step is wrong.

Reject and rerun: send the pack back with failing rows quoted, never patched by you. The outgoing owner reads it before the successor.

## Rules

- One action per step. Split any step containing "and".
- One named person per owner field. No teams.
- Missing facts go to the gap list, never to inference.
- Copy tacit notes word for word.
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.

## If Codex is not installed

Claude writes those files itself and says it did both halves.

## Built from

- Process Street, 16 Steps to Writing SOPs, https://www.process.st/writing-standard-operating-procedures/ - four format archetypes, verb-first steps, pilot at step 11, fresh-eyes review at step 12.
- w95/awesome-claude-corporate-skills, https://github.com/w95/awesome-claude-corporate-skills - 189 stars via api.github.com; sop-builder gives the governed header, DRI, escalation thresholds.
- obra/superpowers, https://github.com/obra/superpowers - 281,934 stars via api.github.com; verification before completion.

# Hand a job over without losing what is in your head - Codex task

## You are given

- {HEADER} the role, the outgoing owner, the incoming owner, the handover date and the review schedule.
- {TASK_REGISTER} one line per recurring task: name, trigger, cadence, deliverable, system, typical duration, new DRI, escalation threshold, escalation contact.
- {INFLIGHT} one line per unfinished item: item, current state, next action, owner, due date, dependency.
- {TACIT_NOTES} the outgoing owner's own words on what goes wrong per task and what they do about it.
- {CONTACTS_ACCESS} contacts (name, organisation, what they need) and systems with the person who grants access.

## Produce

1. `HANDOVER.md` - header block (role, both named owners, handover date, version 1.0, reviews at day 1, day 30, day 90), purpose in 1 to 2 sentences, scope in at most 3, then a contents list linking every file below.
2. `procedures/NN-<task-slug>.md`, one file per task in {TASK_REGISTER}. Each contains: owner after handover, trigger, cadence, expected duration, numbered steps, escalation threshold and contact, then a "What goes wrong" section copied word for word from {TACIT_NOTES}.
3. `IN-FLIGHT.md` - one table, columns Item, Next action, Owner, Due date, Dependency. One row per item, sorted by due date, earliest first.
4. `ACCESS.md` - one table, columns System, Used for, Who grants access, Requested Y/N. Plus the contacts table: Name, Organisation, What they need.
5. `GAPS.md` - numbered list of every field that was missing, blank or ambiguous, with the person named to answer it.

## Rules

- Every step: numbered, imperative verb first, present tense, active voice, exactly one action. If a step joins two actions with "and", split it into two steps.
- Never invent a step, name, number, system, date or contact. If it is not in the input, it goes to `GAPS.md`.
- Copy {TACIT_NOTES} verbatim. Do not paraphrase, shorten or improve it.
- No password, key, token or security answer in any file. Access is named by system and grantor only.
- One named person per owner field. Never a team, never "someone".
- Do not exceed the input. If a task has three facts, its file has three facts.
- British English. No em dash characters.

## Return

Print, in this order: every file path created; per procedure file, its step count; the total number of steps split because they contained "and"; the number of in-flight rows and how many carry all three of owner, deliverable and date; the `GAPS.md` item count. Then print the longest procedure file in full.