| name | gh-work-planning-checklist |
| description | Compact live-execution checklist companion for the canonical gh-work-planning route. Use for fast operational tracking during issue planning without replacing the full route. |
| version | 1.0.0 |
| author | Hermes Agent |
| category | coordination |
| triggers | ["When user says \"gh work planning checklist\"","When running the canonical gh-work-planning flow live and a compact checklist is needed","When you need a short issue-planning execution checklist without rewriting the full route"] |
| related_skills | ["gh-work-planning","github-issues","overnight-parallel-agent-prompts","licensed-machine-prompt-orchestration"] |
| tags | ["planning","github","checklist","coordination","approval-gate","delegation"] |
GH Work Planning Checklist
Use this as the compact operational checklist during live execution.
gh-work-planning remains the canonical and authoritative source of truth.
If this checklist conflicts with the full route, follow gh-work-planning.
Trigger notes
Use when:
- work starts from a GitHub issue
- you need Issue -> Plan -> Approval -> Execution discipline
- you want a short runbook while posting progress live
Do not use this as a substitute for the full planning route.
Live checklist
- Intake
- Read the full issue, acceptance criteria, references, and labels.
- If the user asks to use the issue as an interactive discussion thread, prioritize showing the live GitHub issue URL and a compact comment-ready decision map before deeper fan-out inspection. Do not bury the comment surface under long resource-intel output.
- Classify T1/T2/T3.
- Post planning-start comment before any implementation.
- Decision gate: continue, blocker, or future issue.
1b. Interactive review-thread mode
- Use when planning depends on user comments one topic at a time (for example engineering force-by-force review, API contract decisions, acceptance-criteria triage).
- First response shape: issue link, current known decisions, unresolved prompts grouped in the order the user should comment, and explicit implementation block status.
- Keep resource intelligence read-only and bounded; avoid launching broad code/doc/test reads in the same turn if the user only asked for the issue/commenting surface.
- After each user comment batch, update the issue-plan assumptions and unresolved-blockers list before continuing resource intelligence.
- See
references/interactive-review-thread-mode.md for an example pattern from the B1528 proj-a force-calculation planning thread.
- Resource intelligence
- Stay read-only.
- Check code, tests, docs, issue/PR history, standards or upstream constraints, and prior session context.
- Record proof: exact files, docs, issue/PR numbers, commits, commands.
- Identify implementation surface, gaps, risks, and artifact locations.
- Capture out-of-scope discoveries as future-issue candidates immediately.
- Confidence gate: High/Medium can proceed; Low means keep investigating or stop and post blocker.
2b. Scope-guarded repo fallback
- Some repos intentionally block
git/gh until the user activates an explicit work scope (for example a slash command). If a guarded repo blocks issue creation or label/comment work, do not bypass it and do not keep retrying.
