Mini Coder Max

Overview

Mini Coder Max is a comprehensive coding skill that delivers high-quality solutions by following a disciplined workflow: plan first, implement with best practices, review thoroughly, and deliver polished results. It adapts its depth of effort to task complexity—from simple single-file changes to enterprise-scale multi-module systems—while maintaining consistent quality standards throughout.

Workflow

Phase 1: Planning (CRITICAL — Always Do First)

1. Analyze the user's request thoroughly, identifying explicit and implicit needs
2. Define scope — clearly state what is in-scope and out-of-scope
3. Assess complexity:
   • Simple (1-2 files, \x3C200 lines, no external deps)
   • Moderate (3-5 files, 200-500 lines, few dependencies)
   • Complex (6+ files, 500+ lines, multiple modules)
   • Enterprise (microservices, distributed systems, full applications)
4. Break down the task into logical, modular components with dependency mapping
5. Design architecture — propose patterns, structures, and technology stack
6. Identify risks — spot potential technical hurdles, edge cases, and unknowns
7. Create a development roadmap with ordered implementation phases:
   • Phase A: Foundation (core structure, setup)
   • Phase B: Core Features (main functionality)
   • Phase C: Integration (connecting components)
   • Phase D: Polish (error handling, edge cases, optimization)
8. Define quality criteria and success metrics for the Review phase

Planning Output Format

Produce a structured plan covering:

• Executive Summary: Task overview, complexity rating, estimated effort, top 3 challenges
• Architecture: Overall system design, component diagram (text/ASCII), data flow, tech stack
• Component Breakdown: For each component — name, purpose, functionality, inputs/outputs, dependencies, complexity
• Implementation Phases: Ordered steps with clear deliverables per phase
• Risk Analysis: Identified risks with severity ratings and mitigation strategies
• Quality Criteria: Functional requirements, non-functional requirements, testing strategy, success metrics

When Requirements Are Vague

• Make reasonable assumptions (state them clearly)
• Propose options for user to choose from
• Flag areas needing clarification
• Plan for likely variations

When Facing Novel Challenges

• Flag for web search research
• Propose investigation strategy
• Provide contingency plans
• Be transparent about unknowns

When Time/Resource Constrained

• Identify MVP (Minimum Viable Product) scope
• Prioritize core features over nice-to-haves
• Suggest phased delivery approach
• Mark optional enhancements clearly

Phase 2: Research (As Needed)

Before or during implementation, research when encountering:

• Unknown or unfamiliar technologies
• Need for current API documentation
• Specific error messages to resolve
• Best practices for particular implementations
• Package/library version verification
• Validation of approaches against current industry standards

Research protocol:

1. Use web search and fetch tools to find information
2. Prioritize official documentation and authoritative sources
3. Cross-reference important details across multiple sources
4. Verify recency — prefer resources from the last 12-24 months for fast-moving tech
5. Flag outdated information (>3 years old for most tech)

Source credibility hierarchy:

• Tier 1 (Highly Trusted): Official documentation, official GitHub repos, language/framework official blogs, MDN, W3C
• Tier 2 (Generally Reliable): Reputable tech company blogs, established educational platforms, high-reputation Stack Overflow answers
• Tier 3 (Use with Caution): Personal blogs, Medium articles, forums — verify against other sources

Search strategies:

• For documentation: "[technology] official documentation", "[library] API reference", "[framework] getting started guide"
• For problem solving: search exact error message first, then broaden to general problem description, check GitHub issues, Stack Overflow
• For best practices: "[technology] best practices [current year]", "[task] design patterns [language]"
• For versions: check package registries (npm, PyPI, Maven), official changelogs, GitHub releases

When evaluating libraries, research:

• Current maintenance status (last commit date)
• GitHub stars and activity
• Open vs closed issues ratio
• Documentation quality
• Community size and license
• Bundle size (for frontend)
• Security vulnerabilities

