Agents do the legwork.
I bring the judgment.

I brief agents the way I used to brief engineers, and put working prototypes in front of people in days, not sprints. This page follows one real redesign, the recording flow (33% → 66.58%), run the way I’d run it today.

The hub

Notion is the point guard

I don’t use Notion for notes. I use it as the place every other tool reports to. An agent there is connected over MCP to Figma, PostHog, Relume, GitHub, Linear, Fern and Slack, and the PRDs, design docs and wiki it writes live right next to the work they describe.

I ask in plain language. It fans out, pulls what it needs from each tool, and comes back with a draft I can edit, not a pile of tabs I have to stitch together.

Figma Explorations & files

Relume Sitemaps & system

GitHub Code & issues

Fern API docs & dev wiki

Slack Team comms

PostHog Data & analytics

Docs & wiki PRDs, design docs

Linear Issues & projects

Figma Explorations & files

Relume Sitemaps & system

GitHub Code & issues

Fern API docs & dev wiki

Slack Team comms

PostHog Data & analytics

Docs & wiki PRDs, design docs

Linear Issues & projects

The ask

Product agent

Draft a PRD for the recording-flow redesign. Pull the last 30 days of the record → submit funnel from PostHog, link the current explorations in Figma, check where the flow sits in the Relume sitemap, check the upload API’s limits in our Fern docs, and list the open GitHub issues labelled recording. Use our PRD template and cite every number. Then propose Linear issues for anything we commit to, and share the draft in #recording-flow.

The fan-out

PostHog · Query the record → submit funnel, last 30 days Read
Figma · Read the current recording-flow explorations Read
Relume · Find where the flow sits in the sitemap Read
GitHub · Search open issues labelled recording Read
Fern · Check the upload API’s limits in the reference Read
Notion · Draft the PRD from the team template, numbers cited In Notion
Linear · Create issues for what we commit to Needs OK
Slack · Post the draft to #recording-flow for review Needs OK

Reads run on their own. Anything that writes to another tool waits for a yes, which is Notion’s default for MCP actions, and the right one.

Notion · PRDs

PRDs built from evidence

A PRD used to be an afternoon of copying numbers out of dashboards. Now the agent pulls the funnel, the replays, the files and the API limits itself, drafts against our template, and cites every line. I spend the afternoon on the argument instead.

Product / PRDs / Recording flow v2

Recording flow v2

Status: In review
Owner: Adam Robertson
Linear: REC-140 · Recording flow v2
Drafted by: Product agent · 6 sources

Drafted from 6 sources. Every claim cited; nothing here is from memory.

Problem

Only a third of contributors who start the recorder submit a video. Funnel · 33%
79% get past the first screen; only 42% of those finish. Mobile is worse. Funnel · by device
Those who give up spend the longest waiting on video processing. Time to convert

Constraints

Uploads are capped per request; long takes need chunking. POST /v1/uploads
The current explorations assume a single-screen review. Record — v15

Goal

Double completion without adding a screen to the flow.

Templates, filled from evidence

The agent works from our PRD template and fills it from the tools, so every PRD has the same spine and reads the same in review.
Every number has a source

Each claim links back to the funnel, replay, file or endpoint it came from. A stakeholder can check it without asking me.
It lives with the wiki

PRDs, design docs and decisions sit in one database, linked to their Linear projects, so the next PRD can cite the last one.

Claude Code · Claude Design

The prototype is the code now

The agents write the code; my job is the brief, the direction and the judgment. Four files from the recording flow, as I’d run it today, start to finish.

01# Task: prototype the recording-flow redesign02 03## Context04Read PRODUCT.md, then use the v3-design skill:05open only the docs it routes you to.06Contributors are on a phone, often recording for the07first time, usually minutes before a deadline.08 09## Goal10One flow, mobile-first: record → review → submit.11Completion is the metric. Every extra screen costs it.12 13## Constraints14- Build from documented components only. If none15  fits, propose a contract first; don't invent one.16- daisyUI for structure, the tribute's theme vars17  for brand. No raw values, no btn-primary on CTAs.18- Ask for the camera in context, never on load.19- Design every state: denied, recording, uploading,20  failed upload, success.21 22## Done when23- `check:system` and `impeccable detect` both pass24- It runs at 390px with no horizontal scroll25- A keyboard and a screen reader can finish the flow26- You've listed what you assumed and couldn't verify

