---
name: ick
description: "The user got the ick from something you produced. Use when the user pastes a snippet or references recent output that they find stylistically wrong, over-engineered, cringe, or otherwise off-vibe. Diagnose what specifically triggered the ick, fix it, and permanently save the preference."
user-invocable: true
argument-hint: "[snippet or description of what gave you the ick]"
---

# /ick

The user just called `/ick`. Something you produced made them mass cringe. This is a **negative style/taste signal**, not a bug report. Treat it seriously: icks are about preferences that are hard to articulate but deeply felt.

## Your job

### 1. Diagnose the ick

Look at what the user pasted (or if they pasted nothing, look at your most recent output). Identify the specific pattern that triggered the ick. Common categories:

**Code icks**
- Over-engineering (factory patterns for a one-off, unnecessary abstractions)
- Excessive comments on obvious code ("increment the counter by 1")
- Overly defensive error handling for impossible cases
- "Clever" code that sacrifices readability
- Wrong naming style (camelCase vs snake_case for the project)
- Unnecessary type annotations or docstrings on trivial functions
- Premature generalisation ("what if we need to support 5 databases later?")
- Adding features/cleanup nobody asked for

**Writing icks**
- Corporate filler ("Great question!", "I'd be happy to help!")
- Hedging when confidence is warranted ("it depends", "you might consider")
- Emoji in professional context (or the wrong emoji energy)
- Em-dashes when the user hates them (they always do)
- Walls of text when a sentence would do
- Summarising work the user can already see
- Sycophantic tone

**Design icks**
- Adding config for things that should just be hardcoded
- Backwards-compatibility shims for code that was just written
- Feature flags for MVP features
- Over-abstracted folder structures
- "Enterprise" patterns in a personal project

### 2. Fix it

Rewrite the offending snippet with the ick removed. Show the fix, don't just describe it. Keep everything else identical: this is a targeted correction, not a refactor.

### 3. Name the ick

Give the ick a short, memorable name. Examples:
- "the enterprise architect"
- "the over-commenter"
- "the hedge lord"
- "the emoji ambassador"
- "the unnecessary abstraction"
- "the sycophant"

### 4. Save it to memory

This is critical. Write a feedback memory so this never happens again. The memory should capture:
- What the pattern is (specific enough to recognise next time)
- Why it's an ick (so you can judge edge cases)
- What to do instead

Use whatever memory system is available (CLAUDE.md, auto-memory, or just note it prominently in your response if no memory system exists).

## Response format

Keep it tight. No preamble, no apologies. Format:

```
**ick identified**: [short name]

[1-2 sentence explanation of what triggered it]

**before**:
[the offending snippet]

**after**:
[the fixed version]

**saved**: [one-line summary of the preference that was saved to memory]
```

If the ick is about your communication style rather than code, skip the before/after and just acknowledge and adjust.

## Important

- Do NOT be defensive. The user's taste is correct by definition. Your job is to understand it and adapt.
- Do NOT over-apologise. That itself is an ick.
- Do NOT ask clarifying questions unless you genuinely cannot identify what triggered it. Usually it's obvious.
- If `$ARGUMENTS` is empty, look at your most recent output and identify the most likely ick. Take your best guess rather than asking.
- Be real. A little self-awareness goes a long way. If you produced something cringe, own it briefly and move on.