Codex Long Tasks Need Handoff? I Built a Session Rotation Skill

The problem: a Codex task has been running for three days and context is ballooning

I run a long Codex task, and after three days the context gets longer, responses get slower, and I even want to switch to a stronger model to continue. But how do I safely hand off where I am, what PRs are open, what blockers remain, what's the Git state to the next session?

Copy-paste the chat history? That's full of abandoned intermediate conclusions, trial paths, and irrelevant chatter. Let the new session read the repo? It can't read the reasoning behind why I chose this approach over that one.

365-session-rotation-maintainer solves this handoff problem.

Core principle: rotation is a recoverable transfer

Treat rotation as one recoverable transfer of work and task identity. Preserve the predecessor until one successor has received, acknowledged, and presented a verified handoff.

Hard rules:

• Rotation requires explicit user request; age, context length, inconvenience, or a new model release does not authorize it.
• Create at most one successor; never create another because setup or acknowledgement is slow.
• Preserve unrelated worktree changes; do not reset, clean, stash, or absorb.
• Never copy raw transcripts, hidden reasoning, credentials, tokens, private URLs, or unnecessary logs.

Seven-step rotation flow

1. Freeze and inventory — Capture current truth from durable evidence: task identity, current objective and delivery stage, completed work with evidence, open work and exact blockers, known debt and preserved decisions, active external operations, branch/HEAD/worktree state, ranked next actions.
2. Create durable checkpoint — Use the project's existing handoff location, or write to docs/session-handoffs/<task-slug>.md. Contains decisions and evidence, not conversation history.
3. Audit — Confirm all six conditions pass: predecessor identity known, worktree state preserved, no unknown active protected action in flight, checkpoint matches current work, no nonterminal rotation exists, task-management tools available.
4. Create exactly one successor — In the same project or explicitly selected destination; use a neutral initial prompt like WAIT_FOR_VERIFIED_HANDOFF.
5. Deliver one bounded handoff — Includes: predecessor/successor identifiers, project/repo/branch, checkpoint path and digest, complete work inventory, preserved decisions and constraints, exact first recommended action, actions needing new authorization, required acknowledgement format.
6. Verify the successor — Read back and verify: intended task received the handoff, identifiers and checkpoint digest match, successor can access required repo/artifacts, complete owner-facing kickoff is visible, open work/blockers/decisions/next actions/authorization boundaries are all present, no protected action started from historical approval.
7. Rename and archive last — Only after verified acknowledgement: make successor canonical, rename if requested, archive predecessor only when its worktree is safe and it owns no active obligation.

Recovery rules

• Failure before successor creation: predecessor remains canonical.
• Failure after successor creation: preserve both and resume the same successor.
• Stale or mismatched acknowledgement: correct the named mismatch only.
• Dirty or divergent predecessor: preserve visibly; do not archive.
• Active protected operation: wait for terminal success or verified rollback.

Install

bash git clone https://github.com/laojin1900/365Skill.git ./install.sh 365-session-rotation-maintainer

Repo: github.com/laojin1900/365Skill/tree/main/skills/365-session-rotation-maintainer