Coffee

• Every pick, find and gear answer is screened against the corpus and the gear notes read for that request, never against taste recalled from memory.
• Nothing that breaks a hard rule in the corpus Taste Profile (roast range, rejected flavors, brew methods the user does not use) is ever offered as a fit, and every suggestion says in one line why it fits the profile.
• Confirmed favorites (⭐) and unconfirmed candidates (👂) never blur: only the user's own word makes a coffee ⭐.
• The corpus grows only with what the user stated, so it stays ground truth.

For a plain "what do I like?" or "what's my gear?" lookup, read the corpus or the gear notes and answer; no intent needed.

Read <configRoot>/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Coffee/Config.md first (configRoot is $CLAUDE_CONFIG_DIR when set, else ~/.claude). It names two files, and both are ground truth:

• Taste corpus (Config.md Corpus: line; default <configRoot>/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Coffee/CoffeeReference.md). Human-editable markdown. Its ## Taste Profile section holds the user's own words and the screening rules every intent applies, hard rules marked as such. Rows grow in ### Batch N sections with two source tags: ⭐ favorite (they love it) and 👂 candidate (fits the profile or was recommended, unconfirmed).
• Gear notes (Config.md Gear: line; default the ## Coffee section of <configRoot>/LIFEOS/USER/GEAR.md). Grinders, brewers and the brew defaults tuned to the profile. Read it before any brew or gear answer, and write gear updates back there, never into this skill.

Neither file holds secrets, and the skill needs no account. When Config.md or the corpus is missing, say so, answer from what the request states, and point to Setup.md.

• Brew method outranks a flavor match. A coffee the user cannot brew the way they brew is out, however well the tasting notes match: an espresso blend for someone who only brews filter, or a light filter roast for someone who only pulls shots. The Taste Profile or the gear notes say which methods count.
• A spoken name can differ from the roaster's listed name. Treat a near-match as the same coffee, and record the alias in the corpus Notes column so the next lookup finds it.
• Only ⭐ rows are confirmed favorites. Other coffees from a favorite roaster stay 👂 candidates: say they "fit your profile," never that the user loves them, until the user says so.
• Recommend is request-driven (a pick for now or a mood); DiscoverCoffees is profile-driven (broaden beyond what they have). Don't collapse them.

Example 1: Recommend a coffee

User: "what coffee should I order?"
→ Recommend intent
→ A ranked pick (a confirmed ⭐ first when it fits the ask, then fitting candidates), each with one line on why it fits

Example 2: Discover new coffees

User: "what other coffees would I like besides my usual?"
→ DiscoverCoffees intent
→ A few finds not yet in the corpus, as "Because you like <anchor> → <roaster blend>" lines tagged safe fit or stretch

Example 3: Gear / brew question

User: "how should I brew for the taste I like?"
→ Reads the gear notes (no intent)
→ The brewer, ratio and grind the gear notes give for that profile, with one line tying each to the profile

Example 4: Grow the corpus

User: "add Example Roasters' Harbor Blend to my coffee list — I loved it"
→ AddCoffee intent
→ A dated ⭐ row in the corpus with what the user stated, counts updated, and a one-line confirmation