backend-feature-plannerlisted

Plan a backend feature or module before any code is written. Use this whenever the user wants to add a feature, design a module (auth, products, orders, payments, search, file upload, etc.), or says things like "I want to build X", "plan the auth feature", "design the product module", or "how should I structure Y" for a server-side API. This is the BMAD replacement — it reads the project's ARCHITECTURE.md and MODULE_REGISTRY.md first, asks ONLY the questions those files don't already answer, and writes an editable FEATURE_PLAN markdown file. It does NOT write feature code (that is backend-module-builder) and does NOT write tests (that is backend-test-writer). Works in any project in the Express/TS convention family that has the contract files, or offers to create them for an existing repo.
vipincode/exr-agent-skills · ★ 0 · API & Backend · score 57

Install: claude install-skill vipincode/exr-agent-skills

# backend-feature-planner Turn a feature idea into a concrete, editable plan with the fewest questions possible. The reason this exists: generic planners interrogate the user every time because they have no memory of the codebase. This one reads the project's source of truth first, so it only asks what genuinely isn't decided yet. The output is a markdown file the user reads and edits by hand before any code is generated. **This skill never writes feature code and never invokes backend-module-builder.** ## Step 1 — Load the contract (always first) **First resolve the project dir** for this (`backend`) domain via the resolution protocol in `../LAYOUT.md`: read `.claude/workspace.json` and use the `backend` entry's folder (it may be the repo root or a subfolder like `backend-shoply/`); if there's no manifest but `ARCHITECTURE.md` sits at the repo root, that's the legacy single-project layout. All paths below — the contract files, the grep targets, and the `_docs/` output — are **relative to that project dir**. Read, in this order: 1. `ARCHITECTURE.md` — the project's conventions (paradigm, response envelope, error model, validation flow, import convention, auth primitives, layout). 2. `MODULE_REGISTRY.md` — what already exists: shared utils/middleware, existing modules and their public service surfaces, and the decisions log. 3. **Grep the codebase** for anything related to the requested feature: `src/lib`, `src/middleware`, and sibling modules. Look for models, services,