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:

State which document is being revised and why
Show the specific change (old → new)
State which role identified the need for change
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.

design-cognition