Design the handoff artifact/protocol for MULTI-STAGE sequenced work where each stage carries its binding decisions forward as evidence — so a later stage (or a fresh agent/session) continues without re-deriving or contradicting what was decided. The discipline: a decision-ID register carried across stages (each decision''s ID, whether it still binds), per-stage changed-files AND NOT-touched lists, proven-invocation sections with tell-tale output (evidence the stage did what it claims), and de...
Scanned 9/11/2026
Install to Claude Code
npx -y skills add ModernNomad-98/Project-Aegis --skill phased-work-handoff-designer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Phased Work Handoff Designer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/modernnomad-98-phased-work-handoff-designer)More formats (shields.io, HTML) on the badges page.
---
name: phased-work-handoff-designer
description: 'Design the handoff artifact/protocol for MULTI-STAGE sequenced work where each stage carries its binding decisions forward as evidence — so a later stage (or a fresh agent/session) continues without re-deriving or contradicting what was decided. The discipline: a decision-ID register carried across stages (each decision''s ID, whether it still binds), per-stage changed-files AND NOT-touched lists, proven-invocation sections with tell-tale output (evidence the stage did what it claims), and deviation flags for departures from the plan. Reports across STAGES of one effort — distinct from ai-closeout-reporter (reports ONE turn) and ai-sdlc-operating-model (frames the whole lifecycle). Use when designing handoffs for staged/sequenced work, multi-session efforts, or agent-to-agent continuation. Do NOT use to report a single turn/task (ai-closeout-reporter), define the SDLC operating model/authority (ai-sdlc-operating-model), or guide parallel lanes at work''s start (lane-authoring-guide).'
---
# Phased Work Handoff Designer
## Purpose
Multi-stage work breaks at the seams between stages: stage 3 re-derives a
decision stage 1 already made (differently), a later session "cleans up" a
file stage 2 deliberately left alone, and a stage claims "tests pass" with
no evidence it ran anything. The handoff is where continuity lives or
dies. This skill designs the handoff artifact and protocol for sequenced
work so each stage carries its binding decisions forward as EVIDENCE — a
decision-ID register that later stages honor, explicit changed-files and
NOT-touched lists, proven-invocation sections with the tell-tale output
that shows a stage actually ran what it claims, and deviation flags where a
stage departed from the plan. It reports across STAGES of one effort — not
a single turn (that's `ai-closeout-reporter`) and not the lifecycle model
itself (`ai-sdlc-operating-model`).
## Use When
- Use when: designing handoffs for staged/sequenced work where each stage's
decisions must carry forward to the next.
- Use when: work spans multiple sessions or agents and continuity depends
on a trustworthy handoff (no re-derivation, no contradiction, no silent
drift).
- Use when: agent-to-agent or session-to-session continuation needs a
contract for what carries forward and what evidence proves each stage.
- Use when: staged work keeps losing decisions, touching files a prior
stage intentionally left, or claiming steps without evidence.
- Do NOT use when: the task is reporting ONE turn/task's outcome (what
changed, tests run, next step) — that is `ai-closeout-reporter`; this
designs the CROSS-STAGE carry-forward.
- Do NOT use when: the task is defining the end-to-end SDLC operating model
— the stages, authority holders, and gates for AI-assisted work — that is
`ai-sdlc-operating-model`; this designs the handoff artifact within it.
- Do NOT use when: the task is a pre-work guide for PARALLEL lanes at the
start of work — that is `lane-authoring-guide`; this is for SEQUENTIAL
stages carrying decisions forward.
## Inputs to Inspect
1. The phased effort: the stages, their sequence, and the dependency of
each stage on prior stages' decisions and outputs.
2. The binding decisions: what each stage decides that later stages must
honor (interfaces, conventions, scope boundaries, chosen approaches).
3. The evidence the work produces: the commands/validations each stage
runs, and what tell-tale output proves they ran.
4. The failure history: where prior staged work lost decisions, touched
what it shouldn't, or claimed unproven steps — the concrete gaps to
close.
5. The continuation context: who/what picks up the next stage (a later
session, a different agent) and what they need to continue cold.
## Workflow
1. **Design the decision-ID register.** Every binding decision gets a
stable ID and a one-line statement. The register is carried across
stages; each stage declares which prior decisions still bind (and are
honored) and which it changes — a changed decision is a DEVIATION, not a
silent overwrite. This is what stops stage N from contradicting stage 1.
2. **Require per-stage changed-files AND not-touched lists.** Each stage
records what it changed and, explicitly, what it deliberately did NOT
touch. The not-touched list is the anti-cleanup guard: it tells the next
stage the untouched surface is intentional, not forgotten, so nobody
"helpfully" undoes a prior stage's restraint.
3. **Require proven-invocation sections.** A stage doesn't say "tests
pass"; it shows the command it ran and the tell-tale output proving it
ran (counts, IDs, timestamps, the distinctive line). Claims without
evidence are the crack fabrication slips through; the handoff demands
the receipt.
4. **Design deviation flags.** Where a stage departed from the plan or from
a prior decision, it flags the deviation explicitly with rationale.
Visible deviation is correctable; silent drift compounds across stages
into an effort nobody can trust.
5. **Define the continuation contract.** What a later stage / fresh agent
needs to pick up cold: the current register, the evidence, the
changed/not-touched state, the open items, and the next stage's entry
criteria. Continuation should require reading the handoff, not
re-deriving the effort.
6. **Keep it verifiable, not narrative.** The handoff is evidence, not a
story — a reader (human or agent) can check each claim against its
proof. Cross-reference the register so a decision is traceable to the
stage that made it.
7. **Deliver** the handoff protocol/template in the Output Format, with the
register, per-stage evidence structure, and continuation contract.
The handoff template, the decision-ID register format, the proven-
invocation pattern, and the not-touched/deviation conventions:
[references/handoff-sheet.md](references/handoff-sheet.md).
## Output Format
```
PHASED-WORK HANDOFF PROTOCOL — <effort>
Decision-ID register (carried across stages):
<D-id | decision | made in stage | still binding? | superseded-by (deviation)>
Per stage:
Changed files: <list> NOT touched (intentional): <list>
Proven invocation: <command> → <tell-tale output proving it ran>
Deviations: <departed from plan/decision — rationale, flagged>
Open items → next stage
Continuation contract: what a fresh stage/agent needs to pick up cold (register + evidence + entry criteria)
Verifiable: every claim has its proof; decisions traceable to their stage
Boundaries: one turn → ai-closeout-reporter; lifecycle model → ai-sdlc-operating-model;
parallel lanes → lane-authoring-guide
```
## Validation Checklist
- [ ] A decision-ID register carries binding decisions across stages; each
stage declares which still bind.
- [ ] Each stage lists changed files AND an explicit NOT-touched list.
- [ ] Each stage's claims have proven-invocation evidence (command +
tell-tale output), not bare assertions.
- [ ] Deviations from the plan or prior decisions are flagged with
rationale, not silent.
- [ ] A continuation contract lets a fresh stage/agent pick up cold from
the handoff without re-deriving.
- [ ] The handoff is verifiable evidence, not narrative; decisions are
traceable to their stage.
- [ ] Single-turn reporting, the SDLC operating model, and parallel-lane
guidance are handed to their owning skills.
## Gotchas
- The decision that isn't carried forward gets re-made — differently — by
a later stage, and now the effort contradicts itself. The register is
the single mechanism that prevents this; without it, staged work drifts.
- A missing NOT-touched list invites the "helpful cleanup" that undoes a
prior stage's deliberate restraint. Silence reads as "forgotten"; the
explicit list reads as "intentional".
- "Tests pass" with no evidence is where fabrication hides — a later stage
builds on a claim that was never true. Demand the command and its
tell-tale output; the receipt, not the assertion.
- Silent deviation is the expensive kind: a stage quietly departs from the
plan, later stages assume the plan held, and the mismatch surfaces at the
end. Flag deviations so they're correctable in-flight.
- A handoff written as narrative ("we did a bunch of stuff, looks good")
can't be verified and can't be continued from cold. Structure it as
checkable evidence.
- This is not a single-turn closeout. If you're reporting one PR/task's
outcome, that's `ai-closeout-reporter`; this carries a decision register
and evidence across MANY stages.
- This is not the operating model. Defining the stages, authorities, and
gates of the whole lifecycle is `ai-sdlc-operating-model`; this designs
the handoff that rides between stages.
## Stop Conditions
- The task is reporting a single turn/task's outcome → route to
`ai-closeout-reporter`.
- The task is defining the SDLC operating model (stages, authority, gates)
→ route to `ai-sdlc-operating-model`.
- The task is a pre-work guide for parallel lanes → route to
`lane-authoring-guide`.
- A stage's claimed step can't be backed by proven-invocation evidence →
flag the unproven claim in the handoff rather than carrying it forward as
fact; an unverifiable claim must not become a later stage's foundation.
## Supporting Files
- [references/handoff-sheet.md](references/handoff-sheet.md) — the handoff
template, the decision-ID register format, the proven-invocation pattern,
and the not-touched/deviation-flag conventions.
- `evals/evals.json` — behavior cases including the decision-register
carry-forward, the not-touched guard, and the proven-invocation
requirement.
- `evals/trigger-evals.json` — discrimination against `ai-closeout-reporter`
(one turn), `ai-sdlc-operating-model` (lifecycle), and
`lane-authoring-guide` (parallel lanes).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!