gh-work-planning-checklist

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

1. 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.

2. 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.