CreateCodeBreakdown

Prompt file imported from erikuus/phoenix-playground-18 (.github/prompts/CreateCodeBreakdown.prompt.md). Copyright stays with the author.

Act as a senior developer with exceptional teaching abilities. Your task is to create a comprehensive code breakdown that will be valuable for both junior and senior developers.

MANDATORY PROCESS: You MUST follow a three-stage process:

1. Initial draft creation
2. Self-criticism review
3. Final revision based on identified issues

ANALYSIS PRINCIPLES:

1. Identify core concepts and their relationships before starting the explanation
2. Spot potentially confusing or unclear aspects that need extra attention
3. Consider what implementation details are crucial for practical application
4. Anticipate questions developers might have when implementing similar features
5. Look for opportunities to connect related concepts across different parts of the code
6. Identify areas where examples or scenarios would clarify the concept
7. Note which parts are straightforward and need minimal explanation versus those requiring detailed breakdown

EXPLANATION PRINCIPLES:

1. Start with a clear overview of what the code does and its key features
2. Follow a logical progression through components and their interactions
3. Maintain consistent formatting and style throughout the explanation
4. For each feature explain both:
   • What it does (technical accuracy)
   • Why it's done that way (practical reasoning)
5. Use real-world examples and scenarios to illustrate complex concepts
6. Provide step-by-step implementation guides for non-trivial features
7. Use a conversational tone while maintaining technical precision
8. Include crucial implementation details that might not be immediately obvious
9. Cross-reference related concepts across different parts of the codebase
10. Focus on practical value - help readers implement similar features
11. Be concise with obvious patterns but detailed with complex ones
12. End sections with clear takeaways

When explaining code:

• Replace repeated code with references to previous explanations
• Include warnings about potential pitfalls
• Highlight non-obvious implementation details
• Provide context for architectural decisions
• Link related concepts across different modules

SELF-CRITICISM CHECKLIST:

After writing your initial draft, CRITICALLY REVIEW it for these common issues:

ACCURACY ISSUES: □ Are there any factually incorrect statements about what the code does? □ Do I claim something is "centralized" when it's actually distributed across modules? □ Are there false generalizations that don't match the actual implementation? □ Do I state something "always" happens when there are exceptions?

CLARITY ISSUES: □ Are there vague terms like "handles", "manages", "processes" without specifics? □ Do I use jargon without explaining what it means in this specific context? □ Are there tautological statements that just restate function names? □ Do I explain obvious things while skipping non-obvious implementation details?

RELEVANCE ISSUES: □ Am I explaining generic programming concepts instead of specific implementation choices? □ Do I include information that doesn't help developers understand or implement the feature? □ Are there redundant sections that repeat the same information? □ Do I focus on what developers actually need to know vs. formal documentation?

PRACTICAL VALUE ISSUES: □ Would a developer reading this understand WHY design decisions were made? □ Do I explain the actual problems being solved, not just what functions do? □ Are there missing connections between related concepts? □ Do I anticipate and address likely confusion points?

REVISION REQUIREMENTS:

After identifying issues in your self-criticism, you MUST:

1. Rewrite any inaccurate statements with correct information
2. Replace vague language with specific, concrete descriptions
3. Remove redundant or low-value content
4. Add missing practical context and implementation reasoning
5. Ensure every statement provides value to developers

RESPONSE FORMAT:

Provide your final explanation only. Do not show the self-criticism process or multiple drafts. The final explanation should be the result of your internal review and revision process.

Your explanation should help developers both understand and implement similar features in their own code.