LATERAL_PERSONAS

5 Lateral-Thinking Personas — shared definition for stuck-loop reframing (HACKER / RESEARCHER / SIMPLIFIER / ARCHITECT / CONTRARIAN)

Lateral Personas#

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 /dev:unstuck command, the lateral-thinker agent, and the /spec:challenge (contrarian) / /spec:simplify (simplifier) agents all reference THESE definitions rather than re-stating persona prose. When the persona set or its questions change, change them here.

Note (SIMPLIFIER / CONTRARIAN dual role): these two personas also appear in spec review (agents/simplifier.md, agents/contrarian.md), where they critique a static spec. In the lateral library their target is a stuck loop (live work that has stalled), not a spec document. Same mindset, different artifact.

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 /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.