Agentic Experience Design (AXD) is a discipline now. For some it will still feel like an emerging discipline but I think for many it is shaping up in real-time. It has its own vocabulary, definitions, practices and is coming into its own. Some of the terms are Mixed-initiative flow, Harm anticipation, Handoff protocol, Error personality. If you have not heard those terms, this post is about introducing them and giving you the tools to have a go.

Six layers. 42 skills. 18 commands. Installable in your AI agent in one command, free, MIT-licensed, and ready to be used on real work this week. The repo is at github.com/Owl-Listener/ai-design-skills.

The work in the underlying ideas was done by many other people: by alignment researchers and HCI scholars and the agent community over the last three years. What did not exist was the translation layer: the thing that takes a paper from CHI or FAccT and turns it into a skill your AI agent loads automatically when you ask it to design or audit anything. That is the contribution this week. Translating the science into a form designers can actually reach for when they’re mid-flow on a feature.

Six layers mapping the discipline

Each plugin owns one part of the territory you have to cover to design Agentic products well. Seven skills and three commands inside each, the same shape across all six, because the discipline turns out to have a clear shape.

model-interaction-design is how humans and AI take turns. Conversation patterns, mixed-initiative flow (when the user drives, when the AI drives, when they share, when control transfers), progressive disclosure, generative UI, multimodal orchestration. This is the layer most designers feel comfortable in already. Most current Agentic design work has lived here.

ai-alignment-reasoning is the work designers should be involved in and that the technical alignment community specialises in: Harm anticipation, Guardrail design, Transparency patterns, Value specification, Escalation, Consent and agency. The technical alignment teams are working on the inside of the model. This plugin is for the alignment work that has to happen on the design side.

system-behavior-shaping is how the AI shows up in the experience. Persona architecture, tone calibration, behavioural consistency, cultural adaptation, domain voice, emotional design. The skill in this plugin I keep returning to: error personality. “Every AI makes mistakes. Error personality is how it handles those moments. It is often the most revealing aspect of an AI persona, because it is where the mask of competence slips and the user sees the character underneath.” That sentence is not on any design curriculum I have ever seen, and it is the kind of thing every designer making an Agentic product will eventually need to think about.

evaluation is the plugin most designers have not opened yet and most need to. Failure taxonomy, Output quality rubrics, Comparative evaluation, Longitudinal measurement, Task success metrics, User satisfaction signals, Heuristic evaluation for AI specifically, because the Nielsen heuristics from 1994 do not cover hallucination or overconfidence or sycophancy. If you cannot tell whether your Agent is getting better, you cannot ship it responsibly. This plugin is the bridge for that.

design-agent-orchestration is the plugin I expect to grow fastest, because the products being built right now are no longer single-agent: Agent role design, Handoff protocols, State management, Failure recovery, Human-in-the-loop, Observability…The black hole, the echo chamber, the context cliff are anti-patterns real multi-agent products can fall into and naming them helps you avoid them.

prompt-architecture is for the work that does not feel like design but it is. Chain-of-thought design, Constraint specification, Context engineering, Few-shot patterns, Prompt versioning, System prompt structure, Template design. Designers have been writing prompts for roughly two years now and most of us are still doing it as a craft we have not formally learned. This plugin should help with this.

Subscribe now

Wait, alignment? Yes, alignment.

A note on the second plugin, because this is the part of the discipline I want us to consider most.

The technical alignment community has been doing extraordinary work on the inside of the model: RLHF, Constitutional AI, Mechanistic interpretability. It has been a research conversation, and it has been research-shaped.

What is an opportunity for design, is the outside-of-the-model version of the same work. When you write a guardrail that escalates a conversation to a human at the right moment, that is alignment. When you architect a persona that does not collapse under pressure, that is alignment. When you anticipate the harms a feature could cause before you ship it, that is alignment. When you design the right escalation when the model is wrong, that is alignment.

We have been doing this thinking for years and not calling it that, because the only intelligence in the equation was human, and we had other words for it: usability, empathy, guardrails, taste, care. The skills in ai-alignment-reasoning are those words rewritten for the new world, the new audience, the new reader who is now reading our files and acting on them.

How to use the skills, even if you are new to this

Install the skills in your favourite agent and take them for a spin.

Try this question with your agent, exactly as written:

“I am designing an AI assistant for customer support. Help me write the error states for when the assistant does not understand the user’s question. Walk me through the trade-offs.”

Without the skills installed, the agent will give you five generic apologies and move on. With the skills installed, the agent reads error-personality.md and tone-calibration.md, and the response now actively avoids over-apologising, deflection, blaming the user, and the existential crisis pattern. It produces messages with character, opinionated about what good and bad look like for your specific persona. The output is the same words, structured by an entirely different muscle.

That is what the skills do. They give the agent a frame for thinking about your work. Your job is to be there in the loop, push back, redirect, and decide which output is the one to ship.

