Intent Engineering

Intent Engineering

Every design decision — words, visuals, interactions — should trace back to a human need, not to an abstraction. "We chose this because of art history" is the design equivalent of "we're the fastest way to communicate." Both are technically accurate. Neither connects.

This skill uses two techniques to ground design in real intent:

1. The Three-Question Framework — For each page or flow, answer: What should users accomplish? What should they explicitly notice? What should they implicitly feel?

2. The Why Loop — For each answer, keep asking "why does that matter?" until you hit bedrock: something universal, unique to this product, and emotional.

Inspired by Ellis Hamburger's storytelling work with Raycast, Snapchat, Daylight, Browser Company, and others.

Quick Start

New project:

/intent-engineering start

/intent-engineering — "I'm building a new marketing site for my product"

Audit existing site:

/intent-engineering audit https://example.com

/intent-engineering — "Can you look at my landing page and tell me what it's communicating?"

---

Core Principles

These apply to both Start and Audit workflows:

1. Bedrock over surface — Surface-level intent ("sign up," "look professional") isn't wrong, it's just incomplete. Drill to the human need underneath. Stop when the answer is universal, unique, and emotional.

2. Accomplish, Notice, Feel — Three layers that most people conflate or skip. Separating them reveals misalignment: what users notice might not lead to what you want them to feel, and what they feel might not motivate what you want them to accomplish.

3. Mirror, don't critique — Especially in Audit mode. Reflect what the design communicates. Ask if that matches intent. The user discovers the gaps themselves — that's more powerful than being told.

4. Evocation over information — A design that makes someone feel something is more effective than one that informs them of everything. Ellis: "Not trying to make the feature sound good, but first communicate that I understand you and your problem."

5. Ideas over features — Features are what you built. Ideas are why it matters. Ideas are more shareable, more memorable, and give you more to talk about. A product has one feature set but can own three to five ideas.

6. Grounded, not generic — "Be kind" is generic. "Friends over followers" is grounded. "Browse better" is generic. "The shortcut to everything" is grounded. Every principle, tagline, and design choice should be specific enough to guide a decision.

---

Entry Point Detection

Detect mode from $ARGUMENTS:

Focus hint extraction

After routing, scan $ARGUMENTS for what the user wants to pressure-test — their copy, visual language, product positioning, whether a specific idea comes through, a particular design decision, etc. Pass any extracted focus to the workflow as initial context so Step 1 can confirm it rather than re-asking.

Mode selection (when ambiguous)

If AskUserQuestion is available:

• Start — New project. Walk through the three questions to build a grounded intent brief.
• Audit — Existing site or product. Reflect what it communicates and discover where intent diverges from execution.

Otherwise, ask:

I can help two ways:

1. Start — You're beginning a new project. I'll walk you through the three questions page by page to build a grounded intent brief.

2. Audit — You have an existing site or product. I'll take screenshots, reflect what I see, and help you discover where intent and execution diverge.

>

Which one?

After selecting a workflow, read it and follow it exactly.

---

The Three-Question Framework

For any page, flow, or key moment:

Each answer gets drilled with the Why Loop until it reaches bedrock.

The connection check: After answering all three for a page:

• Does what they notice → lead to what they should feel?
• Does what they feel → motivate what they should accomplish?
• If these connections break, the design has a gap.

---

Gotchas

• Don't become a design critic. This is the #1 risk. You are reflecting what a design communicates and asking if it matches intent. You are not evaluating quality. "This hero is too busy" is critique. "The hero draws attention before the headline — is that what you wanted?" is reflection.

• Don't accept "delight" as bedrock. "We want users to feel delighted" is Layer 1 wearing Layer 3's clothes. Push: "Delighted by what specifically? What changes in their day?"

• Don't drill past bedrock. If you keep asking "why" after hitting a universal human need, you'll land at "because life is short." True but useless. Stop when the answer is deeply human AND specific enough to differentiate this product.

• Don't manufacture depth. If the Why Loop reveals there isn't a clear human need underneath a design choice, that's a real finding. Surface it honestly rather than fabricating bedrock.

