# Taste Encoding

> Interviews the user to extract their design taste, technology preferences, and opinionated defaults for a domain, then encodes those preferences into skill reference files, decision rules, conventions, and anti-patterns. Use when the user says "encode my taste", "add my preferences to this skill", "make this skill opinionated", "interview me about my preferences for X", or asks to capture style/defaults in a reusable skill.

- Skill: `lucasilverentand/taste-encoding` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add lucasilverentand/taste-encoding`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lucasilverentand/taste-encoding/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: lucasilverentand (https://skillmd.com/u/lucasilverentand)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/lucasilverentand/taste-encoding

---


# Taste Encoding
Extracts a user's design taste through structured interviews and encodes it into skill artifacts — reference files, decision rules, conventions, comparison tables, and anti-patterns. Taste is the difference between a generic skill ("here are 5 database options") and an opinionated one ("use D1 for small projects, Neon when you need RLS or compliance — here's exactly why").

## Decision tree
- What does the user want?
  - **Encode taste into a new skill** → the skill doesn't exist yet. Hand off to the authoring skill (`authoring`) to scaffold the skill first, then come back here for taste encoding.
  - **Encode taste into an existing skill** → what's the current state?
    - **Skill has no taste yet** (generic, presents options without opinions) → run the full process below
    - **Skill has some taste but gaps remain** → read the skill, identify which domains still lack opinions, run a focused interview on those gaps only
    - **Skill taste is stale or wrong** → read the skill, ask the user what changed, update the relevant reference files
  - **Review how taste is encoded in a skill** → read the skill's SKILL.md and reference files, assess against the patterns in `references/encoding-patterns.md`, report gaps
  - **Interview without a specific skill target** → run the interview, save findings to a structured document the user can apply later

## Full process

### 1. Scope the domain
Read the target skill's SKILL.md and any existing reference files. Identify:

- What decisions does this skill guide? (e.g., data modeling → ID strategy, naming, tenancy, migrations)
- Which decisions are currently generic (presenting options without recommending one)?
- Which decisions are missing entirely?

List the taste gaps — these become the interview topics.

### 2. Interview
Use the host's structured question mechanism when one is available, such as `AskUserQuestion`, `request_user_input`, or an equivalent UI prompt. If no structured question tool is available, ask concise plain-text questions directly. In either mode, ask 1-3 related questions at a time and wait for answers before continuing.

Follow `references/interview-guide.md` for the full interview protocol. The essentials: open with known context, ask about decisions rather than abstract preferences, capture the "because" behind strong opinions, batch questions by theme, weigh trade-offs actively, and stop when the user has no strong opinion.

### 3. Organize findings
Group interview answers into categories:

|Category|What goes here|Becomes|
|---|---|---|
|**Principles**|Core beliefs that guide many decisions ("monolith-first", "lean on existing stack")|A focused philosophy or principles reference file|
|**Defaults**|Concrete choices for specific decisions ("prefixed ULIDs for IDs", "snake_case for tables")|Conventions section in SKILL.md, or domain-specific reference files|
|**Decision rules**|Conditional choices ("D1 when small, Neon when multi-tenant")|Decision tables or if/then rules in SKILL.md or references|
|**Anti-patterns**|Things to avoid with reasoning ("never sequential integers — they leak count")|Anti-pattern sections in references|
|**No opinion**|Decisions where the user defers to convention|Skip — don't encode absence of taste|

### 4. Encode
Transform organized findings into skill artifacts using `references/encoding-patterns.md`. Prefer rationale-backed rules, comparison tables for context-dependent choices, anti-patterns with stories, and a philosophy or principles reference when three or more decisions share the same underlying principle.

For each artifact:

1. Write the reference file (or update existing ones)
2. Update SKILL.md to reference it — add to the key references table, link from relevant decision tree branches or workflow steps
3. Inline the most critical 1-2 sentence summary in SKILL.md itself so the agent gets the gist without reading the reference

**Multi-skill encoding:** When encoding taste across multiple skills at once, offer to fan out step 4 to parallel agents — one Encoder agent per target skill, each receiving only that skill's organized findings. This avoids serializing work on independent files. For a single skill, stay single-agent.

### 5. Validate
After encoding:

1. Read the updated SKILL.md end-to-end — does an agent following it produce opinionated output aligned with the user's taste?
2. Check that every encoded preference has a rationale (the "because")
3. Check that decision rules have clear conditions, not vague ones ("when it makes sense" → bad, "when you need RLS or multi-tenant isolation" → good)
4. Run the token-estimate tool from the authoring skill (`../authoring/tools/token-estimate.ts`) on the SKILL.md to verify it's still under 5000 tokens — taste encoding can bloat the main file if you inline too much
5. Confirm no reference file exceeds ~300 lines — split if needed

Present a summary to the user: what was encoded, where it lives, and any decisions that were left generic (with reasoning).

## Focused interview (for filling gaps)
When a skill already has some taste but not enough:

1. Read all existing reference files and conventions
2. List what's already encoded vs what's generic
3. Interview only the gaps — skip topics where the skill is already opinionated
4. Encode findings into the existing structure (update files, don't create parallel ones)

## Key references
|File|Covers|
|---|---|
|`references/interview-guide.md`|Question strategies by domain type, signal recognition, batching, depth calibration|
|`references/encoding-patterns.md`|The six encoding patterns with examples from real skills|