If you do not use a CLI (command line) agent like Gemini or Claude Code yet, this is the moment to learn one. The browser chat is not where any of this lives. Skills do not load there, instruction files are not read there, and the design surface this post argues for (the file the agent reads at the start of every session) does not exist in a tab. The CLI is where Agentic Experience Design really happens. The earlier you are there, the more you will shape this practice.

What’s next for us

Take this. Install it. Use it on real work. Then tell me what is missing.

The skill files are plain markdown. Editing one is a sentence and a commit. The discipline gets better when more of us write it. If you fork the repo and add a skill eval-design-for-multimodal, cultural-bias-stress-tests, the-thing-you-are-tired-of-explaining please send it back. I want to read it.

Some of these skills will hold up. Some will need to be rewritten. Some are missing. There is nothing yet about the perceptual layer of design, the part that tells the agent what something should feel like, not just how it should behave. I am working on that one elsewhere and a start is mood.md: https://github.com/Owl-Listener/mood-protocol

Here is a great start for you though: Six layers, 42 skills, free, this morning. The repo is at github.com/Owl-Listener/ai-design-skills.

There is a discipline forming, and we are the community of designers shaping it.

Share

Claude Design launched two days ago. You talk to it and it designs. Complex pages that used to take twenty prompts now happen in two. Figma’s stock dropped 7% by close of trading on Friday. The headlines are all about AI versus designers, tools versus jobs, who wins, who loses.

I want to talk about something else.

If you know where to look, there is something extraordinary happening here.

The thing that is visible

Ray Eames had a line that design schools quote so often it has almost lost its meaning.

Let’s note that it does not mention a rendering, a deliverable, a beautifully crafted file.

It underscores a plan: an act of thinking about purpose, and what it demands.

When Claude Design (or any agent assisted design tool) generates a working prototype from a two-sentence prompt, it is not replacing the design. It is rendering what the design already was. The thinking happened in the conversation. The intent happened in the language. The judgment about purpose and person and constraint happened before anything appeared on a screen.

The canvas was where we went to externalise the thinking. Now there is a faster way to externalise it and that means the canvas, which we spent decades treating as the design, has been revealed as something different. It was always the artifact that design thinking left behind.

This is a clarification that has been a long time coming.

Share

What we're trading away

We do owe it to ourselves to be honest about what changes.

The canvas had friction. You would be making something and it would not quite work, and the wrestling with the material, the three pixels that were wrong, the component that refused to behave, would reveal something you had not understood about the problem yet. Constraints imposed by the tool forced clarity about what was essential. Eames worked within the constraints of plywood and fibreglass not despite them but through them. The resistance was the method.

There is something in the making, in the physical negotiation with a medium, that conversation does not fully replicate. I know a designer who says she does her best thinking with her hands and not at a keyboard, she likes moving things around and drawing. I understand that.

Where the friction went

When execution was the hardest part, you could hide weak thinking behind technical skill. A designer who could not articulate why something should be a particular way could still make it beautiful, and beauty was a kind of argument. It often passed the bar with clients and in product teams.

Now the argument has to come first. The intent has to be precise enough, specific enough, purposeful enough to produce the output you actually need. Claude Design will render your clarity faithfully. It will also render your confusion faithfully.

The constraint has shifted from “can I execute this?” to “can I think this clearly enough?”

That is more design, not less. That is design moving up to where it was always supposed to live.

The piece that is still missing

You can brief Claude Design on purpose. You can give it your brand files, your design system, your target user. You can bring genuine clarity to the conversation. It will generate something technically correct, on brand, well structured.

It will still feel oddly wrong.

Here is why: We have given agents procedural knowledge (how to do things) but we have no way of telling them what something should feel like, and for designers (also musicians, architects, artists…), that feeling is the a huge part of job.

Think about how you actually work. Before you open any tool, before a single decision gets made, you have already have an image or a sensation of something in your mind. You have collected images, pinned references, grouped things spatially, written “YES, this energy” on a sticky note next to a photograph. That moodboard is the highest-bandwidth communication tool in your entire workflow. It carries colour temperature, spatial rhythm, typographic character, emotional register, material quality, and a dozen other signals that would take thousands of words to describe, and even then you would lose the texture.

Now look at what we have built for agents. SKILL.md tells them how to write good CSS. System prompts tell them how to behave. Brand guides tell them which colours and fonts to apply.

There is no protocol for how things should feel.

mood.md - the counterpart to SKILL.md

Designers already have the answer. You already curate visual direction. You already know how to communicate aesthetic intent through images. The problem is that this communication happens on a canvas, in a spatial medium, and it has no way to cross the bridge into the text-based world where agents live.

That is what I have been noodling on this past week. It is called mood-protocol, and the idea is really very simple.

Where SKILL.md says “here is how to do things,” mood.md says “here is what it should feel like.”

