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, and PRs are shaped (mechanical, fast).
2. The orchestration — how an issue becomes a reviewed plan and then code, using three distinct agent roles (the part that prevents half-baked work).

The non-negotiables (and why)

These few rules are what make the workflow trustworthy. Everything else is mechanism in service of them.