# Gh Work Execution Checklist > Compact live-execution checklist companion for approved GitHub issue work. Use during active implementation as a fast operational route; gh-work-execution remains the canonical source of truth. - Skill: `vamseeachanta/gh-work-execution-checklist-2` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add vamseeachanta/gh-work-execution-checklist-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/vamseeachanta/gh-work-execution-checklist-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: vamseeachanta (https://skillmd.com/u/vamseeachanta) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vamseeachanta/gh-work-execution-checklist-2 --- # 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.