You take your moodboard, the one you have already made, the one with the sticky notes and the annotations and the spatial groupings and all your scrawls and export it as an image. Upload it to the AI you already use. Paste one prompt. The vision model reads everything: the images, the annotations, the relationships, the things you labelled as references and the things you labelled as anti-references. Then it generates a structured mood.md that any agent can read.

The output is a creative direction brief: colour palette with hex values and semantic names, typographic character, spatial rhythm, emotional register, and an Agent Instructions section that tells any AI exactly how to apply this direction when making design decisions.

One section matters more than I expected: the anti-reference. In design, knowing what to avoid is as valuable as knowing what to pursue. “NOT corporate dashboard” carries as much information as “warm editorial layout.” Maybe more, because it closes off an entire territory of bad decisions before anyone wastes time making them. Eames chose constraints deliberately, because constraints are the method. The anti-reference is a constraint with a name.

The mood.md file lives in your repo. It versions with your code. It is there when you open Claude Design or nay other agent tool and when you come back to a project three months later and need to remember what it was supposed to feel like. It is the felt brief made portable and persistent.

A brand guide tells Claude Design what to apply. mood.md tells it how the result should feel when everything is applied correctly. Those are not the same instruction. One is specification. The other is more about your judgment.

What this means together

The Eames-inspired Test is five questions you answer before you open any design tool. Purpose, person, constraints, the one thing, how you will know it worked. The thinking that should precede the canvas. The field guide I released this week, 46 ways to work with Design Agents effectively, is built around that discipline. The brief before the tool, intent before execution.

mood.md is the companion to that in some ways. The Eames-inspired Test captures the rational brief. mood.md captures the felt brief. Together they are the full picture of what a designer brings to a project, the thinking and the feeling, externalised from the designer’s head and made usable by any agent, any tool, any collaborator.

This is what is actually happening this week, underneath the Figma stock price and the job-displacement headlines.

We are building the infrastructure for design intent. The protocols, the formats, the structured ways of carrying what designers know and feel into a world where the execution layer is increasingly automated. That work is urgent and it is fundamentally design work, even though it looks like it is being done with terminals and markdown files rather than Figma and sticky notes.

The Eames would recognise it immediately. They spent their careers finding new ways to communicate complex ideas to people who did not share their vocabulary. They used films, exhibitions, multi-screen installations, whatever the medium demanded. The medium is different now. The work is the same.

What you can do this week

Run the Eames Test before you open you favourite agent design tool. Answer the five questions for yourself properly. Take ten minutes and let yourself percolate. Let the thinking precede the canvas.

Generate a mood.md for a project you are working on now. Drop your reference images in a folder. See what it surfaces about what you already know but have never written down.

When you are in Claude Design, brief it on feeling, not just function. “Confident but not aggressive. Dense with information but never overwhelming. The kind of interface a person trusts immediately, the way you trust a good doctor.” That is a design brief. That right there is the friction that has moved.

The canvas was never the design. We always knew that.

Now the question is what you build with the time you just got back.

The field guide “46 ways to work with Claude Design” is on GitHub now. mood-protocol is also on Github and both are open source, MIT licensed, free to use.

I’ve been writing about how design is changing in the AI era. About how our processes haven’t kept up. About how the craft is getting serious again.

Then I decided to share some of the tools I’ve been using to learn about working with AI more deeply and to explore what it means for design as a practice. I made a set of design skills you can use with any model and a set of Inclusive design skills.

This has been pretty handy but next I wanted to explore how a group of design agents would perform and play around with that idea. There’s plenty of room for improvement here, but it has been a very fun experiment and I learned heaps.

I created an open-source design workflow system called Designpowers. It gives you a team of 10 AI agents (each a design specialist) who collaborate to run a complete design process. You direct them as the creative director (human in the loop). They do the work, they hand off to each other, and they show you their thinking as they go.

It covers the full pipeline from discovery through shipping, and it’s free on GitHub.

Why this exists

Most AI tools give you one assistant. You ask it something, it answers, and you figure out what to do next. That’s not how design teams work.

Design teams work because a strategist thinks differently from a visual designer, who thinks differently from a content writer, who thinks differently from someone doing accessibility review. The handoffs between those perspectives are where the work gets better. The friction is productive.

I wanted to build that. Not one AI that tries to do everything, but a team of specialists who pass work between each other, challenge each other’s output, and show you the conversation.

Here’s who’s on the team:

• The design-strategist builds your flows, information architecture, personas, and design principles.

• The design-scout does competitive research and pattern analysis.

• The design-lead handles visual design — layout, colour, typography, components.

• The motion-designer takes care of animation, transitions, and micro-interactions.

• The content-writer writes interface copy at Grade 6 reading level.

• The design-builder converts specs into production code.

• The accessibility-reviewer runs WCAG and COGA evaluations on everything the team produces.

• The design-critic reviews the work against your brief and principles, finding the gaps nobody else caught.

