Taste prune

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:

Category	Action	What it means
Sharp	Keep	When [context] has fired in real sessions (N≥2), rule held up, phrasing is specific.
Stale	Cut or ask	(1) for many months, no recent reinforcement, no clear current use case.
Vague	Tighten	When [context] is too broad to match reliably (e.g., "When working with code…"). Rewrite.
Redundant	Merge	Two rules cover overlapping triggers with the same preference. Combine.
Misplaced	Flag	Belongs in LESSONS.md (gotcha), your process/workflow docs (workflow), CLAUDE.md (architecture), memory (single fact), or a subdirectory-scoped TASTE.md (area-specific taste that shouldn't sit in the cross-cutting root).

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.