Mini Coder Max

---

name: mini-coder-max description: "Autonomous coding agent that systematically plans, implements, reviews, and delivers high-quality code. Handles tasks of any complexity by following a structured workflow: planning → implementation → quality assurance → delivery. Trigger keywords: code, build, implement, create, develop, fix, refactor, architect."

---

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, <200 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 (< vs <=)

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?