The Design Harness | AI Design Ops Documentation

The Harness makes agent work legible.

AI can create more screens, copy, code, and options than one person can review. The question is how the work gets framed, checked, saved, and improved. This documentation explains the system I am building around that work.

01

Frame The Work

Name the audience, the goal, the limits, and what good should feel like before the agent starts.

02

Orchestrate Context

Bring in the product memory, design rules, source material, and previous decisions the work depends on.

03

Protect Quality

Check the output against screenshots, logs, sources, tests, and the designer's own judgment.

The Harness turns loose AI requests into a clear way of working.

A prompt leaves too much in your head. The Harness makes the working parts visible: product memory, design context, skills, source trust, and the judgment gates that make AI useful for real design work.

See the full map

01 Designer Brief

You ask like a designer: critique this, build this screen, find the gaps, or turn this work into a handoff.

The Harness first decides whether this is a new brief, an approved iteration, a critique, a source check, or a share-ready audit.

Start Here Process Note

02 Gather Context

For new work, it gathers the sources, drafts the brief from evidence, and stops for designer approval.

Context can include product memory, design rules, Jira, Slack, Figma, screenshots, logs, prior decisions, and the current project folder.

Context Files Why Harness

03 Choose The Workflow

The request is matched to the right skill or sequence, with inputs, limits, gates, and output format made explicit.

A critique, prototype, source check, article draft, accessibility pass, and publish step should not all run the same way.

Skills Skill Chains

04 Check The Work

The skill runs against real context, writes to the project record, and ends with checks before anything is shared.

Plausible is not enough. The work has to match the brief, the sources, the design system, accessibility expectations, and your judgment.

Guardrails Audit AX

05 Improve The System

Every miss becomes a better rule, routing example, checklist, project note, or eval for the next run.

The system improves because failures are written back into the Harness instead of staying as one-off feedback in a chat.

Harness Planark Proof

The orchestrator routes the work.

The Design Harness orchestrator is the central hub that connects context files, skills, project memory, source trust, validation, and design context into one coordinated system.

Instead of loose prompts, the orchestrator decides which workflow runs, what context to load, when to stop for approval, and how to check the output before anything ships.

Project Memory

Every project lives in its own folder.

The projects folder is your second brain. Each project keeps its brief, sources, findings, decisions, log, screens, artifacts, and testing together. You can always return to any project with full context. No lost chats. No missing history.

This is what makes agent work resumable: the work writes to files, not just ephemeral chat history. The agent can pick up where you left off, any time, with the full story.

design-harness

projects/<project-slug>/
├── brief.md              # PRD, scope, constraints
├── sources.md            # Link catalog (append-only)
├── findings.md           # dated outputs from every skill run
├── decisions.md          # designer decisions + rationale
├── log.md                # routing log for this project
├── debt.md               # optional debt register
├── handoff.md            # session continuity for fresh chats
├── notes/                # working docs, workshop recaps
├── screens/              # live .tsx prototypes + Canvas explorations
├── artifacts/
│   ├── decks/            # shareable HTML presentations
│   ├── snapshots/        # prototype exports
│   └── qa/               # audit screenshots, evidence
└── testing/              # test plans, study results

Append-only log

Every run writes dated entries. Complete audit trail.

Resumable context

New chats load the project folder. Full history available.

Shareable artifacts

Decks, snapshots, and QA evidence ready to publish.

04 Start Here

It is not a rigid wizard.

The Harness should feel like a domain expert you can talk to. You can follow a structured path, or ask something loose like: what do we know, who worked on this, or where should I start?

Ask freely. Use a flow. Get unstuck.

02

It can look at the work from different angles.

The same assistant can act like a researcher, product designer, writing partner, quality reviewer, or design-ops keeper. Same memory underneath, different lens on top.

Research: what do we actually know?
Design: what should this become?
Writing: does this sound right?
Quality: is this ready to trust?

03

It has a real set of jobs it can do.

Some jobs are about discovery. Some are about making screens. Some are about copy, accessibility, audit, handoff, publishing, or saving the lesson for later.

Research and source checks
Screen and prototype work
Copy, critique, and accessibility review
Handoff, publishing, and memory

04

It remembers you and the project.

The useful context should not disappear in a chat. A real project folder keeps the brief, findings, decisions, log, screens, and source notes together.

Brief Findings Decisions Log Screens

05

It turns a vague idea into a checked brief.

If you start with a rough idea, the Harness should not pretend that is enough. It checks sources, finds what already exists, names the assumptions, and asks before building anything.