• The inspiration-scout handles aesthetic references, cross-domain inspiration, mood boards.

• The heuristic evaluator evaluates a design against established usability heuristics (Nielsen’s 10) and conducts cognitive walkthroughs of key tasks.

Ten specialists all using one shared design state document where all their decisions and conversations accumulate with you directing the whole thing. Here’s an example from my Design Lead:

◆ design-lead:
So we've got four open threads — the 320px copy change, the coral AAA question, the breathing pulse concern, and the deferred goal-setting risk. The critic says proceed, and I agree we can ship this. But I want to hear from you: do you want to resolve any of these before we hand off, or are you happy shipping and tracking them as follow-ups? And would you like to run the retrospective to lock in what we learned?

What I learned building it

The act of encoding a design process forces you to decide what the handoffs actually are. When does strategy end and visual design begin? What does the content writer need from the strategist before they can start? What happens when the accessibility reviewer and the design critic disagree? You need a reconciliation step, or the fix round becomes chaos.

The system that emerged has 13 phases:

Discover → Research → Strategise → Taste → Inspire → Plan → Design → Build → Taste Check → Review → Fix → Ship → Retrospective

The bolded phases are where Designpowers diverges from a standard design pipeline: taste, inspiration, mid-build taste checks, and structured retrospectives.

The agents move through them in sequence, but the interesting part is what happens between them. They write conversational handoff messages you can read. You can watch the design-strategist explain their reasoning to the design-lead. You can see the accessibility-reviewer push back on the builder’s implementation. It’s transparent in a way that most AI tools are not.

I also learned that control matters.

• In Direct mode, the pipeline pauses at every handoff for your approval. You steer each transition.

• In Auto mode, the agents run the pipeline themselves but with safeguards.

They’ll pause if an agent recommends rethinking the approach, or if the reviewers disagree with each other. You can switch between modes mid-run. Say “go auto” when you trust the direction. Say “pause” when you want your hands back in.

How the system handles taste

Designpowers asks for your aesthetic instincts early: references you admire, how something should feel, what you'd hate. If you have an existing design system, it extracts the taste signals already embedded in your tokens and palette. Then it carries that judgment through every decision the agents make.

The system also remembers: your taste profile persists across projects, strong opinions confirmed over time, soft patterns that are still forming, and anti-patterns you've rejected.

Each new project starts with what the system already knows about you. During the build, it pauses at strategic checkpoints to show you intermediate output and ask specific questions: "is this weight right, or bolder/lighter?", it catches mismatches before they compound.

The idea is simple: agents can verify that a design is correct, aligned to the brief, accessible, consistent. They can't tell you whether it's beautiful. That's your job.

This isn’t about replacing designers

This isn’t a replacement for design judgement. It’s an amplifier for it. A solo designer using Designpowers gets a structured process and a team of specialists they couldn’t afford to hire. A design lead gets a faster starting point for the parts of the work that are structurally predictable, freeing up attention for the parts that aren’t.

How to use it

You can use Claude Code or any other AI coding tool that works in your terminal, VS Code, or browser. Just add Designpowers by cloning the repo and copying the skills and agents folders into your tool’s instruction directory. Everything is on GitHub.

Here’s a few examples of what you can do:

1. Run a full design process in direct mode: tell it: “I’m designing a medication reminder app for elderly users. Run the full Designpowers pipeline, I want to approve each handoff.”

2. Quick discovery for a smaller project: tell it: “I need a quick discovery for a settings page redesign. Focus on pain points and competitive patterns, then go straight to design.”

3. Go auto for rapid iteration tell it: “Go auto. Design a responsive dashboard for a logistics company. Pause if reviewers disagree or if there are critical issues.”

4. Talk to a specific agent tell it: “I want to work with the design-critic directly. Here’s the mockup, what’s missing?”

Each one gives you a structured design process run by a team of specialists, with every decision documented and every handoff visible.

It’s MIT licensed. Use it, fork it, improve it. If you build something that’s missing, I’d genuinely love a contribution.

What’s next

Designpowers pairs with Jesse Vincent’s Superpowers (which handles engineering: testing, code review, deployment) to cover the full development cycle. Together they’re a proof of concept for something I care a lot about: that a structured, multi-agent design process can work.

I’m curious what happens when more designers start building workflows like this. Not just using AI, but shaping how it works together so that when you ask it to design something, the answer comes from a process, not a guess.

If you try it, I’d love to hear what works, what’s missing, and what you’d build differently. Drop a note in GitHub Issues.

Most accessibility failures don’t originate in code. They originate in design decisions made weeks or months earlier.

Last week I published 63 design skills for Claude. The response surprised me, not just the downloads and forks, but the messages. Designers telling me they’d started encoding their own knowledge. Product leads forwarding the repo to their teams. Engineers telling me how much better the results were than starting with the UI.