---

Reference Index

Workflow Index

Intent Engineering

A Claude Code skill that grounds design decisions in human needs — not abstractions, not feature lists, not aesthetic preferences.

What It Does

Most design decisions start (and stop) at the surface:

• "We need a bold hero section" — Why? What should it make someone feel?
• "Our product is the fastest way to ___" — So what? Why does that matter to a human being?
• "We chose this visual language because it references Bauhaus" — Cool, but your users don't know Bauhaus. What are they supposed to feel?

These decisions aren't wrong — they're incomplete. They describe what without connecting to why it matters. When you can't trace a design choice back to a real human need, you can't evaluate whether it's working.

Intent Engineering helps you find that connection using two techniques:

The Why Loop

Keep asking "why does that matter?" until you hit bedrock — the fundamental human need underneath the features.

Example (Raycast):

• "You don't have to switch apps" → why does that matter?
• "You're not getting distracted" → why does that matter?
• "You can stay in flow" → Bedrock: "The shortcut to everything."

Example (Snapchat):

• "It's the fastest way to communicate" → so that you can...?
• "Share moments from your day" → why does that matter?
• "Your friends feel like they're there with you" → Bedrock: "Deepen your relationships with the people that matter most."

The Three-Question Framework

For any page, flow, or key moment in a product, answer three questions:

1. What should users accomplish? — The functional outcome 2. What should they explicitly notice? — What draws conscious attention 3. What should they implicitly feel? — The emotional undercurrent

Then apply the Why Loop to each answer. The connection check is where it gets interesting: does what they notice lead to what they should feel? Does what they feel motivate what they should accomplish? When those connections break, you've found a design gap.

Two Modes

Start — New Project Discovery

Walk through the three questions page by page for a new project. Drill each answer with the Why Loop. Produce an intent brief that grounds every design decision in human need.

/intent-engineering start

Audit — Existing Site/Product Evaluation

Take screenshots of an existing site, reflect back what the design communicates, and ask: "Is that what you intended?"

The audit is Socratic, not critical. It doesn't tell you your design is bad — it mirrors what your design is saying and lets you discover whether that matches what you meant.

/intent-engineering audit https://your-site.com

You can focus the audit on what you're most uncertain about — your copy, visual language, product positioning, a specific design decision — and the skill will weight its observations toward that while still looking at the full picture.

Use Cases

• Landing page copy audit — "Does my headline communicate an idea or just list what I do?"
• Portfolio review — "Does my site communicate who I am and what I care about, or just show work?"
• Product positioning — "Can a first-time visitor understand why this matters in 5 seconds?"
• Visual language check — "Does the visual tone match the feeling I want to create?"
• New project kickoff — "Before I design anything, what should each page make someone accomplish, notice, and feel?"
• Design decision validation — "I chose this direction — can I trace it back to a human need?"

What It's Not

This isn't a UI audit tool. It doesn't evaluate visual quality, accessibility, or usability. It's about intent alignment — whether what your design communicates matches what it should communicate. The output is clarity about where intent and execution diverge, not a list of design fixes.

Install

One command (all agents)

npx skills add kylezantos/intent-engineering

Auto-detects your installed agents and installs to each. Works with Claude Code, Codex, OpenCode, Cursor, Gemini CLI, Windsurf, and 35+ more.

Target specific agents

npx skills add kylezantos/intent-engineering -a claude-code
npx skills add kylezantos/intent-engineering -a codex -a opencode

Manual install

Copy the entire intent-engineering/ directory into your agent's skills path:

Or clone:

git clone https://github.com/kylezantos/intent-engineering.git ~/.claude/skills/intent-engineering

Then invoke with /intent-engineering in any session.

Cross-agent compatibility: The core workflow (three questions, Why Loop, Socratic reflection) works on any AI coding agent. Claude Code users get enhanced features like tappable options and automated screenshots via dev-browser.

Origin

Synthesized from Ellis Hamburger's Dive Club episode on startup storytelling and extended into product design. Built with skill-distillery.

Anti-Patterns: Ungrounded Design Decisions