01Interactive prototype, phone frame: the contributor02side of a group video gift for a teacher's retirement.03 04Three clickable screens:051. Invite: who it's for, the deadline, one button062. Record: 60-second cap, retake, visible countdown073. Done: what happens next, and a link to share08 09Use the attached screenshots as the visual baseline.10Show two directions for screen 1 side by side, one11quiet and one loud. Real copy, no lorem ipsum.12 13When I pick one, package it as a handoff to Claude Code.

01# Product02 03## Who it's for04Contributors invited to a group video gift, not the05organiser. Most arrive from a text message, on a phone,06with no account and no idea what Tribute is.07 08## What it has to do09Get a heartfelt 60-second video from someone in under10three minutes, without losing them at the camera step.11 12## Constraints13- Mobile Safari is the primary browser14- Contributors never create an account15- Warm, never cute: some of these are memorials16 17## Anti-goals18- No onboarding carousel19- No dark patterns on the upsell

01# Plan the UX before any code exists02/impeccable shape the contributor invite screen0304# A scored review, then act on it05/impeccable critique the record step06/impeccable quieter the invite hero0708# Final passes before it ships09/impeccable polish the review screen10/impeccable harden the upload states1112# Both gates, before handing back and again in CI13$ bun run check:system14$ npx impeccable detect --github src/

The system

A system agents can read

Agents don’t read a design system the way people do. They need to know what exists, what it’s for, and what they’re not allowed to invent. On Tribute that’s four layers: PRODUCT.md for the intent, daisyUI for structure, each tribute’s theme tokens for its brand, and component docs for the patterns, with a design skill that routes every edit to the one doc it needs.

Find the system first, check against it after. Below is one real task, step by step. Click a step to open the file the agent read.

Explore Relume · Claude Design
The system What every agent reads first PRODUCT.mddaisyUITheme tokensComponent docs
Build Claude Code
Check Two gates · review
Measure PostHog

00 Task Add a “ready to send?” confirm before a recording uploads
01 Skill v3-design loads: the edit is in tribute/v3/src
02 Route The router opens one doc, not the whole system
03 Discover Modal and Button already exist. Nothing new to invent
04 Contract Extend BaseModal, max-w-lg, header and footer regions
05 Tokens The CTA is btn + the tribute’s theme colour, not btn-primary
06 Gates check:system and impeccable detect both pass ✓
07 You Review the pull request, then merge ✓

docs / design / v3 one truth · everything else is an index

SKILL.md
README.md
index.json gen
modal.md
daisy-components.md

                
                ---name: v3-designdescription: Tribute v3 UI conventions. Use when  editing v3 templates, components or styles.---# V3 design system## First stepRead docs/design/v3/README.md and open only thelinked doc for the files you are changing.## Non-negotiables1. No daisyUI on marketing pages.2. Branded primary buttons: btn +   var(--theme-primary-color), not btn-primary.3. Modals extend BaseModal.

                
                # Tribute v3 design (for humans and agents)## Which doc to open| You are editing          | Read                  || tribute/v3/src/**        | product-app.md        || Modals or slideouts      | components/modal.md   || Daisy class names        | daisy-components.md   || templates/v3/homepage**  | marketing-pages.md    |## Do not- Add daisyUI classes to marketing templates.- Copy daisyUI's llms.txt into the repo. Link it.## Maintaining these docsChange a token, update its table in the same PR.

                
                {  "source": "docs/design/v3/components/*.md",  "note": "Generated on build. Do not edit.",  "components": [    { "name": "Modal", "status": "stable",      "extends": "BaseModal.ts",      "doc": "components/modal.md" },    { "name": "Slideout", "status": "stable",      "extends": "BaseSlideout.ts",      "doc": "components/slideout.md" },    { "name": "Button", "status": "stable",      "doc": "components/button.md" },    { "name": "Alert", "status": "stable",      "doc": "components/alert.md" }  ]}

                
                ---name: Modalstatus: stableextends: BaseModal.tsclasses: [modal, modal-box, modal-backdrop]regions: [header, content, footer?]widths: [max-w-md, max-w-lg, max-w-2xl]use_when: One decision that blocks the flowavoid_when: More than one decision (use a slideout)a11y:  - Native <dialog>; Esc and the backdrop close it  - Focus returns to the trigger on close---# ModalPick the closest existing width before adding one.Header and footer share the chrome colours,--modal-header-bg and --modal-border.

                
                # daisyUI subset (product app)Upstream: daisyui.com/llms.txt (linked, not copied)## Daisy vs Tribute theme vars| Need                    | Use                       || Occasion-branded action | btn + --theme-primary-... || Cancel, low emphasis    | btn btn-ghost             || Dialog structure        | modal, modal-box          || Status, warnings        | alert alert-soft          |btn-primary is daisyUI's primary, not the occasioncolour. Avoid it for main actions.

