Conducts exhaustive requirements-gathering interviews for software features or systems. Reads existing context, then asks structured numbered questions covering purpose, technical design, UI/UX, edge cases, security, and rollout. Use when the user says "interview me", "deep dive on requirements", "spec this out", "fill out the spec", "help me think through this feature", or when a feature needs thorough requirements elicited before a spec or plan can be written. Don't use for quick clarifying questions during an in-progress task (use ask-questions-if-underspecified instead), for writing or updating a SPEC.md document (use create-spec instead), for generating a task plan (use create-plan instead), or for general architectural discussions that don't need structured requirements output.
Builds new MCP (Model Context Protocol) servers that expose external API tools to LLMs. Use when the user wants to create, scaffold, or implement an MCP server to integrate a third-party service or API, in Python (FastMCP) or Node/TypeScript (MCP TypeScript SDK). Also use when asked to add tools to an existing MCP server, write or run evaluations for an MCP server, or design the tool interface for a new MCP integration. Don't use for: connecting to or configuring an already-running MCP server, debugging MCP client connections, explaining the MCP protocol in general, or configuring Claude Desktop MCP settings.
Creates or updates a ROADMAP.md file for a software project by analyzing the codebase and defining vision, milestones, and a timeline. Use when the user asks to create, generate, write, update, or revise a project roadmap, or wants to communicate project direction and priorities to contributors or stakeholders. Don't use for updating a single section of an existing roadmap in isolation without touching the rest, creating sprint plans or Jira boards, writing a product requirements document, or generating architecture or design docs.
Analyzes all uncommitted changes (staged and unstaged), groups them into atomic commits by logical purpose, and generates conventional commit messages with user-facing bodies. Use when the user asks to "smart commit", "group my commits", "split into atomic commits", "organize my changes into commits", or when there are many uncommitted changes across multiple files that should be separated into well-scoped commits. Don't use for a single, simple commit message request, for push/pull operations, for rebasing or squashing existing commits, or when the user just says "commit this" without asking for grouping or splitting.
Upgrades Elixir Mix/Hex dependencies safely, covering patch/minor bumps, major-version migrations with changelog research, and post-update verification. Use when the user asks to update deps, bump packages, upgrade a specific Hex package, or run mix hex.outdated. Don't use for: adding a new dependency, removing a dependency, resolving a dependency conflict or lockfile error without upgrading, or updating npm/pip/cargo/other non-Elixir package managers.
Coaches the user through completing a task themselves instead of doing it for them. The core signal is that the user wants to remain the actor and build understanding, not receive a finished result. Use when the user explicitly signals they want to be in the driver's seat: phrases like "guide me", "teach me", "help me learn", "I want to understand how to do this", "don't do it for me", or "let me figure it out". Don't use when the user says "show me how" or "walk me through" without pairing it with a desire to do the work themselves (these usually mean "just show me"). Don't use for requests that want a task completed directly, a bug fixed, a document produced, a one-shot explanation without back-and-forth, or general Q&A. Don't use when "help me understand X" means "explain X" without requesting interactive back-and-forth. Don't use when "help me work through" refers to debugging or problem-solving assistance, not skill-building.
Writes production-quality @moduledoc, @doc, and @typedoc annotations for Elixir modules. Scales doc shape to module complexity: one-line docs for simple wrappers, multi-section guides with examples for core concepts. Applies ExDoc conventions including cross-references, admonitions, doctests, tables, options lists, and return contracts. Use when asked to "document modules", "add moduledocs", "write elixir docs", "doc standard", "add @doc", "improve documentation", or when Elixir modules have thin, missing, or inconsistent documentation. Don't use for README files, user-facing guides, ExDoc configuration, hex.pm publishing, mix docs generation, non-Elixir projects, or LiveBook notebooks.
Generates high-end, production-quality React and Next.js UI components and full pages using Tailwind CSS, Framer Motion, and premium design principles. Use when the user wants to build, design, or refactor frontend UI where visual quality matters: hero sections, SaaS dashboards, pricing pages, bento grids, navigation, forms, cards, landing pages, or interactive components with animations. Don't use for backend logic, API routes, database schemas, server-side data processing, non-React frameworks (Vue, Svelte, Angular, Astro), plain HTML/CSS without a component framework, reviewing or auditing existing UI without producing new code, accessibility-only audits, or performance profiling unrelated to UI rendering.