# 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` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vamseeachanta/gh-work-execution-checklist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vamseeachanta/gh-work-execution-checklist/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- 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

---


# 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 is incomplete or ambiguous, do not advance.

6. Adversarial review gate
- Challenge the change like a skeptical reviewer.
- 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.

8. Closeout
- Close only when the issue is landed, or proven already satisfied/invalid with evidence.
- Link any future issues discovered during execution.
- 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.