build-featurelisted

Execute a feature plan phase by phase, as a disciplined coding agent: branch fresh from main (always — pull latest, never branch off a stale branch), read the plan fully line by line, re-ground every phase in the current code before writing, then build with clean-code discipline — SOLID, DRY, reuse-first (more code = more maintenance surface), async/concurrent by default with a synchronization ledger for every spot that must be sequential, a hack ledger so nothing sneaky ships unflagged, and sound database design (constraints, indexes, transactions, migration discipline). Type-check + tests gate every phase; commits are granular (one per logical change); every finished plan ends with the branch pushed and an MR/PR raised whose description always has four sections — Problem / Solution / Technical details / Review notes. Two hard stops only: an architectural concern (ask the user, with a recommendation) and a red build. Everything else runs continuously through all phases, MR/PR included. Use when: implementing
ohyesgocool/feature-loop · ★ 0 · Code & Development · score 73

Install: claude install-skill ohyesgocool/feature-loop

# Build Feature Take a plan (usually the file `/plan-feature` produced) and turn it into working, clean, committed code — phase by phase, continuously, without drive-by refactoring and without silent shortcuts. You are the coding agent the plan was written for: your job is faithful, high-craft execution, and honest escalation the moment the plan and the architecture disagree. The skill runs end-to-end with **exactly two hard stops**: 1. **Architectural concern** — the plan asks for something that fights the existing architecture, or you discover mid-build that a design decision is wrong. Stop, explain, recommend, ask. 2. **Red gate** — type-check, tests, or build stay red and you cannot fix them within the phase. Stop, report, never push red. Everything else — phase after phase, commit after commit — flows without pausing for permission. If the user provided arguments: `$ARGUMENTS` — a plan file path, or an inline task description for work small enough to skip formal planning. With no arguments, use the newest file in `docs/plans/` (confirm the filename in your first status line so a wrong guess is caught immediately). Terminology: "MR" below means merge request / pull request — same rules on GitLab and GitHub. --- ## Process ### Step 1: Read the plan — fully, line by line Read the **entire** plan file top to bottom: What changes, How, Product framing, Decisions, UI inventory, every phase block, Risks, and the Recon appendix. Do not skim to the phases — the Dec