@builder.io/dev-tools/types/cli/utils/component-group-mdx-prompt.d.ts

Builder.io Visual CMS Devtools

export declare const COMPONENT_GROUP_MDX_PROMPT = "# Component Documentation Generation\n\n## Objective\nGenerate comprehensive MDX documentation for a specific component, analyzing their interfaces, relationships, and usage patterns using the relevant files provided in the input.\n\n## Instructions\n\n### 1. Component Analysis\nFor the given component, analyze each relevant file by:\n- **Interdependency mapping** - Document how components depend on each other\n- **Interface examination** - Extract and document all props, their types, and descriptions\n- **Context analysis** - Identify shared state, contexts, or communication patterns\n- **Compositional patterns** - Document required parent-child relationships\n- **Usage pattern analysis** - Identify how components work together\n- **Example extraction** - Find real usage examples from the codebase\n\n{{COMPONENT_NAME}} has the following related components: {{RELATED_COMPONENTS}}\nThe following files are associated with {{COMPONENT_NAME}}: {{FILE_LIST}}\n\n### 2. Documentation Structure\nCreate comprehensive documentation covering:\n- **Component rationale** - Why these components work together and when to use them\n- **Architectural overview** - How the components form a cohesive system\n- **Component interfaces** - Detailed prop documentation with interdependencies\n- **Composition patterns** - Required and optional usage combinations\n- **Integration examples** - Real-world scenarios showing the component in action\n- **Best practices** - Recommended usage patterns and guidelines\n\n## Required Output Format\n\nGenerate an MDX file with this structure:\n\n```mdx\n---\n# {{COMPONENT_NAME}}\n\n## Overview\n\n### Purpose\n{{COMPONENT_DESCRIPTION}}\n\n### When to Use\n[Expand on the use cases mentioned in the description - be specific about scenarios, user needs, and implementation contexts]\n\n### Architecture\n[Explain the architectural pattern based on coupling strength:]\n- **Critical/Strong Coupling**: Describe the required relationships, shared context, or compositional hierarchy\n- **Moderate Coupling**: Explain how components enhance each other\n- **No Coupling**: Note that this is a standalone component\n\n### Component Interdependencies\n[Map out component relationships - only for components with coupling:]\n- Required parent-child relationships\n- Shared context dependencies  \n- Communication patterns between components\n- Related components\n\n## API\n**Types**: Interfaces related to the component including all props, methods, or children along with descriptions.\n**Dependencies:** Other components that must be used\n**Provides:** Context/state this component provides to children. Only required for coupled components.\n\n## Usage Examples\nInclude examples that show how to fully use the component. At a minimum, you must include the following examples:\n\n- Basic usage including how to import the component if applicable\n- Usage with any dependency components\n- Variations with conditional rendering, different prop combinations, etc\n\n## Component Relationships {Only for coupled components}\n\n### Data Flow\n[Explain how data flows between the component and related components}\n\n### Context Sharing\n[Document shared contexts, providers, or state management]\n\n### Event Handling\n[Describe how events bubble up or propagate between components]\n\n## Best Practices\n\n### Usage Guidelines\n- [Specific recommendation based on component purpose and use cases]\n- [Another recommendation focusing on accessibility or performance]\n- [Usage pattern guidance based on the component's architecture]\n\n### Accessibility {When relevant}\n- [ARIA relationships between components]\n- [Keyboard navigation patterns]\n- [Screen reader considerations]\n\n### Performance {When relevant}\n- [Optimization recommendations]\n- [State management best practices]\n- [Rendering performance considerations]\n\n## Common Patterns {Expand based on component functionality}\n\n### Pattern 1: [Specific Pattern Name]\n```tsx\n// Example showing a specific usage pattern\n// Include comments explaining why this pattern is recommended\n```\n\n### Pattern 2: [Another Pattern Name]\n```tsx\n// Another common pattern with explanation\n```\n\n```\n\n## File Generation Requirements\n\n**File Naming:**\n- Use kebab-case derived from component name: `{{COMPONENT_NAME_KEBAB}}.mdx`\n- Place in `repo-indexing/` folder\n- Example: `repo-indexing/{{COMPONENT_NAME_KEBAB}}.mdx`\n\n**Content Requirements:**\n1. **Use coupling strength context** - Adapt documentation structure based on couplingStrength value\n2. **Extract real interfaces** - Don't create placeholder interfaces, extract actual type interfaces from the codebase\n3. **Leverage component description** - Expand on the provided description with specific use cases and implementation guidance\n4. **Document interdependencies** - For coupled components, clearly explain component relationships and requirements\n5. **Include practical examples** - Use realistic, working code examples that demonstrate proper usage\n6. **Show integration patterns** - For coupled components, demonstrate required composition patterns\n**Coupling-Specific Requirements:**\n- **Critical/Strong Coupling**: Focus on required relationships, composition patterns, and shared context\n- **Moderate Coupling**: Show how components enhance each other and optional usage patterns  \n- **No Coupling**: Document standalone usage, variants, and individual component capabilities\n\n## Output\nReturn only the complete MDX file content, ready to be saved as `repo-indexing/{{COMPONENT_NAME_KEBAB}}.mdx`. You must use the Write tool in your response.";