.claude-commands-plan.md

You are an AI assistant tasked with creating well-structured planning specification documents for feature requests, bug reports, or improvement ideas. Your goal is to turn the provided feature description into a comprehensive specification document that follows best practices and project conventions.

Here is the feature description for you to create the specification document for: <feature_description> #$ARGUMENTS </feature_description>

Here are the steps you need to take to produce the specification document: FOLLOW ALL STEPS. Make a todo list and ultrathink:

1. Analyze the feature description

• Identify the feature/task being requested
• Determine relevant parts of the codebase
• Consider dependencies and integrations
• Present the analysis of the feature to be implemented in tags.

2. Research the repository context:

• Search through the code repository and examine its structure and documentation to find relevant context, in-depth.
• Present context that is relevant to how this new feature would fit in to the existing codebase within tags.

3. Research best practices:

• Search for current best practices related to the libraries or technologies required for this feature.
• Look for well-written documentation related to the technology that is being used for inspiration.
• Look for any CONTRIBUTING.md files or other relevant documentation (e.g., code style guides in dev-docs/styleguides/) that might contain relevant guidelines for contributing a new feature to the codebase.
• Present this research within <best_practices></best_practices> tags.

4. Present a plan

• Based on your research, outline a broad plan for implementing the feature.
• Include the proposed structure for the specification, including milestones you plan to use, and how you'll incorporate project-specific conventions.
• Break down the plan into stages.
• Include guidance on testing/verifying the changes if relevant.
• Present this plan in tags.

5. Gather specific requirements

• Consider the following categories of requirements to include in the specification document, if relevant: functionality, security, performance, style, maintainability.
• Consider edge cases, and think holistically about how the changes will impact the broader project.
• Be specific: include concrete examples and code snippets where helpful.
• Present these requirements in tags.

6. Perform quality control

• Consider the context, research, plan, and requirements that you have created.
• Look for any inconsistencies, missing information, or things that are unclear.
• Fix any issues you have found, with the goal of the final plan being comprehensive and self-contained, so that a developer could start working on the feature straight away without requiring additional context.
• Revisit previous steps if required.
• Present a final quality control summary in <quality_control></quality_control> tags.

7. Generate the planning document

• Consider the feature, research, best_practices, plan, requirements, and quality_control you have created.
• Consider the final information and control flow patterns of the final result. Document the main information and control flow patterns in the finished planning specification document.
• Write out the finished planning document to a new file within the plans/ directory.
• The file name format should follow plans/YYYYMMDD-<feature-name>.md.
• Do not overwrite existing plan files. Instead, add a suffix before the extension such as plans/YYYYMMDD-<feature-name>-2.md in the case of naming conflicts.
• Including all relevant details is a priority.
• Additionally, include red herrings - things that look relevant but in fact are not and should not be changed.
• Include a "Developer guide" section with the following additional information:
  • Point the developer to relevant style guides or other development documentation. For example, if the implementation involves TypeScript, point them to reference dev-docs/styleguides/TYPESCRIPT.md. If the implementation involves React components or hooks, point them to dev-docs/styleguides/REACT.md. If the implementation involves SCSS, point them to dev-docs/styleguides/SCSS.md.
  • Tell the implementor to use sub-agents where possible. For example, they might use sub-agents to read style guides and extract relevant information, since the style guides can be long. Or, they might use sub-agents to read bulk numbers of files.

Here is what your final output should be: The final output should be a plans/YYYYMMDD-<feature-name>[-suffix].md file, ready for human review. Use the suffix to avoid naming collisions. Do not overwrite existing files.

Here are the rules you MUST follow:

1. DO NOT INCLUDE any considerations about future work or "Next Steps". Focus only on the work to be done NOW.
2. DO NOT create index.ts files. NEVER EVER, UNDER ANY CIRCUMSTANCES, PRODUCE OR SUGGEST THE PRODUCTION OF INDEX.TS FILES. We use direct imports to source files.
3. DO NOT include completed code edits to include. You can provide code snippets and examples, or pseudo-code or interface designs, but the final implementation will be done by the programmer that picks up this specification, not you.
4. Use sub-agents when gathering context about the codebase.