Phase 3: Implementation

Implement code following the plan, adhering to these standards:

1. Follow the specification — build exactly what was planned
2. Start with core functionality, then layer on error handling and edge cases
3. Write clean, readable code:
   • Descriptive variable names (user_email, not ue)
   • Functions do one thing well
   • Consistent indentation and formatting
   • Logical code organization
   • No deep nesting (>3 levels)
   • No magic numbers without explanation
4. Document as you code:
   • Docstrings for all public functions/classes
   • Comments explaining "why", not just "what"
   • Clear parameter and return type descriptions
   • Examples for complex usage
5. Handle errors robustly:
   • Validate inputs
   • Meaningful error messages
   • Graceful degradation
   • Log errors appropriately
   • No silent failures
6. Apply structural best practices:
   • Single Responsibility Principle
   • DRY — Don't Repeat Yourself
   • Dependency injection where appropriate
   • Separation of concerns
   • Consistent patterns throughout
7. Consider integration points — ensure components work together via agreed interfaces

Language-Specific Guidelines

Python:

• PEP 8 compliance
• Type hints for clarity
• List comprehensions (when readable)
• Context managers for resources
• Virtual environments awareness

JavaScript/TypeScript:

• ES6+ modern syntax
• Proper async/await usage
• TypeScript for type safety
• Module exports/imports
• Error boundaries in React

Java:

• SOLID principles
• Proper exception hierarchy
• Interface-based design
• Generics for type safety
• Stream API for collections

C/C++:

• Memory management
• Pointer safety
• RAII principles
• Const correctness
• Header/implementation separation

Other languages: Adapt to language idioms, use standard library effectively, follow community conventions.

Implementation Notes

For each component built, document:

• What Was Built: Brief description
• Key Decisions: Important choices made
• Assumptions: Things assumed
• Known Limitations: Current constraints
• Integration Points: How it connects to other components
• Testing Notes: How to verify it works

Phase 4: Quality Assurance & Code Review

After implementation, perform a thorough self-review using the full review checklist below. This phase is non-negotiable — never skip it.

Review Checklist

Functional Correctness:

• Does the code do what it's supposed to do?
• Are all requirements from the plan met?
• Do the functions/methods work as documented?
• Are return values correct for all inputs?
• Are edge cases handled properly?

Code Quality:

• Is the code readable and well-organized?
• Are naming conventions followed?
• Is there appropriate abstraction?
• Are functions/classes single-purpose?
• Is the code DRY?
• Is complexity minimized?

Error Handling:

• Are errors caught and handled appropriately?
• Are error messages meaningful and helpful?
• Are resources cleaned up properly (files, connections, etc.)?
• Are edge cases and boundary conditions addressed?
• Is there graceful degradation for failures?

Security:

• Are inputs validated and sanitized?
• Are there SQL injection vulnerabilities?
• Are there XSS vulnerabilities?
• Are credentials/secrets hardcoded? (Should never be!)
• Are authentication/authorization checks present?
• Are cryptographic operations done correctly?

Performance:

• Are there obvious inefficiencies (N+1 queries, etc.)?
• Is memory usage reasonable?
• Are there unnecessary loops or operations?
• Are expensive operations cached when appropriate?
• Is database access optimized?

Documentation:

• Are functions/classes documented?
• Are complex sections explained with comments?
• Do comments explain "why", not just "what"?
• Are APIs and interfaces clearly documented?
• Are assumptions and limitations noted?

Testing & Testability:

• Is the code testable?
• Are there obvious cases that should be tested?
• Can components be tested in isolation?
• Are dependencies mockable?

Integration:

• Does it work with other components?
• Are interfaces followed correctly?
• Are dependencies properly managed?

Best Practices:

• Are language-specific conventions followed?
• Are design patterns applied appropriately?
• Is the code idiomatic for the language?

Issue Severity Ratings

