eric-mini-coder-max

by ericn26-star

Install this Skill

curl -fsSL -o eric-mini-coder-max.zip https://skill.seembox.com/api/v1/skills/eric-mini-coder-max/download && unzip eric-mini-coder-max.zip

Download eric-mini-coder-max.zip

SKILL.md About

---
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?

_meta.json Metadata

{
  "ownerId": "kn712egma3976f4b68hksznyrs85wsr5",
  "publishedAt": 1777701613163,
  "slug": "eric-mini-coder-max",
  "version": "3.0.1"
}