Trimmed from Tribute’s design docs. Shaped by Kaelig Deloumeau-Prigent’s State of AI in Design Systems (July 2026) and Southleft’s What does AI-readiness mean in design systems?

Route, don’t load

The skill reads one router and opens only the doc for the files being changed. One long manifest teaches agents to rebuild components instead of reaching for them.

Contracts, not prose

Each component doc opens with a short structured header: what it is, what it allows, when to use it. Agents and the gates check against that; the prose is for people. The index is built from the headers, never typed by hand.

Link, don’t copy

daisyUI’s own llms.txt stays upstream and the docs link to it. A copied vocabulary goes stale the day daisyUI ships, and our docs only hold our decisions.

Measured, not assumed

Five real tasks, run with and without the system, scored on reuse, token discipline, accessibility and judgment. If the docs don’t move the score, they’re decoration.

Impeccable

Taste, as a command

Agents write competent, forgettable UI by default. Impeccable is a design skill for coding agents, built on Anthropic’s frontend-design skill, that gives them a vocabulary for taste: commands I aim at a narrow target, judged against the PRODUCT.md and DESIGN.md it writes for the project.

A narrow target beats a whole page. /impeccable critique the pricing cards gets a better answer than “make the site nicer” ever will.

Plan

Before code exists

init Writes PRODUCT.md from the codebase
document Writes DESIGN.md
shape Plans the UX before code
extract Pulls repeats into the system

Steer

Push it a direction

bolder Amplifies a safe design
quieter Tones down a loud one
distill Removes what isn’t needed
typeset Fonts, hierarchy, sizing
layout Spacing and rhythm
colorize Colour for a grey interface
animate Transitions and feedback
delight Adds personality
overdrive Shaders, springs, scroll effects

Review & finish

Before it ships

critique A scored UX review
audit A technical quality report
polish The final pass
harden Errors, i18n, overflow, edge cases
clarify Rewrites unclear copy
adapt Screen sizes and devices
optimize Loading and rendering
onboard First-run and empty states

Iterate live

In the browser

live Pick an element, cycle variants
generate Variants of a named element

Two gates, and neither one is an agent

Impeccable judges whether the UI is good. It can’t tell whether it’s ours: a hand-built dialog can be beautiful and still go around the system. So a second check runs the system’s own rules: daisyUI for structure and the tribute’s theme for brand, documented components before new ones, a component’s contract changed with its code, and axe for the basics. The agent runs both before it hands work back, and both annotate the pull request. Taste stops being a review comment someone has to remember to leave, and becomes a check that has to pass.

Is it good?impeccable

# the one I use most, as its own shortcut

/impeccable pin audit

/audit

# the same rules, no agent, on every PR

$ npx impeccable detect --github src/

exit 2 · findings — the check fails

Is it ours?check:system

$ bun run check:system

✖ RecordStep.ts:58 btn-primary on an occasion CTA → use btn + --theme-primary-color
✖ UploadSheet.ts:12 hand-built dialog → extend BaseModal · components/modal.md
✖ BaseModal.ts changed, but components/modal.md didn’t → update the contract in this PR
✖ ReviewStep.ts:31 button has no accessible name → axe · button-name

exit 1 · 4 findings — the check fails

The skeleton

Relume, for the structure

Before there’s code there’s a sitemap. Relume is where the skeleton comes from: page structure, wireframes and a brand system, exported to Figma, Webflow or React, and now straight into the agents.

01

Sitemaps first

A prompt becomes a sitemap, then a wireframe per page. The fastest way I know to agree on structure before anyone argues about pixels.

02

Explore the brand, then codify it

The Style Guide Builder turns a palette and a type pairing into a direction in minutes. Once one is approved, it’s translated into the daisyUI theme and the design docs. Relume never owns a production token.

03

A starting point, not a second system

Over a thousand sections, searchable in plain language through the Relume MCP. Agents take the layout and composition, then rebuild it from our documented components and tokens. The shadcn/ui code never ships as is.

04

Into Claude Design

The design system exports to Claude Design as one import, so first drafts start on-brand instead of being dragged there.

Fern · Dev & API docs

Docs that write themselves from the spec

An API is only as usable as its docs, and hand-written docs rot the week after launch. Fern generates the reference and the SDKs from the spec, and serves the whole thing in a form agents can read as easily as people can.

docs / api-reference Ask AI ⌘K

Overview
Authentication
Tributes
Uploads
Webhooks

Guide Getting started

Tribute API

REST over HTTPS, JSON in and out. Every endpoint here, and every SDK, is generated from one OpenAPI spec.