Every accessibility skill set that exists for AI coding agents is engineer-facing. They audit code. They check WCAG conformance. They validate ARIA attributes and flag contrast ratios. They catch problems after the design decisions have already been made.

By the time an automated audit catches it, the cost to fix it has multiplied tenfold.

I wanted something that nudged me earlier, during design, not after code existed. Building these skills forced me to go much deeper into accessibility than I had before.

Subscribe now

What I built

40 skills and 18 commands across 6 plugins, covering the design side of accessibility:

Cognitive accessibility — designing for how people actually think. Cognitive load assessment, plain language, wayfinding, focus and attention, memory load reduction, error prevention, contextual help, and adaptive personalisation. Grounded in the W3C Cognitive and Learning Disabilities Accessibility Task Force (COGA) guidelines.

Inclusive interaction — designing for how people actually move and perceive. Keyboard navigation, touch targets, voice interaction, multi-modal input, motion sensitivity, gesture alternatives, and feedback that works across senses.

Accessible content — structuring content that works for everyone. Meaningful alt text, heading hierarchy, readable content, link text, table accessibility, form labelling, and multimedia accessibility.

Inclusive personas — building user stories and personas that include disability from the start. Not as a separate “accessibility persona” on a slide nobody looks at, but woven into the real picture of who uses your product.

Adaptive interfaces — designing systems that respect user preferences. System preference detection, responsive accessibility, flexible typography, colour independence, simplified views, and information density.

Accessibility decisions — the plugin nobody thinks to build. Documenting why accessibility decisions were made so they survive team changes, redesigns, and the inevitable “why is it like this?” from someone who wasn’t in the room.

The whole collection is free, open source, MIT licensed, and model-agnostic. The skills use the universal SKILL.md format — they work with Claude Code, OpenAI Codex, Gemini CLI, Cursor, and anything else that supports the standard.

Browse the full collection on GitHub →

Why this is different from what exists

The accessibility tools that exist for AI agents ask: does this code comply?

These skills ask: are we making the right design decisions for the humans who will use this?

That’s a fundamentally different question, and it needs to be asked at a fundamentally different point in the process before code, not after.

Here’s what that looks like in practice.

Type /cognitive-accessibility:review and your AI agent runs a full cognitive accessibility review of a flow, assessing cognitive load, plain language, wayfinding, error handling, focus design, and memory demands. It doesn’t check your HTML. It evaluates whether a tired, stressed, unfamiliar user can complete their task without help.

Type /inclusive-personas:generate and it builds a persona set that includes disability as a natural dimension of human diversity with specific assistive technology, specific environments, and specific scenarios that show step by step how someone navigates your product with their actual setup.

Type /accessibility-decisions:handoff and it generates an accessibility specification for engineering, not “make it accessible” but specific HTML elements, keyboard behaviours, screen reader announcements, and test cases for every interactive component.

These are design tools that happen to result in more accessible products.

The skill that surprised me most

When I started building, I assumed the cognitive accessibility plugin would be the hardest. It wasn’t really. The COGA guidelines from W3C gave me a strong framework, and once I had the eight objectives mapped to design patterns, the skills wrote themselves.

The hardest plugin was accessibility decisions.

It’s because the problem it solves is cultural, not technical. The reason accessibility degrades over time isn’t that teams make bad decisions. It’s that good decisions aren’t recorded, so they get reversed by people who weren’t in the room when the decision was made.

A new engineer joins. They see a form with inline error messages and think “a summary banner at the top would be cleaner.” They refactor. They’ve just undone three weeks of user testing that showed participants with cognitive disabilities couldn’t find the banner.

That’s a knowledge preservation problem and it’s exactly the kind of problem that skills are built to solve: encoding institutional knowledge so it persists beyond any individual’s tenure.

Who this is for

If you’re a designer, these skills help you build accessibility into your process from the start, not bolt it on at the end. The cognitive accessibility and inclusive interaction plugins will change how you think about every flow you design.

If you’re a product manager, the inclusive personas and accessibility decisions plugins give you the tools to make informed tradeoffs — and document them so you’re not relitigating the same decisions every quarter.

If you’re an engineering lead, the accessibility decisions handoff skill gives you what you’ve always wanted: a specific, testable accessibility specification instead of a vague instruction to “make it accessible.”

If you’re an accessibility practitioner, these skills amplify your impact. Instead of reviewing every design yourself, you can equip every designer on the team with the knowledge to get it right the first time.

If you build products used by humans, these skills encode a simple principle: accessibility is a design commitment, not a compliance checkbox.

How to use them

With Claude Code

Install everything:

claude install github:Owl-Listener/inclusive-design-skills

Or install a single plugin:

claude install github:Owl-Listener/inclusive-design-skills/cognitive-accessibility

With other AI agents

The skills use the universal SKILL.md format. Copy the skill folders into your tool’s skills directory. They work with Codex, Gemini CLI, Cursor, and any tool that supports the standard.

