plan-devlisted

## Live context !`git branch --show-current 2>/dev/null | sed 's/^/current branch: /' || echo "not a git repo"` !`gh repo view --json defaultBranchRef,nameWithOwner --jq '"repo: \(.nameWithOwner) | default branch: \(.defaultBranchRef.name)"' 2>/dev/null || true` !`gh issue list --state open --limit 5 --json number,title --jq '.[] | " open issue #\(.number): \(.title)"' 2>/dev/null | head -5 || true` # plan-dev Structure raw tasks, specs, and review docs into phased GitHub issues — reviewed by the user before a single issue is created. ## Why this skill exists When a developer jumps straight from "here's a big task" to writing code, they lose sequencing — risky changes land alongside safe ones, reviewers get massive PRs with unrelated diffs, and nothing is trackable. The naive approach of "just start coding and figure it out" creates re-work, merge conflicts, and no audit trail. This skill forces a planning gate: parse the raw input, organize it by dependency/theme/risk into reviewable phases, show the plan to the user for approval, and only then create atomic GitHub issues. Each phase maps to one issue, making the work parallelizable, reviewable, and cancellable independently. ## Input Parse `$ARGUMENTS` as one of: - Free-text task or feature description - File path to a spec, review doc, or requirements file - A GitHub issue URL or number to decompose into sub-tasks - A bullet list of fixes or changes If empty, prompt: "What should I plan? Paste a task description,