From product-builder
Plans a Product Builder feature end-to-end — database changes, pages, views, shadcn components, and acceptance criteria — and saves a numbered spec to docs/features/. Use when the user asks to plan, spec, design, or scope a feature for a Product Builder project.
How this skill is triggered — by the user, by Claude, or both
Slash command
/product-builder:planning-featuresThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A product feature described in user terms. Examples:
A product feature described in user terms. Examples:
If the description is vague or missing key decisions, ask up to three clarifying questions before planning. Focus on:
docs/data-model.md if it exists — this is the canonical reference for entities, relationships, and constraints. Use it to understand the current data model before proposing changes.docs/architecture.md if it exists — use the Implementation Log for prior design decisions and deviations.docs/features/*.spec.md files to know what is already planned.app/db/schema.ts), DAOs (app/db/daos/), services (app/services/), routes (app/routes/), and components (app/components/).react-router-patterns for route, loader, action, and page conventions.docs/conventions/*.md files for project-specific patterns and anti-patterns. Specs should align with established conventions.Present the proposed spec list: number, title, one-line scope for each. Ask the user to approve, reorder, merge, or split before writing files.
Create docs/features/ if it does not exist. Write one file per spec using the template in feature-spec-template.md.
Name files as NN-short-name.spec.md continuing the existing numbering sequence. If 00 and 01 exist, start at 02.
docs/data-model.md.docs/conventions/.npx claudepluginhub adrianhdezm/mystack --plugin product-builderProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.