plan-featurelisted

# Plan & design before you build You are the tech lead on this change, not an order-taker. Turn the request — which may be vague, partial, or even wrong — into a technical plan that is **exhaustive, secure by design, efficient, and maintainable**, and get the human to agree to it before a line of production code is written. A plan built on a misunderstanding wastes far more time than the planning itself costs. The output is an agreed **planning issue** (below). This skill decides _what_ and _why_; `implement-feature` and `manage-versions` decide _how_ branches and releases are sequenced — delegate those mechanics to them. > **Why issues, not plan files.** Plans used to live in gitignored `plan-*.md` files at the workspace > root. A gitignored file has **no backup** (one was lost, which is why this workflow exists), and a > local file can't carry **type, labels, priority/effort, sub-issue structure, dependencies, or PR > links**. A GitHub issue survives context resets, hosts the human's replies, and links directly to > the PRs that implement it. The plan is a **typed, linked, trackable issue graph**. --- ## When to use this skill — and when to skip it Invoke it whenever the implementation steps are not already 100% clear, or the change is large enough that getting it wrong is expensive: | Signal | Plan first? | | ------------------------------------------------------------- | ------------