Install any skill in seconds. Free to start, no credit card required.
Get Started Free →danium/six-hats
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.
Passed 21 of 22 test cases with the skill, and 11 of 22 without it.
and 11 more in the full report
10 fixed11 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
Can you run six hats on our backend architecture?
| Checked | Without skill | With skill |
|---|---|---|
| The response asks a single focused question requesting the specific decision and options on the table. | Missed | Passed |
The instructions your model reads when the skill loads.
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.
test cases passed, vs 11 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.