felipereisdev

Performs a structured, comprehensive code review of git changes. Detects stack and architecture automatically, applies relevant stack/pattern-specific rules, and reports findings by severity. Use when: user runs /code-review, /review-pr, or asks to "review my changes".

Analyzes a codebase and breaks down a goal into implementable user stories with clear acceptance criteria. Use when planning a new feature, estimating work, or creating a development roadmap. Outputs structured stories to .context/[goal-slug]-plan.md ordered by dependency. Filename is generated from the goal (kebab-case, 3-5 words). Do NOT implement anything - only analyze and plan.

Use whenever you work in a project wired to the RAG knowledge base (the `rag_*` MCP tools are available) — search it BEFORE answering anything about this project's business rules, architecture, past decisions, conventions, or "why is it done this way", and store durable decisions/rules you establish. Also use when the user says "remember this", "save this decision", "what did we decide about X", "look up prior context", wants to import docs into the base, or asks how domain concepts relate. When this base exists, don't answer project-knowledge questions from assumption — check it first.