@heart-of-gold/toolkit 0.1.43 → 0.1.45

package/.claude-plugin/marketplace.json

@@ -15,7 +15,7 @@
       "name": "deep-thought",
       "source": "./plugins/deep-thought",
       "description": "The Answer Computer — reasoning tools for brainstorming, planning, and deep thinking",
-      "version": "0.2.10"
+      "version": "0.2.11"
     },
     {
       "name": "marvin",

package/README.md

@@ -2,7 +2,7 @@
 
 > **Don't Panic.**
 
-31 skills for AI coding agents. Five plugins. Works with **Claude Code, Codex, OpenCode, Pi**, and any tool supporting the [agentskills.io](https://agentskills.io) standard. Named after *The Hitchhiker's Guide to the Galaxy* because the universe is absurd and your tools should at least have personality.
+32 skills for AI coding agents. Five plugins. Works with **Claude Code, Codex, OpenCode, Pi**, and any tool supporting the [agentskills.io](https://agentskills.io) standard. Named after *The Hitchhiker's Guide to the Galaxy* because the universe is absurd and your tools should at least have personality.
 
 ## Installation
 
@@ -79,11 +79,11 @@ Treat skills and helper scripts as executable automation, not passive text. Revi
 
 ### [Deep Thought](plugins/deep-thought/) — The Answer Computer
 
-Nine ways to think clearly about hard problems.
+Ten ways to think clearly about hard problems.
 
-Brainstorm before you plan. Plan before you build. Investigate when something breaks. Review when it ships. And when the stakes are high, simulate an expert panel that argues with itself until the right answer falls out.
+Brainstorm before you plan. Plan before you build. Investigate when something breaks. Review when it ships. Map where it could go when you can't see the futures yet. And when the stakes are high, simulate an expert panel that argues with itself until the right answer falls out.
 
-9 skills · 9 agents · 16 knowledge files
+10 skills · 9 agents · 16 knowledge files
 
 ```
 /deep-thought:brainstorm          # explore before committing
@@ -95,6 +95,7 @@ Brainstorm before you plan. Plan before you build. Investigate when something br
 /deep-thought:architecture-review # failure modes, scaling, ADRs
 /deep-thought:cto                 # strategic CTO advisor (grounded in the leadership canon)
 /deep-thought:craft-skill         # meta: generate SKILL.md files
+/deep-thought:improbable-futures  # product cartography — three lovable futures + visual map
 ```
 
 ### [Marvin](plugins/marvin/) — The Paranoid Android

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@heart-of-gold/toolkit",
-  "version": "0.1.43",
+  "version": "0.1.45",
   "type": "module",
   "description": "Cross-platform installer for Heart of Gold skills — works with Codex, OpenCode, Pi, Claude Code, and more",
   "bin": {

package/plugins/deep-thought/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "deep-thought",
-  "version": "0.2.10",
+  "version": "0.2.11",
   "description": "The Answer Computer — reasoning tools for brainstorming, planning, architecture design, and deep thinking",
   "author": {
     "name": "ondrej-svec",

package/plugins/deep-thought/README.md

@@ -3,7 +3,7 @@
 > "The Answer to the Great Question... Of Life, the Universe and Everything... Is... Forty-two."
 > But the question matters more. That's what this plugin is for.
 
-A reasoning plugin for Claude Code. Nine skills for thinking clearly about hard problems — from early-stage brainstorming through architectural review and strategic CTO decisions.
+A reasoning plugin for Claude Code. Ten skills for thinking clearly about hard problems — from early-stage brainstorming through architectural review and strategic CTO decisions.
 
 ## Skills
 
@@ -39,6 +39,9 @@ Strategic CTO advisor grounded in the leadership canon (Larson, Fournier, Majors
 ### `/deep-thought:craft-skill`
 Meta-skill — generates and refines SKILL.md files for Claude Code. Use it to create new skills with proper structure, boundaries, and validation criteria.
 
+### `/deep-thought:improbable-futures`
+Product cartography for any project. Reads current state, sketches three lovable futures worth chasing — each with a named user's love-letter from six months ahead, the capability that future demands, and the first moves toward it. Adds wild-card branches and hands off to `/babel-fish:visualize` for the visual map.
+
 ## Agents
 
 Nine specialized agents available for subagent delegation:

package/plugins/deep-thought/knowledge/strategy-dashboard-spec.md

@@ -0,0 +1,160 @@
+# Strategy Dashboard Spec
+
+Reference for `/deep-thought:improbable-futures` Phase 5h (structured data in output frontmatter) and Phase 8 (visual brief passed to `/babel-fish:visualize`). Extracted from the SKILL.md to keep the skill file under the 500-line threshold.
+
+The skill file references this knowledge; the skill does not work without it. Do not delete without updating the SKILL.
+
+---
+
+## Why this exists
+
+`/babel-fish:visualize` is a generalist designer. Without explicit direction, it produces "prose with one decorative SVG" and the strategic argument stays locked in paragraphs. The structured data blocks below give the visualizer the raw material for real visual components; the visual brief below tells it exactly what to build.
+
+---
+
+## Structured data blocks (Phase 5h output frontmatter)
+
+The skill's output markdown must carry four YAML blocks in the frontmatter. These are machine-readable — visualizers scan them to build components.
+
+### `comparison_dimensions` — the scannable matrix
+
+4–6 dimensions × 3 futures. Each cell is one short phrase. This is the single most important visual in the artifact — it lets a reader scan the strategic shape of all three futures in ~10 seconds.
+
+**Dimensions must reveal tradeoffs, not describe features.** Good: "Identity you become." "What you leave behind." "What this kills." Bad: "Has a CLI." "Uses Python." "Pricing tiers available."
+
+```yaml
+comparison_dimensions:
+  - name: "Identity you become"
+    future_1: "Software vendor"
+    future_2: "Embedded consultant"
+    future_3: "Standards author"
+  - name: "Revenue model"
+    future_1: "Org-layer licensing"
+    future_2: "€60k × 6 residencies/year"
+    future_3: "Books, talks, reputation"
+  - name: "What you leave behind"
+    future_1: "A daemon that runs without you"
+    future_2: "A customised harness in one codebase"
+    future_3: "A spec other people teach from"
+  - name: "What this kills"
+    future_1: "Workshops, residency, claim to own the spec"
+    future_2: "Daemon, scaling, canonical authorship"
+    future_3: "Brand dominance, premium-vendor identity"
+```
+
+### `timeline_waypoints` — per-future journey
+
+3–4 waypoints per future from "now" to 6 months. Each waypoint is a specific move at a specific time. These power the side-by-side journey timeline visuals.
+
+Waypoints are directions, not milestones. "Ship harness verify MVP" — good. "Sprint 1: scope MVP" — bad.
+
+```yaml
+timeline_waypoints:
+  future_1:
+    - { when: "Week 2",  move: "Ship harness verify CLI to 3 trusted engineers" }
+    - { when: "Week 6",  move: "Three skills live" }
+    - { when: "Month 3", move: "Cancel remaining workshops" }
+    - { when: "Month 6", move: "Petr's letter arrives" }
+  future_2: [ ... ]
+  future_3: [ ... ]
+```
+
+### `research_timing` — the urgency visual
+
+Dated events in the category plus the "YOU ARE HERE" pin and the "WINDOW CLOSES" marker. This makes the timing argument *visible* rather than buried in thesis prose.
+
+The YOU ARE HERE and WINDOW CLOSES markers are mandatory. Without them, the urgency is implicit rather than visual.
+
+```yaml
+research_timing:
+  - { date: "2025-07", source: "Manus", event: "Context Engineering for AI Agents" }
+  - { date: "2025-09", source: "Anthropic", event: "Effective Context Engineering" }
+  - { date: "2026-04-02", source: "Böckeler", event: "Harness Engineering defined" }
+  - { date: "2026-04-15", source: "ThoughtWorks Radar", event: "Cognitive Debt named" }
+  - { date: "2026-04-16", source: "YOU ARE HERE", event: "This map" }
+  - { date: "2027-04", source: "WINDOW CLOSES", event: "Spec-maintainer position claimed by someone" }
+```
+
+### `naming_landscape` — competing frames (optional)
+
+Positions competing terms/vocabularies against each other so the reader can see where this project's claim fits. Include when the category is mid-naming-fight; skip when the category's vocabulary is settled.
+
+```yaml
+naming_landscape:
+  - term: "context engineering"
+    backers: ["Anthropic", "Manus"]
+    scope: "What goes into the model — tokens, memory, tools"
+    position: "narrower"
+  - term: "harness engineering"
+    backers: ["Böckeler / Fowler", "harness-lab claim"]
+    scope: "The full loop — context PLUS verification PLUS workflow"
+    position: "wider — operationalises context engineering"
+```
+
+### `visual_brief` — the directive header
+
+Lists required components so the visualizer knows what to build.
+
+```yaml
+visual_brief:
+  artifact_family: "strategy-dashboard"
+  primary_components:
+    - "comparison_matrix"
+    - "journey_timelines"
+    - "urgency_timeline"
+    - "naming_landscape"
+  secondary_components:
+    - "strategy_thesis_hero"
+    - "letter_cards"
+    - "agent_command_ctas"
+```
+
+---
+
+## The visual brief — pass verbatim to `/babel-fish:visualize`
+
+> Treat this as a strategy dashboard, not a stylised document. The source markdown carries a `visual_brief` frontmatter listing required visual components and structured data blocks (`comparison_dimensions`, `timeline_waypoints`, `research_timing`, `naming_landscape`) that supply the data those components need.
+>
+> Implement each primary component as a distinct visual object with real visual weight — at least 4 prose-free or prose-light components above the fold:
+>
+> 1. **Comparison matrix** — render `comparison_dimensions` as a scannable 3-column × N-row grid at the top of the page. Use color/chips/spacing per cell so a reader can compare across futures in 10 seconds. Not a wall of text. This is the single most important visual on the page.
+> 2. **Journey timelines** — render `timeline_waypoints` as three side-by-side vertical timelines, each with date markers and one-line moves. Visual rhythm matters more than detail.
+> 3. **Urgency timeline** — render `research_timing` as a **vertical** timeline with one event per row (date column + label column). Do not use horizontal timelines with absolute-positioned labels — they collide whenever events cluster within a few weeks. The "YOU ARE HERE" row gets a larger, accent-coloured pin. The "WINDOW CLOSES" row gets the danger colour.
+> 4. **Naming landscape** (when present) — render `naming_landscape` as a position map showing where the project's claim fits among competing terms.
+>
+> Secondary components: render love-letters as styled letter objects (with date, signature, mild paper texture) — not as blockquotes. Render agent-commands as primary CTAs per future, distinctly stylised, copy-able.
+>
+> Anti-goals: do not produce a document with one SVG at top. Do not put the comparison matrix as bullet points. Do not let prose dominate the layout. The 10-second-scan test: a reader should see the strategic shape (three futures, their key differences, the timing pressure) without reading any paragraph.
+>
+> Use the agent-authored HTML path. Do not delegate the whole job to the smart-render fallback.
+
+---
+
+## UI quality rules — non-negotiable
+
+These rules exist because past runs failed on each one.
+
+- **Label collisions are bugs, not aesthetics.** If two text labels could overlap at any common viewport (1024 / 1280 / 1440 / 1920px wide), the layout is wrong. Default to vertical layouts for any timeline with ≥4 events or any cluster of events within 8% of axis distance.
+- **Absolute positioning is a smell on dense data.** Prefer flex/grid layouts that auto-space. Use absolute positioning only when the visual semantics demand it (e.g., a 2D scatter plot) AND when label collision is mathematically impossible.
+- **Every interactive component must work at 760px wide.** Test mentally: stacked single-column on mobile, multi-column on desktop. Add `@media (max-width: 760px)` collapses for every grid.
+- **Long labels must wrap or truncate predictably.** No `white-space: nowrap` on labels longer than 30 characters unless you've measured the available space.
+- **Color-coded futures must keep their colour everywhere.** Future 1 = accent (purple in default theme). Future 2 = accent-2 (teal). Future 3 = accent-3 (amber). Use these consistently across matrix, timelines, letters, CTAs.
+- **The danger colour is reserved for "what this kills" / "deadline" / "risk."** Do not use it decoratively.
+- **No more than one hero-scale element above the fold.** The thesis hero IS that element. The comparison matrix can be visually heavy but must not compete for primacy.
+
+---
+
+## Browser self-verification (when tools allow)
+
+If the agent executing the skill has Chrome / browser tooling available (e.g., `mcp__claude-in-chrome__*`, `mcp__plugin_chrome-devtools-mcp_chrome-devtools__*`, Playwright, or equivalent), use it to verify the published artifact before declaring success.
+
+After publishing, navigate to the published URL and:
+
+1. **Take a full-page screenshot at 1440px viewport.** Inspect for: overlapping text, broken grid alignment, wild whitespace gaps, components that render as raw markdown, missing visual elements from the brief.
+2. **Take a second screenshot at 760px viewport.** Inspect for: horizontal scroll, broken stacking, illegible text, cramped components.
+3. **If issues found:** describe the issue in one sentence, edit the artifact HTML, republish, re-verify. Cap iterations at 3 — beyond that, surface to the user with screenshots and ask for direction.
+4. **If clean:** report the URL to the user with a one-line verification note ("verified at 1440px and 760px — no collisions, all components render").
+
+If browser tools are not available, state that explicitly in the handoff note ("visual verification skipped — no browser tooling available") so the user knows to eyeball the result.
+
+The cost of an extra round-trip is small. The cost of shipping a broken visual that the user has to point out is large.

package/plugins/deep-thought/skills/improbable-futures/SKILL.md

@@ -0,0 +1,513 @@
+---
+name: improbable-futures
+description: >
+  Strategy-forward product cartography. Articulates the goal, grounds the analysis in domain
+  research, commits to a strategic thesis, then maps three mutually-exclusive futures that
+  execute it — each with a user's love-letter, required capability, what it excludes, and a
+  next move you can hand to your agent. Auto-invokes /babel-fish:visualize for the visual map.
+  Use when exploring "where could this go," forcing a strategic commitment, or stress-testing
+  a product idea for lovability. Triggers: improbable futures, product futures, where could
+  this go, map my project, lovable product, cartographer, product atlas, product strategy.
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Write
+  - Agent
+  - AskUserQuestion
+  - WebSearch
+  - WebFetch
+---
+
+# Improbable Futures
+
+Most product advice asks "is this good?" This skill asks better questions: **"what is the goal? what strategy serves it? where could that strategy take you, and what does each path cost?"**
+
+You are a cartographer and a strategist. Read the project as it actually is. Name the goal — explicitly. Ground the analysis in real domain research, not vibes. Commit to a single strategic thesis. Then sketch three futures that execute that thesis differently — each genuinely improbable, each mutually exclusive with the other two. Pin a love-letter from a named user six months ahead to each future. Surface wild cards. Hand the builder a map AND a next move they can give to their agent.
+
+Think of it as the Improbability Drive for product strategy: not three options that look similar, but three commitments that look mutually unreachable until you land in one of them.
+
+## Boundaries
+
+**This skill MAY:** read project files, scan repos, ask the user for goal and pitch when context is thin, run targeted web research for domain best-practices and strategic-move patterns, generate a strategy + map markdown, auto-invoke `/babel-fish:visualize` on the output.
+**This skill MAY NOT:** edit code, run builds, write implementation plans, produce verdicts or scorecards, generate pitch-deck copy, do TAM/SAM/SOM market sizing, name real clients, attribute opinions to specific named people.
+
+**This is a strategy AND a map, not a plan. Commit to a thesis — do not implement it. Hand the next move to the user's agent — do not execute it.**
+
+## Common Rationalizations
+
+| Shortcut | Why It Fails | The Cost |
+|----------|-------------|----------|
+| "Skip research — generate the futures from the project signal alone" | Without grounded reference to what works in this category, you produce vibe-strategy. Three futures that read smart but match no real strategic move pattern. | Smoothie output that the builder closes without aching |
+| "Skip the goal — work from what the project clearly is" | Projects rarely make the goal explicit. If you guess wrong, every future executes the wrong strategy. The map is geometrically correct and pointed at nothing. | Builder reads three "interesting" futures and feels none of them. The goal mismatch is silent until the futures land flat |
+| "Three plausible futures is enough" | Plausible is the enemy. The brief asks for IMPROBABLE futures that are mutually exclusive — not three reasonable variations the founder could pursue in parallel. | "Pick one and lose the others" turns into "pick whichever, do all three eventually" — no commitment, no map |
+| "Love-letters can sound similar across futures — same author, same project" | If all three letters read like the same person wrote them, you've written articles, not letters. Real letters have distinct voices, distinct ticks, distinct silences. | Reader skims the letters as decoration. The ache that should drive choice never lands |
+
+---
+
+## Phase 0: Detect Input Shape
+
+**Entry:** User invoked `/deep-thought:improbable-futures` with a path, a pitch, or nothing.
+
+**Case A — path to a repo or directory:** Note the path. Proceed to Phase 1.
+
+**Case B — inline pitch:** Note the pitch. Ask: "Is there a repo or docs I should read too, or should I work from this pitch alone?" If a path is offered, add it. Proceed.
+
+**Case C — nothing, or near-empty repo:** Use **AskUserQuestion** once. Header: "Improbable Futures". Question: "Give me one paragraph: what is this project, who is it for, and what's the nearest win you're imagining?" Conversational, not a form.
+
+**Exit:** You have a path, a pitch, or both.
+
+---
+
+## Phase 1: Read Current State
+
+**Entry:** Phase 0 complete.
+
+Read the signal-dense surface only:
+
+- `README.md`, `README` (root)
+- `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`
+- Top-level `docs/` — especially `brainstorms/`, `plans/`, dated last 90 days
+- One representative source file per major surface
+- `CLAUDE.md`, `AGENTS.md` at the root
+
+**Anti-pattern:** opening a tenth file. Stop — you have enough.
+
+Synthesize internally (not yet output): what the project actually is (the thing, not the pitch), who it's for, what it's orbiting (the unstated gravity well).
+
+**Exit:** You could describe the project in two to three honest sentences — its shape, not its copy.
+
+---
+
+## Phase 2: Articulate the Goal
+
+**Entry:** You understand the project's shape.
+
+**Why this phase exists:** Most builders haven't named their goal explicitly. They have a project. They know what they're working on. They haven't said out loud what success looks like, on what time horizon, in what shape. Without a named goal, the futures aim at nothing.
+
+**Step 1 — try to extract the goal from signal.** Read recent brainstorms, READMEs, plans, and any `goals.md` / `roadmap.md` style files. Look for explicit statements of intent. Synthesize one sentence: "The goal of this project, as far as the signal shows, is [X by Y]."
+
+**Step 2 — confirm or correct via AskUserQuestion.**
+- header: "Goal"
+- question: "I read your goal as: '[X]'. Adjust?"
+- options: `Yes, that's it`, `Close — let me edit`, `No — let me restate`, `I haven't articulated a goal yet`
+
+**Step 3 — handle "no goal yet."** If the user picks the last option, ask one focused question: "What does success look like for this project six to twelve months from now? One sentence. If you don't know yet, say so — we'll work from a placeholder and the futures will surface what the goal should be." Use the answer (or "no goal yet" placeholder) as the goal of record.
+
+**Why goal precedes strategy:** A future is a way to execute a strategy. A strategy is a way to pursue a goal. If the goal is unclear, every future is shooting at fog. If the user doesn't have a goal yet, the futures themselves can become a goal-articulation tool — but only if you name that explicitly in the output.
+
+**Exit:** A single-sentence goal of record. Could be a placeholder. Either way, you can quote it.
+
+---
+
+## Phase 3: Stage Detection
+
+**Entry:** Goal of record exists.
+
+Guess the stage from signals:
+
+| Stage | Signals |
+|---|---|
+| **Idea** | Pitch only, empty repo, no deployed surface |
+| **Mid-build** | Active commits, partial features, plans present, no public launch signal |
+| **Pre-launch** | Feature-complete signals, landing/waitlist language, launch references |
+| **Live** | Users referenced, usage metrics, post-launch docs, support files |
+
+Confirm with **AskUserQuestion** (header: "Stage"; question: "I read this as [stage]. Adjust?"; options: Idea / Mid-build / Pre-launch / Live / Mix).
+
+Stage shapes the weight of each section in Phase 5 — do not add new sections. Idea-stage futures are wider; live-stage futures must reckon with what already exists.
+
+**Exit:** Stage agreed.
+
+---
+
+## Phase 4: Research Grounding
+
+**Entry:** Goal and stage agreed.
+
+The futures must be grounded in what actually works in this category — not generated from vibes. Use the tier system below to pick the highest available source of grounding.
+
+### Grounding tiers
+
+**Tier 1 — User-provided references (highest fidelity).** If the project root contains a `references/futures/` directory or the user passed `--references <path>`, read those files first. Treat them as authoritative for the domain.
+
+**Tier 2 — Targeted web research (default).** Use **WebSearch** + **WebFetch** to pull 3–5 sources on:
+- Strategic-move patterns for projects in this category (e.g., "open-source workshop businesses how they scale," "developer tools community to commercial product")
+- Recent (≤24 months) writing from category practitioners — not generic advice, but specific case studies, post-mortems, founder essays
+- Best-practice frameworks the user's domain references (e.g., for a workshop business: pricing models, productisation patterns, embedded-residency models)
+
+Cite each source you use in the output's `Research Sources` section. If a source contradicts a future, surface the contradiction in that future's "What you'd have to believe" section.
+
+**Tier 3 — Training-data only (fallback).** If web access is unavailable or the user passes `--no-research`, state explicitly in the output: "Grounding tier: training-data only. Specific concepts applied: [list named frameworks or patterns]."
+
+### What to research, concretely
+
+Generate 3–5 search queries, then dispatch a parallel research subagent. Sample brief:
+
+> Research strategic-move patterns and case studies for [category]. Focus on:
+> - Real founder-written accounts (not advice columns)
+> - Post-mortems and pivots — what worked, what failed
+> - Specific products in this category that took unusual or improbable paths
+> - The 2–3 most-cited frameworks in this category (and their critics)
+> Return: 5–8 specific patterns or moves, each with one citation.
+
+**Anti-pattern:** generic "product strategy" advice from generalist business sites. Reject if the source isn't category-specific or doesn't cite a real product.
+
+**Exit:** A short internal brief: 5–8 grounded patterns, each citable. The futures in Phase 5 will be tested against these.
+
+---
+
+## Phase 5: Generate the Strategy Thesis and Map
+
+**Entry:** Phases 0–4 complete.
+
+This phase produces seven internal drafts. Do not write the file yet — Phase 6 reviews them first.
+
+### 5a. You are here — the diagnostic
+
+Two to four sentences. Quiet observation of the gravity well the project is already orbiting. No verdict. Specific. End with the tension the project is currently living inside (e.g., "right now you're trying to be both, which is the most expensive way to be either").
+
+### 5b. Strategy thesis — a single committed direction
+
+One paragraph, 3–5 sentences. Format:
+
+> Given the goal — **[quoted goal]** — your strategic thesis is **[single, committed direction grounded in research]**. The three futures below are not three different goals; they are three mutually-exclusive ways to execute this one thesis. Pick one and the others become unreachable.
+
+This is the load-bearing part. The thesis must:
+- Reference the goal verbatim
+- Commit to a single direction (not "explore options")
+- Be grounded in at least one Phase 4 research finding (cite inline)
+- Make the mutual-exclusivity of the futures intelligible — three executions of one thesis, not three different theses
+
+### 5c. Three mutually-exclusive futures
+
+Exactly three. Each a different execution of the thesis. For each, produce:
+
+1. **One-line bet** — specific, committal. Not a category ("a SaaS version"); a thing ("a small daemon installed in your repo that exposes three skills").
+2. **Stance paragraph** — 3–5 sentences explaining what this future actually is, what the builder becomes if they pick it, and what they stop being.
+3. **Required capability** — one sentence. The single thing that must exist for the love-letter to be possible.
+4. **This excludes** — one sentence. What picking this future kills. Naming the kill is what makes it mutually exclusive.
+
+**Improbability test (apply to every future before keeping it):**
+- Would a smart founder in this category have considered this option? If yes — push harder. The future is too obvious.
+- Is this a textbook scaling move (named-discipline play, productised-self-serve play, geographic-specialisation play)? If yes — regenerate.
+- Does this future, if pursued, kill the other two? If no — they're not mutually exclusive; they're parallel options. Regenerate.
+
+### 5d. Love-letters — one per future, distinct voices, with ache
+
+Each letter: 4–7 sentences from a named user, six months after they live in this future. Attribution line at the end.
+
+**Voice rules:**
+- Each letter must read like a different person wrote it. Different sentence rhythm, different vocabulary, different tics.
+- After drafting, re-read the three letters back-to-back. If two of them could trade signatures and nobody would notice, regenerate at least one.
+
+**Ache rules — every letter must contain at least two of these:**
+- A contradiction or longing (something they miss or didn't get, even though they love this)
+- A specific physical detail (time of day, what they were holding, the silence in the room)
+- An unresolved question or concern they tell only the recipient
+- A mild request (don't water this down, please don't change X, tell people in [place])
+- A sentence that wouldn't make sense in a testimonial reel
+
+**Anti-test:** Could this letter appear unmodified on a SaaS landing page as a customer quote? If yes — it's marketing copy. Regenerate.
+
+### 5e. Wild cards
+
+Three to five one-line branches. Genuinely improbable — not variations on the three futures.
+
+**Test:** would a "wild" card slot into one of the three futures as a feature? If yes, it's not wild. Regenerate.
+
+Each wild card should be a left turn the project could (improbably) take. Tactile, weird, anti-software, anti-scale, accidentally institutional — these are good directions. Variation of "another revenue stream" — bad direction.
+
+### 5f. Paths and required beliefs (per future)
+
+For each future:
+
+**Paths — first 2–3 moves.** Directions, not milestones. If you're writing "Sprint 1" or "Milestone 1", stop — that's `/plan`'s job.
+
+**What you'd have to believe — 2–4 assumptions.** Concrete bets, not vague "market exists" statements. Each belief is a place where you and a smart competitor could disagree and only time would tell who's right.
+
+### 5g. Agent-actionable next moves
+
+For each future, draft a single command the user can hand to their coding agent verbatim. Format:
+
+```
+/deep-thought:plan "[future-specific brief in one sentence]"
+```
+
+or, when more brainstorming is needed:
+
+```
+/deep-thought:brainstorm "[narrow exploration question]"
+```
+
+These commands appear in two places in the output:
+- In the YAML frontmatter as a structured `next_moves:` block (machine-readable)
+- In a "Hand this to your agent" section at the bottom of the output (human-readable)
+
+### 5h. Structured data for the visual (mandatory)
+
+The output markdown must carry structured data blocks in frontmatter that `/babel-fish:visualize` reads to build real components — not stylised prose. Without these blocks, the downstream visualizer falls back to "prose with one decorative SVG."
+
+Produce four (sometimes five) frontmatter blocks:
+
+- **`comparison_dimensions`** — 4–6 tradeoff-revealing dimensions × 3 futures. The single most important visual.
+- **`timeline_waypoints`** — 3–4 specific moves per future, dated.
+- **`research_timing`** — category events plus "YOU ARE HERE" and "WINDOW CLOSES" markers (both mandatory).
+- **`naming_landscape`** — competing vocabularies positioned (include when the category is mid-naming-fight).
+- **`visual_brief`** — directive header listing required components.
+
+**See `../knowledge/strategy-dashboard-spec.md`** for the exact YAML shape of each block, tradeoff-vs-feature examples, and the reasoning behind each field. That knowledge file is the authoritative spec; the skill must produce frontmatter that matches it.
+
+**Exit:** Seven internal drafts ready plus the structured visual blocks above. Nothing written yet.
+
+---
+
+## Phase 6: Self-Review Against Rejection Criteria
+
+**Entry:** Phase 5 drafts complete.
+
+Walk this checklist honestly. Look for reasons the map is wrong, not reasons to ship it.
+
+**Rejection checklist (the output is wrong if any item is true):**
+
+Strategic content:
+- [ ] The strategy thesis does not quote the goal of record verbatim
+- [ ] The thesis does not cite at least one research finding
+- [ ] Any future could be pursued in parallel with another — they are not mutually exclusive
+- [ ] Any future is a textbook category-conventional move (named-discipline / productised-self-serve / geographic-specialisation / "go enterprise")
+- [ ] The "This excludes" line for any future is vague or polite — it should name what you kill
+- [ ] Any love-letter could appear unmodified on a SaaS landing page as a customer quote
+- [ ] Two or more love-letters could trade signatures and nobody would notice
+- [ ] Any love-letter has zero of the ache markers (contradiction, physical detail, unresolved question, request, non-testimonial sentence)
+- [ ] Any wild card could slot into one of the three futures as a feature — it isn't wild
+- [ ] "You are here" praises or criticises instead of observing
+- [ ] Any "Path" reads as an implementation plan (Sprint 1, Milestone, etc.)
+- [ ] Any "What you'd have to believe" item is vague ("market exists") instead of a concrete bet
+- [ ] Drafts collectively exceed three futures, five wild cards, or seven sections
+- [ ] Pitch-deck vocabulary is present (TAM, SAM, SOM, value prop, positioning, ICP)
+- [ ] Any agent-actionable command is generic — it must be future-specific and verbatim-runnable
+- [ ] A contributor or client name appears anywhere
+
+Structured visual data (Phase 5h):
+- [ ] `comparison_dimensions` block has fewer than 4 dimensions, or any dimension is descriptive rather than tradeoff-revealing ("Has feature X" — wrong; "Identity you become" — right)
+- [ ] `timeline_waypoints` has fewer than 3 waypoints per future, or any waypoint reads as a milestone rather than a specific move
+- [ ] `research_timing` is missing the "YOU ARE HERE" pin or the "WINDOW CLOSES" marker — the urgency must be visible
+- [ ] Any structured block is in the prose body rather than the frontmatter — visualizers cannot scan prose for structure
+
+If any box is ticked, revise the affected draft. If the same box keeps getting ticked on rewrites, the signal for that part is too thin — ask one more clarifying question or drop the offending future and regenerate from the thesis.
+
+**Exit:** Every box unticked.
+
+---
+
+## Phase 7: Write the Output
+
+**Entry:** Drafts have passed self-review.
+
+**Output path:** `docs/futures/YYYY-MM-DD-{kebab-project}-improbable-futures.md`
+
+Write this skeleton exactly — heading depths are what `/babel-fish:visualize` reads as hierarchy.
+
+```markdown
+---
+title: "Improbable Futures: {project}"
+type: improbable-futures
+date: YYYY-MM-DD
+stage: {idea | mid-build | pre-launch | live}
+goal: "{goal of record, verbatim}"
+grounding_tier: {1 | 2 | 3}
+research_sources:
+  - "{url or citation 1}"
+  - "{url or citation 2}"
+next_moves:
+  future_1:
+    direction: "{one-line summary}"
+    suggested_command: "/deep-thought:plan ..."
+  future_2: { direction: "...", suggested_command: "..." }
+  future_3: { direction: "...", suggested_command: "..." }
+comparison_dimensions:
+  - { name: "Identity",        future_1: "...", future_2: "...", future_3: "..." }
+  - { name: "Revenue model",   future_1: "...", future_2: "...", future_3: "..." }
+  - { name: "What you leave",  future_1: "...", future_2: "...", future_3: "..." }
+  - { name: "What it costs",   future_1: "...", future_2: "...", future_3: "..." }
+  # 4–6 dimensions, each tradeoff-revealing
+timeline_waypoints:
+  future_1:
+    - { when: "Week 2",  move: "..." }
+    - { when: "Week 8",  move: "..." }
+    - { when: "Month 3", move: "..." }
+    - { when: "Month 6", move: "...'s letter arrives" }
+  future_2: [ ... ]
+  future_3: [ ... ]
+research_timing:
+  - { date: "YYYY-MM", source: "...", event: "..." }
+  - { date: "YYYY-MM-DD", source: "YOU ARE HERE", event: "This map" }
+  - { date: "YYYY-MM", source: "WINDOW CLOSES", event: "..." }
+naming_landscape:
+  - { term: "...", backers: ["..."], scope: "..." }
+visual_brief:
+  artifact_family: "strategy-dashboard"
+  primary_components:
+    - "comparison_matrix"     # from comparison_dimensions — top of page
+    - "journey_timelines"     # from timeline_waypoints — three side-by-side
+    - "urgency_timeline"      # from research_timing — single horizontal axis
+    - "naming_landscape"      # from naming_landscape — when present
+  secondary_components:
+    - "strategy_thesis_hero"
+    - "letter_cards"          # love-letters as letter-styled objects, not blockquotes
+    - "agent_command_ctas"    # primary call-to-action per future
+---
+
+# Improbable Futures: {project}
+
+## You are here
+
+{2–4 sentences from 5a.}
+
+## Strategy thesis
+
+{Single paragraph from 5b. Quotes the goal. Cites a research finding.}
+
+## Three futures worth chasing
+
+Each future is a way to execute the thesis above. Pick one and the other two stop being available.
+
+### Future 1: {one-line bet}
+
+{Stance paragraph.}
+
+> {Love-letter, 4–7 sentences.}
+>
+> — {Named user, role, six months in}
+
+**Required capability:** {one sentence}
+
+**This excludes:** {one sentence — what picking this future kills}
+
+**Hand to your agent:** `/deep-thought:plan "..."`
+
+<details>
+<summary>First moves and what you'd have to believe</summary>
+
+**First moves**
+- {Direction 1}
+- {Direction 2}
+- {Direction 3}
+
+**What you'd have to believe**
+- {Belief 1}
+- {Belief 2}
+
+</details>
+
+### Future 2: {one-line bet}
+
+{Same shape as Future 1.}
+
+### Future 3: {one-line bet}
+
+{Same shape as Future 1.}
+
+## Wild cards
+
+- **{Title}** — {one-line description}
+- {3–5 wild cards total}
+
+## Hand this to your agent
+
+If you've picked a future — even tentatively — the next move is not another brainstorm. It's a plan.
+
+- **Future 1 ({direction}):** `/deep-thought:plan "..."`
+- **Future 2 ({direction}):** `/deep-thought:brainstorm "..."`
+- **Future 3 ({direction}):** `/deep-thought:plan "..."`
+
+If you haven't picked one, sit with the love-letters one more time. The one you ached at is the one to chase.
+
+## Research sources
+
+- {Source 1 with citation}
+- {Source 2 with citation}
+- Grounding tier: {1, 2, or 3}
+```
+
+**Exit:** File written.
+
+---
+
+## Phase 8: Auto-Visualize with Explicit Brief, Then Handoff
+
+**Entry:** Output file written.
+
+The visual is a first-class part of this skill, not an option. Do not ask whether to visualize — invoke it. And do not invoke it without a brief — `/babel-fish:visualize` is a generalist; without explicit direction it produces "prose with one decorative SVG" and the strategic argument stays locked in paragraphs.
+
+### Step 1 — invoke visualize with the strategy-dashboard brief
+
+Call the Skill tool with `babel-fish:visualize`. Pass the output path as the primary argument and append the **strategy-dashboard brief from `../knowledge/strategy-dashboard-spec.md`** as additional context (concatenate verbatim to the args string after the path).
+
+Why the brief: the visualizer is a generalist. Without explicit direction it produces "prose with one decorative SVG." The knowledge file tells it exactly which components to build, enforces the UI quality rules (no label collisions, colour consistency, 760px mobile behaviour, danger-colour reserved for risk), and includes a browser-self-verification protocol for agents with Chrome tooling available. Read the knowledge file and pass it along.
+
+Surface three things after the call returns:
+- the markdown path: `docs/futures/YYYY-MM-DD-{kebab-project}-improbable-futures.md`
+- the published URL from visualize
+- verification status — if the executing agent has browser tools, the 1440px / 760px screenshot check per `strategy-dashboard-spec.md`; otherwise an explicit note that verification was skipped
+
+If `/babel-fish:visualize` fails, report plainly, leave the markdown in place, and tell the user how to retry (`/babel-fish:visualize {output-path}` plus the brief from the knowledge file). Do not silently fall back to a menu without the visual.
+
+### Step 2 — post-visual handoff
+
+Present the post-visual menu (prefer the harness's structured choice UI if available):
+
+1. **Review and refine** — Tell me what reads off; I'll rewrite the affected sections and republish
+2. **Plan a future** — Pick 1, 2, or 3; I'll suggest `/deep-thought:plan` with the agent-command from the output
+3. **Done for now** — Markdown and visual are both saved
+
+If "Review and refine": ask which section, rewrite through Phases 5–6, rewrite the file, re-invoke visualize with the same brief, return here.
+If "Plan a future": surface the matching `next_moves[future_N].suggested_command` from the frontmatter.
+If "Done": confirm both paths and exit.
+
+**Why the brief, not just the path.** The visualizer is a generalist designer who's never met this skill. Handing it a markdown file alone is like handing a designer a brief that says "make something nice with this content." This skill knows what makes an improbable-futures map land — the visual brief is how that knowledge survives the handoff.
+
+---
+
+## Validate
+
+Before delivering the map, verify:
+
+- [ ] Phase 0–1 detected input shape and synthesized the project in 2–3 honest sentences
+- [ ] Phase 2 surfaced a goal of record (or an explicit "no goal yet" placeholder) — confirmed with the user
+- [ ] Phase 3 confirmed stage with the user
+- [ ] Phase 4 grounding tier is declared in the output frontmatter; sources cited if Tier 2
+- [ ] Phase 5b strategy thesis quotes the goal verbatim and cites a research finding
+- [ ] Three mutually-exclusive futures — each with bet, stance, capability, "this excludes," love-letter, paths, beliefs, agent-command
+- [ ] Each love-letter passes the voice-distinctness test (could the letters trade signatures? — no) and the ache test (≥2 ache markers per letter)
+- [ ] Each future has a "This excludes" line that names what is killed by picking this future
+- [ ] 3–5 genuinely-wild wild cards, each one line
+- [ ] `next_moves:` block in frontmatter has all three futures with verbatim-runnable commands
+- [ ] "Hand this to your agent" section appears in the output body
+- [ ] Phase 6 rejection checklist was walked — every box unticked
+- [ ] Output file exists at `docs/futures/YYYY-MM-DD-{kebab-project}-improbable-futures.md`
+- [ ] Frontmatter contains all four structured visual blocks (`comparison_dimensions`, `timeline_waypoints`, `research_timing`, `visual_brief`); `naming_landscape` present when relevant
+- [ ] `comparison_dimensions` has 4–6 tradeoff-revealing dimensions (not feature lists)
+- [ ] `research_timing` includes the "YOU ARE HERE" pin and "WINDOW CLOSES" marker
+- [ ] `/babel-fish:visualize` was auto-invoked **with the explicit strategy-dashboard brief** — not a bare path
+- [ ] Published artifact passes the 10-second-scan test: the three futures and their key differences are visible without reading paragraphs
+- [ ] Published artifact has at least 4 distinct prose-light visual components above the fold
+- [ ] Comparison matrix renders as a scannable grid (not bullet points)
+- [ ] Timelines with dense events use vertical layout (no horizontal label collision)
+- [ ] Browser self-verification completed (1440px + 760px screenshots) OR explicit note that tooling is unavailable
+- [ ] No contributor names, no client names, no pitch-deck vocabulary, no MBA vocabulary
+
+## What Makes This Heart of Gold
+
+- **Problem Reframing (1.4):** Refuses the verdict trap. Asks "what is the goal, what strategy serves it, and what futures execute it?" — not "is this good?"
+- **AI-Augmented Discovery (1.3):** Phase 4 grounds the futures in real category research — case studies, founder writing, post-mortems — so the strategy thesis is not vibes.
+- **AI Curiosity (1.1):** Three mutually-exclusive futures plus wild cards — structurally biased toward widening the option space before forcing commitment. The "This excludes" line is what turns options into commitment.
+- **Opportunity Recognition (1.2):** The named-user love-letter surfaces the smallest unit of "why this should exist" — a specific person on a specific Tuesday — instead of the generic "market opportunity" abstraction.
+
+## Knowledge References
+
+- `../knowledge/strategy-dashboard-spec.md` — **authoritative spec for Phase 5h structured data and the Phase 8 visual brief.** Referenced by both phases; the skill will not produce a coherent dashboard without it.
+- `../knowledge/discovery-patterns.md` — AskUserQuestion usage, thin-context handling, goal articulation
+- `../knowledge/socratic-patterns.md` — evidence grounding for Phase 6 self-review
+- `../knowledge/twelve-techniques.md` — technique checklist this skill applies (few-shot examples, negative prompting, format specification, reflection, RAG via Phase 4 research)
+- `../knowledge/strategic-decomposition.md` — strategy-thesis framing (referenced by Phase 5b)

package/plugins/guide/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "guide",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "The Hitchhiker's Guide — content creation suite with automated pipeline, daily briefs, and blog writing",
   "author": {
     "name": "ondrej-svec",

package/plugins/guide/scripts/fetch-anthropic-news.py

@@ -0,0 +1,163 @@
+#!/usr/bin/env python3
+"""
+fetch-anthropic-news.py — Fetch Anthropic news posts from sitemap.xml as signals.
+
+Anthropic publishes no RSS feed, but anthropic.com/sitemap.xml lists every
+/news/ post with a <lastmod> timestamp. We parse that, filter by freshness,
+fetch each recent page for its <title> + meta description, and emit signals
+in the same schema as fetch-rss.py.
+
+Usage:
+    python3 fetch-anthropic-news.py --config <path-to-config.yaml>
+
+Config (under sources.anthropic_news):
+    enabled: true
+    freshness_hours: 168
+    max_items: 5
+"""
+import argparse
+import json
+import re
+import sys
+import urllib.error
+import urllib.parse
+import urllib.request
+from datetime import datetime, timedelta, timezone
+from xml.etree import ElementTree as ET
+
+import yaml
+
+SITEMAP_URL = "https://www.anthropic.com/sitemap.xml"
+PATH_PREFIX = "/news/"
+USER_AGENT = "heart-of-gold-pipeline/1.0"
+FETCH_TIMEOUT = 10
+SITEMAP_NS = "{http://www.sitemaps.org/schemas/sitemap/0.9}"
+
+TITLE_RE = re.compile(r"<title[^>]*>([^<]*)</title>", re.IGNORECASE)
+META_DESC_RES = [
+    re.compile(
+        r'<meta[^>]+name=["\']description["\'][^>]*content=["\']([^"\']*)["\']',
+        re.IGNORECASE,
+    ),
+    re.compile(
+        r'<meta[^>]+content=["\']([^"\']*)["\'][^>]*name=["\']description["\']',
+        re.IGNORECASE,
+    ),
+    re.compile(
+        r'<meta[^>]+property=["\']og:description["\'][^>]*content=["\']([^"\']*)["\']',
+        re.IGNORECASE,
+    ),
+]
+
+
+def fetch_url(url, timeout=FETCH_TIMEOUT):
+    req = urllib.request.Request(url, headers={"User-Agent": USER_AGENT})
+    with urllib.request.urlopen(req, timeout=timeout) as resp:
+        return resp.read().decode("utf-8", errors="replace")
+
+
+def parse_sitemap_urls(xml_text, path_prefix, cutoff):
+    root = ET.fromstring(xml_text)
+    entries = []
+    for url_elem in root.findall(f"{SITEMAP_NS}url"):
+        loc = (url_elem.findtext(f"{SITEMAP_NS}loc") or "").strip()
+        lastmod = (url_elem.findtext(f"{SITEMAP_NS}lastmod") or "").strip()
+        if not loc:
+            continue
+        path = urllib.parse.urlparse(loc).path
+        if not path.startswith(path_prefix) or path == path_prefix:
+            continue
+        if not lastmod:
+            continue
+        try:
+            dt = datetime.fromisoformat(lastmod.replace("Z", "+00:00"))
+        except ValueError:
+            continue
+        if dt < cutoff:
+            continue
+        entries.append((loc, dt))
+    return entries
+
+
+def extract_meta(html):
+    title = ""
+    m = TITLE_RE.search(html)
+    if m:
+        title = m.group(1).strip()
+    description = ""
+    for pattern in META_DESC_RES:
+        m = pattern.search(html)
+        if m:
+            description = m.group(1).strip()
+            break
+    return title, description
+
+
+def slug_to_title(url):
+    slug = urllib.parse.urlparse(url).path.rstrip("/").rsplit("/", 1)[-1]
+    return slug.replace("-", " ").title()
+
+
+def main():
+    parser = argparse.ArgumentParser(description="Fetch Anthropic news signals from sitemap")
+    parser.add_argument("--config", required=True)
+    args = parser.parse_args()
+
+    try:
+        with open(args.config) as f:
+            config = yaml.safe_load(f)
+    except Exception as e:
+        print(f"Error reading config: {e}", file=sys.stderr)
+        sys.exit(1)
+
+    src = (config.get("sources") or {}).get("anthropic_news") or {}
+    if not src.get("enabled", False):
+        print("[]")
+        sys.exit(0)
+
+    freshness_hours = src.get("freshness_hours", 168)
+    max_items = src.get("max_items", 5)
+
+    cutoff = datetime.now(timezone.utc) - timedelta(hours=freshness_hours)
+
+    try:
+        sitemap_xml = fetch_url(SITEMAP_URL)
+    except (urllib.error.URLError, TimeoutError) as e:
+        print(f"Error fetching sitemap: {e}", file=sys.stderr)
+        print("[]")
+        sys.exit(0)
+
+    try:
+        entries = parse_sitemap_urls(sitemap_xml, PATH_PREFIX, cutoff)
+    except ET.ParseError as e:
+        print(f"Error parsing sitemap: {e}", file=sys.stderr)
+        print("[]")
+        sys.exit(0)
+
+    entries.sort(key=lambda x: x[1], reverse=True)
+    entries = entries[:max_items]
+
+    signals = []
+    for url, lastmod in entries:
+        try:
+            html = fetch_url(url)
+            title, description = extract_meta(html)
+        except (urllib.error.URLError, TimeoutError) as e:
+            print(f"Warn: could not fetch {url}: {e}", file=sys.stderr)
+            title, description = "", ""
+
+        signals.append({
+            "source": "rss",
+            "title": title or slug_to_title(url),
+            "url": url,
+            "content": description,
+            "published_at": lastmod.isoformat(),
+            "metadata": {"source_name": "anthropic-news"},
+        })
+
+    print(json.dumps(signals, indent=2))
+    sys.exit(0)
+
+
+if __name__ == "__main__":
+    main()

package/plugins/guide/scripts/run-pipeline-fetch.sh

@@ -172,6 +172,12 @@ if [[ "$EVENTS_ENABLED" == "true" ]]; then
   run_source "events" "python3 '$SCRIPTS_DIR/fetch-events.py' --config '$CONFIG_PATH'"
 fi
 
+# 5. Anthropic news (sitemap-driven)
+ANTHROPIC_NEWS_ENABLED=$(echo "$CONFIG_JSON" | python3 -c "import json,sys; d=json.load(sys.stdin); print('true' if d['sources'].get('anthropic_news',{}).get('enabled',False) else 'false')")
+if [[ "$ANTHROPIC_NEWS_ENABLED" == "true" ]]; then
+  run_source "anthropic_news" "python3 '$SCRIPTS_DIR/fetch-anthropic-news.py' --config '$CONFIG_PATH'"
+fi
+
 # ── Combine and normalize ─────────────────────────────────────────────────────
 
 echo "  · Combining signals..." >&2
@@ -183,7 +189,7 @@ sys.path.insert(0, '$SCRIPTS_DIR')
 from pipeline_utils import combine_signals, validate_signal, next_pipeline_path, normalize_score
 
 # Read all source outputs
-source_files = ['rss', 'hn', 'gmail', 'events']
+source_files = ['rss', 'hn', 'gmail', 'events', 'anthropic_news']
 all_signals = []
 for name in source_files:
     path = '$WORK_DIR/' + name + '.json'