Prune TASTE.md

Walk every 🚩 marker forcing a resolution decision, then audit the remaining rules for staleness, vagueness, and redundancy. Goal: keep TASTE.md sharp and load-bearing.

Before you start

1. Read the TASTE.md in scope in full. A repo may have a cross-cutting root TASTE.md plus nested subdirectory-scoped ones. Prune the file the user pointed at, or the root by default. Note siblings exist but don't merge them — each is scoped to its subtree deliberately; keep the root cross-cutting and push area-specific rules down.
2. Read context files — CLAUDE.md, LESSONS.md, and your auto-memory (e.g. .claude/memory/MEMORY.md) if they exist. These are redundancy references: if a TASTE rule duplicates content there, it's a candidate to cut.
3. Assess current state:
   • Count 🚩 markers. Each one is an unresolved decision that blocks completion.
   • Count rules per domain subsection. Subsections with only 1 rule may be premature (collapse them back to flat).
   • Note rules at (1) older than ~3 months (check git log -L if needed). These are "never reinforced" candidates.
   • Total rule count. Target: under 30 rules across all subsections. Over 50 is overdue for pruning.
4. Ask about scope: "Walk all 🚩 markers, then full prune — or just 🚩 resolution this round?" Default to all if the user said /taste-prune without qualification.

5. Establish a clean git baseline. Prune is destructive, so the pre-prune state must be its own recoverable commit before you cut anything. Check git status for TASTE.md:

   • Dirty (uncommitted edits): commit it first, scoped — git add TASTE.md && git commit -m "context(taste): checkpoint before prune". Never git add -A.
   • Clean: HEAD is already your baseline; nothing to do.

   This guarantees every rule you're about to cut or rewrite is preserved at a known SHA, recoverable with one command.

Phase 1 — Resolve 🚩 markers

This phase is non-skippable: every 🚩 must be addressed before any other cleanup happens.

For each rule with a 🚩 marker, present:

🚩  {Subsection} / "{Rule excerpt}"
    Marked {date}: {context from the marker}

    Resolve:
    [a] Retire the rule entirely
        — The contradiction shows the rule is wrong, not just narrow.
    [b] Rewrite trigger condition to exclude the contradicting case
        — The rule is right in general but its `When [context]` was too broad.
        Propose a narrowed trigger; user can edit.
    [c] Dismiss as one-off — strip 🚩, keep the rule as-is
        — The contradicting moment was situational, not a real counter-pattern.
    [d] Scope it — move the contradicting variant to a subdirectory-scoped TASTE.md
        — The contradiction is a genuine per-area divergence, not a narrowing.
        Both rules are right, each in its own subtree. Only when that subdir's
        taste is substantial and usually out-of-scope elsewhere; otherwise prefer
        [b]. The nested file gets a precedence header + names the root rule it overrides.

    Choice? [a/b/c/d]

Apply each decision before moving to the next 🚩. After all 🚩 markers are resolved, the file is in a clean state — counters preserved, narrowing applied, dead rules cut.

Worked example — narrowing a trigger (path [b])

Rule in TASTE.md:
- Writing / "When writing emotional content, prefer honest plainness over
  symmetrical phrasing, because concrete beats clever. (2)
  🚩 2026-04-22: chose symmetrical hook for YouTube thumbnail"

Presented:
  🚩  Writing / "When writing emotional content, prefer honest plainness..."
      Marked 2026-04-22: chose symmetrical hook for YouTube thumbnail
      Choice? [a/b/c]

User picks [b]. Propose:
  Narrowed trigger: "When writing emotional content in long-form prose..."
  Reason: thumbnails/hooks have different forces — memorability rewards symmetry.
  Result: "When writing emotional content in long-form prose, prefer honest
           plainness over symmetrical phrasing, because concrete beats clever. (2)"
  Counter preserved. 🚩 stripped.

The instinct on [b] is to find the smallest phrasing change that excludes the contradicting case without gutting the rule. If you can't narrow without making the trigger awkward or near-empty, that's a signal the rule was wrong in shape — escalate to [a].

Phase 2 — Classify remaining rules

For each rule still in the file, classify:

Decision tree per rule

Apply in order; short-circuit on first match:

1. Does the `When [context]` describe a situation specific enough to match in a future session?
   → No: tighten (vague)

2. Is the `because [principle]` cited in TASTE.md's Principles section?
   → No: propose adding the principle, OR rephrase to cite an existing one.

3. Does another rule in the file cover the same trigger context?
   → Yes: merge

4. Is `(N) == 1` and the rule has been in the file >3 months without a 🚩 (no contradiction either)?
   → Ask the user: "This rule has never been reinforced. Still relevant?"

