Process

Design decisions should become executable infrastructure.

My process would not make a fast team wait for design approval on every detail. It would set the taste bar, make judgment explicit, and build the system that helps the team repeat good decisions through skills, hooks, design-system defaults, and governed automation.

My role

I would not become the manual taste gate. I would build the system that catches known issues and frees review for new judgment.

At this pace, design culture cannot live only in critique notes or someone's memory. Once the team makes a good decision, the next question should be: where should this live so it helps everyone ship better next time?

Lifecycle

The operating loop is: Decision -> Skill -> Hook -> Design system default -> Audit -> Retire.

01 / Decision

Make the judgment explicit

Capture the rule behind a product or design decision: where it applies, why it matters, examples, exceptions, and who can change it.

02 / Skill

Teach the repeatable work

Turn stable judgment into a reusable skill for research, interaction design, copy review, prototyping, implementation, QA, or release judgment.

03 / Hook

Enforce known decisions at the point of work

Run checks when work starts, changes, merges, or ships so the team does not have to manually remember every standard.

04 / Design system default

Move durable patterns into primitives

When a pattern proves stable, make it a component, token, template, state model, or visual QA example rather than another one-off review note.

05 / Audit

Watch for misses, noise, and drift

Review where rules are ignored, where hooks are noisy, where skills produce weak work, and where manual critique keeps catching the same issue.

06 / Retire

Remove rules that no longer earn their keep

A governed system needs expiration dates. If a rule is stale, too broad, or no longer tied to user risk, it should be changed or removed.

Encode first

I would start with the decisions that most directly affect user trust, product quality, and speed of review.

Approval gates

External, irreversible, expensive, or reputation-impacting actions must pause, explain the risk, and ask for explicit approval.

Evidence requirements

Important claims need visible support: source references, tool output, user-provided context, confidence boundaries, or a clear unknown.

Visual polish checks

Before a flow is considered ready, it should pass checks for hierarchy, spacing, responsive fit, overflow, focus, loading, empty, and recovery states.

Accessibility

Semantic structure, keyboard paths, focus states, labels, contrast, and reduced-motion expectations should be part of the default review path.

Toolchain

The process should be engineery enough to run where the work happens, not off to the side as a separate ceremony.

AGENTS.md

Persistent product and design rules that shape how agents work inside the repo.

Skills

Repeatable workflows for agent UX review, accessibility audit, visual QA, copy critique, and prototype creation.

Hooks

Automatic enforcement for known non-negotiables at creation, review, merge, and release moments.

PR templates and checks

A lightweight review contract for approval gates, evidence, accessibility, visual QA, and documented exceptions.

Design system

Executable product memory: primitives, states, tokens, interaction patterns, accessibility rules, and examples of what good looks like.

Browser screenshot checks

Desktop and mobile visual verification for layout fit, text overflow, theme behavior, and interaction polish.

Governance

Automation should preserve judgment, not replace it.

  • Automate only decisions the team understands well enough to explain.
  • Every hook needs an owner, an override path, and a review date.
  • A skill should teach the judgment, not just output the artifact.
  • The design system should capture proven decisions, not speculative components.
  • Manual critique should focus on new judgment, not repeatedly catching known issues.
  • When a hook creates noise, fix the rule instead of training the team to ignore it.
  • When manual review finds the same issue twice, consider turning it into a skill, hook, or default.