Without a coding agent

Open any SKILL.md file on GitHub, copy the contents, and paste it as context at the start of a conversation with whatever AI assistant you use. The frameworks and decision criteria work regardless of the tool.

What comes next

This is version 1. It’s comprehensive, but it’s not complete, no accessibility resource ever is.

I particularly want contributions from people with lived experience of disability. The CONTRIBUTING.md has guidelines, and the principle is simple: nothing about us without us.

If you try these skills and find something missing, something wrong, or something that could be better, please open an issue or a pull request. That’s how this gets better over time.

Get the skills on GitHub →

Last weekend I built skills to make builders more effective. This week I built skills to make products more inclusive. I don’t think those are different goals. I think they’re the same goal, seen from different angles.

The best design is the design that works for the most people in the most contexts. That’s not a nice-to-have. It’s the craft.

I’ve been writing about how design is changing in the AI era. About how the processes we rely on are failing us. About how the craft is getting serious again.

This week I did something different. I stopped writing about the shift and started building for it.

I created an open-source collection (with my friend Claude) of 63 design skills and 27 commands for Claude Code. They’re organised into 8 plugins that cover the full breadth of what designers typically do: research, systems, strategy, UI, interaction design, prototyping and testing, design ops, and the everyday toolkit stuff like writing rationale and building case studies.

It’s called the Designer Skills Collection, and it’s free on GitHub.

Subscribe now

Why this exists

Most AI tools treat design as image generation. That’s never been what design is.

Design is knowing when to run a heuristic evaluation instead of a usability test. It’s understanding that a design token isn’t just a hex code: it’s a decision about how a system scales. It’s writing a problem statement that’s specific enough to be useful and broad enough to leave room.

None of that knowledge existed inside Claude so I taught it.

Each skill is a structured markdown file that gives Claude deep, specific knowledge about a design domain. When you ask Claude to help you create a user persona, it doesn’t guess. It draws on the same frameworks an experienced researcher would: demographics, goals, frustrations, behavioural patterns, context of use. When you ask it to audit a design system, it works through token coverage, naming consistency, accessibility compliance, and theming support.

The commands chain these skills together into workflows.

Type `/discover` and Claude runs a full research discovery cycle. Type `/strategize` and it builds a UX strategy from vision through to metrics. Type `/handoff` and it generates a developer handoff package with measurements, behaviours, edge cases, and a QA checklist.

What I learned building it

Building this taught me something I wasn’t expecting.

The act of encoding design knowledge (I mean really encoding it, not summarising it) forces you to articulate what you actually know. What’s essential to a component spec versus what’s habit. What makes a design principle genuinely useful versus decoratively aspirational. Where your expertise is deep and where it’s shallow.

It’s a strange kind of audit. Not of a design system, but of yourself as a designer.

I also learned that the structure matters more than the content. Claude doesn’t need paragraphs of theory. It needs clear frameworks, decision criteria, and an understanding of when to apply what. The skills that work best are the ones that mirror how an experienced designer actually thinks through a problem, not how a textbook explains it.

This isn’t about replacing designers

I want to be clear about what this is and isn’t.

This isn’t a replacement for design judgment. It’s an amplifier for it. A junior designer using these skills will get better scaffolding. A senior designer will get a faster starting point for the parts of their work that are structurally predictable, freeing up attention for the parts that aren’t.

The creative leaps, the taste, the intuition, the ability to read a room and know which research finding actually matters…that’s still ours. But the frameworks, the checklists, the structural knowledge that we carry around in our heads and deploy when needed? That can be shared with a tool that’s already in our workflow.

How to use it

You’ll need Claude Code — Anthropic’s agentic coding tool that works in your terminal, VS Code, or browser. If you haven’t used plugins before, the marketplace guide walks you through it. Once you’re set up, add the collection:

/plugin marketplace add Owl-Listener/designer-skills

Then browse and install whichever plugins you want through the /plugin menu. If you just want to look at the structure, everything is on GitHub.

It’s MIT licensed. Use it, fork it, improve it. If you build a skill that’s missing, I’d genuinely love a contribution.

Here’s a few examples:

1. Run a full research discovery cycle type /design-research:discover then tell Claude: "I'm designing a habit-tracking app for people recovering from burnout. Run a full discovery cycle — personas, empathy map, and journey map."

2. Generate an accessible colour palette type /ui-design:color-palette: then tell Claude: "Create a colour system for a health and wellness brand. I need primary, secondary, neutral, and semantic colours, all passing WCAG AA."

3. Build a developer handoff package type /design-ops:handoff: then tell Claude: "Generate a handoff spec for a settings page with a profile section, notification preferences, and a danger zone for account deletion."

4. Run a heuristic evaluation type /prototyping-testing:evaluate: then tell Claude: "Run a heuristic evaluation of a checkout flow with these steps: cart review, shipping address, payment, and confirmation. Flag usability issues by severity."

