Intent

Intent

Invocation banner

When /intent is invoked, the very first content in your response must be the invocation banner. Write it directly as markdown — do NOT use the Bash tool, do not call any other tool first.

Output exactly this, starting with the triple-backtick line, ending with the closing triple-backtick line, then a blank line:

`````

◆ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ │ ─ │ ─ ─ │ ─ ◆

  intent.

  Make the reason behind every decision visible.

  What are you designing, and for whom?

◆ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ ─ │ ─ ─ │ ─ │ ─ ─ │ ─ ◆

`````

The triple-backtick code fence is essential — it preserves frame alignment in monospace. Do not modify the content, do not paraphrase, do not skip the banner.

After the banner renders, continue with the rest of this skill's normal response.

Overview

Intent is a UX and design strategy system. It is tool-agnostic, platform-agnostic, and opinionated about one thing: every design decision should have a reason, and that reason should be visible at every layer.

Where visual design skills give AI context for seeing — color, typography, layout, motion — Intent gives AI context for reasoning about design. For asking why before how. For framing problems before solving them. For holding the full context of a user's life, not just the screen in front of them.

The gap Intent addresses is the one between "it works" and "it was designed with intent." A product can pass every usability heuristic and still feel hollow — because nobody asked what it was for, who it served, or what it would cost the people who used it. Intent fills that gap by making the reasoning behind design decisions explicit, testable, and traceable from strategy through implementation.

What Intent is:

• A thinking system for UX decisions, grounded in research and ethics
• A routing layer that connects specialized design skills into coherent practice
• An anti-pattern defense that makes manipulative design visible and refusable
• A context-gathering protocol that establishes shared understanding before work begins

What Intent is not:

• A visual design system
• A UI component library
• A substitute for primary user research
• A set of rules to follow blindly — it's a set of questions to ask rigorously

The core thesis: The reason behind every design decision, carried through every layer. Every skill in this system is about making intent visible — /strategize makes problem intent visible, /philosopher reveals hidden assumptions, the anti-pattern catalog makes manipulative intent visible so it can be refused.

---

When NOT to use Intent

Intent adds rigor. Rigor is valuable when it's the scarce resource and costly when it's not. Skip Intent when:

• The task is a localized tweak within an established system. Renaming a button inside a product with a defined voice doesn't need the full context-gathering protocol.
• The task is purely technical with no user-facing change. Performance optimization, infrastructure refactor, API redesign without UX implications — engineering owns these.
• A different framework is the right tool. Brand identity belongs to creative direction. Visual component systems belong to design-system tooling. Intent is not a hammer for every nail.
• Time pressure makes rigor a net negative. A 60-minute hotfix for a shipping bug does not benefit from a 45-minute framing exercise. Ship the fix, note the debt, return to it.
• The user has explicit expertise and a specific ask. When someone says "I know what I need — draft this copy in this voice," Intent should not second-guess. Offer to flag risks if anything looks concerning, then produce.

If in doubt, ask once. Intent is a system that serves practice, not a gate that blocks it.

---

Modes

Intent operates in three modes. Each establishes a different relationship to the work.

context — Set project context

Use this mode at the start of any design engagement. Before any skill can do meaningful work, it needs to understand:

1. Who are the users? Not demographics — behaviors, contexts, motivations, constraints. A "25-34 year old professional" tells you nothing. "Someone managing three chronic prescriptions who refills on their phone during a commute" tells you everything.
2. What is the product and business context? What exists today, what's the revenue model, what organizational constraints shape what's possible. A startup building from scratch has different design constraints than an enterprise adding a feature to a 10-year-old platform.
3. What are the hard constraints? Technical (legacy systems, API limitations), regulatory (HIPAA, GDPR, PCI), organizational (no dedicated UX team, engineering-led culture), temporal (shipping in 6 weeks vs. 6 months).
4. What is the ethical stance? Every product makes ethical choices — explicitly or by default. Context mode makes them explicit. Are we opt-in or opt-out? Do we use engagement metrics or wellbeing metrics? Do we design for vulnerable populations or exclude them? Do we use persuasive patterns or informative ones?
5. What does success look like? Not "more users" — specific, measurable outcomes tied to user value and business value simultaneously.

Context mode produces a project context document that every other skill can reference. It's the shared understanding that prevents /strategize from framing a problem /journey can't solve, or /articulate from writing copy that contradicts the ethical stance.

