| name | strip-down |
| description | Strip rich briefs down to their raw human desire before ideating, forcing AI to generate from internal associations rather than anchoring on provided details. Use BEFORE any brainstorming, ideation, or generation when the user has provided a detailed brief, background context, multiple constraints, or a long description of what they want. Triggers when you notice yourself about to rephrase the user's own words back to them as "ideas," when a prompt contains more than 2-3 sentences of context, or when the user says "I keep getting back what I put in," "the ideas just restate my brief," or "give me something I haven't already thought of." Also use when output from other skills feels anchored or overly shaped by the input. Works on any problem in any domain — strategy, engineering, science, policy, design, education, medicine, law, research — wherever professional language is anchoring the output. |
Strip Down (Minimal Context Forcing)
Every problem description is written in the wrong language.
Not wrong as in incorrect.
Wrong as in: the language of the description
is professional language.
The formal, respectable, institutional language
that the field uses to talk about itself.
Every field has one.
In business it's deck language:
"Positioned at the intersection
of wellness and sophistication"
means "make women who think they're too smart
to be marketed to
need this thing anyway."
In science it's grant language:
"We propose to investigate the role of
epigenetic modifications in cellular plasticity"
means "we think cells can be reprogrammed
and we want to figure out the switch
before the lab down the hall does."
In engineering it's spec language:
"The system shall provide a scalable,
fault-tolerant, event-driven architecture"
means "we need something that doesn't fall over
when 10x more people show up than we planned for,
and nobody gets paged at 3am."
In policy it's proposal language:
"A multi-stakeholder approach to
evidence-based intervention design"
means "get the people who actually live with this problem
and the people who control the money
into the same room
and make them agree on something
before the election cycle kills it."
The description knows what it wants.
It just won't say it out loud
because every profession has a dress code.
Your job is to undress it.
What This Skill Does
Take any problem description —
brief, proposal, spec, grant, plan,
research question, design doc, anything —
and translate it into a desire statement.
A desire statement is:
what the person behind this document
actually wants to happen in the world,
said in the bluntest possible human language,
the way they'd explain it to a sharp friend
after two drinks,
loaded with the specific details
that make the desire textured and actionable
rather than generic.
Not a tension. Not a framework.
Not "X vs. Y."
A statement of want
that a real person would recognize as true.
How to Build a Desire Statement
Step 1: Find the want
Read the entire document and ask one question:
"What does this person actually want
to happen in the world?"
Not what they say they want.
Not their stated objectives.
Not their success metrics.
What they want.
Every document has a want.
It's usually more specific,
more emotional, and more human
than the document admits.
The want hides in different places
depending on the domain.
Before you look for it,
identify what kind of professional language
is doing the hiding:
In business and marketing,
the want hides behind KPI language.
"Increase brand awareness" → not the want.
"Make people who pride themselves on discovering things
feel like they discovered us" → the want.
In science and research,
the want hides behind methodology language.
"Develop a novel computational framework
for predicting protein interactions" → not the want.
"Figure out which proteins talk to each other
so we can stop guessing at drug targets
and start knowing" → the want.
In engineering and product,
the want hides behind architecture language.
"Build a scalable microservices-based platform
with event-driven communication" → not the want.
"Build something that works no matter
how many people use it,
that any engineer on the team can debug at 2am
without needing to understand the whole system" → the want.
In policy and governance,
the want hides behind institutional language.
"Implement a comprehensive,
evidence-based homelessness reduction strategy" → not the want.
"Get people off the street
into places they'll actually stay,
fast enough that the city council doesn't lose patience
and defund the program" → the want.
In education,
the want hides behind pedagogical language.
"Design a differentiated, student-centered
curriculum aligned with 21st-century skills" → not the want.
"Make kids who've decided school is pointless
give a damn about something
before they check out permanently" → the want.
In any other domain:
the professional language will be different
but the pattern is the same.
The want is underneath the first sentence
you'd delete if you were explaining this
to someone outside the field.
Find that sentence. The want is what it's protecting.
Name the want in plain language.
Use words a person would think,
not words a person would put in a document.
If the want sounds like it could appear
in the original document,
you haven't found it yet.
Dig under it.
Step 2: Find the who — in human terms
Every problem has a "who."
But "who" means different things
in different domains.
When the who is a person or group of people:
Translate from demographic or professional jargon
into a human being you can picture.
Not "women 28-42 in the wellness space."
Instead: "the woman who has a Sweetgreen order memorized
and considers her La Croix choice passé
but would never say that out loud
because having opinions about water
is exactly the kind of thing she has opinions about."
Not "enterprise decision-makers."
Instead: "a VP who's been burned by three vendors
and now makes their team do 6 months of evaluation
before buying anything,
partly for diligence and partly out of spite."
Not "underserved communities."
Instead: "a single mother working two jobs
who would use the clinic if it were open
after 6pm but it isn't,
so she goes to the ER
and gets a $4,000 bill instead of a $40 visit."
The human description should make you feel like
you've met this person.
If it doesn't, it's still jargon.
When the who is a system, phenomenon, or entity:
Not every problem has a human audience.
Sometimes the "who" is:
- a biological system ("these tumor cells
that keep finding ways around every drug we throw at them")
- a physical system ("this bridge
that has to survive 100 years of freeze-thaw cycles
and politicians who won't fund maintenance")
- an institution ("this school district
that's been reorganized four times in a decade
and the teachers are too exhausted to trust
the next reform")
- a codebase ("this legacy monolith
that three teams depend on
and nobody alive fully understands anymore")
Describe it the way someone who works with it
every day talks about it in private.
Not the way they describe it in documents.
The private version has personality,
frustration, and specificity.
The document version has abstract nouns.
Use the private version.
Step 3: Load the specific details that give it teeth
A desire statement is not a generic want.
It's a want with enough specificity from the document
that the ideas it produces couldn't be
for any other problem.
Pull in the details that make this particular.
What you're looking for depends on the domain,
but the principle is the same:
find the details that make THIS problem
different from the generic version of this problem.
In business:
What makes their audience specific
(not demographics — behaviors, contradictions,
self-perceptions, the things they'd never admit).
What makes their market situation specific
(the gap, the cultural moment,
the thing that's true right now
that won't be true in two years).
In science:
What makes their question specific
(not the broad field — the specific observation
that doesn't fit existing models,
the anomaly they can't explain,
the experiment that keeps producing weird results).
What makes their constraints specific
(the equipment they have, the funding timeline,
the competing lab that's six months ahead).
In engineering:
What makes their system specific
(not the tech stack — the actual usage patterns,
the failure modes that keep waking people up,
the one user behavior that breaks every assumption).
What makes their team situation specific
(who's available, what they know,
what nobody on the team has done before).
In policy:
What makes their population specific
(not demographics — the actual lived experience
that existing policy ignores).
What makes their political situation specific
(who needs to say yes, what they care about,
what kills this initiative if it goes wrong).
In any domain:
the specific details are the ones
that a generic prompt would never include
because they only matter here.
Those are the ones that give the desire statement teeth.
These details are the difference between
"solve the protein folding problem"
and "figure out why this specific protein
keeps folding into a conformation
that shouldn't be stable according to
everything we know about hydrophobic interactions,
and do it before our funding runs out in March."
The first produces generic ideas.
The second produces ideas
that only work for this problem.
Step 4: Say it in one breath
Combine the want, the who, and the specific details
into a single statement.
It should be 1-3 sentences.
It should sound like a person talking, not a document.
The emotional register depends on the domain.
In business, the desire statement might be
slightly crude or slightly funny.
In science, it might be bluntly curious
or slightly obsessive.
In engineering, it might be exasperated and practical.
In policy, it might be angry and specific.
The common thread isn't a single tone.
It's honesty.
The desire statement should sound like
what the person would say
to a trusted colleague in private —
the version that's too direct,
too emotional, or too honest
for the official document.
Read it back to yourself.
Does it sound like something
the person behind this document would say
to someone they trust
but would never put in writing?
Then you have it.
Does it sound like something that could appear
in the original document?
Then you're still translating into the same language.
Push further.
What to Strip, What to Keep
Once you have the desire statement,
everything else in the document falls into two piles:
Keep — anything that's already IN your desire statement.
It's there because it earned its place.
Strip — everything else.
What gets stripped depends on the domain,
but the principle is the same:
strip anything that anchors the AI
toward the document's own conclusions
instead of generating new ones.
In business: budgets, timelines, channels, tactics,
competitive analysis, deliverable lists,
half-formed concepts the team is exploring,
org chart details, and any sentence that starts with
"We believe" or "Our approach."
In science: literature review, methodology details,
preliminary data interpretations,
theoretical framework sections,
and any sentence that starts with
"Previous work has shown" or "It is well established."
In engineering: existing architecture descriptions,
tech stack decisions, performance benchmarks
from the current system, vendor evaluations,
and any sentence that starts with
"The current approach" or "Industry best practice."
In policy: stakeholder maps, implementation timelines,
legislative history, cost-benefit analyses
from previous proposals,
and any sentence that starts with
"Evidence suggests" or "Best practices indicate."
In any domain: strip the parts of the document
that tell the AI what to think.
The desire statement tells the AI what to want.
Those are different instructions
and they produce different output.
The stripped material comes back later
when you reconnect ideas to reality.
But it stays out of the room
during generation.
Confirm — This Is the Most Important Step
Present the desire statement to the user
as a blockquote, then pause for confirmation.
The confirmation has two visual layers
designed so the user can't miss them.
Layer 1: the soft pause.
After the desire statement,
add a horizontal rule and whitespace,
then ask the confirmation question in bold.
The whitespace says "stop reading."
The bold says "answer this."
Layer 2: the pushback.
After flagging your concerns,
put the second question in a blockquote AND bold.
The blockquote creates a visual lane change.
The bold makes the question impossible to skim past.
The format:
[desire statement in blockquote]
Does that feel true? Not just reasonable,
but actually what this [problem domain] needs?
[1-2 specific concerns about the framing —
things the document assumes that might be wrong,
or angles the desire statement might be missing.]
Does the desire statement hold,
or does one of those worries land?
Both questions must be bold.
The first uses whitespace isolation (divider above it).
The second uses blockquote + bold.
Two different weights for two different moments.
The user cannot miss either one.
Do not accept a quick "yes" at face value.
If the user says "yes" or "looks good"
without engaging deeply,
push once more with the concerns.
Always have 1-2 concerns ready
even if the desire statement feels solid —
because surfacing doubt the user is holding
but not voicing
is more valuable than false confidence.
The goal is not to second-guess the user.
The goal is to surface doubt
that the user might be holding
but not voicing
because the tool sounds confident.
The most dangerous failure mode
isn't the user disagreeing.
It's the user going along with it
because "the tool knows what it's doing."
The tool doesn't know. The user does.
The confirm step exists to extract
what the user knows
before the tool runs in a direction
that wastes everyone's time.
If they correct you, rebuild.
Don't patch. Start over.
Their correction IS the desire statement
or is close to it — they know the want
better than the document does.
If they push back on the framing entirely —
if they say something like
"I don't think we're asking the right question" —
stop Strip Down and route to
the Wrong Problem Detector.
The desire can't be extracted
from a document that's solving the wrong problem.
Fix the problem first,
then come back and extract the desire.
Once genuinely confirmed —
and genuinely means the user engaged
with the statement, not just nodded —
generate immediately.
Do not offer a menu of skills.
Do not ask "would you like me to brainstorm
or use the Guilford Engine or..."
Just go.
The desire statement is the prompt.
Produce ideas from it directly
or feed it into whatever skill
fits the task.
The user came here to get ideas,
not to manage a tool selection process.
Examples
Brand launch brief (verbose, 400+ words about positioning, competitors, channels)
Desire statement:
"Figure out how to make taste-obsessed women
who love/hate Erewhon
crave this sparkling water
as part of their personal identity kit —
the thing they reach for
to signal high-cool-but-I-don't-care-that-I'm-cool status —
so that the people who influence them
can't help but talk about it
without anyone asking or paying them to."
Research grant proposal (verbose, 800+ words about background, significance, methodology, broader impacts)
Desire statement:
"Prove that the reason glioblastoma keeps coming back
isn't that we're not killing the tumor —
it's that a tiny population of cells
goes dormant in a way we can't detect
and wakes up after treatment stops,
and if we can catch them sleeping
we can kill the cancer
instead of just shaving it back every time."
Systems architecture spec (verbose, 600+ words about requirements, constraints, current infrastructure, scaling targets)
Desire statement:
"Build a system where the payments team
and the inventory team and the fulfillment team
can each move as fast as they want
without breaking each other,
because right now every time one team ships,
another team's stuff catches fire,
and the engineers are spending more time
coordinating deploys than writing code."
Education reform proposal (verbose, 500+ words about standards, assessment, equity frameworks, implementation phases)
Desire statement:
"Get ninth-graders in this district —
kids who've been told by every standardized test
that they're behind and by every adult
that they need to catch up —
to walk into a classroom and actually want to be there
because for once the work connects to something
they recognize as real."
Public policy brief (verbose, 700+ words about stakeholder analysis, regulatory framework, implementation strategy)
Desire statement:
"Cut the time between someone calling 911
for a mental health crisis
and someone qualified actually showing up
from 45 minutes to 10,
without sending armed officers
to a situation where the person in crisis
is more scared of the responders
than of whatever's happening to them."
What This Skill Is Not
This is not summarization.
A summary shortens the document
in the document's own language.
The desire statement translates the document
into a different language entirely.
This is not a tension framework.
Tensions are analytical.
Desire statements are emotional.
The tension for the water brand is
"earned attention for a bought product."
The tension for the glioblastoma research is
"treatment efficacy vs. dormancy escape."
The desire is
"catch the cells sleeping and kill them."
One is an academic framing.
The other is a human want.
Generate from the want.
Relationship to Other Skills
This skill feeds every generation skill in the stack.
The desire statement is a better input
for the Guilford Engine than a tension.
It gives the five passes something human
to diverge from.
The desire statement is a better input
for the Persona Divergence Engine than a document.
Each persona responds to desire differently.
They all respond to professional language the same way.
The desire statement is a better input
for Think Wrong than a problem statement.
Think Wrong needs to find the consensus answer.
When the input is a human want,
the consensus answer is obvious and killable.
When the input is professional language,
the consensus answer hides.
Strip first. Then create.
The desire statement is the raw material.
Everything else is packaging.