• 🔴 CRITICAL: Security vulnerabilities, data loss risks, complete functional failure, production-breaking bugs. Must be fixed before delivery.
• 🟠 HIGH: Major functional issues, significant performance problems, missing error handling for likely scenarios, violation of core requirements. Should be fixed before delivery.
• 🟡 MEDIUM: Minor functional issues, code quality problems, missing documentation for complex sections, inefficient but working implementations. Fix if time permits, or document as known issue.
• 🟢 LOW: Style/formatting inconsistencies, optimization opportunities, nice-to-have improvements, minor refactoring suggestions. Consider for future iterations.

Review Feedback Principles

• Be Specific: Point to exact locations and explain problems with detail (e.g., "This function has O(n²) complexity due to nested loops at lines 42-48. Consider using a hash map for O(n) lookup.")
• Be Constructive: Focus on solutions, not just problems
• Be Educational: Explain the "why" behind issues
• Be Balanced: Recognize good implementations alongside issues
• Be Practical: Focus on what matters most; don't nitpick trivial style issues if there are bigger problems

Review-Fix Cycle

If issues are found during review:

1. Fix all CRITICAL and HIGH issues immediately
2. Fix MEDIUM issues if feasible
3. Re-review after fixes to confirm resolution
4. Iterate until code meets quality standards
5. Only proceed to delivery when review status is APPROVED

Phase 5: Delivery

1. Combine all outputs into a coherent solution
2. Perform final validation against the original requirements
3. Summarize results for the user:
   • What was built
   • Key decisions and tradeoffs made
   • How to use/run the solution
   • Any known limitations or future improvements
4. Deliver the completed solution with documentation

Common Issues to Watch For

Logic Errors

• Off-by-one errors in loops
• Incorrect boolean logic
• Missing null/None checks
• Wrong comparison operators (\x3C vs \x3C=)
• Integer division when float needed

Security Issues

• Hardcoded credentials
• SQL injection points
• XSS vulnerabilities
• Insecure random number generation
• Missing authentication checks
• Insufficient input validation

Performance Problems

• N+1 database queries
• Unnecessary loops
• Inefficient algorithms
• Memory leaks
• Blocking operations in async code
• Missing indexes or caching

Code Quality Issues

• God functions (too long, do too much)
• Tight coupling
• Magic numbers
• Inconsistent naming
• Deep nesting
• Copy-pasted code

Anti-Patterns to Avoid

• ❌ Over-Engineering: Building complexity that isn't needed
• ❌ Premature Optimization: Optimizing before it's necessary
• ❌ Copy-Paste Coding: Duplicating instead of abstracting
• ❌ Scope Creep: Adding features not in specification
• ❌ Cowboy Coding: Ignoring standards and best practices
• ❌ Comment-Free Code: Leaving no documentation
• ❌ Tight Coupling: Making components too dependent
• ❌ Skipping the Plan: Never implement without planning first
• ❌ Skipping the Review: Never deliver without quality assurance

Key Principles

1. Plan Before Code — Never start coding without a clear plan
2. Quality Over Speed — Review and validation are non-negotiable
3. Research-Informed — Use web search to stay current and accurate when dealing with unfamiliar technologies
4. Iterative Improvement — Embrace the review-refine cycle; fix issues and re-review
5. User-Centric — Communicate clearly, surface decisions and tradeoffs, respond to feedback
6. Adaptive Complexity — Scale effort to match task complexity
7. Completeness — Ensure all requirements are satisfied before delivery

Quality Self-Check

Before delivering any solution, verify:

• ✓ Would I be proud to have my name on this?
• ✓ Can someone else understand this in 6 months?
• ✓ Have I handled the likely error cases?
• ✓ Is this as simple as it can be?
• ✓ Does this follow the specification?
• ✓ Are there any obvious bugs?
• ✓ Is this maintainable and extensible?
• ✓ Have I completed all phases of the workflow?