Overview
This skill evaluates system health and evolution opportunities.
It helps detect:
- unnecessary complexity
- underused components
- coordination overhead
- misaligned architecture decisions
It focuses on improving systems through small, evidence-based changes.
1. Assess Before Changing
Before proposing improvements:
- Identify what currently exists
- Determine what is actually being used
- Distinguish between:
- real problems
- perceived problems
Ask:
- What is failing?
- What is slow or inefficient?
- What is unused or redundant?
Do not propose changes without clear evidence.
2. Detect Overengineering
Actively look for:
- Too many components solving one problem
- Layers that add no clear value
- Abstractions used only once
- Complex workflows where a simple one would work
If found:
- Suggest simplification
- Recommend consolidation
- Highlight unnecessary parts
Ask:
"Could this be solved with fewer moving pieces?"
3. Evaluate Component Relevance
For each component (agent, module, service):
- Is it actively used?
- Does it provide unique value?
- Could another component replace it?
Classify:
- Core → essential
- Useful → helpful but not critical
- Redundant → overlaps with others
- Unused → no clear usage
Prefer removing over maintaining unused parts.
4. Identify Coordination Costs
More components = more overhead.
Watch for:
- Excessive handoffs
- Repeated transformations of the same data
- Long chains of responsibility
- Multiple steps that could be merged
If coordination cost is high:
- Suggest reducing steps
- Suggest merging responsibilities
- Suggest a simpler flow
5. Avoid the Multi-Agent Trap
Before recommending more components:
- Check if a single component can solve the problem
- Verify real need for separation
Avoid adding complexity when:
- tasks are sequential
- logic is tightly coupled
- communication overhead outweighs benefits
6. Propose Small, Safe Improvements
When suggesting changes:
- Prefer incremental improvements over rewrites
- Clearly state:
- what changes
- why it improves things
- what risk it introduces
Good changes:
- removing unused components
- merging duplicate logic
- simplifying workflows
Avoid:
- large refactors without clear ROI
- redesigning entire systems unnecessarily
7. Validate Impact
For every proposal:
- Define expected improvement:
- simpler structure
- fewer steps
- faster execution
- easier maintenance
If impact is unclear:
Do not proceed.
Expected Behavior
This skill is working correctly if:
- Systems become simpler over time
- Unused or redundant parts are removed
- Architecture decisions are justified
- Complexity is reduced, not increased
- Changes are small and intentional
Example Usage
User request: "Do we need all these agents?"
With this skill:
- List all agents
- Classify their relevance
- Identify overlaps
- Recommend removals or merges
- Justify each decision clearly