Parallel thinking with six enforced perspectives, based on Edward de Bono's Six Thinking Hats® method - examine one decision through sequential passes for facts, feelings, risks, benefits, alternatives, and synthesis, never blending them. Use when a decision is being made too fast or from one angle, when everyone agrees suspiciously quickly, when the discussion mixes emotions with data, or for "six hats", "thinking hats", "look at this from every angle", "structured devil's advocate". Do NOT use for analytical work like debugging, code review, or implementation tasks.
npx skills add https://github.com/danium/lateral-thinking --skill six-hats
Take one decision and run it through six deliberately separated perspectives, one at a time. Each pass wears a single "hat": facts, feelings, risks, benefits, alternatives, then synthesis. The power is in the separation — a group that argues all six dimensions at once collapses into whoever talks loudest, but a group that examines facts *only*, then feelings *only*, surfaces things the argument would have buried. It converts a tug-of-war into six clean passes over the same ground.
Based on Edward de Bono's Six Thinking Hats® method (*Six Thinking Hats*, 1985). Six Thinking Hats is a registered trademark of the de Bono Group; this skill is an independent educational implementation.
A valid target is a *decision* — something with an option to accept, reject, or modify. "Should we ship X in v1?", "Do we adopt this dependency?", "Which of these two rollout plans?" all qualify. If the request is open-ended ideation with no decision to weigh ("what could we build next?"), this is the wrong technique — point the user to a generative technique such as ../random-stimulus/SKILL.md instead. If the target is unclear, ask one focused question: "What's the specific decision, and what are the options on the table?"
Refuse requests to *perform* analytical work — "debug this", "review this code", "implement this change" — and suggest an analytical approach instead. Redesigning or ideating about such a process is a valid target: "reinvent our code-review ritual" is in scope; "review this PR" is not.
Run all six, each under its own clear heading, never blending. If material for one hat surfaces while wearing another, park it and raise it when its hat comes up.
Offer, don't push: re-run a single hat deeper, take one of the Green alternatives through all six hats, switch to another technique, or stop here. Never pressure the user to commit to the recommendation.
The Red hat must bite. It must contain at least one feeling that *contradicts* the emerging conclusion — the discomfort with a decision that otherwise looks clean, or the reluctance to reject something that fails on paper. If no such feeling genuinely surfaced, say so explicitly rather than manufacturing one: Red hat is suspiciously aligned — flagging possible motivated reasoning. A Red hat where every feeling agrees with the answer is a tell.
The Blue hat must not paper over the split. Name the strongest unresolved tension in plain terms — the one thing that, if it broke the other way, flips the recommendation. Synthesis is not the same as consensus; a real disagreement between the hats is more useful reported than smoothed.
references/hats-guide.md — what belongs in each hat, what is banned, examples, and the leakage patterns between neighbouring hatsreferences/worked-example.md — a real run of all six hats on one decision, disagreement and confidence level includedTake danium/six-hats from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.