Facilitate structured brainstorming sessions to generate, explore, and refine ideas before committing to requirements. Use when the user has a vague concept, wants to explore possibilities, needs creative solutions, or is in the early ideation phase. Do NOT use when the requirements are already clear and the user is ready to plan implementation (use create-prd or prd-to-tasks instead).
Interview the human-in-the-loop to clarify ambiguous requests before taking action. Use when the user's request is vague, missing key details, or has multiple valid interpretations. Do NOT use when the request is clear and unambiguous, or when the clarification can be resolved by reading code, docs, or a quick web search.
Read a tasks.json file, resolve the dependency graph, and delegate each task to specialized expert agents using the Mixture of Experts (MoE) orchestration pattern. Use when a tasks.json exists and the user wants to start implementing, or says "implement the tasks," "build it," or "execute the plan." Do NOT use when no tasks.json exists (run prd-to-tasks first), for a single straightforward task (just do it directly), or when the user wants manual control over each step.
Convert a Product Requirements Document (PRD) into a structured tasks.json file with tasks, dependencies, priorities, and estimated effort. Use when a PRD exists and the user wants to break it down into implementable tasks, or says "turn this into tasks," "create issues from the PRD," or "what are the next steps?" Do NOT use when there is no PRD or when the user wants to skip planning and start coding immediately.
Create a Product Requirements Document (PRD) from recent discussions, conversations, or accumulated context. Use when the user wants to formalize requirements, document what was discussed, or create a spec to guide implementation. Do NOT use for technical implementation specs (use SPEC.md from project-files) or for already-implemented features (use CHANGELOG.md).
Research and explore codebases to build context before making changes. Use when starting work on an unfamiliar project, investigating a bug, planning a feature, or when you need to understand how something works.
Format and write git commit messages using a structured type-based format (fea, fix, ref, ai, oth). Use when the user asks to commit, stage, create a commit message, or summarize code changes. Do NOT use for merge commits, revert operations, work-in-progress commits, or when user specifies a custom format.
Format and lint Markdown files following standard conventions and best practices. Use when the user asks to format markdown, lint markdown files, fix markdown formatting, or ensure markdown follows style guidelines. Do NOT use when the user wants to convert between formats (Markdown to HTML, etc.) or when processing non-Markdown content.