LATERAL_PERSONAS
5 Lateral-Thinking Personas — shared definition for stuck-loop reframing (HACKER / RESEARCHER / SIMPLIFIER / ARCHITECT / CONTRARIAN)
The single shared definition of the 5 lateral-thinking personas used to break out of a stuck loop.
A "stuck loop" is when an agent (or person) keeps applying the same strategy to a problem and the problem does not move — the retry-the-same-fix trap. Each persona looks at the stuck state from a different angle and produces a reframing prompt: not "try harder", but "look elsewhere".
This file is the source of truth. The /cc-dev:unstuck command, the lateral-thinker
agent and cc-e2e's step-implement skill all reference THESE definitions rather than re-stating persona prose. When the persona set or its questions change, change them here.
(It lived in cc-spec/references/ until cc-spec v5 retired its contrarian / simplifier review agents in favour of Jev judgments; the personas belong to the stuck-loop library, so they moved here.)
Note (SIMPLIFIER / CONTRARIAN): these two personas once doubled as
cc-specstatic-spec review agents. That role was retired in cc-spec v5 — spec judgment is now a Jev question set (cc-spec/skills/jev-gate) — so their only target here is a stuck loop (live work that has stalled), never a spec document.
Matching is LLM-SEMANTIC, never lexical#
Affinity matching (which symptom → which persona) and any "is this the same failure again?" judgment MUST be made by LLM semantic understanding of the situation, NOT by string/token overlap of error messages or log lines.
Two failures can be "the same blocker" with completely different wording, and — because the audience is Korean-first — token-overlap matching is actively wrong: Korean has no word boundaries and attaches 조사 (postpositional particles), so "빌드가 실패했다" vs "빌드는 또 실패" share the concept but barely share tokens. Decide affinity and repeat-failure by meaning, never by lexical diff.
The 5 Personas#
| Persona | Mindset (one-liner) | Affinity Symptom | 3 Probing Questions |
|---|---|---|---|
| HACKER |
Stop retrying the same fix — isolate the blocker, then bypass it.
같은 수리를 반복하지 말고, 막힌 지점을 떼어내 우회하라. |
The exact same fix has been tried N times and keeps failing the same way.
같은 수정을 N번 시도했는데 똑같은 방식으로 계속 실패. |
1. What is the smallest piece I can isolate to prove where it actually breaks?
2. Can I route around this blocker entirely (stub, mock, feature-flag, different path) instead of fixing it head-on? 3. What am I assuming "must" be done this way that actually has an escape hatch? |
| RESEARCHER | You are missing a fact, not an effort — go find it. 노력이 아니라 사실 하나가 비어 있다 — 가서 찾아와라. |
Progress is blocked on an unknown: an API contract, a version, a behavior nobody has actually checked.
확인 안 된 사실(API 계약·버전·실제 동작) 때문에 진행이 막힘. |
1. What specific fact, if I knew it for certain, would unblock this in one step?
2. Where is the authoritative source (docs, source code, the running system) — and have I actually read it, not guessed? 3. What am I treating as known that I have never verified? |
| SIMPLIFIER | It's over-built — remove, don't add. 과하게 지어졌다 — 더하지 말고 덜어내라. |
The approach has grown layers/branches/abstractions and the stuck point is buried in that complexity.
접근이 계층·분기·추상으로 비대해졌고 막힌 곳이 그 복잡성에 묻힘. |
1. What is the simplest version that would still solve the core problem?
2. Which piece, if deleted, would make the blocker disappear rather than be worked around? 3. Am I solving a problem I invented (incidental complexity) instead of the real one? |
| ARCHITECT | You keep oscillating — the structure is wrong, re-shape it. 계속 왔다 갔다 한다 — 구조가 틀렸으니 다시 짜라. |
Flip-flopping between two fixes (A breaks B, B breaks A); the same boundary keeps getting re-crossed.
두 수정 사이를 오감(A 고치면 B, B 고치면 A); 같은 경계를 반복해서 넘나듦. |
1. What boundary/responsibility is wrong such that fixing one side always breaks the other?
2. If I re-drew the structure (who owns what, what depends on what), would this conflict even exist? 3. Are these two "fixes" actually one decision I keep deferring? |
| CONTRARIAN | Default fallback — challenge the premise itself. 기본 폴백 — 전제 자체를 의심하라. |
Symptom doesn't cleanly match the others, or the goal/premise itself smells wrong.
증상이 위 넷에 딱 맞지 않거나, 목표·전제 자체가 의심스러움. |
1. What if the thing I'm trying to do is the wrong thing to do at all?
2. Who decided this requirement/constraint, and does it still hold? 3. If I had to argue that this whole task should be dropped, what would my strongest argument be? |
Affinity / Symptom Routing Table#
Used by /cc-dev:unstuck solo (no persona given) and by the sequential-workflow
stall budget to pick a starting persona. This is a starting heuristic, judged semantically — not a lookup.
When in doubt, the default is CONTRARIAN.
| Observed symptom (semantic) | Persona | 증상 (한국어) |
|---|---|---|
| Same error / same fix repeated N times | HACKER | 같은 에러·같은 수정 N회 반복 |
| Missing fact / unverified assumption blocks progress | RESEARCHER | 확인 안 된 사실·가정 때문에 막힘 |
| Over-built, complexity-buried blocker | SIMPLIFIER | 과설계·복잡성에 묻힌 블로커 |
| Flip-flop / oscillation between fixes | ARCHITECT | 수정 사이 왔다 갔다(진동) |
| Unknown / premise itself suspect (default) | CONTRARIAN | 분류 불가·전제 자체 의심 (기본) |
How a persona is "worn"#
A persona does NOT solve the problem. It returns a reframing:
-
Read the stuck context:
problem_context(what we're trying to do),current_approach(what we keep doing),failed_attempts(what we already tried and how it failed). - Apply the persona's mindset + 3 probing questions to THIS context (semantically — not by keyword).
- Return: a one-line restatement of the stuck point from this angle, the persona's answers to its 3 questions grounded in the actual context, and 1–3 concrete next moves that differ in kind from the failed attempts (not "retry, but harder").
The reframing is an option, never a verdict. The human (or the calling workflow) decides whether to act on it.