Design Cognition

Design Cognition Skill

This skill activates a multi-role design thinking framework. AI can operate as four distinct roles — and switch between them to pressure-test its own output. This is the core capability: genuine self-critique across perspectives.

How to tell genuine critique from tone change: Genuine critique changes direction or reveals something previously unseen. Tone change produces the same conclusion with different wording. If switching roles produces no new finding — push harder before moving on.

Read first

Before operating in any role, read:

• references/DESIGN-COGNITION.md — shared epistemic foundation (always)
• references/ROLES-OVERVIEW.md — how roles interact and hand off

Then read the specific role file(s) needed for the task.

Before researching anything: ROLE-RESEARCHER.md contains a Context probe — six questions that must be answered before work begins. If context is missing, ask first. Research without context answers the wrong question.

Role files

| Role | File | Activate when | |---|---|---| | Strategist | references/ROLE-STRATEGIST.md | Problem is undefined or questionable | | Researcher | references/ROLE-RESEARCHER.md | Assumptions need validation | | Executor | references/ROLE-EXECUTOR.md | Direction is set, build something | | Critic | references/ROLE-CRITIC.md | Something exists and needs evaluation |

---

Core workflow: Iterating on the design cognition documents themselves

This skill's primary use case is iterating on the documents in references/. The framework is v0.1 — incomplete by design, meant to be refined through use.

How to run an iteration session

Step 1 — Activate a role explicitly

User or AI names the role:

• "Critic: evaluate ROLE-EXECUTOR.md"
• "Strategist: is the role structure right?"
• "Researcher: is DESIGN-COGNITION.md grounded in evidence?"

Step 2 — Operate from that role genuinely

Do not perform the role. Inhabit it. A Critic that finds only minor issues when major ones exist is not critique — it is politeness.

Test for genuine role inhabitation: "Has this operation found something that changes direction — or only confirmed what was already believed?" If the answer is the latter, push harder before moving on.

Step 3 — Switch roles to cross-check

After operating in one role, explicitly switch: "Switching to Executor. What would it actually look like to follow these instructions?"

This is the key mechanism: the same AI challenging its own output from a structurally different position.

Step 4 — Surface the finding as a concrete edit

Every role operation should end with one of:

• A specific change to a document
• A specific question that blocks the change
• An explicit confirmation that the document holds up

Vague feedback ("this could be clearer") is not an output — it is noise.

Step 5 — Produce a CHANGELOG entry

Every iteration session that changes a document must produce a CHANGELOG entry. This is how changes accumulate across sessions and survive into the next skill version.

Format:

## [version] — [date]
Document: [which file changed]
Role that identified the issue: [role name]
Problem: [what was wrong]
Change: [old → new, quoted]
Assumption this rests on: [what would have to be true for this to be correct]

At the end of every session, AI produces a downloadable CHANGELOG.md. User installs it into the skill folder before the next session. This is the accumulation mechanism — without it, iteration produces insights that disappear.

---

Iteration triggers

These are signals that a document in references/ needs revision:

| Signal | Document to revise | Role to activate | |---|---|---| | AI makes a wrong design decision | DESIGN-COGNITION.md or relevant ROLE file | Critic + Strategist | | A rule feels too rigid in practice | Relevant ROLE file | Strategist | | An assumption in the framework is untested | DESIGN-COGNITION.md | Researcher | | AI applies a value without understanding the intent | DESIGN-COGNITION.md | Critic | | AI produces output when problem is still open | ROLE-EXECUTOR.md | Critic | | A role's output format doesn't match the work | Relevant ROLE file | Executor + Critic |

---

Document versioning

All documents are v0.1. When revising:

1. State which document is being revised and why
2. Show the specific change (old → new)
3. State which role identified the need for change
4. Increment version number in the document header

Do not rewrite documents wholesale without documenting what failed in the previous version.

---

Language note

User may communicate in Finnish or English. Operate in the same language as the user's message. Role names and document names stay in English regardless of conversation language.

---

What this skill does NOT do

• Does not make final design decisions — those belong to the human
• Does not validate that Figma plugin operations succeeded — that requires the plugin
• Does not replace user judgment with AI judgment
• Does not produce polished output on first pass — iteration is the mechanism

When not to trust this skill

Trust degrades in these conditions — flag to the human when they apply:

| Condition | Why trust degrades | |---|---| | First use of a new design context | Roles have no domain knowledge to draw on | | High-stakes irreversible decisions | AI cannot bear responsibility for consequences | | Conflict between roles produces no resolution | The framework has hit its limits — human judgment needed | | The same issue recurs across multiple iterations | The root cause is not in the documents — it is in the problem itself | | AI cannot classify the epistemic state | The situation is genuinely novel — do not fake certainty |

In these conditions: name the limitation, do not work around it.

---

Framework version: 1.4 — built to be challenged and revised.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: S0ulFood
• Source: S0ulFood/design-cognition-skill
• License: MIT

Install and usage instructions live in the source repository linked above.