| name | kiss-principle |
| description | Apply the K.I.S.S principle (Keep It Simple, Stupid) to reduce complexity, improve maintainability, and solve problems elegantly. Use when designing systems, writing code, planning solutions, creating documentation, architecting features, or making decisions where simplicity drives quality and efficiency. |
| version | 1 |
K.I.S.S Principle Orchestration Skill
This skill helps you apply the K.I.S.S principle—"Keep It Simple, Stupid"—to systematically reduce unnecessary complexity while maintaining functionality and effectiveness. Simplicity is not about removing necessary features; it's about eliminating unnecessary complications.
Quick Reference: When to Load Which Resource
| Your Situation | Load Resource | Why |
|---|
| Need to understand KISS fundamentals and why simplicity matters | resources/kiss-fundamentals.md | Learn core concepts, history, and empirical benefits |
| Reviewing code, design, or system for unnecessary complexity | resources/complexity-analysis.md | Identify complexity sources, anti-patterns, red flags |
| Want proven strategies to simplify solutions | resources/simplification-strategies.md | Learn 10+ actionable techniques with software/UX examples |
| Building or designing something new with KISS in mind | resources/kiss-driven-design.md | Apply KISS during design, architecture, feature planning |
| Comparing simple vs complex approaches | resources/decision-frameworks.md | Use frameworks to evaluate tradeoffs, make smart choices |
| Seeing worked examples of effective simplification | resources/case-studies.md | Real cases: code refactoring, API design, UX improvements |
Core Principle
Simplicity is the ultimate sophistication. — Leonardo da Vinci
The K.I.S.S principle states that most systems work better when kept simple rather than made complex. Unnecessary complexity:
- Increases bugs and maintenance burden
- Makes systems harder to understand and modify
- Reduces performance and reliability
- Wastes development time and resources
- Creates cognitive overload for users and developers
The Goal: Solve problems with the minimum necessary complexity while preserving correctness and user value.
Orchestration Protocol
Phase 1: Assess Your Situation
Quickly identify what you're simplifying and why:
Context Type:
- Code Review/Refactoring: Existing code has unnecessary complexity → Load complexity-analysis.md
- Feature Design: Planning new functionality → Load kiss-driven-design.md
- Architecture/System Design: Building infrastructure or large systems → Load simplification-strategies.md
- Problem-Solving: Finding solution to technical challenge → Load decision-frameworks.md
- UX/Documentation: Improving clarity and usability → Load simplification-strategies.md
- Learning: Understanding KISS principles → Load kiss-fundamentals.md
Complexity Level:
- Light: Minor improvements, small scope → Use simplification-strategies.md directly
- Medium: Significant redesign needed, moderate scope → Use complexity-analysis.md + decision-frameworks.md
- Heavy: Major architectural changes, system-wide complexity → Use all resources systematically
Action: Load appropriate resource file(s) based on situation.
Phase 2: Analyze and Plan
Based on context, follow these steps:
| Step | What to Do | Resource |
|---|
| 1. Identify complexity | What makes this complex? What's unnecessary? | complexity-analysis.md |
| 2. Understand tradeoffs | What are we gaining/losing with each approach? | decision-frameworks.md |
| 3. Select strategies | Which simplification techniques apply here? | simplification-strategies.md |
| 4. Design simply | How would we design this with KISS in mind? | kiss-driven-design.md |
| 5. Verify value | Does the simple solution meet requirements? | decision-frameworks.md |
| 6. Reference examples | How have others solved this simply? | case-studies.md |
Phase 3: Execution & Validation
Before Simplifying:
- Preserve core functionality and requirements
- Document why current complexity exists
- Identify what stakeholders actually need vs. want
- Create rollback plan if needed
During Simplification:
- Remove one layer of complexity at a time
- Verify functionality after each change
- Measure improvement (LOC, cyclomatic complexity, performance)
- Document decisions and rationale
After Simplification:
- Test thoroughly (more bugs often hide in complexity)
- Gather feedback from team and users
- Monitor performance and stability
- Document simpler approach for future reference
Complexity Assessment Framework
Quickly evaluate if something is too complex:
Red Flags - This is Too Complex:
- ❌ You can't explain it in 2-3 sentences
- ❌ It requires extensive documentation to understand
- ❌ New team members struggle to modify it for weeks
- ❌ It has many interdependencies and side effects
- ❌ Performance problems correlate with feature addition
- ❌ Bugs consistently appear in this component
- ❌ It has deeply nested conditionals (>3 levels)
- ❌ Multiple abstractions on top of each other
- ❌ Over-engineered for current and foreseeable needs
Green Flags - This is Appropriately Simple:
- ✅ You can explain it clearly in 1-2 minutes
- ✅ New developers understand it quickly
- ✅ It does one thing well (single responsibility)
- ✅ Dependencies are explicit and minimal
- ✅ It's stable with few bugs
- ✅ Code is readable and self-documenting
- ✅ It serves current needs without speculation
KISS vs Over-Engineering
| Aspect | KISS | Over-Engineering |
|---|
| Scope | Solves current problem | Anticipates future needs |
| Code | ~100-200 LOC | ~500+ LOC |
| Time to Ship | 1-2 weeks | 4-8+ weeks |
| Maintenance | Easy to modify | Complex to change |
| Performance | Good enough | Highly optimized |
| Bugs | Few, obvious | Many, hidden |
| Approach | Add complexity when needed | Remove complexity as possible |
Key Principles to Remember
- Necessity Test: Does every component, line, and feature serve a current user need?
- Clarity First: Clear code beats clever code
- Single Responsibility: Each function/module does one thing well
- Minimal Dependencies: Fewer connections = fewer failure points
- Explicit Better Than Implicit: Code should be obvious, not magical
- Measure Before Optimizing: Don't optimize prematurely
- Refactor Incrementally: Simplify gradually, test continuously
Common Complexity Anti-Patterns
See resources/complexity-analysis.md for detailed analysis of:
- Over-abstraction (too many layers)
- Premature optimization (optimizing before profiling)
- Gold plating (adding nice-to-haves)
- Speculative generalization (over-generalizing)
- Feature creep (scope expansion)
- Accidental complexity vs essential complexity
- Technical debt accumulation
Simplification Strategies
See resources/simplification-strategies.md for 10+ proven techniques:
- Constraint-based design
- Default assumptions
- Removing features
- Consolidating logic
- Flattening architecture
- Eliminating abstractions
- Standardizing approaches
- And more...
Resource Files Summary
resources/kiss-fundamentals.md
Foundation and philosophy:
- KISS principle definition and history
- Why simplicity matters (empirical evidence)
- Simplicity vs complexity tradeoffs
- Principles of effective simplification
- Common misconceptions
resources/complexity-analysis.md
Identifying and understanding complexity:
- Complexity sources and types
- Measuring complexity (cyclomatic, LOC, coupling)
- Identifying unnecessary complexity
- Recognizing over-engineering
- Red flags and anti-patterns
resources/simplification-strategies.md
Actionable techniques for simplifying:
- 10+ proven simplification strategies
- When to apply each strategy
- Code examples in multiple languages
- UX simplification approaches
- Architecture simplification patterns
resources/kiss-driven-design.md
Applying KISS from the start:
- Designing for simplicity
- Requirements gathering with KISS in mind
- Architecture patterns that promote simplicity
- Feature design principles
- Documentation and communication
resources/decision-frameworks.md
Making trade-off decisions:
- Simple vs Complex evaluation framework
- When complexity is justified
- Cost-benefit analysis for features
- Decision trees for architectural choices
- Measuring ROI of simplification
resources/case-studies.md
Real-world examples of successful simplification:
- Code refactoring case studies
- API design simplifications
- Architecture improvements
- UX improvements through simplification
- Decision-making examples
How This Skill Works
- Assess your situation: What are you simplifying and why?
- Analyze complexity: Identify unnecessary complication
- Select approach: Choose relevant strategies and frameworks
- Plan simplification: Design the simpler solution
- Execute carefully: Make changes incrementally, test continuously
- Validate: Confirm the simple solution meets all needs
- Learn: Reference cases and patterns for future decisions
Quick Start: 5-Minute Simplification Check
- Can you explain this in 2 sentences? (If no → too complex)
- What would the simplest possible version look like?
- What complexity is essential? What's optional?
- Could you remove one component without breaking functionality?
- What would new developers struggle with?
Templates & Checklists
- Complexity Assessment Checklist in
resources/complexity-analysis.md
- Simplification Planning Template in
resources/simplification-strategies.md
- Decision Framework Template in
resources/decision-frameworks.md
- Design Checklist in
resources/kiss-driven-design.md
Common Scenarios
Scenario 1: Code Review
→ Load complexity-analysis.md → identify issues → Load simplification-strategies.md → suggest improvements
Scenario 2: Feature Design
→ Load kiss-fundamentals.md → Load kiss-driven-design.md → plan with simplicity in mind
Scenario 3: Architecture Redesign
→ Load complexity-analysis.md → assess current state → Load decision-frameworks.md → evaluate tradeoffs → Load simplification-strategies.md → plan improvements
Scenario 4: Learning from Examples
→ Load case-studies.md → study approaches → Load decision-frameworks.md → understand tradeoffs
Next Steps
- Identify what you're working on (code, design, system, decision)
- Load appropriate resource from table above
- Assess complexity and identify problem areas
- Select simplification strategies or design approaches
- Plan and execute changes incrementally
- Validate that simple version meets all requirements
- Document decisions for team learning
Remember: The goal is solving the problem correctly with minimum necessary complexity. Simplicity requires discipline—resist the urge to over-engineer, and refactor ruthlessly to remove unnecessary complication.
"Everything should be as simple as it is, but not simpler." — Albert Einstein