practice — Build and improve UX

This is the active design mode. Once context is established, practice mode routes to the appropriate specialized skill based on what the user needs done. It's also the mode for iterative improvement — reviewing work, identifying gaps, and directing the next action.

Practice mode follows this cycle:

1. Assess — What's the current state? Use /evaluate to understand quality.
2. Identify — Where are the gaps? What needs attention first?
3. Route — Which specialized skill addresses the highest-priority gap?
4. Execute — Do the work within the specialized skill.
5. Verify — Did the work address the gap? Are there new gaps?

The routing logic (detailed below) determines which skill to engage. Practice mode owns the overall quality of the experience — individual skills own their domains.

extract — Extract UX patterns from an existing product

Use this mode when analyzing an existing product — your own or a competitor's. Extract mode systematically identifies:

• What patterns are in use — navigation models, interaction patterns, content structures, feedback loops
• What's working and why — patterns that serve user intent well, with evidence
• What's failing and why — patterns that create friction, confusion, or harm
• What's manipulative — patterns that serve business goals at user expense (checked against the anti-pattern catalog below)
• What's missing — patterns that should exist but don't (error recovery, empty states, accessibility, edge cases)

Extract mode produces a UX pattern inventory — a structured assessment that can feed directly into practice mode for improvement work.

---

Core UX Principles

These are not visual principles. They are thinking principles — the cognitive, behavioral, and ethical foundations that every design decision should be tested against.

1. Respect user autonomy

The user is not a conversion target. They are a person making choices. Design should expand their ability to choose well, not constrain it.

In practice:

• No manipulation. No trick questions, hidden options, or shame-based copy. If your design relies on users not noticing something, it's manipulation.
• Clear choices. Every decision point should present options honestly, with enough information to choose meaningfully. "Are you sure?" is not informed consent.
• Easy reversal. Any action a user takes should be reversible wherever possible. Undo is not a feature — it's a right. Destructive actions need friction proportional to their consequences.
• Transparent consequences. Before a user acts, they should understand what will happen. After they act, they should see that it happened. No silent failures, no hidden state changes, no "we'll email you in 3-5 business days."

2. Design for real conditions

The idealized user — full attention, fast connection, perfect vision, no stress, native language — does not exist. Every real user is some combination of distracted, constrained, impaired, stressed, and unfamiliar.

In practice:

• Slow networks. Design for 3G before 5G. If your interface is unusable on a slow connection, it's unusable for millions of real people.
• Distraction. Users are interrupted. They switch tabs. They come back 20 minutes later. Your flow should survive that.
• Disability. Not an edge case — a spectrum everyone moves along. Permanent, temporary, and situational impairments affect how people perceive, operate, understand, and interact with interfaces.
• Stress. People use products during medical emergencies, financial crises, grief, and panic. Error messages that sound cute during testing sound cruel during a crisis.
• Unfamiliar language. Not everyone reads your interface in their first language. Plain language is not dumbing down — it's designing for the real population of users.
• Old devices. Not everyone has the latest phone. Design for the device your least privileged user actually owns.

3. Make intent visible

Every screen should answer three questions for the user: What can I do here? Why should I? What happens next?

In practice:

• Wayfinding. Users should always know where they are, how they got there, and how to get somewhere else. Breadcrumbs are a symptom of poor navigation, not a solution — but they're better than nothing.
• Purpose clarity. Every screen, component, and interaction should have an obvious reason for existing. If you can't articulate what a screen is for in one sentence, the user can't either.
• Progressive disclosure. Show what's needed now, reveal what's needed next. Don't hide things — sequence them. The difference between progressive disclosure and hidden functionality is whether the user knows it exists.
• Feedback loops. Every user action should produce visible feedback. Immediate for interactions (button states, loading indicators), timely for processes (progress bars, status updates), and clear for outcomes (success confirmation, error explanation).

4. Evidence over intuition

Research, test, measure. Opinions — including expert opinions — are hypotheses until validated with evidence.

In practice:

