issue-driven-github-flowlisted

# Issue-Driven GitHub Flow This skill encodes a disciplined development workflow: **nothing gets coded until a GitHub issue exists and a plan for it has been reviewed and approved.** The goal is that every line of code is traceable to a tracked, planned, and reviewed unit of work — which keeps `main` clean, history meaningful, and review load low. The workflow has two layers that always apply together: 1. **The gitflow** — how branches, commits, PRs, CI gates, and rollback are shaped (mechanical, fast). 2. **The orchestration** — how an issue becomes a reviewed plan, reviewed code, and then a human-approved merge using distinct agent roles. ## The non-negotiables (and why) These few rules are what make the workflow trustworthy. Everything else is mechanism in service of them. - **`main` is never edited directly.** If you're on `main` and the user asks for a code change, silently create the correct branch first (see below) and tell them you did. Editing `main` defeats PR review and makes rollbacks painful. - **Every change starts from a GitHub issue.** The issue is the source of truth for *what* and *why*; the code is just the *how*. No issue → make one before touching code. - **No code before an approved plan.** A planning agent proposes, a review agent critiques, and only an explicit approval unblocks implementation. This catches design mistakes while they're still cheap (a comment) instead of expensive (a diff). The loop is worth running even for s