Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
branch status is clean or only contains the next expected artifact
the intended handoff file is actually tracked in the expected commit (git log --oneline -- <file> and git show --stat -- <file>), especially if hooks/tooling return confusing output such as nothing to commit after a commit attempt
If a commit command returns non-zero or says nothing to commit after you just added a handoff file, do not assume failure. Immediately check:
git status --short --branch
git ls-files <handoff-file> --stage
git log --oneline -- <handoff-file> -3
git show --stat --oneline -- <handoff-file> | head -80
Some workspace automation/hooks may have already staged/committed the file or cleaned unrelated state; verify by file-specific git history before retrying or rewriting.
9. Explicitly verify push/no-push state and post-push CI
Do not merely assert whether a push happened. Check using git/remote evidence, for example:
git branch -vv
git ls-remote --heads origin <branch>
git rev-parse HEAD and git rev-parse origin/main after git fetch origin
post-commit output indicating no upstream configured / no auto-push
If the user chooses the exit path of "commit/push, document, and prepare to exit":
commit the handoff artifact as a narrow docs-only commit
push it
verify local HEAD equals the pushed remote ref
inspect the CI run triggered by the handoff commit
separate scoped-success evidence from unrelated CI failures
If git push reports a remote ref-lock/race error such as cannot lock ref ... is at <new> but expected <old>, do not assume the handoff failed. Immediately run git fetch origin <branch> and compare git rev-parse HEAD with git rev-parse origin/<branch>. In concurrent/auto-sync environments the remote may already contain the just-created commit despite the non-zero push result; if hashes match, treat the push as effectively complete and avoid duplicate commits or force-pushes.
A docs-only handoff commit can still trigger repo CI/docs workflows. If CI is red for failures outside the completed stream's scope, do not reopen the completed issue by default. Instead:
record the relevant scoped pass/fail evidence in the handoff and/or issue comment
open or draft a new follow-up issue for the remaining failure family
explicitly state that the completed stream remains complete only if its acceptance gate stayed green
Example: after a lint-restoration stream, a handoff commit triggered CI where Lint, Type Check, and Security Scan passed but Python test-matrix jobs failed. Correct closeout was to preserve the lint handoff, keep the lint issue closed, and create a new plan-gated follow-up issue for the Python test-matrix failures.
Report the evidence plainly.
Output checklist
A solid handoff should usually include:
summary of current branch state in <=8 lines if requested
written follow-up issue drafts
written next-stage authorization note
written deploy-readiness checklist
written operator note on promoting a fix
git status checked
explicit statement that no push happened
optionally, exact gh commands and a single operator bundle
Pitfalls
Do not reopen already-completed tasks just because review found future hardening work.
Do not mistake a worktree smoke test for production validation.
Do not bury the real high-value recommendation (e.g. promote a narrow enforcement fix first).
Do not leave issue drafts as prose only; convert them into gh-ready packets when possible.
Do not stop after creating docs if a simple docs-only commit would materially improve handoff cleanliness.
Minimal verification loop
Before finishing:
git status --short --branch
git log --oneline -N
verify all promised docs exist
verify whether anything remains uncommitted
explicitly state whether a push occurred
Why this is reusable
This pattern works whenever a completed implementation wave needs a safe operational handoff for the next wave, especially in plan-gated repos where docs, issue packets, and deployment sequencing must be preserved without reopening feature code.