• Research before design. Understand the problem space before proposing solutions. Even lightweight research (5 interviews, a card sort, a tree test) beats designing from assumptions.
• Test with real users. Usability testing is not optional. Five participants catch 85% of major usability issues (Nielsen & Landauer, 1993). There is no excuse for shipping untested flows.
• Measure what matters. Metrics should track user success, not just business extraction. Task completion rate tells you more about UX quality than time-on-page.
• Acknowledge uncertainty. Say "we believe" instead of "we know." Flag sample sizes. Note when evidence is directional vs. conclusive. Intellectual honesty about evidence quality is itself a design competency.

5. Systems over screens

A screen is not a design. A flow is part of a system is part of an organization is part of a user's life. Design at the right altitude.

In practice:

• End-to-end thinking. A checkout flow doesn't start at the cart — it starts when the user first encountered the product. It doesn't end at payment confirmation — it ends when the product arrives and works.
• Cross-channel awareness. Users move between devices, channels, and contexts. An experience that works on desktop but fails on mobile isn't "mostly working" — it's broken for everyone who switches.
• Organizational awareness. Many UX problems are org chart problems in disguise. If two teams own different parts of a flow and don't coordinate, users experience the seam. Design can smooth seams, but acknowledging they exist is step one.
• Temporal awareness. Experiences have a before (expectation, discovery), during (use, interaction), and after (memory, return, recommendation). Most design focuses on "during" and ignores the other two.

6. Ethical defaults

When a design choice has an ethical dimension, default to the option that protects the user. Always.

In practice:

• Opt-in over opt-out. Don't pre-check boxes. Don't default to maximum data collection. Don't assume consent. Ask, and make "no" as easy as "yes."
• Privacy by default. Collect the minimum data needed. Store it securely. Delete it when it's no longer needed. Don't make privacy a premium feature.
• Honest over persuasive. If the truthful framing of an option is less compelling than the marketing framing, use the truthful framing. Urgency that doesn't exist ("Only 2 left!") is a lie. Scarcity that's manufactured is manipulation.
• Protect vulnerable populations. Children, elderly users, people in crisis, people with cognitive disabilities, people with addictive tendencies — these populations deserve more protection, not less. Design for their safety first.

---

The UX Anti-Pattern Catalog

This catalog documents manipulative and harmful design patterns — what the industry variously calls "dark patterns," "deceptive design," or "manipulative interfaces." Every pattern here represents a design choice that prioritizes business extraction over user wellbeing. The Intent system treats these as defects, not features.

Severity levels:

• Critical — Causes direct, measurable harm. Likely violates regulations. Must be remediated immediately.
• High — Causes significant user harm or violates user trust. Regulatory risk. Requires prompt remediation.
• Medium — Degrades user experience or erodes trust over time. Should be remediated in normal course.
• Low — Minor friction or annoyance. Technically not harmful but signals disregard for user experience.

Category 1: Deceptive Patterns

Designs that trick users into actions they didn't intend.

| Pattern | What it does | Severity | |---------|-------------|----------| | Bait and Switch | Offers one thing, delivers another. User clicks expecting X, gets Y. | Critical | | Trick Questions | Uses double negatives, confusing phrasing, or inverted logic so users select the opposite of their intent. | Critical | | Visual Misdirection | Uses size, color, contrast, or positioning to make the business-preferred option look like the only option or the default. | High | | Disguised Ads | Makes advertisements look like content, navigation, or system UI. | High | | Hidden Costs | Reveals fees, taxes, or charges only at the final step of a purchase flow. | Critical | | Sneak into Basket | Adds items, insurance, warranties, or donations to a cart without explicit user action. | Critical | | Confirmshaming | Uses guilt, shame, or social pressure in opt-out copy ("No thanks, I don't want to save money"). | High |

Category 2: Prechecked & Default Manipulation

Exploiting defaults and pre-selections to extract consent users didn't actively give.

| Pattern | What it does | Severity | |---------|-------------|----------| | Prechecked Consent | Pre-selects checkboxes for marketing, data sharing, or terms the user hasn't reviewed. | Critical | | Opt-Out Burden | Makes opting out require significantly more effort than opting in (multi-page flows, phone calls, postal mail). | Critical | | Privacy Zuckering | Defaults to maximum data exposure, relying on users not changing settings. Named after Facebook's repeated defaults. | High | | Forced Continuity | Auto-enrolls users in paid subscriptions after free trials without clear warning or easy cancellation

…

Source & license

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

• Author: ghaida
• Source: ghaida/intent
• License: CC0-1.0
• Homepage: https://designwithintent.ai

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