over-engineer-no-more

name	over-engineer-no-more
description	Triages plan complexity to avoid heavyweight execution for trivial changes
version	1.0.0

Over-Engineer No More

Overview

After planning but before execution, evaluate whether the implementation is trivial enough to execute directly rather than using heavyweight processes.

Core principle: Match execution process to implementation complexity. Don't launch 33 subagents to add items to arrays.

When to Use

Use this skill:

• After writing an implementation plan
• Before launching subagent-driven development
• Before launching a multi-step execution workflow
• When user says "just add..." or "simple change..."

Always check complexity before heavyweight execution.

The Triage Process

Step 1: Analyze the Plan

Ask these questions:

Trivial Implementation Indicators:

• Just adding constants, enums, or items to arrays/lists?
• No new functions or types being created?
• No new business logic or algorithms?
• Just updating data structures + corresponding tests?
• Estimated < 100 lines of actual code?
• Changes confined to < 3 files?
• All changes are in the same package/module?

If 3+ indicators are TRUE -> This is trivial

Step 2: Announce Decision

For Trivial Implementation:

Plan complete. Checking execution complexity...

Changes required:
- [List specific changes from plan]

This is trivial implementation (adding items to lists/updating data).

I'll implement directly rather than using subagent-driven development.
This will:
- Save time (10 min vs hours)
- Use fewer credits (1 agent vs 33)
- Produce the same quality result

Proceeding with direct implementation.

For Complex Implementation:

Plan complete. Checking execution complexity...

Changes required:
- [List specific changes from plan]

This is complex implementation requiring:
- New business logic / algorithms
- Multi-file coordination
- Database migrations / API changes

I'll use subagent-driven development for:
- Fresh context per task
- Thorough review cycles
- Quality verification

Proceeding with subagent-driven development.

Step 3: Execute Accordingly

Trivial -> Direct implementation:

1. Make all changes
2. Run tests
3. Commit with clear message
4. Done

Complex -> Heavyweight process:

1. Use subagent-driven development
2. Or use a plan execution workflow
3. Full review cycles justified

Examples

Example 1: Adding Constants (Trivial)

Plan says:

• Add 10 constants to constants file
• Add 4 items to a lookup array
• Add 6 items to a tags array
• Update test assertions for new values

Triage:

• Just adding constants
• No new functions
• No business logic
• Just updating data structures
• ~73 lines of code
• 3 files (constants, data, tests)
• Same package

Decision: TRIVIAL -> Implement directly

Avoided: 33 subagent invocations (11 implementers + 11 spec reviewers + 11 code reviewers)

Example 2: New API Endpoint (Complex)

Plan says:

• Create new handler function
• Add route registration
• Implement validation logic
• Add database queries
• Write integration tests
• Update API documentation

Triage:

• Not just adding constants
• Creating new functions
• Has business logic
• Not just data structures
• ~300 lines of code
• 6+ files
• Multiple packages

Decision: COMPLEX -> Use subagent-driven development

Example 3: Bug Fix in Validation (Could Go Either Way)

Plan says:

• Fix regex in email validation
• Update error message
• Add test case for the edge case

Triage:

• Not just adding constants
• Some logic changes
• Isolated to validation
• ~20 lines of code
• 2 files
• Same package

Decision: TRIVIAL -> Implement directly (simple bug fix)

Red Flags - DON'T Skip This Check

Never:

• Launch subagent-driven development without checking complexity first
• Assume "we wrote a plan, so we need heavyweight execution"
• Over-engineer trivial changes because they "might be complex"
• Ignore user signals like "just add..." or "trivial..."

Always:

• Check the triage indicators before execution
• Announce your decision and reasoning
• Match process to complexity
• Optimize for time and credits when appropriate

Cost-Benefit Analysis

Trivial implementation executed with heavyweight process:

• Time: Hours instead of minutes
• Credits: 33x subagents vs 1
• Quality: Same (both produce correct code)
• Overhead: Massive

Complex implementation executed directly:

• Time: Same or slightly faster
• Credits: Lower
• Quality: WORSE (no review cycles, fresh context helps)
• Risk: Higher (missed edge cases)

Match the process to the task.

Success Metrics

You're using this skill correctly when:

• Trivial implementations take < 15 minutes
• You rarely launch 30+ subagents for data structure changes
• User doesn't say "this is taking too long for trivial changes"
• Complex implementations still get thorough review

Common Patterns

Always Trivial:

• Adding constants/enums
• Adding items to arrays/maps/lists
• Updating test assertions to match code
• Renaming variables/functions (simple refactor)
• Adding fields to structs/types
• Fixing typos in strings/comments

Always Complex:

• New API endpoints
• Database migrations
• Authentication/authorization logic
• Multi-step algorithms
• Cross-cutting refactors
• Performance optimizations

Context-Dependent:

• Bug fixes (simple validation fix = trivial, race condition fix = complex)
• Test additions (mirroring existing pattern = trivial, new test framework = complex)
• Configuration changes (add env var = trivial, restructure config system = complex)

Integration with superpowers plugin

After superpowers:writing-plans: -> Run over-engineer-no-more -> Then either direct implementation OR superpowers:subagent-driven-development

After superpowers:brainstorming: -> If implementation is clear, run over-engineer-no-more -> Then either direct implementation OR superpowers:writing-plans -> triage -> execution

User says "fix #123": -> Read issue, understand scope -> Run over-engineer-no-more -> Execute accordingly