5. Does this rule actually express a *judgment call*, or is it a factual gotcha / workflow step / single fact?
   → Not a judgment call: move to LESSONS / process docs / memory

6. None of the above:
   → Keep (sharp)

Subsection hygiene

This is easy to skip — do it deliberately, not as an afterthought.

• Collapse premature subsections. If a domain subsection (Design, Writing, etc.) has only 1 rule, remove the subheading and put the rule under Decision Rules flat. Subsections should emerge from data, not anticipation.
• Graduate a subsection to a nested file when warranted. If a subsection has grown into a distinct sub-project domain (≥~3 rules) whose taste is usually out-of-scope elsewhere, flag it as a candidate to move into a subdirectory-scoped TASTE.md (progressive disclosure — it loads only when working in that subtree). Don't move it unilaterally; propose it, since it changes file layout and discovery wiring.
• Surface cross-domain patterns. If 3+ rules across different domains resolve the same underlying force (e.g., "plain vs clever" appears in Writing and Design), flag it to the user as a candidate Tension grouping. Do not create the grouping unilaterally — it changes file structure.

Phase 3 — Audit Principles

1. Orphan principles — Principles not cited in any Decision Rule's because clause. Ask: "Still load-bearing, or candidate to cut?"
2. Missing principles — because clauses citing a value that isn't in the Principles section. Propose adding it, or rewording the rule to cite an existing principle.
3. Format check — Principles use [aphorism] — [clarifier] form on a single line. The aphorism is the citable handle; the 5-15 word clarifier prevents misreading when read cold. Tighten any that bury the aphorism in the clarifier, omit the clarifier entirely, or whose clarifier just restates the aphorism.

Phase 4 — Present and apply

Show the user a structured summary before any writes:

TASTE.md prune proposal

Phase 1 — 🚩 resolutions:
  [resolved interactively above]

Phase 2 — Rule changes:
  Cut (stale):     X rules
  Cut (misplaced): Y rules → see recommendations
  Rewritten (vague/narrowed): Z rules
  Merged: A rules combined into B

Phase 3 — Principles:
  Added: ...
  Cut: ...
  Tightened: ...

Subsections:
  Collapsed: ...
  Pattern flagged for Tension grouping: ...

Apply all? [y / n / by-phase]

by-phase means walk Phase 2 → Phase 3 → subsections one at a time, getting [y/n] per phase. Use it when the user wants to commit between phases or veto a single phase's worth of edits.

Apply all approved edits in a single pass, then commit — scoped, immediately, so the prune is its own atomic, identifiable commit. A prune is one semantic op, so it's a single commit (or one per phase if the user chose by-phase), following the ledger grammar (see the lessons skill's Commit protocol). List what was cut or retired so a wrongly-removed rule is greppable in git log later:

git add TASTE.md
git commit -m "context(taste): prune — cut N, rewrote M, resolved K 🚩" -m "cut: <rule key 1>
cut: <rule key 2>
rewrote: <rule key 3>"

Only ever add the specific TASTE.md you pruned (use its real path for a nested file) — never git add -A. Skip the commit only on a true no-op. Then verify it landed (git status + git log -1 --stat) and register the repo in the machine-wide ledger index:

mkdir -p ~/.claude/context-ledger
r=$(git rev-parse --show-toplevel)
grep -qxF "$r" ~/.claude/context-ledger/repos 2>/dev/null || echo "$r" >> ~/.claude/context-ledger/repos

Report the recovery line to the user: the prune commit SHA plus git revert <sha> to undo the entire prune in one step.

Rescue pass

Before writing, do a final scan of everything being cut. Ask: "Any of these look like they'd be painful to re-derive if cut?" Show the full cut list. A cut taste rule is harder to recover than a cut gotcha — it required real session experience to articulate.

Rules

• Never silently delete 🚩 markers. Every one must be resolved interactively or the user must explicitly say "dismiss all 🚩s as one-offs."
• Never decrement (N) counters. If a rule is wrong, cut it or rewrite it — don't reduce N.
• Preserve (N) on rewrites. When narrowing a trigger, the prior reinforcements still count. On merges, default to sum — each prior (N) represents an independent confirmation of the underlying judgment, so summing reflects real cumulative evidence. Use max only when you suspect a single session reinforced both rules in parallel (double-counting). Ask the user if uncertain.
• Never move rules across files without telling the user. Flag misplaced rules in the proposal; the user decides whether to move them.
• Use (N), never [N]. (N) is the counter convention across these skills. (Square brackets also render as checkboxes in Obsidian.)
• Tension groupings require explicit approval. Don't restructure the file by adding a Tensions section unilaterally.
• If TASTE.md is already clean (no 🚩, all rules sharp, principles cited), say so and exit. Don't manufacture work.