Gh Work Execution Checklist

GH Work Execution Checklist

Compact companion skill for live execution. gh-work-execution is the canonical and authoritative route. Use this checklist to stay on-track during active work, not to replace the full route.

Trigger notes

Use when:

• the issue is already planned and approved
• you need a fast execution checklist while working
• you want to keep GitHub updates, validation, and closeout disciplined

Do not use this instead of the canonical route when scope, delegation, policy, or closeout decisions are unclear.

Live checklist

1. Entry gate

• Confirm the issue is approved for execution.
• Confirm repo/worktree/policy context is known.
• Confirm you know the intended validation path.
• Post a concise execution-start note if execution is proceeding.
• If approval, authz, environment, or validation path is missing: stop and route back per gh-work-execution.

2. Already-done check first

• Inspect the deliverable surface before changing code.
• Run the most relevant targeted validator/test.
• Check issue comments, linked PRs, and recent history if it may already be landed.
• Decide explicitly: already done, not done, or uncertain.
• If already done, post evidence and close from the verification-first path.

3. Central vs delegated decision

• Default to central unless ownership boundaries are crisp.
• Delegate only when owned paths, validators, GitHub authority, and integration ownership are explicit.
• Use hybrid only when recon/slices can be delegated safely but final integration stays central.
• If the decision changes execution ownership or reporting flow, post that change to GitHub.

4. TDD loop

• Write or update the failing targeted test first.
• Implement the smallest change that should pass.
• Run the narrowest relevant test loop.
• Refactor only after green.
• Repeat until acceptance is satisfied.

5. Targeted validation gate

• Run the specific tests/validators that prove the issue is done.
• Add broader validation only where risk or repo policy requires it.
• Capture exact evidence for GitHub and commit messaging.
• If validation changes a test fixture from a metadata stub to a real tool-backed object, update teardown/removal semantics in the same pass. Example: when code now runs real git status, test fixtures must use git init instead of empty .git directories, and tests that simulate absence must remove .git recursively rather than using Path.rmdir().
• If validation is incomplete or ambiguous, do not advance.

6. Adversarial review gate

• Challenge the change like a skeptical reviewer.
• For unattended/dispatch/orchestrator CLIs, explicitly adversarial-test missing evidence and canonical registry enforcement; do not accept a green path that only proves the happy case.
• Check acceptance coverage, regressions, edge cases, and policy fit.
• Check whether new work should become a future issue instead of being absorbed.
• If non-trivial concerns remain, fix them and re-run validation.

7. Commit/push gate

• Confirm the diff matches approved scope.
• Confirm tests/validators used as evidence are still green.
• Commit with a message tied to the landed work.
• Push only after validation and review are complete.
• Post the landed summary and verification evidence to GitHub.

7a. Interruption / tool-budget handoff gate

• If execution is interrupted by context compaction, tool-call budget limits, user stop, or before validation, commit/push, or closeout, do not write a completion-style summary.
• Write a resumption handoff instead: live issue state, labels, plan/approval status, exact dirty paths, tests already run and their result, first unmet acceptance criterion, and explicit not completed statements.
• If the interruption happens after local code edits but before final tests/review, name the edited files and the validation gap separately. Do not imply that helper insertions, lint-on-write, or partial diagnostics equal a completed review.
• Include the first resume commands/checkpoints when tool calls are exhausted: git status --short, targeted git diff, and the narrowest relevant test/validator from the issue plan.
• Preserve RED-state evidence truthfully. A failing TDD test plus no implementation is progress, not completion.
• Call out suspicious unrelated dirty files as session residue candidates; do not silently absorb them into the issue commit.
• On resume, re-run live checks rather than trusting the handoff narrative: issue labels/state, git status, relevant diffs, and the targeted test/validator.
• If an interruption happens immediately after a failed verification command, preserve the exact failing command and parser/output error as the first resume target; do not continue to review/commit until the verifier contract is corrected or the command is adjusted to the actual CLI interface.
• Use references/interrupted-approved-issue-execution-handoff.md for the required handoff shape when execution stops mid-gate.

8. Closeout

• Close only when the issue is landed, or proven already satisfied/invalid with evidence.
• Link any future issues discovered during execution.
• For governance/prerequisite child issues that intentionally do not unblock the parent, post parent issue updates before/with child closeout that explicitly state: artifact landed, no raw/private implementation occurred, parent remains blocked, and future implementation still requires a separately approved issue.
• Post concise final verification evidence.
• Leave the issue with a clear done-state, not an implied one.

Operating note

When in doubt, stop using the checklist as a shortcut and return to gh-work-execution for the full decision framework, delegation rules, GitHub posting cadence, blocker handling, and closeout requirements.

Reference: references/interrupted-approved-issue-execution-handoff.md captures the interruption handoff pattern for approved issue work that reaches RED tests or reconnaissance but stops before implementation/closeout.

Reference: references/sso-verification-interruption.md captures the pattern for interrupted approved-issue verification where a live checker/repair CLI contract fails and must be resumed before review/commit.

Reference: references/cli-orchestrator-safety-gates.md captures the TDD safety-gate pattern for cron/label/Telegram-Hermes-style CLI orchestrators: dry-run default, explicit execute opt-in, host-local readiness evidence, canonical registry machine labels, real git cleanliness checks, no-overlap locks, and recursive output redaction.