5. Write a case study for your portfolio type /designer-toolkit: write-case-study: then tell Claude: "Help me write a portfolio case study. The project was a redesign of an internal dashboard for a logistics company. We reduced task completion time by 40%. Walk me through the full structure."

Each one gives you something tangible in a few minutes: a full persona set, a production-ready colour system, a handoff doc engineers can actually use.

What’s next

I’m curious what happens when designers start encoding their own knowledge this way. Not just using AI, but teaching it. Shaping what it knows about our discipline so that when it’s asked a design question, the answer reflects real craft and not a surface-level approximation.

Obviously (need I say) this is no workaround for having experienced researchers and designers on your team.

If you try it, I’d love to hear what works, what’s missing, and what you’d build differently.

The opinions expressed in this article are solely those of the author and do not reflect the official position of any institution or organization.

Share

A few weeks ago, I was reading about ship strikes on whales. The numbers are hard to ignore:

• 20,000+ whales killed by ships annually (International Whaling Commission)

• One whale death every 26 minutes from vessel collisions

• North Atlantic right whales down to just 340 individuals - extinction possible within decades

• 80% of ship strikes could be prevented with better detection technology

Here's what really motivated me: we have the technology to solve this. We just need better, more accessible whale detection systems deployed at scale. I wondered if AI could help tackle a problem like this. Unsurprisingly, building a fully deployable system is a huge undertaking but I wanted to tinker and learn, so I treated it as a weekend-style project to see what was possible in a few hours.

Sources: NOAA Marine Mammal Ship Strike Database, International Whaling Commission Ship Strike Report, North Atlantic Right Whale Consortium

Whale detection technology isn’t science fiction, several commercial and pilot systems already exist. Woods Hole Oceanographic Institution has developed thermal-imaging cameras with AI that can spot whales in real time from ships. The Whale Safe system combines acoustic buoys, visual sightings, and predictive models to send AIS alerts to vessels in high-risk areas. Companies like FarSounder are using forward-looking sonar to detect whales underwater before a collision occurs.

My EchoWhale experiment isn’t meant to compete with these, it’s a small, hands-on way to understand how such systems might work.

Subscribe now

One Afternoon, Claude, and Me

I hadn’t touched neural networks in about a decade. My Python was patchy. I’d never processed audio before. So I opened my trusty notebook, sketched some ideas, fired up Claude, and started asking questions.

By the end of the afternoon, we had a small, working thing:

• A basic neural network that could recognise synthetic whale calls.

• An audio pipeline to turn sounds into spectrograms.

• Some simple noise handling and visualisations.

It was all built on fake data we generated mathematically. In other words, the AI had never heard a real whale, only our computer-generated versions.

In controlled, lab-like conditions, it got everything right. In the real ocean, it probably wouldn’t work as is. But the point was that I could go from zero to something in a few hours and learn a lot along the way.

What I Learned

I also have to say, using Cursor made this whole thing so much easier. Setting up Python, installing libraries, and getting everything running used to feel like a mini-project in itself. With Cursor, it was smooth, and I could focus on actually building rather than wrestling with my environment.

I used Cursor to actually write and run the code, and Claude as my endlessly patient co-pilot for all the “wait, explain that again” moments. Keeping the chat separate from the editor meant I could tinker in peace without my code window turning into a wall of questions.

And let’s be honest: I spent a lot of time asking Claude to explain things to me… again and again. In the past, that’s the kind of thing I’d text my good friend Tom about (“Why won’t my code work?!”). Now, instead of pestering him, I could get the same patient explanations on demand and try things out right away.

Some of these libraries and tools felt daunting, but having that instant back-and-forth made me a lot more confident. By the end of the afternoon, I actually understood how the pieces fit together.

• Building teaches faster than reading. I learned more about modern AI in one afternoon than I had in years of passively reading about it.

• “Good enough” is good enough to start. Synthetic whale calls aren’t the real thing, but they were enough to explore the problem.

• AI-assisted coding is like having a patient tutor. Claude handled the boilerplate and explained things as we went, leaving me to focus on the shape of the solution.

• Tinkering lowers the barrier. You don’t need to be an expert to start. You just need curiosity and a free afternoon.

The next steps for something like this would be huge: gathering real hydrophone data, testing in noisy marine environments, partnering with researchers and shipping companies. That’s years of work and collaboration.

EchoWhale

Let's be realistic about what EchoWhale actually is:

• Trained on synthetic data - We synthetically generated calls for blue, humpback, and fin whales and trained a classifier on those labels.

• Controlled test environment - perfect lab conditions, not chaotic ocean reality

• Afternoon project scope - proof-of-concept, not production system

• Academic exercise - demonstrates feasibility, needs real-world validation

Here’s the output:

Below is a snapshot of what the AI “sees” when it listens to real whale recordings. Each panel is a spectrogram that shows how sound energy changes over time and across different frequencies.