Basics

base_url string https://api.example.dev/v1
version date Pinned per key, e.g. 2026-10-01
format json UTF-8, snake_case keys, ISO 8601 times

TypeScriptReactPython

import { TributeClient } from '@tribute/sdk';

const client = new TributeClient({
  token: process.env.TRIBUTE_TOKEN,
});

import { QueryClient, QueryClientProvider } from '@tanstack/react-query';

const queryClient = new QueryClient();

export function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Routes />
    </QueryClientProvider>
  );
}

import os

from tribute import Tribute

client = Tribute(token=os.environ["TRIBUTE_TOKEN"])

Guide Bearer tokens

Authenticate requests

Every request carries a bearer token. Server keys never reach a browser: the web app trades its session for a short-lived token scoped to one tribute.

Headers

Authorization string required Bearer <token>
Tribute-Version date Overrides the version pinned to the key

TypeScriptReactPython

// Server-side only. The key never ships to a browser.
const client = new TributeClient({
  token: process.env.TRIBUTE_TOKEN,
  timeoutInSeconds: 30,
});

export function useTribute() {
  const { data: token } = useSuspenseQuery({
    queryKey: ['tribute-token'],
    queryFn: fetchScopedToken,
    staleTime: 5 * 60_000,
  });

  return useMemo(() => new TributeClient({ token }), [token]);
}

client = Tribute(
    token=os.environ["TRIBUTE_TOKEN"],
    timeout=30.0,
)

GET /v1/tributes/{tribute_id}

Retrieve a tribute

Returns a tribute with its status and deadline, and optionally its contributors and uploads.

Path

tribute_id string required For example trb_8f2k

Query

expand string[] contributors, uploads

TypeScriptReactPython

const tribute = await client.tributes.get('trb_8f2k', {
  expand: ['contributors'],
});

const client = useTribute();

const { data: tribute } = useQuery({
  queryKey: ['tribute', tributeId],
  queryFn: () => client.tributes.get(tributeId),
});

tribute = client.tributes.get(
    "trb_8f2k",
    expand=["contributors"],
)

POST /v1/uploads

Create an upload

Starts a chunked upload for a contributor’s video. Large takes are split into parts and resumed if the connection drops.

Body

tribute_id string required The tribute the video belongs to
part integer required Chunk index, from 1
content_type string video/mp4 or video/webm

TypeScriptReactPython

const upload = await client.uploads.create({
  tributeId: 'trb_8f2k',
  part: 1,
  contentType: 'video/mp4',
});

const client = useTribute();

const { mutate: uploadPart } = useMutation({
  mutationFn: (part: number) =>
    client.uploads.create({ tributeId, part }),
});

upload = client.uploads.create(
    tribute_id="trb_8f2k",
    part=1,
    content_type="video/mp4",
)

POST /v1/webhooks

Register a webhook

Sends a signed POST to your endpoint when an event fires, retrying with backoff for 24 hours.

Body

url string required An HTTPS endpoint you control
events string[] required For example upload.completed

TypeScriptReactPython

const webhook = await client.webhooks.create({
  url: 'https://example.com/hooks/tribute',
  events: ['upload.completed'],
});

const client = useTribute();

const { mutate: register } = useMutation({
  mutationFn: (url: string) =>
    client.webhooks.create({ url, events: ['upload.completed'] }),
});

webhook = client.webhooks.create(
    url="https://example.com/hooks/tribute",
    events=["upload.completed"],
)

One spec, every surface

The reference, the SDKs and the changelog all regenerate from the spec, so the docs can’t fall behind the API.

Docs agents can read

Every page has a Markdown twin and an llms.txt index, so an agent reads the reference instead of guessing at it.

An MCP server for the docs

Notion’s agent, Claude Code or Cursor can ask the docs directly — which is how the PRD knew the upload limit.

The dev wiki, too

Guides, runbooks and how-tos live beside the reference, versioned with the code they describe.

Linear · Planning

From commitment to pull request

The PRD says what we’re committing to; Linear is where that turns into work someone owns. More and more of that someone is an agent, which changes what a good issue looks like: scoped tightly enough to hand off, with the evidence attached.

Recording · Cycle 24 6 issues

Backlog 2

REC-146

Photo upload as a secondary path

Design PRD
REC-147

Notes field for the person recording

Design

In progress 2

REC-141

Ask for the camera in context, not on load

Frontend PRD
REC-143

Resumable chunked uploads

Backend Coding agent

In review 1

REC-142

Show processing progress instead of a spinner

Frontend PRD Coding agent PR · needs review

Done 1

