Coding agents are already good at generating components, copying visual styles, and producing working interfaces quickly.

The harder problem is product judgment.

A repository can show an agent which component shipped. It rarely explains why that component was chosen, which alternatives were rejected, what edge cases mattered, or which user consequence changed the decision.

I built the AudranLab Product Design Agent Skill to place that missing reasoning beside the code.

The goal is not to make an agent imitate a design. The goal is to make its decisions inspectable, repeatable, and grounded in product truth.

Download skill v1.0.0

The problem

Most coding-agent instructions focus on implementation quality:

  • use TypeScript
  • split components
  • follow the design system
  • write tests
  • keep the code clean

Those instructions matter, but they do not answer product questions:

  • Should this be a dialog, page, drawer, or inline disclosure?
  • What should happen when a model provider fails after the user edited a long prompt?
  • How should a RAG interface distinguish source evidence from generated synthesis?
  • What makes a model evaluation credible rather than visually persuasive?
  • When should an autonomous workflow require human approval?
  • Which states are actually reachable, and how does the user recover?

Without explicit guidance, the agent makes these decisions from nearby code and general web patterns. That can produce a coherent interface that is still wrong for the product.

The solution

The AudranLab skill is a repository-local decision system with four layers:

  1. A single runtime skill that resolves the request mode and workflow.
  2. Focused references for product judgment, visual language, accessibility, AI trust, resilience, and implementation.
  3. Surface guides and exemplars for recurring product decisions.
  4. Governance and evaluations that prevent one local preference from becoming an accidental universal rule.
terminal ~
.agents/skills/audranlab-product-design/
├── SKILL.md
├── AGENTS.md
├── references/
│   ├── product-judgment.md
│   ├── design-language.md
│   ├── ai-trust-and-provenance.md
│   ├── implementation-nextjs.md
│   ├── verification.md
│   └── surfaces/
├── exemplars/
├── assets/
└── scripts/

Six operating modes

The skill resolves the task before it changes anything:

  • Shape — Define the problem, flow, states, risks, and acceptance criteria.
  • Implement — Build the smallest complete end-to-end change.
  • Review — Report prioritized findings without silently editing.
  • Copy — Improve user-facing language without turning the task into a redesign.
  • Harden — Fix accessibility, resilience, responsive behavior, and edge cases.
  • Evaluate — Compare variants with a hypothesis, scenarios, metrics, limitations, and a decision.

This separation matters. An audit should not become an unrequested rewrite, and a copy pass should not quietly change product behavior.

The AudranLab-specific layer

I designed this version for the kinds of systems I research and build: prompt tools, model evaluations, RAG pipelines, agent workflows, automation, and modern Next.js applications.

AI output must be classifiable

The interface should make it possible to distinguish content that is:

  • authored
  • retrieved
  • generated
  • calculated
  • transformed
  • inferred

A generated synthesis and a retrieved source passage should not look like the same kind of evidence.

Trust must be inspectable

Where relevant, the interface exposes the model, version, run date, sources, prompt or configuration, sample size, limitations, and stale or partial state.

The skill explicitly rejects decorative confidence percentages that have no calibrated meaning.

Experiments must be reproducible

Prompt experiments and model evaluations should preserve the variables, configuration, input, output, and version information required to understand or reproduce the result.

Automation must reveal side effects

An automation interface should show its trigger, major steps, credential dependencies, latest run, failure location, retry behavior, and external side effects.

Research pages must separate evidence from interpretation

A technical article should clearly expose the problem, hypothesis, method, evidence, result, limitations, artifact, and next experiment.

Example: improving a failed prompt run

A weak implementation clears the editor, replaces the button label with 'Loading...', and displays 'Something went wrong' after a provider timeout.

The skill instead guides the agent to:

  • preserve the prompt and variables
  • keep the action label stable
  • distinguish rate limit, provider outage, timeout, and validation when recovery differs
  • state what failed and what remains preserved
  • offer retry or a valid model alternative
  • announce status accessibly without moving focus unexpectedly

The UI change is small. The product decision is not.

Why references are separated

A giant instruction file is difficult for an agent to route and expensive to load. The main skill therefore stays focused and uses progressive disclosure.

A RAG task loads AI provenance and the RAG surface guide. A destructive credential action loads product judgment, copy, dialog, authentication, and state guidance. A research article loads the article, visual-language, performance, and verification references.

The agent receives more context only when the task earns it.

Designed for Next.js and TypeScript

The implementation guidance favors:

  • Server Components by default
  • small client boundaries
  • typed domain objects and discriminated state unions
  • server-side secrets and privileged actions
  • URL-shareable filters and experiment state
  • explicit loading, error, and not-found boundaries
  • semantic Tailwind tokens rather than arbitrary values
  • rendered verification at compact and wide sizes

The design guidance and engineering guidance live in one system because a product decision is only useful when it survives implementation.

What is included

Version 1.0.0 contains:

  • the main Agent Skill
  • 14 core reference files
  • 14 surface-specific guides
  • 18 decision exemplars
  • 36 governed rules
  • trigger and application evaluations
  • reusable decision, state, review, and experiment templates
  • a dependency-free validator
  • installation examples for repository agent instructions

Install it

Copy the skill directory into a repository:

terminal ~
mkdir -p .agents/skills
cp -R .agents/skills/audranlab-product-design .agents/skills/

Then route user-facing work to the skill from AGENTS.md, CLAUDE.md, or the equivalent file used by your coding agent.

terminal ~
For any task that changes what a user sees, understands, chooses,
submits, or receives, load:

.agents/skills/audranlab-product-design/SKILL.md

Validate the package with:

terminal ~
python .agents/skills/audranlab-product-design/scripts/validate_skill.py

What this does not solve automatically

A generic public skill cannot know every private product truth.

The strongest version will include your actual:

  • component APIs and tokens
  • user roles and permission model
  • product terminology
  • accepted design decisions
  • failure modes and support evidence
  • real before-and-after evaluations

The package deliberately keeps unknown standards in a coverage-gap file rather than inventing certainty.

The broader idea

A design system tells an agent which components exist.

A product-design skill tells it why, when, and under which constraints those components should be used.

That difference becomes increasingly important as coding agents move from isolated implementation tasks to complete product changes.

Download the AudranLab Product Design Agent Skill

Build a product-specific agent system

I design AI-agent workflows, prompt systems, evaluation interfaces, RAG products, and automation architectures. For a version grounded in your product, component library, and internal decisions, reach out to build a product-specific skill.

Build a product-specific skill