agentsclimarketplace

Kai taste

Skill cgallic/kai-cmo-harness/harness/skills/kai-taste

Audit or design generative AI interfaces against three diagnostic pillars (deterministic-stochastic balance, interaction density, visual cohesion). Treats taste as a measurable control system, not subjective preference. Use when: 'taste audit', 'score this UI', 'design quality', 'interaction density', 'visual cohesion', 'refiner layer', 'correction cost', 'why does this feel off', 'polish this', 'design review', or building any user-facing AI product.From its SKILL.md

Install
npx -y skills add cgallic/kai-cmo-harness --skill kai-taste

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

14.1 KB, ~3.1k tokens by cl100k_base, as published. Nobody here has run it

Design Taste: Engineering Framework

Taste is a control system that converts stochastic model output into reliable user outcomes with minimal correction cost. It is not subjective preference — it has measurable proxies, diagnosable failure modes, and an engineering protocol.

Two modes:

  • Audit — score an existing UI, product, or generated output against the Three Pillars
  • Design — apply taste principles when building new features or interfaces

Iron law: Taste must remain subordinate to function. The moment the system's correction vector dominates the user's intent vector, the product crosses from high-fidelity to high-friction.


The Three Pillars

Every generative AI product sits in a 3-dimensional taste space. Score each pillar independently.

PillarWhat It MeasuresControl KnobsBad Signal
Deterministic-Stochastic BalanceWhere entropy is injected in the pipeline — where the system is creative vs reproducibleEntropy budgeting across phases, multi-sample + rerank, structured outputs (schema), tool calls as determinism anchorsUser says "why did it change?" or fights the AI's personality
Interaction DensityAffordances per cognitive load unit — the cost-per-outcome ratioProgressive disclosure, correction as first-class UI, Chat-to-Canvas transition for persistent artifactsUser manages the interface more than their task
Visual CohesionPerceptual grammar consistency across outputs and statesDesign tokens + component grammar, semantic structure before styling, affordance protection (buttons look like buttons)Output looks "dropped in from another system"

These pillars form a feedback system — adjusting one shifts the feasible region of the other two.

For detailed 1-10 scoring criteria: Read references/pillar-rubrics.md


Failure Modes

Too much taste is a system failure. Scan for all 8 modes during every audit.

