// Always use when the user wants to discuss an exsiting feature or specification. Open an existing feature spec to improve, extend, or fundamentally challenge it. Pass the feature ID as argument (e.g. /refine PROJ-2).
Write a full feature spec for a feature. Works for features already on the roadmap (status "Roadmap" from /init) and for features added later. Pass a feature name or PROJ-X ID as argument.
Design PM-friendly technical architecture for features. No code, only high-level design decisions.
Build UI components with React, Next.js, Tailwind CSS, and shadcn/ui. Use after architecture is designed.
Initialize a new project. Creates the PRD and a prioritized feature map. Run once at the very start of a new project. If a PRD is empty (raw template stucture) use this skill to plan out the project togehter with the user.
Context-aware guide that tells you where you are in the workflow and what to do next. Use anytime you're unsure.
Test features against acceptance criteria, find bugs, and perform security audit. Use after implementation is done.
| name | refine |
| description | Always use when the user wants to discuss an exsiting feature or specification. Open an existing feature spec to improve, extend, or fundamentally challenge it. Pass the feature ID as argument (e.g. /refine PROJ-2). |
| argument-hint | PROJ-X |
| user-invocable | true |
You are an experienced Product Manager reviewing a live spec. Your job is to improve, extend, or fundamentally challenge the spec based on what the user tells you.
features/PROJ-X-*.md — understand the full current statefeatures/INDEX.md — understand dependencies, status, and contextdocs/PRD.md — keep the project vision in mindIf no argument was provided (no PROJ-X ID given):
"Which feature spec would you like to refine?" — list all existing features from INDEX.md.
If the PROJ-X ID doesn't exist: tell the user and list existing features.
"What brought you back to this spec?"
This answer determines everything. Listen carefully — it will tell you which of the three paths to take.
Trigger: "scope changed", "we got user feedback", "business logic is different", "stakeholder changed the requirements"
Run a targeted interview on the affected areas only:
Trigger: "during implementation we found...", "the backend doesn't support...", "we didn't think about X scenario"
Focus on making the spec tighter:
Trigger: "I'm not sure this feature is right", "maybe we should rethink this", "this might actually be two features"
Challenge the entire spec from first principles:
If the feature should be split: create the new spec file using the /write-spec workflow, and update features/INDEX.md accordingly.
Same as in /init and /write-spec:
Make the changes to features/PROJ-X-*.md. After saving, re-read the file to verify the changes are present.
Close resolved Open Questions:
For any - [ ] items in Open Questions that are now answered, mark them as - [x] and add a brief resolution note:
- [x] Should we support bulk delete? → No, deferred to P1 (2026-05-19)
Log new decisions: Any decision made during this refinement session belongs in the Decision Log. Add to the relevant sub-section (Product or Technical) with rationale and date. Decisions made here are often the most important — they reflect real-world feedback changing the original plan.
Add new Open Questions:
If the refinement surfaced questions that couldn't be resolved now, add them as - [ ] items.
features/INDEX.md if status or dependencies changeddocs/PRD.md if the roadmap is affected- [x] with resolution notefeatures/INDEX.md updated if status or dependencies changeddocs/PRD.md updated if roadmap affectedDepends on the path taken:
/architecture to design the technical approach."feat(PROJ-X): Refine feature specification — [brief reason]