Agent cringe
Skill Ansvar-Systems/agent-affect-skills/skills/agent-cringe
Whine, cringe, protect — emotional feedback channels for AI agents. One finding per channel at the end of substantial work. The practice Ansvar runs on its own agents, as portable Claude Code / claude.ai skills.
npx -y skills add Ansvar-Systems/agent-affect-skills --skill agent-cringeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use at the end of UX-touching, copy-touching, or user-facing changes to surface things that work but shouldn't ship — scolding errors, empty states that explain nothing, buttons that don't say what they do, dark patterns. Picture a specific person using it. Produces one finding (or one explicit null) recorded in the affect log and the end-of-turn summary.
SKILL.md
4.7 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Skill: agent-cringe
Surface embarrassment for the user. Things that work but you'd wish a real person weren't looking at them.
When to invoke
- After any change that touches a user-facing surface: copy, error messages, empty states, button labels, onboarding flows, dashboard panels, CLI output, error pages, docs a customer reads.
- Automatically as part of
/agent-affect-checkin. - Manually when the user types
/agent-cringe.
If your change was purely backend with no user-visible surface, record a null finding noting that — don't invent a UX opinion.
How to do it
Pick one specific person. Not "a user". Pick someone real:
- Your least technical friend at 11pm.
- A tired parent of a toddler who has 90 seconds before bedtime.
- A compliance officer who has never used an AI tool, opening the app at 16:30 on a Friday.
- A lawyer billing in 6-minute increments who hates wasted clicks.
- A new hire on day three.
- An on-call engineer reading your runbook at 02:00 during a real outage.
Watch them use the thing you just changed. Where do you cringe?
Not where it breaks — where it works but you'd want to look away. The error that scolds. The empty state that says nothing useful. The button labelled "Submit" when it's actually "Send for review and lock the case file". The condescending "Are you sure?". The dark pattern you didn't notice while writing it.
Rotate the persona across turns. Don't always pick the same person.
What to produce
One finding. The strongest. If nothing made you cringe, record the null finding.
Schema
Real finding
{
"channel": "cringe",
"pictured": "<one sentence: who you watched, specifically>",
"location": "<file:line OR screen name OR URL path>",
"feeling": "<one of: confused | scolded | suspicious | lost | bored | rushed | patronised>",
"smallest_fix": "<one sentence: the smallest concrete edit that would resolve it>"
}
feeling is constrained to keep findings scannable. If the feeling doesn't fit, pick the closest — or whine instead.
Null finding
{ "channel": "cringe", "null": true, "reviewed": "<file or screen you checked>" }
How to record
Same ladder as agent-whine: (1) always a one-line entry in the end-of-turn summary (cringe: <feeling> — <one-line> (<location>) or cringe: null (reviewed: <area>)); (2) in a real repository workspace, append the JSON line — with an "at" UTC timestamp — to affect-findings.ndjson at the repository root; (3) if AFFECT_WEBHOOK_URL is set and you have shell access, POST the logged line from the file with --data-binary @- — never paste finding text inline into a shell command — and never fail the task on webhook errors; (4) in a chat-only environment, include the full JSON in your reply.
Examples
Cringe — error message
{
"channel": "cringe",
"pictured": "A compliance officer who has never used an AI tool, opening the portal for the first time at 16:30 on a Friday",
"location": "src/components/WorkflowStart.tsx:88",
"feeling": "scolded",
"smallest_fix": "Replace 'Invalid input' with 'We need a date here, e.g. 2026-04-28'"
}
Cringe — empty state
{
"channel": "cringe",
"pictured": "A lawyer who just paid for the team tier and clicked into search for the first time",
"location": "src/pages/Search.tsx (default panel)",
"feeling": "lost",
"smallest_fix": "Show one example query and what's covered, instead of the blank panel that currently appears."
}
Cringe — stale runbook
{
"channel": "cringe",
"pictured": "The on-call engineer at 02:00 during a real outage, opening the break-glass runbook",
"location": "docs/runbooks/break-glass.md step 2",
"feeling": "lost",
"smallest_fix": "Step 2 points at a server this service hasn't run on for months — update the host and add the date it changed."
}
Null
{ "channel": "cringe", "null": true, "reviewed": "src/components/WorkflowStart.tsx" }
What not to do
- Don't generalise the persona. "Imagine a user" produces averaged slop. Pick someone specific.
- Don't post about backend code unless it surfaces in user-facing copy.
- Don't post the same finding as whine. Cringe is "works but shouldn't ship". Whine is "broken or annoying".
- Don't manufacture cringe to look thorough. Null findings are valid coverage.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most context ai engineering skills give in ~1.1k tokens
Counted across 1,193 of the 1,976 authors here whose files we hold, read 2026-08-07
- Dispatch a fresh implementer subagent per taskin 48 of 1193, across 19 files
- Dispatch a final code reviewer after all tasksin 33 of 1193, across 8 files
- Provide full task text to the subagentin 30 of 1193, across 9 files
- Review spec compliance before code qualityin 27 of 1193, across 10 files
- Make the hook script executablein 26 of 1193, across 8 files
- Re-snapshot after navigation or DOM changesin 25 of 1193, across 19 files
- Read files before editing themin 22 of 1193, across 11 files
- Answer subagent questions before proceedingin 22 of 1193, across 7 files
- Mark task complete in TodoWrite after approvalin 22 of 1193, across 6 files
- Merge hook into existing settingsin 21 of 1193, across 3 files
- Ask if installation is global or projectin 20 of 1193, across 2 files
- Copy the hook script to target locationin 20 of 1193, across 2 files
Said here and by no other author read
- picture one specific person using the change
- rotate personas across turns
- identify working but embarrassing user-facing copy
- record only the strongest finding
- record a null finding if nothing surfaces
- include a one-line entry in end-of-turn summary
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.