Failure ModeDetection SignalAntidote
Stochastic Over-ConstraintRevision entropy increases; users fight the AI's "personality" instead of steering itRe-calibrate entropy injection points; let user steer creative vs deterministic
Density ParalysisChoice overload; user's mental model fragments (Hick's Law violation)Progressive disclosure; layer density spatially, not all at once
Cohesion RigidityOutput locked in narrow aesthetic band; system fights user when intent divergesAllow visual escape hatches; parameterize cohesion
Oracle PolishUsers over-trust because surface coherence bleeds into perceived correctness (halo effect)Confidence-aware UI; expose uncertainty; never smooth caveats
Affordance CollapseUsers miss actions; can't tell content from controls (flat design trap)Buttons must look like buttons; test discoverability with real users
Interaction CeremonyTime-to-value inflated by forced wizards, confirmations, tone selectorsRemove any step that doesn't reduce correction cost; measure TTV
Trust DistortionUsers accept outputs because they sound right, not because they verifiedCalibrate confidence to reliability; never use persona polish to mask uncertainty
Metric GamingProxies improve but product quality degrades (Goodhart's Law)Pair every metric with a counter-metric; run periodic qualitative audits

North Star Metrics

Taste is an unobservable latent variable. Measure these proxies instead.

MetricFormulaPlain EnglishBad Looks Like
Refinement VelocityVr = 1 / n_promptsFewer prompts to accepted final stateUser needs 5+ turns to get something usable
Correction DensityDc = manual_edits / generated_tokensHow much cleanup is neededHeavy post-generation editing on every output
Kinetic FrictionFk = t_action - t_renderTime between seeing output and first meaningful actionToo fast (no thinking, oracle trust) or too slow (navigation overhead)
Time-to-ValueSeconds to first artifact surviving >30s without modificationHow quickly users get something usefulSlow first output; high churn in first session
Correction EffortEdit distance between generated and accepted outputTotal cleanup costOutput requires heavy reformatting to become usable
Dismissal Rate% of AI suggestions ignored, collapsed, or dismissedRelevance + intrusion controlSystem is noisy; users suppress it to work
Clarification BurdenAverage turns before a stable artifact existsInteraction density taxUsers spend turns explaining instead of building

Moderate kinetic friction is optimal. Too low = oracle trust (users accept without thinking). Too high = navigation overhead eats productivity. Target the zone where users think, then act.


Routing: Which Reference to Read

SituationAction
Scoring a pillar in detailRead references/pillar-rubrics.md for 1-10 criteria with observable evidence
Building something new (Design mode)Read references/refiner-protocol.md for the 10-step Refiner Layer
Want the theoretical "why"Read references/theory-foundations.md for information theory, neuroscience, cognitive load
Auditing a live URLUse browse daemon: $B goto <url>, $B snapshot -i -a, $B screenshot
Auditing code or mockupsRead files directly, score against pillar rubrics

Audit Mode Protocol

Use this when scoring existing work.

Step 1: Identify the Subject

What are we auditing?

  • Live URL — use browse daemon for snapshots (take at mobile 375px, tablet 768px, desktop 1440px)
  • Code — read the source files and rendered output
  • Mockup / design file — read or screenshot the design
  • Generated output — evaluate the content directly

Step 2: Score Each Pillar (1-10)

Read references/pillar-rubrics.md for detailed scoring criteria. Quick reference:

Deterministic-Stochastic Balance:

  • Where is entropy injected? Is it phase-aware (exploration vs execution)?
  • Are structured outputs used where reliability matters?
  • Can users toggle between creative and deterministic modes?

Interaction Density:

  • How many turns/clicks to reach first useful output?
  • Is correction cheap (edit-in-place, diffs) or expensive (re-prompt from scratch)?
  • Are advanced controls hidden by default (progressive disclosure)?
  • Is state persistent (canvas/artifact) or ephemeral (chat)?

Visual Cohesion:

  • Does output render through a component grammar or raw text?
  • Are affordances visible (buttons, links, actions clearly distinguishable)?
  • Is typography, spacing, and hierarchy consistent across all states?
  • Does generated content look native to the surrounding UI?

Step 3: Scan Failure Modes

Check all 8 failure modes from the table above. For each, mark Present/Absent with evidence.

Step 4: Measure Available Metrics

Which north star metrics can you compute from observation?

  • Count turns to acceptance (Refinement Velocity)
  • Estimate edit distance (Correction Density)
  • Time the gap between render and first action (Kinetic Friction)

Step 5: Output the Scorecard

## Taste Audit: [Subject]
**Date:** [date]
**Auditor:** [name/agent]

### Pillar Scores
| Pillar | Score | Key Finding | Recommended Fix |
|--------|:-----:|-------------|-----------------|
| Deterministic-Stochastic Balance | /10 | | |
| Interaction Density | /10 | | |
| Visual Cohesion | /10 | | |
| **Composite** | **/30** | | |

### Failure Mode Scan
| Mode | Present? | Evidence | Severity |
|------|:--------:|----------|:--------:|
| Stochastic Over-Constraint | | | |
| Density Paralysis | | | |
| Cohesion Rigidity | | | |
| Oracle Polish | | | |
| Affordance Collapse | | | |
| Interaction Ceremony | | | |
| Trust Distortion | | | |
| Metric Gaming | | | |

### Metrics (if measurable)
| Metric | Observed Value | Assessment |
|--------|:--------------:|------------|
| Refinement Velocity | | |
| Correction Density | | |
| Kinetic Friction | | |
| Time-to-Value | | |

### Prioritized Fixes
| P | Fix | Pillar | Impact |
|:-:|-----|--------|:------:|
| 0 | | | |
| 1 | | | |
| 2 | | | |

### Grade
- 25-30 = **A** (taste is a competitive asset)
- 20-24 = **B** (solid, minor gaps)
- 15-19 = **C** (functional but friction-heavy)
- 10-14 = **D** (taste is actively hurting the product)
- <10   = **F** (taste is absent or harmful)

**Overall: [Grade]**

Step 6: Prioritize Fixes

Map findings to P0 (blocking UX) / P1 (significant friction) / P2 (polish). Fix P0s before shipping.


Design Mode Protocol

Use this when building new features or interfaces.

Step 1: Define the Taste Contract

Translate quality goals into testable constraints, not adjectives:

  • What must be reproducible? (deterministic zones)
  • Where is creativity allowed? (stochastic zones)
  • What must never happen? (hard constraints)
  • Reading level, verbosity ceiling, required sections, prohibited moves
  • Citation rules, formatting grammar, interaction rules

Step 2: Pre-Score Against Three Pillars

Before building, predict where you'll land on each pillar. Identify the target score band and what observable criteria you need to hit.

Step 3: Apply the Refiner Layer

Read references/refiner-protocol.md for the full 10-step protocol. Summary:

  1. Define taste contract as constraints, not adjectives
  2. Separate divergence (exploration) from convergence (refinement)
  3. Generate structured intent representation before drafting
  4. Draft into intermediate representation, not directly into final UI
  5. Run critic pass with explicit rubrics
  6. Refine via diffs, not rewrites
  7. Anchor truth with tools, then re-render
  8. Compile to UI using component grammar
  9. Guarantee correction affordances at the surface
  10. Instrument taste as feedback loops

Step 4: Pre-Mortem Failure Modes

Run through all 8 failure modes as a pre-mortem: which could this design fall into?

  • If adding polish: check for Oracle Polish and Cohesion Rigidity
  • If adding features: check for Density Paralysis and Interaction Ceremony
  • If reducing friction: check for Agency Collapse (IKEA effect loss)
  • If showing confidence: check for Trust Distortion

Step 5: Plan Metrics Instrumentation

Decide which north star metrics you will track and how:

  • Log time-to-first-value
  • Track edit operations per session
  • Count regenerations and diff rejections
  • Monitor dismissal rates
  • Pair every metric with a counter-metric (Goodhart protection)

Design Checklist

Run before shipping any user-facing AI feature:

Deterministic-Stochastic Balance

  • Entropy injection points identified (where creative, where locked)
  • Structured outputs enforced for downstream actions
  • Tool calls used for factual queries instead of model guessing
  • Multi-sample + rerank for quality-sensitive outputs
  • User can toggle between exploration and execution modes

Interaction Density

  • Default path is shallow (progressive disclosure)
  • Correction is cheap (edit-in-place, scoped refine, accept/reject diffs)
  • Advanced controls contextual, not upfront
  • Persistent artifacts used for multi-step work (not buried in chat)
  • State externalized as manipulable objects

Visual Cohesion

  • Outputs compile through component grammar (not raw text to UI)
  • Semantic structure enforced before styling (headings, sections, callouts)
  • Affordance protection (buttons look like buttons, links look like links)
  • Design tokens consistent across all output states
  • Generated content indistinguishable from hand-authored content in the same UI

Anti-Failure-Mode Gates

  • Uncertainty is signaled, not smoothed (anti-Oracle Polish)
  • User can override/escape system suggestions (anti-Cohesion Rigidity)
  • No forced steps that don't reduce correction cost (anti-Interaction Ceremony)
  • Trust calibrated to actual reliability (anti-Trust Distortion)
  • Selective friction preserves user agency (anti-Agency Collapse)

Common Mistakes

MistakeReality
"Taste is subjective, can't be scored"Taste has measurable proxies: correction cost, time-to-value, dismissal rate
"More polish = more taste"Oracle Polish is a failure mode. Polish that outpaces reliability destroys trust
"Minimize all friction"Selective friction (IKEA effect) builds ownership. Remove friction only where it doesn't reduce understanding
"The model output IS the product"The model is a probabilistic component. The Refiner Layer makes it feel authored
"Chat is good enough"Chat serializes multi-dimensional state into a 1D stream. Canvas externalizes memory
"Make it beautiful and it's tasteful"Cohesion Rigidity and Affordance Collapse are both beauty-caused failures
"Users want everything instantly"Optimal pacing is layered: immediate ack (0.1s), provisional structure (1s), deferred commitment (seconds)
"Show confidence to build trust"Uncalibrated confidence creates the Uncanny Valley of Agency. Transparency builds trust

Source Material

For the full 40,000-word theoretical foundation, see:

  • taste/taste.md — Foundation taxonomy, North Star metric, 5-step Refiner
  • taste/chatgpt_taste.md — Engineering framework, 10-step Refiner, proxy metrics
  • taste/deep-research-report.md — Neuroscience, cognitive load, agency, RLDF spec
  • taste/AI Design Taste_ A Systems Approach.md — Information theory, SDEs, style weights
  • taste/Engineering AI Design Taste Framework.md — Operationalization, failure modes, synthesis

What ships with it: 3 files

28.2 KB alongside SKILL.md

Keep looking

Skills are one crate of 326,871. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.