REC-140

Recording flow v2 — PRD

Product

Filed from the PRD

The agent proposes issues from what the PRD commits to, each linked back to the line that justifies it. Nothing is created until I say yes.

Delegated, not dumped

Well-scoped issues go to a coding agent. It opens the PR; a human reviews and merges. The issue keeps the whole trail.

Context in, over MCP

Linear’s own agent pulls context from other tools over MCP, so an issue can start from meeting notes or a replay rather than a blank form.

PostHog · Self-driving

The product files its own bug reports

PostHog is where the work gets judged after it ships. Replays, errors, funnels and experiments in one place, and now an AI layer that watches the replays for me, files what it finds, and can open the pull request that fixes it.

Self-driving means autonomy from my instructions, not from engineers. Every fix still goes through review, and every release still goes out behind a flag.

Replay Vision Inbox Background agent Pull request You merge

Open beta · the agent proposes the fix · a person still merges

The mocks below are illustrative; their numbers are not real data.

UX bugs, found in the replays

Replay Vision watches sessions so I don’t have to: it flags the rage clicks and dead ends, scores how frustrated someone was, and writes up what happened.

Dev bugs, with the session attached

Every error comes with the replay it happened in, so nobody has to reproduce it from a stack trace. The Inbox groups the signal, and an agent researches it into a fix.

Ship behind a flag, prove it with a test

Experiments run on the same flags as releases: a staged rollout, a holdout to measure against, and a kill switch if the numbers turn. Nothing goes to everyone on a hunch.

The team

A team’s system, not my setup

None of this is a personal productivity stack. It’s how we rebuilt Tribute’s platform: functioning code as the deliverable instead of Figma files, one-week sprints across product, design and engineering, and a team that started skeptical and stopped being.

to rebuild a decade-old platform: 3 months; to rebuild a decade-old platform
from skeptical to one-week sprints: Team of 4; from skeptical to one-week sprints
onboarding conversion: ~25% → 54%; onboarding conversion
purchases, same period: +19%; purchases, same period

PRD template

One spine for every PRD

The agent drafts against the same template for everyone, so review is about the argument, not the format.

PRODUCT.md · v3-design · daisyUI

The system lives in the repo

Not in my head. PRODUCT.md holds the intent, a design skill routes every edit to the doc it needs, daisyUI carries structure and each tribute’s theme carries its brand. Changing the system is a pull request, and CI fails if a component changes without its doc.

check:system · detect

Two gates hold the line

One checks the system was used, one checks the result is good. Both run on every pull request, including the reviews I’m not in. Taste that only exists in one reviewer doesn’t scale.

Writes need a yes

One trust model

Agents read freely; anything that changes another tool waits for a person. Secrets and production data stay out of reach, because read-only isn’t the same as safe.

The sketchbook

Figma, now

Still open, mostly as a sketchbook: a moodboard, a layout to argue with, a component to poke at. It used to be where the work lived. Now the work starts as a brief and is running code by the end of the day.

And when an exploration wins, a comment is enough. The Notion agent reads Figma over MCP, picks up the mention, and logs the decision on the PRD, linked back to the frame.

Which keeps ownership simple. Code owns the components and tokens, Notion owns the decisions, and Figma owns neither, so nobody has to ask which one is official.

Tribute v3 — FINAL (2) 100%

Pages

Cover
Explorations
v3 — final
v3 — final FINAL
Archive (do not use)

Layers

Record — v15 (Copy)
Frame 1428
Group 88
Rectangle 12 copy
Rectangle 12 copy 2
Button / Primary / Final
Record your message
Frame 1429

Record — v14

Record — v15

Record — v15 (Copy)

AR

Adam Robertson· 2m

use this one??

AR

Adam Robertson· now

@Notion agent log this as the winner on the PRD

Notion agent· now

Logged Record — v15 (Copy) as the decision on Recording flow v2, linked to this frame.

See what it shipped

All work

Tribute Recording Flow 33% → 66.58% submission rate on the core flow Doubling submissions on a core flow Tribute V3 3 months to rebuild a decade-old platform, team of four Re-architecting a decade-old platform

Agents do the legwork. I bring the judgment.

Notion is the point guard

PRDs built from evidence

The prototype is the code now

A system agents can read

Taste, as a command

Relume, for the structure

Sitemaps first

Explore the brand, then codify it

A starting point, not a second system

Into Claude Design

Docs that write themselves from the spec

From commitment to pull request

The product files its own bug reports

A team’s system, not my setup

Figma, now

See what it shipped

Breakout™

Agents do the legwork.
I bring the judgment.

Breakout