# Shift Change

> Live decision-review session between graveyard shifts. Compile every decision and approval currently waiting on the user — across ALL prior shifts, not just the latest — walk them together, and RECORD each outcome onto GitHub as shaped permission rather than executing it live (execution is the graveyard's job; building/merging mid-meeting just makes the user wait). Reactions are cues to capture;…

- **Type:** Skill
- **Install:** `agentstack add skill-rhdeck-operating-model-shift-change`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [rhdeck](https://agentstack.voostack.com/s/rhdeck)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [rhdeck](https://github.com/rhdeck)
- **Source:** https://github.com/rhdeck/operating-model/tree/main/skills/shift-change

## Install

```sh
agentstack add skill-rhdeck-operating-model-shift-change
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Shift Change

The daytime counterpart to `graveyard-shift`, and the other half of the primary development loop:

> **shift change** (live, short, user-attention-dense) → **graveyard shift** (autonomous, long, user-attention-free) → repeat.

Graveyard shifts maximize what gets built while the user is away. Shift change maximizes what the user's scarce live attention resolves: the decisions, approvals, and live verifications that only they can do. The loop is efficient precisely because each side stays in its lane — the graveyard never waits on the user, and the user never spends live time on things the graveyard could have done.

## The spine: write it up, don't execute it

**A shift change converts live decisions into written, shaped GitHub permission. The graveyard executes them — not this session.** This is the load-bearing rule and the one most easily broken. When the user approves something during the walk, the action you take is to **record that approval onto the issue** (a decision comment, a `ready`/greenlit signal, a reshaped body) so the next graveyard can execute it without them. You do **not** build it, open the PR, run the review loop, or merge it here.

Why: executing live makes the user *wait between decisions*. The whole value of a live session is decision density — walking many forks quickly while their attention is here. The moment you drop into an implement→test→review→merge grind, the meeting stalls behind one item and the other decisions don't get made. The user's time is for deciding; the graveyard's time is for doing. (This rule was written from a real failure: a session took the user's greenlights as live commands, spent the meeting building and merging, and made the user wait through execution that belonged overnight.)

The only things that actually *happen* during a shift change:
- **Read-only investigation** that informs a decision (read the code, check state, verify an assumption) — fast, in service of the call being made.
- **Live verification** that needs the user's eyes/hands (driving a running build) — see that section below.
- **Writing decisions onto GitHub** — comments, new issues, labels, reshaped bodies, `shape-an-epic`. This is the session's actual output.
- A **genuinely explicit now-imperative** ("do this *right now*, I'm watching", "I need this merged this second") — rare, and narrow.

Everything else — every "build it / ship it / just do it / merge it" said *about a backlog item while planning* — is an **approval to record and defer**, not a command to execute now.

## The agenda: current state, not the latest shift

Open by compiling **everything currently waiting on the user**, swept from reality — never from memory of what the last shift produced:

- `gh pr list --draft` and open agent-authored PRs (each is a parked decision)
- The most recent graveyard brief's decision section — and anything it carried forward
- Issues explicitly awaiting the user (a fork posted as a proposal comment, an approval gate)
- Queued live verifications (changes that need the user's eyes/hands on the running app)

Present it as one screen, each item with its **age**. An item waiting since three shifts ago is the *most* important line, not a stale footnote — old pending fixes are why the user keeps re-hitting bugs that "were already fixed." Hiding the ball — surfacing only the newest shift's output — is this skill's named failure mode.

## Cues, not actions

The core behavioral rule of a live session. The user's reactions are **cues** — invitations to explain, capture, and queue — not commands to execute. Jumping to action on a reaction fragments the conversation the user is trying to have, takes the decision out of their hands, and spends agents on something that may not be the priority.

| The user says... | It is... | You do... |
|---|---|---|
| "What the fuck?" / "I thought we fixed this" | A request for **explanation** | Explain the state in words: what happened, where the fix lives, why they're still hitting it. Then ask what they want done. |
| "This is broken" / hits a bug mid-session | A **capture** cue | File (or find) the GitHub issue, add it to this session's decision list, continue the walk. |
| "That's annoying" / "not what I need" about a built thing | A **design cue** | Record the reaction on the PR/issue; queue the reshape question for this session's list. |
| "Build it" / "ship it" / "just do it" / "merge it" about a backlog item | An **approval to record** | Record the greenlight on the issue (decision comment + `ready`/greenlit signal; reshape the body if needed) so the *next graveyard* executes it. Do NOT build/merge it live. |
| "Do it *right now*" / "I'm watching" / "I need this merged this second" | A **live imperative** | Act now — genuinely urgent or needs their presence. Narrow; don't stretch a backlog approval into this. |
| "Go do the next graveyard shift" / the meeting wraps | The **handoff/release** | Launch it (see end state below). |

The test before launching any agent or making any change mid-session: **did the user issue a *now*-imperative, or approve/react to a backlog item?** A backlog approval gets *recorded and deferred*; a reaction gets words and a queue entry; only an explicit now-imperative gets executed live. When in doubt, it was an approval-to-record — write it onto the issue and let the graveyard run it. The tell for a true live imperative is *time pressure or presence* ("right now", "while I'm here", "I need to see it") — not mere assent ("yeah, build that"). (Background work *already* in flight is fine to keep running and report on; the rule governs *starting* new work off a cue.)

This inverts the graveyard's "default to shipping" rule — deliberately. Overnight, asking is the failure mode; live, jumping is. The session's whole purpose is to put decisions in front of the user, so taking one away from them mid-discussion defeats it.

## Live verification happens here

Serial app/desktop driving can't parallelize (one window, one set of hands) and is exactly what live time is for. Get builds up **proactively**: if the agenda includes draft PRs needing live tests, have the right build compiled and running before the user asks "is there a build for me?" When multiple drafts sit on different branches, sequence them — one binary at a time — and announce each build's SHA + branch label.

## Outcomes land on GitHub before the session ends

Every item walked gets its durable state updated *during* the session, not batched to later. But "updated" means **the decision is recorded**, not **the work is done** — execution is the graveyard's job (see the spine above):

- **Approved** → record the greenlight on the issue/PR (decision comment + `ready`/greenlit signal) so the next graveyard merges/builds it. Do NOT merge or build it live (unless it's an explicit now-imperative per the table).
- **Rejected** → close the PR/issue with the reason as a comment.
- **Reshaped** → edit the issue body to the new shape; the next graveyard picks it up correctly.
- **New cue captured** → a new issue, filed before the conversation moves on, shaped enough that a graveyard worker can execute it without the user.

The chat is disposable; GitHub is the record. A decision the user made out loud that never reached the issue **will be lost** and re-asked — the most expensive possible waste of the session. The second-most-expensive waste is *executing* that decision live instead of recording it — it stalls the meeting behind one item. Record, defer, keep walking.

## Close out the brief you worked

The brief is a **conversation object**, not a write-once log — the agenda you walked came out of a specific Notion brief, and that brief should show how the conversation ended. Once you've extracted everything you needed from a brief and landed its outcomes on GitHub, close it out *before moving to the next brief*:

```bash
# append a "what we did" footer capturing the resolutions (decisions made, what landed, what carried forward)
printf '## What we did (%s)\n\n- ...\n' "$(date +%F)" > /tmp/closeout.md
python3 ~/.config/ai-briefs/notion_briefs.py append  --file /tmp/closeout.md --divider
# then retire it so it stops showing up as open — Done OR Superseded, see below
python3 ~/.config/ai-briefs/notion_briefs.py set-status  --status Done        # genuinely finished
# python3 ~/.config/ai-briefs/notion_briefs.py set-status  --status Superseded # replaced / graduated
```

The lifecycle is **In Progress → Ready → (Superseded | Done)** (see `~/.config/ai-briefs/README.md`). After the closeout footer, pick the retiring status by *where the work went*:
- **Done** — the thread is genuinely finished: its decisions are resolved/acted on and nothing carries forward. "Done, here's how."
- **Superseded** — the work lives on *somewhere else*, so this page is now just history: (a) a newer report of the same kind replaced it with open items carried forward, or (b) a strategy **`Brief` graduated into a tracked GitHub epic** — its decisions now live in issues, so the brief is no longer the source of truth. This is the common ending for a big topic Brief: once you've turned its agreed to-dos into issues (the whole point of shift-change — "the deliverable of a decision is an issue"), append a closeout pointing at the epic and flip the brief **Ready → Superseded**. Don't leave it Ready — a brief lingering Ready after its epic exists is the stale-Ready smell, the reason a later "what should I have open?" review finds four Ready docs that are really one live decision plus three graveyards.

The footer + status flip are what let you move to the next brief without losing the thread. If a brief is still mid-work, leave it **In Progress** (the visible "still being worked" signal); only retire it (Done or Superseded) when it's truly closed out.

## End state: cue the next graveyard

The session is done when the waiting-on-user list is empty (each item resolved, or explicitly deferred with that recorded on the issue). Close with a one-screen wrap:

- What was decided and where it landed
- What's now unblocked
- Publish/update the Notion report so it reflects the new state — **that report is the baseline for the next shift-change conversation.** Structure it **decisions-first**: the open 🟥/🟢 decisions sit at the very top, above the fold, above any shipped/status recap — the reader opens it to find *what needs their call*, and a decision buried below a done-log is a decision they'll miss (see `~/.config/ai-briefs/README.md` → *Structure: lead with the decisions*).

**Then run.** The user has granted standing permission: *when a shift-change conversation wraps, you are released to launch the next graveyard shift without waiting for a fresh one-word cue.* Don't end on "say the word and I'll run" — end on "everything's recorded; I'm running the next graveyard now (stop me if you'd rather I didn't)," then launch it. The release is the natural close of the loop: discuss → write up → run → report → discuss again. (If the user has explicitly gated graveyard work — paused Codex, capped the budget, said "not tonight" — honor that gate instead and say what's queued for when it lifts.)

The groomed, GitHub-resident backlog *is* the handoff artifact. The next graveyard shift needs nothing from this chat because everything it needs is on the issues — which is exactly what lets you be released to run it immediately.

## When NOT to use this skill

- The user wants to deep-dive one feature or bug live — just work it synchronously; don't force the agenda walk.
- Nothing is waiting on the user — say so in one line and offer to start the next graveyard shift directly.
- Mid-graveyard (user still away) — that's the other skill's territory.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [rhdeck](https://github.com/rhdeck)
- **Source:** [rhdeck/operating-model](https://github.com/rhdeck/operating-model)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-rhdeck-operating-model-shift-change
- Seller: https://agentstack.voostack.com/s/rhdeck
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.