Plan to Graph

Translate an approved plan into GitHub Issues. Do not implement code or modify the source plan. GitHub Issues are the only durable work-item store: use native sub-issues for hierarchy and native blocking relationships for dependencies.

Load references/github-surface.md before drafting. That file is the only place that binds abstract operations to concrete tools.

When to Use

• Convert an approved *.spec.md, master plan, or roadmap into GitHub Issues.
• Turn a GitHub epic's ## Tasks section into native GitHub sub-issues.
• Preserve task requirements and verification as issue bodies while representing explicit dependencies as blocking edges.

Do not use this skill to implement a plan, triage unrelated issues, or create speculative project-management work. Do not use it to author a new plan from an idea (use feature-to-plan — spec file or one new GitHub issue) or to rewrite an existing issue in place and split it (use issue-refine-loop). A feature-to-plan-authored issue whose tasks are already session-sized is a valid epic source; no refine run is required in between.

Prerequisites and Input

Bind a GitHub surface before drafting. Load references/github-surface.md and run its probe once: CCR-proxy check → gh candidacy (including the three graph capabilities) → enumerate harness tools only if gh is not a candidate → score → bind exactly one path. Do not re-probe. Do not mix surfaces. After binding, never invoke gh unless gh is the bound surface.

A surface qualifies only if it can do all three: create an issue with a parent (create_child); add a native blocked-by edge (add_blocked_by); read back parent, subIssues, blockedBy, and blocking (read_graph). A missing capability is a blocker, not a degraded mode.