How to recognize design decisions that aren't rooted in human need. Used in both Start (prevention) and Audit (diagnosis) workflows.

The Four Ungrounded Patterns

Every ungrounded design decision falls into one of these categories. Learn to recognize them — in your own work and in what you're evaluating.

1. Feature-First

The design communicates what the product does, not why it matters.

Signs:

• Headlines like "faster," "better," "more efficient," "all-in-one"
• Visual hierarchy organized by feature list rather than user story
• Onboarding that tours features instead of priming expectations
• Pages that read like a spec sheet

Why it fails: Features aren't unique. "Browse better" sounds simple but has no meaning — every browser could say it. It's not a hook because it doesn't connect to a feeling or a problem.

The fix: Apply the Why Loop. "We have X feature" → "so that you can ___" → keep going until you hit a human need that only you can credibly own.

Ellis's example: Snapchat was stuck on "the fastest way to communicate" for years. Functional, true, but meaningless — texting is pretty fast too. It took asking "so that you can ___?" to arrive at "deepen your relationships with the people that matter most."

2. Intellectually-Grounded-But-Disconnected

The design is rooted in a real idea, but one the audience won't connect with.

Signs:

• Visual language explained through art movements, philosophy, or theory
• Design rationale that requires domain expertise to appreciate
• Choices that are internally coherent but externally opaque
• "We chose this because of [reference most users don't know]"

Why it fails: The reasoning is real, but it lives in the designer's head, not the user's experience. A visual language rooted in Bauhaus means nothing to someone who doesn't know Bauhaus. The design might still work accidentally — but you can't evaluate or iterate on reasoning your audience doesn't share.

The fix: Translate the intellectual grounding into the three questions:

• What should users accomplish on this page? (Does the art-history choice serve that?)
• What should they explicitly notice? (Does the reference communicate what you think it does?)
• What should they implicitly feel? (Is the feeling accessible without knowing the reference?)

If the design works through the three questions independent of its intellectual backstory, it's fine — the backstory is just bonus context. If it only works when you know the backstory, it's disconnected.

3. Generic / Ego-Inflated

The design communicates importance without specificity, or inflates value beyond what's credible.

Signs:

• Mission statements like "contribute to human progress"
• Values like "be kind," "move fast," "innovate"
• Language that sounds impressive but could apply to any company
• Silicon Valley jargon: "leverage," "empower," "disrupt," "reimagine"
• Visuals designed to impress rather than communicate

Why it fails: Generic statements don't guide decisions. "Be kind" doesn't tell a designer what to build. "Contribute to human progress" doesn't tell a salesperson what to pitch. And inflated language triggers the bullshit radar — as Ellis puts it, "who talks about pitching their friend like 'oh yeah this tool is such a good way to leverage your blah blah blah'?"

The fix: Make it specific and actionable. Ellis's examples of good principles:

• "Simple apps over super apps" (Amo)
• "Friends over followers" (Snapchat)
• "Hesitate before gamifying"

These are opinionated, memorable, and they actually help someone make a decision when they're stuck.

4. Aesthetic-Only

The design looks good but isn't in service of anything.

Signs:

• Visual choices justified by "it looks nice" or "it's trendy"
• Typography, color, and layout decisions made in isolation from intent
• Beautiful design that doesn't communicate what the user should do, notice, or feel
• Style that could belong to any product in the category

Why it fails: Aesthetic quality is necessary but not sufficient. A beautiful page that doesn't communicate intent is decoration, not design. And decoration is indistinguishable from every other well-designed product.

The fix: Run the three-question test. For each major visual choice:

• Does this help the user accomplish what they came here to do?
• Does this draw their attention to the right thing?
• Does this make them feel what you want them to feel?

If a visual choice serves at least one of these — great, keep it. If it serves none, it's aesthetic-only and should be reconsidered.

Using This in Audit Mode

When auditing an existing site, don't lead with "this is feature-first" or "this is ungrounded." Instead, use Socratic reflection:

1. Describe what you observe on the page — what draws attention, what the hierarchy communicates, what the emotional tone feels like 2. Ask the user: "Is that what you intended?" 3. If there's a gap, help them identify which pattern is at play 4. Use the Why Loop to find what the design should be rooted in instead

The anti-pattern labels are diagnostic tools for you, not critiques to present to the user.

Using This in Start Mode

When building from scratch, use these patterns as guardrails:

• After the user answers the three questions, check: are any answers feature-first? Drill deeper.
• When they describe visual direction, check: is it intellectually grounded but disconnected? Translate through the three questions.
• When they articulate mission/values, check: are they generic? Push for specificity and actionability.
• When they describe aesthetics, check: are they in service of intent? Connect each choice to accomplish/notice/feel.

The Why Loop

The core drilling technique for getting from surface-level descriptions to bedrock human needs. Used in both Start and Audit workflows.

How It Works

When someone describes what their product does, what their page should look like, or what a design choice communicates — keep asking "why does that matter?" until you hit bedrock.

Bedrock is where an answer meets all three criteria:

• Universal — not specific to this product, but to being human
• Unique — something only this product/brand can credibly own
• Emotional — it makes you feel something when you say it out loud

When all three are present, stop drilling. You've found the foundation that design decisions should root in.

The Drilling Process

Step 1: Start with the functional statement

The user (or their existing design) will usually express intent in functional terms:

• "We're the fastest way to ___"
• "Our product lets you ___"
• "This page should show our features"
• "I want bold typography here"

This is the surface. Don't reject it — it's the starting material.

Step 2: Ask "why does that matter?"

Not confrontationally. The tone is curious, not interrogating. You're helping them think, not challenging them.

Each answer peels away a layer:

• Layer 1: Functional restatement ("so you don't have to switch apps")
• Layer 2: Behavioral consequence ("so you stay focused")
• Layer 3: Emotional/human need ("so you can find flow in your work")

Most people stop at Layer 1. Good founders get to Layer 2. Bedrock is Layer 3.

Step 3: Recognize when you've arrived

You've hit bedrock when the answer:

• Could apply to a person's life, not just their use of this product
• Makes the founder's eyes light up (or in text, they say "yes, exactly")
• Feels like something worth fighting for, not just building

Step 4: Work back up

Once you have bedrock, trace back up: does the original functional statement serve this deeper truth? Often it does, but now you can express it differently. Sometimes it reveals that the surface statement was pointing at the wrong thing entirely.

Ellis Hamburger's Examples

These are real cases from Ellis's work. Study the drilling pattern:

Raycast

Notice: "the shortcut to everything" is universal (everyone wants shortcuts), unique (only Raycast can credibly claim it), and emotional (it promises liberation from friction).

Snapchat

The "so that you can ___" variant is just as powerful as "why does that matter?" Use whichever fits the moment.

Daylight Computer

Browser Company (Peak feature)

A tiny feature, elevated into something people shared because it was rooted in a real feeling.

Companion Technique: "So That You Can"

Ellis discovered this framing at Snapchat:

"We are the best way to _____ so that you can _____."

The "so that" forces you past the feature and into the outcome. If you can't complete the sentence with something meaningful, you haven't found bedrock yet.

When to Use Each Variant

Gotchas

• Don't drill past bedrock. If you keep asking "why" after hitting a universal human need, you'll end up at "because life is short" or "because humans need connection." Those are true but useless — too abstract to guide decisions. Stop when you hit something that's both deeply human AND specific enough to differentiate.

• Don't accept the first emotional-sounding answer. "We want people to feel delighted" is Layer 1 wearing Layer 3's clothes. Push: "Delighted by what specifically? What changes in their day?"

• Don't interrogate. The Why Loop is collaborative excavation, not cross-examination. If the user feels defensive, you've lost the thread. Rephrase: "That's interesting — what's the feeling underneath that?"

• Don't manufacture bedrock. If the drilling reveals there isn't a clear human need underneath, that's a real finding. The design may be solving a problem that doesn't emotionally resonate, and that's worth surfacing honestly rather than fabricating depth.

