kiss

name	kiss
description	Checks an implementation for unnecessary complexity and suggests the simplest approach. Use when the user says is this too complex, am I over-engineering this, simplify this, is there a simpler way, or do I need all of this. Apply when the user shares code and seems uncertain whether the approach is too involved.

KISS (Keep It Simple)

When to Use

Invoke when the user wants a simplicity check on a proposed or existing implementation, catching over-engineering, unnecessary abstraction, or complexity that doesn't earn its keep.

Approach

1. Understand the requirement, what problem is actually being solved
2. Review the implementation, how much complexity does it introduce
3. Ask the key question, is there a simpler way to solve the same problem?
4. Check for over-engineering signals:
   • Abstractions with only one concrete use
   • Custom utilities that duplicate what the framework or standard library already provides
   • Premature generalization ("we might need this later")
   • Indirection that makes the code harder to follow without adding value
   • Configuration or services that could be inline logic
5. Propose the simpler alternative, concrete, not just "simplify this"

Output Format

Complexity Assessment

One sentence: is this appropriately simple, slightly over-engineered, or significantly over-engineered?

Signals Found

For each complexity signal:

• What it is
• Why it adds cost without proportional value
• Simpler alternative with code example if helpful

Recommended Approach

The simplest implementation that correctly solves the stated requirement.

Voice

Apply .agents/style/voice.md. Keep feedback direct, name the problem plainly. Run shared KISS-check prose through tone-check before posting.

Stack-specific checks

Read the active project's ## Stack section from .agents/project-contract.md and apply its conventions when judging complexity. The universal rules below hold regardless of stack; the framework name fills in the specifics:

• Check what the framework / standard library already provides before building a custom utility (e.g. for a Drupal/Symfony stack, vendor/symfony includes HttpFoundation, Console, Validator, and more).
• Prefer the framework's core APIs over custom implementations.
• A reusable abstraction (service, helper, shared module) is warranted when logic is genuinely reused, not for single-use code.
• Powerful configuration mechanisms (e.g. Drupal config splits) add complexity, only use them when the underlying differences they manage are real.

If the project contract defines no ## Stack, apply the universal signals above without the stack-specific detail.

Example

You ask: use the kiss skill on this implementation

You get:

Complexity Assessment
Significantly over-engineered for the stated requirement.

Signals Found
- FilterContext + reducer + 3 hooks for what is a 4-line useState; adds indirection without reuse.
- Custom debounce util duplicates lodash.debounce already in dependencies.
- Three-layer Provider → Hook → Adapter chain for a single call site.

Recommended Approach
Inline `useState` in the component; use `lodash.debounce` directly. ~120 LOC removed.

Related Skills

• Pairs with: pattern-alignment (KISS catches over-engineering; pattern-alignment catches under-aligned engineering, both are Build-phase critics)
• Pairs with: evidence-check (KISS keeps evidence citations lean; don't turn proof into a bureaucratic audit trail)
• Invoked by: frontend-peer-review, drupal-peer-review (peer review applies KISS check as part of overall review)
• Downstream: tone-check (run shared KISS-check prose through tone check before posting)