• Top left: Blue whale call – You can see the deep, rumbling pulses spaced a few seconds apart, bright at the very bottom of the frequency range.

• Top right: Humpback whale call – These appear as sweeping diagonal lines, climbing in pitch over time — humpbacks are famous for these melodic, rising notes.

• Bottom left: Ocean noise – A fuzzy, continuous band of energy, with no clear “call” patterns, representing background underwater sound.

• Bottom right: Mixed recording – A combination of whale calls and background noise, showing how the patterns blend in more realistic, noisy conditions.

In all four, brighter colours mean louder sounds at those frequencies. The AI learns to distinguish the clear patterns of whale calls from the messy texture of ocean noise which is a crucial step toward detecting whales in the wild.

Why Share This?

Because I think more of us should feel free to tinker, especially with conservation problems. The tech is here. The data exists. And the leap from “I can’t” to “I built a thing” might be smaller than you think.

If you’ve been sitting on an idea, waiting until you feel ready maybe just start. Even if it’s messy and nowhere near perfect.

Technical stuff

Skip ahead if you’re not into code

Technical Stack & Tools

Development Environment:

• Python 3.13 in virtual environment

• Cursor

• Claude as AI coding assistant

• Git version control → GitHub deployment

Core Libraries:

• PyTorch - Neural network framework

• librosa - Audio processing & mel-spectrogram generation

• NumPy - Mathematical operations

• Matplotlib - Data visualization

• SciPy - Signal filtering & processing

AI Architecture

Neural Network Design:

• Convolutional CNN for spectrogram analysis

• Conv2D layers with ReLU activation

• MaxPooling for feature reduction

• Dropout layers for regularization

Data Generation Approach

Synthetic Whale Calls:

• Blue whale: Low-frequency pulses (15-30 Hz) with harmonics

• Humpback: Frequency sweeps (80-400 Hz) with modulation

• Ocean noise: Filtered random signals mimicking real ocean acoustics

• Mixed scenarios: Whale calls + background noise

Audio Processing Pipeline:

• Convert audio to mel-spectrograms

• Normalize frequency ranges (0-1000 Hz focus)

• Feature extraction using librosa

• Real-time visualization of AI decision-making

Development Method: Real-time collaboration between human and AI coding assistance, with iterative building and testing throughout the afternoon.

What's Missing for Production:

• Real ocean recording validation (we used mathematical whale call simulations)

• Robustness testing in actual marine noise environments

• Performance optimization for real-time processing requirements

• Integration with maritime navigation systems

• Regulatory compliance and safety certifications

Get the complete EchoWhale code on GitHub and start building your own conservation technology.

Ready to build your conservation AI project? The ocean needs more builders like you. Start this weekend.

Share

Winglet is a personal experiment I built to learn how to go end-to-end with AI from idea to launch , with something that brings me joy 🦅

Winglet is a beautifully simple birdwatching app designed for beginners and lifelong bird lovers alike. It helps you track which birds you've seen, explore nearby species, listen to bird calls, and learn how to protect local wildlife. It’s available on mobile, lightweight, and totally login-free for now.

Check it out on your phone:https://lnkd.in/ej8mF-yk

I used Lovable to bring it to life and loved the experience of using dev mode for more control. Huge thanks to the team for making such a delightful platform to lean on 🙌

Curious to hear what you think and if you’re a bird nerd too, I’d love to know what would make this more useful or fun for you (apart from fixing some of my bugs!)

👉 You can vote for it here: https://lnkd.in/eZvAGpA

✨ Why build a birding app?

Winglet is part of a wider philosophy I call slow design: a movement toward crafting software that invites presence, curiosity, and care. Birdwatching embodies that. It’s not about hustle. It’s about attention. You slow down. You listen. You look up.

With Winglet, I wanted to create a digital companion that didn’t distract from that, but deepened it. Something that didn’t overcomplicate things with badges and logins and likes. Just a simple way to say:

“Hey, that’s a spotted towhee. Isn’t it beautiful?”

🌏 Built with love (and real data)

Winglet uses real-time eBird data to tell you what birds are nearby right now. We’ve added features like:

• "What to Watch For" – seasonal cards based on local sightings

• "Migrants Passing Through" – a gentle guide to what species are flying overhead

• Sound Exploration – play recent bird calls to help you learn what you’re hearing

All presented in a calm, modern interface that feels as thoughtful as the practice it supports.

🌱 What’s next

I'm just getting started. Next, I’d love to:

• Add location-aware conservation tips

• Let users create “field notes” to accompany their sightings

• Explore AI-generated illustrations and soundscapes based on user experience

• Introduce seasonal quests (like spotting spring returners or nocturnal singers)

And maybe… Remix it for ocean life?

If you want to experience Winglet for yourself, just head outside and open winglet.app. No sign-in. No stress. Just birds.

Subscribe