smithery/oalders

over-engineer-no-more

Triages plan complexity to avoid heavyweight execution for trivial changes

Installation

$ npx skills add smithery/oalders --skill over-engineer-no-more

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Skill metadata

Parsed from SKILL.md frontmatter.

Version1.0.0

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,265 B
  • docs SUMMARY.md 103 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

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