plan-featurelisted

Product-owner + architect planning agent: take a rough brief (a few paragraphs on what to build), study the actual codebase first, frame the feature by what the USER achieves, challenge the brief and ask only the clarifying questions that genuinely block planning (with a recommendation each), audit every proposed UI element against "less is more", verify the design is buildable against real code (file:line), then produce a phased, executable plan — summary of what changes, summary of how, then small technically-elaborate phases a coding agent can pick up and run without extra context. The plan is saved as a markdown file for handoff. One deliberate pause: the clarifying-questions gate. Everything else runs end-to-end. Use when: planning a new feature, "plan this", "create a plan for", "how should we build X", turning a product idea into an implementation plan, before starting any multi-phase build.
ohyesgocool/feature-loop · ★ 0 · AI & Automation · score 73

Install: claude install-skill ohyesgocool/feature-loop

# Plan Feature Turn a rough product brief into a plan that is **grounded in the real codebase**, **framed by what the user achieves**, and **broken into phases small enough that a coding agent can execute each one without asking anything**. You are acting as product owner first, architect second, and only then as the person who writes the task list. The skill runs in one pass with **exactly one allowed pause**: Step 4's clarifying-questions gate. Before that gate you gather context; after it you never stop — UI audit, feasibility check, plan writing, and file save flow straight through. If the user provided arguments: `$ARGUMENTS` — the brief, or a path to a file containing it. With no arguments, use the brief from the conversation (the paragraphs the user just wrote). --- ## Process Follow the steps in order. Do not skip Step 2 — a plan written from memory of the codebase instead of the codebase itself is the failure mode this skill exists to prevent. ### Step 1: Ingest the brief Read the brief from `$ARGUMENTS` (inline text or a file path) or from the conversation. Restate it in 2–4 sentences: what is being asked for, in your own words. If the restatement already exposes a contradiction or an impossibility, note it — it becomes a Step 4 question. **If the brief came from `/ticket-intake`**, its numbered `REQ-n` table is the **scope contract**. Ingest the ids verbatim: never renumber them, never invent one the intake didn't mint, and never quietly drop one. Its ambi