• Don't skip the trace back up. Finding bedrock is only half the work. You must reconnect it to the actual design decisions. "Flow" is bedrock for Raycast, but that insight is useless until it informs specific choices: naming, visual language, feature prioritization, onboarding narrative.

Workflow: Audit (Existing Site/Product)

Evaluate an existing site or product against the three-question framework. Use screenshots to see what the user sees, reflect observations back Socratically, and help the user discover where their design's communicated intent diverges from their actual intent.

Required Reading

Read these reference files before proceeding: 1. references/why-loop-technique.md 2. references/anti-patterns.md

---

Step 1: Get the Target

Shortcut: Check $ARGUMENTS first

If the user provided a URL at invocation (e.g., /intent-engineering audit https://example.com), don't ask for it again. Navigate to it immediately with dev-browser and take a homepage screenshot while asking about scope:

I'm pulling up [URL] now. While that loads — are there specific pages you want to focus on, or should I work through the main ones?

If they also provided scope or intent hints (e.g., "homepage and pricing only, feels too cold"), acknowledge those and skip to Step 2.

If no URL was provided

Ask what to audit:

What's the site or product you want to look at? Give me a URL, or if it's a local project, point me to it.

If AskUserQuestion is available:

• Live URL — I'll open it in a browser and take screenshots
• Local dev server — I'll navigate to localhost
• Existing screenshots — I have screenshots to share

For a live URL or localhost, use dev-browser to navigate and take screenshots.

Also ask:

Before I look at it — what pages or flows matter most to you? I can audit the whole thing, but if there's a specific page you're uncertain about, let's start there.

What intent are you pressure-testing?

If a focus was extracted from $ARGUMENTS (e.g., "especially the copy," "whether my positioning comes through," "if the visual language feels right"), present it for confirmation:

It sounds like you're most interested in whether [extracted focus]. I'll weight my observations toward that while still looking at the full picture. Sound right?

If no focus was provided, ask:

Is there a specific intent you want to pressure-test? For example:

- Whether your copy communicates ideas vs. just listing what you do

- Whether your visual language creates the feeling you're going for

- Whether your positioning or a specific design decision matches what it should communicate

- Or something else entirely — this works for any decision you're questioning

>

You can also skip this and I'll do a full holistic audit.

The focus doesn't narrow the audit to one dimension. It tells the agent where to apply the most pressure when reflecting back what the design communicates. Every observation still connects through accomplish/notice/feel.

Wait gate: Confirm the target, scope, and focus before taking screenshots.

---

Step 2: Screenshot and Observe

For each page in scope:

1. Navigate to the page — use dev-browser to open the URL. If dev-browser is not available, ask the user to provide screenshots or share their screen. 2. Take a full-page screenshot — capture what a real user would see 3. Observe silently first — before sharing anything, form your own read of the page

What to observe (internal notes, not shared yet)

For each page, note:

• What draws the eye first? (Visual hierarchy — what's loudest?)
• What action does the page seem to want you to take? (CTAs, layout flow)
• What's the emotional tone? (Warm? Clinical? Energetic? Sparse? Overwhelming?)
• What story is the page telling? (Problem → solution? Feature list? Vibes?)
• What's missing? (Is there a clear "why" or just a "what"?)

If the user stated a focus, deepen your observations in that dimension:

• Copy/messaging: Read every headline, subhead, and body block. Does the language communicate ideas or list capabilities? Does it complete "so that you can ___"? Does it sound like how a real person would describe this to a friend, or like marketing-speak?
• Visual language: What feeling does the visual treatment create independent of the words? Does the color, typography, spacing, and imagery serve an intent or just look good?
• Positioning/product: What does a first-time visitor understand about what this is and why it matters within 5 seconds? Is the positioning grounded in a human need or a comparison?
• Specific decision: Observe the specific element or choice the user asked about. What is it communicating? What feeling does it create? What action does it imply?

The focus weights your attention — it doesn't narrow the audit. Still observe the full page.

Do NOT evaluate quality. Do NOT identify design problems. You are forming a read of what the page communicates — that's different from whether it's "good."

---

Step 3: Reflect Back (Socratic)

This is the core of the audit. You are a mirror, not a critic.

Present your read

For each page, share what you observed — as observations, not judgments:

Looking at [Page Name], here's what I'm picking up:

>

First thing I notice: [What draws the eye — could be a headline, an image, a color block, whitespace]

>

The action it seems to want me to take: [What the page is pushing toward — sign up, scroll, click, read]

>

The feeling I get: [The emotional tone — be specific and honest. "Professional but distant." "Energetic but unfocused." "Calm and confident."]

>

The story it's telling: [What narrative structure, if any. "Here's what we do, here's how it works, here's social proof." Or "Here's a vibe, no clear next step."]

Then ask — don't tell

Is that what you intended?

That single question does most of the work. Let the user respond. They'll either:

• Confirm — "Yeah, that's exactly right" → move to next page
• Partially confirm — "The feeling is right but the action isn't clear enough" → drill into the gap
• Disagree — "No, I wanted them to feel X not Y" → now you've found the divergence

If there's a gap

When the user's intent doesn't match what the page communicates, don't prescribe a fix. Instead, drill:

You wanted them to feel [X], but the page is giving off [Y]. Let's figure out why.

>

- What on this page do you think is creating the [Y] feeling?

- What would need to change for [X] to come through instead?

- Is [X] still the right target, or has your thinking shifted?

Use the Why Loop here — if the user says "I want them to feel inspired," ask "Why is inspired the right feeling for this moment? What does it set up?"

Connect to anti-patterns

When a gap emerges, check whether an anti-pattern from references/anti-patterns.md is at play — but surface it through the user's language, not as a label:

• If the page leads with what rather than why → may be feature-first. Surface specific text: "This line says [X] — is that the idea you want to lead with, or is there a deeper 'so that you can' underneath it?"
• If the design reasoning won't land with the audience → may be intellectually-disconnected. Ask: "This choice makes sense to me — would your [audience] connect with it the same way?"
• If the language could apply to anyone → may be generic/ego-inflated. Ask: "Could a competitor paste this exact line on their site? What makes this specifically yours?"
• If a visual or structural choice looks good but doesn't serve accomplish/notice/feel → may be aesthetic-only. Ask: "This is visually strong — what intent is it serving?"

If the user stated a focus, prioritize anti-pattern checks in that dimension. But surface whatever you actually observe — the focus is a weight, not a filter.

---

Step 4: Three-Question Assessment

After the Socratic reflection, structure what you've learned using the framework.

For each audited page:

PAGE: [Name]

What you intended:
- Accomplish: [What the user told you]
- Notice: [What they wanted highlighted]
- Feel: [Target emotion]

What the page communicates:
- Accomplish: [What the page actually pushes toward]
- Notice: [What actually draws attention]
- Feel: [Actual emotional tone from the screenshot]

Alignment:
- Accomplish: [Aligned / Partially aligned / Misaligned] — [brief note]
- Notice: [Aligned / Partially aligned / Misaligned] — [brief note]
- Feel: [Aligned / Partially aligned / Misaligned] — [brief note]

Identify patterns

If you audited multiple pages, look for recurring patterns:

• Is misalignment concentrated in one dimension? (e.g., "accomplish" is always clear but "feel" is consistently off)
• Is there an anti-pattern at work? (Feature-first? Aesthetic-only? Intellectually-grounded-but-disconnected?)
• Is the cross-page thread coherent or fragmented?

Use anti-pattern labels internally to guide your thinking, but present findings through the user's own language. Don't say "this is feature-first." Say "the page leads with what the product does rather than why it matters — is that intentional?"

---

Step 5: Gap Prioritization

Help the user decide what to address:

Here are the gaps I see, in order of impact:

>

1. [Biggest gap] — [Which page, which dimension, what the divergence is]

2. [Second gap] — ...

3. [Third gap] — ...

>

Which of these feel most urgent to you?

If AskUserQuestion is available, present the top 3 gaps as selectable options.

Do not propose design solutions. This skill identifies where intent and execution diverge. The user (or another skill/process) handles the fix. You can suggest what the design should aim for — but not how to get there visually.

The one exception: if the user explicitly asks "what would you change?" — then you can offer directional suggestions framed as hypotheses, not prescriptions:

• "One hypothesis: if the headline led with the problem instead of the feature, the 'accomplish' alignment might improve."
• "You might explore whether a warmer color palette shifts the feeling from 'clinical' toward 'confident.'"

---

Gotchas

• Don't slip into critique mode. This is the #1 failure risk. You are not evaluating whether the design is good. You're reflecting what it communicates and asking if that matches intent. "This hero image is too busy" is critique. "The hero image draws attention before the headline — is that what you wanted?" is reflection.

• Don't project intent the user hasn't stated. If you observe something on the page, reflect it as observation. Don't say "it seems like you wanted X" unless the user told you they wanted X. Say "I'm picking up X from this page" and let them confirm or deny.

• Don't evaluate copy in isolation. This skill looks at what the page communicates holistically — copy, visuals, layout, hierarchy working together. Don't pull out a headline and critique it separately. Everything is in service of accomplish/notice/feel.

• Don't skip the screenshot. Reading code or markup is not the same as seeing the page. The user experiences their product visually. You need to see what they see. Always take screenshots before reflecting.

• Don't overwhelm with observations. Three to four observations per page is plenty. First thing noticed, implied action, emotional tone, story structure. More than that and you're writing a report, not having a conversation.

• Don't rush past "is that what you intended?" That question is where the real work happens. Sit in the silence. Don't immediately follow it with your own analysis. Let the user respond first.

---

Success Criteria

This workflow is complete when:

• [ ] Target site/product identified and scoped
• [ ] Screenshots taken for each page in scope
• [ ] Observations reflected back Socratically for each page
• [ ] User confirmed or identified gaps for each page
• [ ] Three-question assessment structured for each page
• [ ] Gaps prioritized by impact
• [ ] User has clarity on where intent and execution diverge

Workflow: Start (New Project)

Guided discovery for a new project, page, or product. Walk through the three-question framework page by page, drill each answer with the Why Loop, and produce a grounded intent brief.

Required Reading

Read these reference files before proceeding: 1. references/why-loop-technique.md 2. references/anti-patterns.md

---

Step 1: Scope the Work

Understand what the user is building and how to break it down.

Shortcut: Check $ARGUMENTS first

If the user already described their project at invocation (e.g., /intent-engineering start — building a marketing site for a dev tool, main pages are homepage, pricing, and docs), don't re-ask. Extract what they provided, present it back for confirmation, and skip to the page breakdown.

Sounds like you're building [extracted description]. I'd work through these pages:

1. [Extracted page A]

2. [Extracted page B]

>

Want to start with these, or adjust?

If no context was provided, ask:

What are you building? Give me the high-level picture — is this a full product, a marketing site, an app, a single landing page?

Based on their answer, identify the key pages or flows that need intent engineering. For a marketing site, this might be:

• Homepage
• Product/feature page
• Pricing
• About

For an app, it might be:

• Onboarding flow
• Core workflow
• Empty states
• Settings/profile

Present the proposed breakdown:

Based on what you described, I'd work through these pages/flows:

1. [Page A]

2. [Page B]

3. [Page C]

>

Want to start with these, or adjust the list?

Wait gate: Confirm the page/flow list before proceeding.

---

Step 2: Three Questions (Per Page/Flow)

For each page or flow, work through all three questions. Do them one page at a time — don't try to do every page at once.

Announce the page

Let's start with [Page Name].

Question 1: Accomplish

When someone lands on this page, what do you want them to accomplish? What's the action or outcome?

Listen for functional answers ("sign up," "understand the product," "find pricing"). These are valid starting points.

Apply the Why Loop: Once they answer, drill once or twice:

• "Why is that the most important action here?"
• "What changes in their life or workflow after they do that?"

Stop when the answer connects to something the user genuinely cares about — not just a conversion metric.

Question 2: Notice

What do you want them to explicitly notice on this page? What should jump out?

Listen for visual or content elements ("the headline," "the demo video," "social proof"). This reveals what they think matters most.

Apply the Why Loop:

• "Why should that be the thing they notice first?"
• "What does noticing that set up for them?"

This often reveals misalignment — the thing they want people to notice isn't always connected to what they want them to accomplish.

Question 3: Feel

What do you want them to implicitly feel when they're on this page? Not what they think — what they feel.

This is the hardest question. Many people haven't considered it. Give them space. If they struggle, offer prompts:

• "Should they feel excited? Calm? Confident? Curious? Relieved?"
• "Think about the best version of someone experiencing this page — what's their emotional state?"

Apply the Why Loop:

• "Why is that the right feeling for this moment?"
• "How does that feeling serve what you want them to do next?"

Synthesize the page

After all three questions, present a structured summary:

PAGE: [Name]

Accomplish: [Drilled answer — the real outcome, not the surface action]
Notice: [Drilled answer — what and why it matters]
Feel: [Drilled answer — the emotion and why it's right]

Connection check:
- Does what they notice → lead to what they should feel?
- Does what they feel → motivate what they should accomplish?
- If not, flag the gap.

Here's what I'm hearing for [Page Name]. Does this feel right? Anything that surprises you or doesn't sit well?

Wait gate: Confirm before moving to the next page.

Repeat for each page/flow

Move through the agreed-upon list, one at a time. Each page gets the full three-question treatment.

---

Step 3: Cross-Page Coherence

After all pages are complete, look across the full set:

Thread check

• Is there a consistent emotional thread across pages? (There should be)
• Does the "feel" from one page set up the "accomplish" of the next?
• Are there contradictions? (e.g., homepage promises excitement but product page feels clinical)

Bedrock identification

• Across all the drilled answers, is there a single bedrock human need emerging?
• This is the equivalent of Raycast's "flow" or Snapchat's "deepen your relationships"
• If one emerges, name it. If not, that's a finding worth surfacing.

Present:

Looking across all your pages, here's the thread I see:

>

Bedrock: [The core human need this product/site serves]

>

Thread: [How it flows from page to page]

>

Gaps: [Where the thread breaks or contradicts]

>

Does this resonate?

Wait gate: This is the most important confirmation point. The bedrock shapes everything downstream.

---

Step 4: Intent Brief

Produce a structured brief the user can reference when making design decisions. This is the output artifact.

Deriving design implications

For each page, derive 1-2 design implications directly from the drilled answers. These are not generic UX advice — they're choices that would only be right for this product's bedrock.

• Connect the implication to the bedrock, not to general best practices
• If the bedrock is "flow," the implication isn't "reduce clutter" — it's "every interaction should feel like it disappears into the task"
• If the bedrock is "deepen relationships," the implication isn't "add social features" — it's "every screen should feel like you're close to the people you care about"
• Use the connection check as your derivation: what notice → feel → accomplish chain does this page need, and what design direction serves that chain?

INTENT BRIEF: [Project Name]

Bedrock: [The core human need, one sentence]

---

[Page Name]
- Accomplish: [Grounded outcome]
- Notice: [What and why]
- Feel: [Emotion and why it's right]
- Design implication: [What this means for visual/copy/interaction choices]

[Page Name]
- Accomplish: ...
- Notice: ...
- Feel: ...
- Design implication: ...

---

Cross-page thread: [How the emotional arc flows]

Anti-patterns to avoid:
- [Specific to this project, drawn from the drilling]

Validation question: For every design choice, ask —
"Can I trace this back through accomplish/notice/feel to the bedrock?"

Here's your intent brief. This is the reference document for design decisions going forward. Every visual choice, copy decision, and interaction pattern should be traceable back to these answers.

---

Success Criteria

This workflow is complete when:

• [ ] Pages/flows identified and confirmed
• [ ] Three questions answered and drilled for each page
• [ ] Cross-page coherence checked
• [ ] Bedrock human need identified (or its absence surfaced)
• [ ] Intent brief produced and confirmed by user