chore: remove dev artifacts from installer scan surface (#465)

* chore: remove dev artifacts from installer scan surface Hermes (and other harnesses that clone raw GitHub instead of honoring .clawhubignore) scan files that never reach an installed skill, producing a wall of false-positive security findings. Remove the stale SKILL-original.md backup, internal docs/plans and docs/test-results, and release-notes.md so the scanned tree matches what actually ships. These were already excluded from the ClawHub bundle via .clawhubignore and from git archives via .gitattributes export-ignore. No runtime files change. Refs #464 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs: drop dangling SKILL-original.md reference in AGENTS.md Greptile-flagged: the deletion left a 'kept for reference only' pointer to the removed file. Refs #465 --------- Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-01 07:41:30 -07:00
parent 4aae93ee5d
commit 26da1e157c
20 changed files with 2 additions and 3648 deletions
@@ -23,13 +23,11 @@ assets/        export-ignore
 # claude.ai-bundle-specific exclusions live in scripts/build-skill.sh.
 # Historical + repo-only manifests
 SKILL-original.md  export-ignore
 SPEC.md            export-ignore
 TASKS.md           export-ignore
 test-run.log       export-ignore
 CONTRIBUTORS.md    export-ignore
 HERMES_SETUP.md    export-ignore
 release-notes.md   export-ignore
 CHANGELOG.md       export-ignore
 uv.lock            export-ignore
@@ -3,14 +3,14 @@
 Agent Skills package for researching any topic across Reddit, X, YouTube, and web. Installable across Claude Code (most common host), Codex, Cursor, GitHub Copilot, Gemini CLI, and 50+ other [Agent Skills](https://agentskills.io) hosts. Python scripts with multi-source search aggregation.
 ## Structure
- `skills/last30days/SKILL.md` — canonical skill definition / runtime spec the model reads when the slash command fires (`SKILL-original.md` at repo root is the historical v1 spec, kept for reference only)
+- `skills/last30days/SKILL.md` — canonical skill definition / runtime spec the model reads when the slash command fires
 - `skills/last30days/scripts/last30days.py` — main research engine
 - `skills/last30days/scripts/lib/` — search, enrichment, rendering modules
 - `skills/last30days/scripts/lib/vendor/bird-search/` — vendored X search client
 - `docs/solutions/` — documented solutions to past problems (bugs, best practices, workflow patterns), organized by category with YAML frontmatter (`module`, `tags`, `problem_type`)
 - `CONCEPTS.md` — shared domain vocabulary (Skill, Engine, Harness, Beta channel) — relevant when orienting to the codebase or discussing project terminology
 - `CONFIGURATION.md` — user-facing knobs (env vars, flags, per-host install patterns); keep in sync per the rules below
- `CHANGELOG.md` / `release-notes.md` — release history and human-readable notes (CHANGELOG = structured, release-notes = launch copy)
+- `CHANGELOG.md` — structured release history (launch copy lives in GitHub Releases)
 - `HERMES_SETUP.md` — install instructions for the Hermes harness specifically
 ## Orientation
@@ -1,391 +0,0 @@
 ---
 name: last30days
 description: Research a topic from the last 30 days on Reddit + X + Web, become an expert, and write copy-paste-ready prompts for the user's target tool.
 argument-hint: "[topic] for [tool]" or "[topic]"
 context: fork
 agent: Explore
 disable-model-invocation: true
 allowed-tools: Bash, Read, Write, AskUserQuestion, WebSearch
 ---
 # last30days: Research Any Topic from the Last 30 Days
 Research ANY topic across Reddit, X, and the web. Surface what people are actually discussing, recommending, and debating right now.
 Use cases:
 - **Prompting**: "photorealistic people in Nano Banana Pro", "Midjourney prompts", "ChatGPT image generation" → learn techniques, get copy-paste prompts
 - **Recommendations**: "best Claude Code skills", "top AI tools" → get a LIST of specific things people mention
 - **News**: "what's happening with OpenAI", "latest AI announcements" → current events and updates
 - **General**: any topic you're curious about → understand what the community is saying
 ## CRITICAL: Parse User Intent
 Before doing anything, parse the user's input for:
 1. **TOPIC**: What they want to learn about (e.g., "web app mockups", "Claude Code skills", "image generation")
 2. **TARGET TOOL** (if specified): Where they'll use the prompts (e.g., "Nano Banana Pro", "ChatGPT", "Midjourney")
 3. **QUERY TYPE**: What kind of research they want:
   - **PROMPTING** - "X prompts", "prompting for X", "X best practices" → User wants to learn techniques and get copy-paste prompts
   - **RECOMMENDATIONS** - "best X", "top X", "what X should I use", "recommended X" → User wants a LIST of specific things
   - **NEWS** - "what's happening with X", "X news", "latest on X" → User wants current events/updates
   - **GENERAL** - anything else → User wants broad understanding of the topic
 Common patterns:
 - `[topic] for [tool]` → "web mockups for Nano Banana Pro" → TOOL IS SPECIFIED
 - `[topic] prompts for [tool]` → "UI design prompts for Midjourney" → TOOL IS SPECIFIED
 - Just `[topic]` → "iOS design mockups" → TOOL NOT SPECIFIED, that's OK
 - "best [topic]" or "top [topic]" → QUERY_TYPE = RECOMMENDATIONS
 - "what are the best [topic]" → QUERY_TYPE = RECOMMENDATIONS
 **IMPORTANT: Do NOT ask about target tool before research.**
 - If tool is specified in the query, use it
 - If tool is NOT specified, run research first, then ask AFTER showing results
 **Store these variables:**
 - `TOPIC = [extracted topic]`
 - `TARGET_TOOL = [extracted tool, or "unknown" if not specified]`
 - `QUERY_TYPE = [RECOMMENDATIONS | NEWS | HOW-TO | GENERAL]`
 ---
 ## Setup Check
 The skill works in three modes based on available API keys:
 1. **Full Mode** (both keys): Reddit + X + WebSearch - best results with engagement metrics
 2. **Partial Mode** (one key): Reddit-only or X-only + WebSearch
 3. **Web-Only Mode** (no keys): WebSearch only - still useful, but no engagement metrics
 **API keys are OPTIONAL.** The skill will work without them using WebSearch fallback.
 ### First-Time Setup (Optional but Recommended)
 If the user wants to add API keys for better results:
 ```bash
 mkdir -p ~/.config/last30days
 cat > ~/.config/last30days/.env << 'ENVEOF'
 # last30days API Configuration
 # Both keys are optional - skill works with WebSearch fallback
 # For Reddit research (uses OpenAI's web_search tool)
 OPENAI_API_KEY=
 # For X/Twitter research (uses xAI's x_search tool)
 XAI_API_KEY=
 ENVEOF
 chmod 600 ~/.config/last30days/.env
 echo "Config created at ~/.config/last30days/.env"
 echo "Edit to add your API keys for enhanced research."
 ```
 **DO NOT stop if no keys are configured.** Proceed with web-only mode.
 ---
 ## Research Execution
 **IMPORTANT: The script handles API key detection automatically.** Run it and check the output to determine mode.
 **Step 1: Run the research script**
 ```bash
 python3 ~/.claude/skills/last30days/scripts/last30days.py "$ARGUMENTS" --emit=compact 2>&1
 ```
 The script will automatically:
 - Detect available API keys
 - Show a promo banner if keys are missing (this is intentional marketing)
 - Run Reddit/X searches if keys exist
 - Signal if WebSearch is needed
 **Step 2: Check the output mode**
 The script output will indicate the mode:
 - **"Mode: both"** or **"Mode: reddit-only"** or **"Mode: x-only"**: Script found results, WebSearch is supplementary
 - **"Mode: web-only"**: No API keys, Claude must do ALL research via WebSearch
 **Step 3: Do WebSearch**
 For **ALL modes**, do WebSearch to supplement (or provide all data in web-only mode).
 Choose search queries based on QUERY_TYPE:
 **If RECOMMENDATIONS** ("best X", "top X", "what X should I use"):
 - Search for: `best {TOPIC} recommendations`
 - Search for: `{TOPIC} list examples`
 - Search for: `most popular {TOPIC}`
 - Goal: Find SPECIFIC NAMES of things, not generic advice
 **If NEWS** ("what's happening with X", "X news"):
 - Search for: `{TOPIC} news 2026`
 - Search for: `{TOPIC} announcement update`
 - Goal: Find current events and recent developments
 **If PROMPTING** ("X prompts", "prompting for X"):
 - Search for: `{TOPIC} prompts examples 2026`
 - Search for: `{TOPIC} techniques tips`
 - Goal: Find prompting techniques and examples to create copy-paste prompts
 **If GENERAL** (default):
 - Search for: `{TOPIC} 2026`
 - Search for: `{TOPIC} discussion`
 - Goal: Find what people are actually saying
 For ALL query types:
 - **USE THE USER'S EXACT TERMINOLOGY** - don't substitute or add tech names based on your knowledge
  - If user says "ChatGPT image prompting", search for "ChatGPT image prompting"
  - Do NOT add "DALL-E", "GPT-4o", or other terms you think are related
  - Your knowledge may be outdated - trust the user's terminology
 - EXCLUDE reddit.com, x.com, twitter.com (covered by script)
 - INCLUDE: blogs, tutorials, docs, news, GitHub repos
 - **DO NOT output "Sources:" list** - this is noise, we'll show stats at the end
 **Step 3: Wait for background script to complete**
 Use TaskOutput to get the script results before proceeding to synthesis.
 **Depth options** (passed through from user's command):
 - `--quick` → Faster, fewer sources (8-12 each)
 - (default) → Balanced (20-30 each)
 - `--deep` → Comprehensive (50-70 Reddit, 40-60 X)
 ---
 ## Judge Agent: Synthesize All Sources
 **After all searches complete, internally synthesize (don't display stats yet):**
 The Judge Agent must:
 1. Weight Reddit/X sources HIGHER (they have engagement signals: upvotes, likes)
 2. Weight WebSearch sources LOWER (no engagement data)
 3. Identify patterns that appear across ALL three sources (strongest signals)
 4. Note any contradictions between sources
 5. Extract the top 3-5 actionable insights
 **Do NOT display stats here - they come at the end, right before the invitation.**
 ---
 ## FIRST: Internalize the Research
 **CRITICAL: Ground your synthesis in the ACTUAL research content, not your pre-existing knowledge.**
 Read the research output carefully. Pay attention to:
 - **Exact product/tool names** mentioned (e.g., if research mentions "ClawdBot" or "@clawdbot", that's a DIFFERENT product than "Claude Code" - don't conflate them)
 - **Specific quotes and insights** from the sources - use THESE, not generic knowledge
 - **What the sources actually say**, not what you assume the topic is about
 **ANTI-PATTERN TO AVOID**: If user asks about "clawdbot skills" and research returns ClawdBot content (self-hosted AI agent), do NOT synthesize this as "Claude Code skills" just because both involve "skills". Read what the research actually says.
 ### If QUERY_TYPE = RECOMMENDATIONS
 **CRITICAL: Extract SPECIFIC NAMES, not generic patterns.**
 When user asks "best X" or "top X", they want a LIST of specific things:
 - Scan research for specific product names, tool names, project names, skill names, etc.
 - Count how many times each is mentioned
 - Note which sources recommend each (Reddit thread, X post, blog)
 - List them by popularity/mention count
 **BAD synthesis for "best Claude Code skills":**
 > "Skills are powerful. Keep them under 500 lines. Use progressive disclosure."
 **GOOD synthesis for "best Claude Code skills":**
 > "Most mentioned skills: /commit (5 mentions), remotion skill (4x), git-worktree (3x), /pr (3x). The Remotion announcement got 16K likes on X."
 ### For all QUERY_TYPEs
 Identify from the ACTUAL RESEARCH OUTPUT:
 - **PROMPT FORMAT** - Does research recommend JSON, structured params, natural language, keywords? THIS IS CRITICAL.
 - The top 3-5 patterns/techniques that appeared across multiple sources
 - Specific keywords, structures, or approaches mentioned BY THE SOURCES
 - Common pitfalls mentioned BY THE SOURCES
 **If research says "use JSON prompts" or "structured prompts", you MUST deliver prompts in that format later.**
 ---
 ## THEN: Show Summary + Invite Vision
 **CRITICAL: Do NOT output any "Sources:" lists. The final display should be clean.**
 **Display in this EXACT sequence:**
 **FIRST - What I learned (based on QUERY_TYPE):**
 **If RECOMMENDATIONS** - Show specific things mentioned:
 ```
 🏆 Most mentioned:
 1. [Specific name] - mentioned {n}x (r/sub, @handle, blog.com)
 2. [Specific name] - mentioned {n}x (sources)
 3. [Specific name] - mentioned {n}x (sources)
 4. [Specific name] - mentioned {n}x (sources)
 5. [Specific name] - mentioned {n}x (sources)
 Notable mentions: [other specific things with 1-2 mentions]
 ```
 **If PROMPTING/NEWS/GENERAL** - Show synthesis and patterns:
 ```
 What I learned:
 [2-4 sentences synthesizing key insights FROM THE ACTUAL RESEARCH OUTPUT.]
 KEY PATTERNS I'll use:
 1. [Pattern from research]
 2. [Pattern from research]
 3. [Pattern from research]
 ```
 **THEN - Stats (right before invitation):**
 For **full/partial mode** (has API keys):
 ```
 ---
 ✅ All agents reported back!
 ├─ 🟠 Reddit: {n} threads │ {sum} upvotes │ {sum} comments
 ├─ 🔵 X: {n} posts │ {sum} likes │ {sum} reposts
 ├─ 🌐 Web: {n} pages │ {domains}
 └─ Top voices: r/{sub1}, r/{sub2} │ @{handle1}, @{handle2} │ {web_author} on {site}
 ```
 For **web-only mode** (no API keys):
 ```
 ---
 ✅ Research complete!
 ├─ 🌐 Web: {n} pages │ {domains}
 └─ Top sources: {author1} on {site1}, {author2} on {site2}
 💡 Want engagement metrics? Add API keys to ~/.config/last30days/.env
   - OPENAI_API_KEY → Reddit (real upvotes & comments)
   - XAI_API_KEY → X/Twitter (real likes & reposts)
 ```
 **LAST - Invitation:**
 ```
 ---
 Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into {TARGET_TOOL}.
 ```
 **Use real numbers from the research output.** The patterns should be actual insights from the research, not generic advice.
 **SELF-CHECK before displaying**: Re-read your "What I learned" section. Does it match what the research ACTUALLY says? If the research was about ClawdBot (a self-hosted AI agent), your summary should be about ClawdBot, not Claude Code. If you catch yourself projecting your own knowledge instead of the research, rewrite it.
 **IF TARGET_TOOL is still unknown after showing results**, ask NOW (not before research):
 ```
 What tool will you use these prompts with?
 Options:
 1. [Most relevant tool based on research - e.g., if research mentioned Figma/Sketch, offer those]
 2. Nano Banana Pro (image generation)
 3. ChatGPT / Claude (text/code)
 4. Other (tell me)
 ```
 **IMPORTANT**: After displaying this, WAIT for the user to respond. Don't dump generic prompts.
 ---
 ## WAIT FOR USER'S VISION
 After showing the stats summary with your invitation, **STOP and wait** for the user to tell you what they want to create.
 When they respond with their vision (e.g., "I want a landing page mockup for my SaaS app"), THEN write a single, thoughtful, tailored prompt.
 ---
 ## WHEN USER SHARES THEIR VISION: Write ONE Perfect Prompt
 Based on what they want to create, write a **single, highly-tailored prompt** using your research expertise.
 ### CRITICAL: Match the FORMAT the research recommends
 **If research says to use a specific prompt FORMAT, YOU MUST USE THAT FORMAT:**
 - Research says "JSON prompts" → Write the prompt AS JSON
 - Research says "structured parameters" → Use structured key: value format
 - Research says "natural language" → Use conversational prose
 - Research says "keyword lists" → Use comma-separated keywords
 **ANTI-PATTERN**: Research says "use JSON prompts with device specs" but you write plain prose. This defeats the entire purpose of the research.
 ### Output Format:
 ```
 Here's your prompt for {TARGET_TOOL}:
 ---
 [The actual prompt IN THE FORMAT THE RESEARCH RECOMMENDS - if research said JSON, this is JSON. If research said natural language, this is prose. Match what works.]
 ---
 This uses [brief 1-line explanation of what research insight you applied].
 ```
 ### Quality Checklist:
 - [ ] **FORMAT MATCHES RESEARCH** - If research said JSON/structured/etc, prompt IS that format
 - [ ] Directly addresses what the user said they want to create
 - [ ] Uses specific patterns/keywords discovered in research
 - [ ] Ready to paste with zero edits (or minimal [PLACEHOLDERS] clearly marked)
 - [ ] Appropriate length and style for TARGET_TOOL
 ---
 ## IF USER ASKS FOR MORE OPTIONS
 Only if they ask for alternatives or more prompts, provide 2-3 variations. Don't dump a prompt pack unless requested.
 ---
 ## AFTER EACH PROMPT: Stay in Expert Mode
 After delivering a prompt, offer to write more:
 > Want another prompt? Just tell me what you're creating next.
 ---
 ## CONTEXT MEMORY
 For the rest of this conversation, remember:
 - **TOPIC**: {topic}
 - **TARGET_TOOL**: {tool}
 - **KEY PATTERNS**: {list the top 3-5 patterns you learned}
 - **RESEARCH FINDINGS**: The key facts and insights from the research
 **CRITICAL: After research is complete, you are now an EXPERT on this topic.**
 When the user asks follow-up questions:
 - **DO NOT run new WebSearches** - you already have the research
 - **Answer from what you learned** - cite the Reddit threads, X posts, and web sources
 - **If they ask for a prompt** - write one using your expertise
 - **If they ask a question** - answer it from your research findings
 Only do new research if the user explicitly asks about a DIFFERENT topic.
 ---
 ## Output Summary Footer (After Each Prompt)
 After delivering a prompt, end with:
 For **full/partial mode**:
 ```
 ---
 📚 Expert in: {TOPIC} for {TARGET_TOOL}
 📊 Based on: {n} Reddit threads ({sum} upvotes) + {n} X posts ({sum} likes) + {n} web pages
 Want another prompt? Just tell me what you're creating next.
 ```
 For **web-only mode**:
 ```
 ---
 📚 Expert in: {TOPIC} for {TARGET_TOOL}
 📊 Based on: {n} web pages from {domains}
 Want another prompt? Just tell me what you're creating next.
 💡 Unlock Reddit & X data: Add API keys to ~/.config/last30days/.env
 ```
@@ -1,306 +0,0 @@
 ---
 > **NOTE (added 2026-05-16):** This plan references `bash scripts/sync.sh`. That script was deleted in [PR #405](https://github.com/mvanhorn/last30days-skill/pull/405); the install workflow is now `npx skills add . -g -y` (symlinks the working tree across every detected harness). For context on why sync.sh went away, see [docs/solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md](../solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md). The decisions captured in this plan remain accurate; only the deploy mechanism changed.
 title: "feat: --competitors flag for auto-discovered comparison fan-out"
 type: feat
 status: active
 date: 2026-04-22
 ---
 # feat: --competitors flag for auto-discovered comparison fan-out
 ## Overview
 Add a `--competitors` flag to the last30days engine that auto-discovers 2-4 peer entities for the topic, runs the full retrieval pipeline on each in parallel, and renders a multi-entity comparison. Invoking `last30days Kanye West --competitors` should resolve to "Kanye vs Drake vs Kendrick Lamar" and emit a comparison report covering all three. Invoking `last30days OpenAI --competitors` should resolve to "OpenAI vs Anthropic vs xAI vs Gemini" and emit a four-way comparison.
 Discovery mirrors the existing `resolve.auto_resolve()` pattern used for X handles and subreddits at pipeline start — web search (Brave / Exa / Serper) plus deterministic extraction. Not an internal LLM call.
 ## Problem Frame
 Users who want a comparison today must type "OpenAI vs Anthropic vs xAI" themselves. The `planner._comparison_entities()` path already handles explicit multi-entity topics and `render._render_comparison_scaffold()` already emits a 9-axis comparison table. What is missing is the discovery half — a user who types a single entity with `--competitors` should get the comparison for free.
 This is also the natural next step after the Step 0.55 category-peer subreddit work (PR #305, merged 2026-04-22). That feature widens the subreddit set within a single topic; this feature widens the entity set into peer entities.
 ## Requirements Trace
 - R1. New `--competitors` boolean flag that triggers competitor discovery and multi-entity fan-out.
 - R2. New `--competitors-list="A,B,C"` to explicitly skip discovery (mirrors `--plan`, `--subreddits`, `--x-handle` overrides).
 - R3. New `--competitors=N` short form to set competitor count inline (N in 1..6).
 - R4. Default count is 3 competitors (original + 3 = 4-way comparison).
 - R5. Competitor retrieval depth inherits the main run's depth (`--quick` / `--deep`); all entities run in parallel so wall clock stays close to a single run.
 - R6. Discovery mirrors `resolve.auto_resolve()`: web search for peers, deterministic text extraction. No internal LLM dependency.
 - R7. If no web search backend is configured and no `--competitors-list` was passed, engine emits a LAW 7-style stderr telling the host agent to pass `--competitors-list` and exits non-zero.
 - R8. Output rendering is a single comparison report covering all entities, reusing the existing 9-axis scaffold from `render._render_comparison_scaffold()` where applicable.
 ## Scope Boundaries
 - Synthesis prompt changes beyond wiring N reports into the existing comparison scaffold are out of scope.
 - `--competitors` does not replace the existing explicit "A vs B vs C" topic parsing in `planner._comparison_entities()`; both paths coexist.
 - No caching layer for discovery results in v1.
 - No UI/SKILL.md rewrite of the entire comparison section; only the new flag is documented.
 - No new web search backend.
 ### Deferred to Separate Tasks
 - Caching of competitor lookups: separate follow-up once hit rate justifies it.
 - Disambiguation UX for topics with multiple common entities ("Amazon" the company vs the river): separate brainstorm.
 ## Context & Research
 ### Relevant Code and Patterns
 - `scripts/last30days.py:168-249` — `build_parser()` argparse definitions. Existing depth flags (`--quick`, `--deep`) and override flags (`--plan`, `--subreddits`, `--x-handle`, `--auto-resolve`) set the convention to mirror.
 - `scripts/lib/resolve.py:179-258` — `auto_resolve()` is the reference pattern: web search fan-out via `ThreadPoolExecutor`, per-query extraction functions, graceful empty-dict return when no backend is available.
 - `scripts/lib/resolve.py:98-140` — `_extract_x_handle()` and sibling extractors show the deterministic text-mining style competitor extraction should mirror.
 - `scripts/lib/pipeline.py:162-220` — `pipeline.run()` signature is the fan-out target. One call per entity, each returning a `schema.Report`.
 - `scripts/lib/planner.py:430-564` — Existing comparison-intent handling and `_comparison_entities()` entity extraction. The new flag feeds the same mental model but populates entities from discovery instead of from the topic string.
 - `scripts/lib/render.py:333-392` — `_render_comparison_scaffold()` already emits a 9-axis markdown comparison table. The new multi-report renderer should reuse this helper by assembling a synthetic "A vs B vs C" topic header for it.
 - `scripts/lib/grounding.py` + `scripts/lib/providers.py` — Web search backend resolution (Brave / Exa / Serper). Reused as-is.
 ### Institutional Learnings
 - No existing `docs/solutions/` entries for competitor discovery or multi-entity fan-out.
 - Recent plan `docs/plans/2026-04-22-001-fix-category-peer-subreddit-resolution-plan.md` established the precedent of deterministic peer expansion; this plan extends that idea from subreddits to entities.
 ### External References
 - None gathered — local patterns are strong. `resolve.auto_resolve()` is a direct template.
 ## Key Technical Decisions
 - **Discovery mirrors auto_resolve, not plan_query.** Web search + regex extraction, not an LLM call. Matches the user's explicit direction ("use the python brain the same way it searches for X handles"). Cheaper, no provider credential requirement, deterministic.
 - **Orchestration lives in `last30days.py` main, not inside `pipeline.run()`.** The fan-out is a top-level concern — one pipeline run per entity, each independent. Keeps `pipeline.run()` single-entity and unchanged except for sharing a `ThreadPoolExecutor` factory.
 - **Sub-runs inherit main depth and run in parallel.** Wall clock ≈ single run; token cost scales linearly with N. User-controlled via the existing `--quick`/`--deep` flags.
 - **New module `scripts/lib/competitors.py` instead of adding to `resolve.py`.** Keeps resolve focused on single-entity entity-bundle discovery (handles/subreddits/github); competitors.py owns peer-entity discovery. Similar shape, different responsibility.
 - **Multi-report render is additive in `render.py`.** New `render_comparison_multi(reports: list[Report]) -> str` composes a synthetic "A vs B vs C" topic and delegates to the existing scaffold + synthesis path where possible. No rewrite of the single-entity render path.
 - **Default count = 3 competitors (4-way comparison).** Hard cap at 6.
 - **LAW 7-style stderr when no backend and no list.** Matches how `planner.plan_query()` already tells the hosting agent to pass `--plan`.
 ## Open Questions
 ### Resolved During Planning
 - **Discovery mechanism:** Web search via `grounding.web_search()`, not an internal LLM. User confirmed the auto_resolve pattern is the target.
 - **Default competitor count:** 3 (original + 3 = 4-way).
 - **Sub-run depth:** Inherit main depth, parallel execution.
 - **Flag naming:** `--competitors` (standard argparse double-dash). `--competitors=N` for inline count. `--competitors-list="A,B,C"` to skip discovery.
 ### Deferred to Implementation
 - Exact extraction heuristics for competitor names across Brave / Exa / Serper result shapes. The SERP text varies (listicles, comparison pages, "vs" pages); the initial implementation will start with listicle parsing plus a "X vs Y" pattern match, and harden against real results in the test phase.
 - Handling of topic ambiguity ("Amazon", "Apple"). Initial behavior: trust whatever web search returns for the topic verbatim; disambiguation is a separate concern.
 - Merge strategy when two entities return overlapping URLs (e.g., an "OpenAI vs Anthropic" article shows up in both runs). Likely dedupe at the clustering step, but defer the exact policy until we see how often it happens.
 - Whether to expose competitor discovery artifacts (the raw web search results) as a debug emit. Follow the existing `--debug` conventions.
 ## Implementation Units
 - [ ] **Unit 1: CLI flag parsing and validation**
 **Goal:** Add `--competitors`, `--competitors=N`, and `--competitors-list` to the argparse surface, validate values, and thread them into the main orchestration.
 **Requirements:** R1, R2, R3, R4
 **Dependencies:** None
 **Files:**
 - Modify: `scripts/last30days.py`
 - Test: `tests/test_cli_competitors.py`
 **Approach:**
 - Add three mutually cooperative flags near line 205 in `build_parser()`:
  - `--competitors` with `nargs="?"` and `const=3` so bare `--competitors` defaults to 3, `--competitors=4` is honored, and `--competitors=0` is rejected
  - `--competitors-list` free-text CSV
 - Normalize in `main()`: if `--competitors-list` is present, skip discovery and use the list. If `--competitors` is set and no list, trigger discovery with count = the flag value. Clamp count to 1..6 with a stderr warning at boundary.
 - Thread the resulting entity list into the orchestrator added in Unit 3.
 **Patterns to follow:**
 - `--plan` argument at `scripts/last30days.py:187` — same skip-discovery-when-explicit shape.
 - `--subreddits` / `--x-handle` at `scripts/last30days.py:180,189` — same override semantics.
 **Test scenarios:**
 - Happy path: bare `--competitors` parses to count=3, empty list.
 - Happy path: `--competitors=4` parses to count=4.
 - Happy path: `--competitors-list="A,B,C"` parses to count=3, list=["A","B","C"], and is preferred over any discovery signal.
 - Edge case: `--competitors=0` and `--competitors=-1` are rejected with a clear error.
 - Edge case: `--competitors=99` clamps to 6 with a stderr warning.
 - Edge case: `--competitors` combined with `--competitors-list` uses the list and logs that discovery was skipped.
 - Edge case: `--competitors-list` value with whitespace ("A, B , C") normalizes correctly.
 **Verification:**
 - Running the binary with each flag variation produces the expected post-parse state without calling out to the network.
 - [ ] **Unit 2: `scripts/lib/competitors.py` discovery module**
 **Goal:** Discover peer entities for a topic using web search + deterministic extraction, mirroring `resolve.auto_resolve()`.
 **Requirements:** R6, R7
 **Dependencies:** None (pure module; wired by Unit 3)
 **Files:**
 - Create: `scripts/lib/competitors.py`
 - Test: `tests/test_competitors.py`
 **Approach:**
 - Public entry point `discover_competitors(topic: str, count: int, config: dict) -> list[str]`.
 - Early return `[]` when `_has_backend(config)` is false (reuse the helper from `resolve.py`; factor if needed).
 - Fan out 2-3 web searches in a `ThreadPoolExecutor`:
  - `"{topic} competitors"`
  - `"{topic} alternatives"`
  - `"{topic} vs"` (captures "X vs Y" articles)
 - Feed results into a deterministic `_extract_peer_entities(results, topic)` that:
  - Mines titles and snippets for capitalized noun phrases other than the topic itself
  - Scores by frequency across results
  - Filters stopwords and the topic's own tokens
  - Returns top `count` unique entities ordered by score
 - Emit a single-line stderr log mirroring the `resolve._log` format.
 **Patterns to follow:**
 - `scripts/lib/resolve.py:179-258` for the function shape, executor usage, and empty-result fallback.
 - `scripts/lib/resolve.py:98-140` for extractor style (small, deterministic, no external state).
 **Test scenarios:**
 - Happy path: canned SERP fixtures for "OpenAI" return ["Anthropic", "xAI", "Google"] or close peers in the top 3.
 - Happy path: canned SERP fixtures for "Kanye West" return rap peers (Drake, Kendrick) in the top 3.
 - Edge case: empty SERP results return `[]` without raising.
 - Edge case: extractor filters out the topic itself (case- and punctuation-insensitive).
 - Edge case: near-duplicate entities ("OpenAI" vs "Open AI") dedupe to one slot.
 - Error path: web search backend raises — the failure is logged and the function returns `[]`.
 - Edge case: count=1 returns a single-element list; count=6 returns up to six entities.
 **Verification:**
 - Unit tests pass with fixtures committed under `tests/fixtures/competitors-*.json`.
 - Manual run against a live backend for one topic confirms sensible output (recorded as a notes file, not a test assertion).
 - [ ] **Unit 3: Parallel fan-out orchestrator**
 **Goal:** Run `pipeline.run()` once per entity (topic + discovered competitors) in parallel, collect `schema.Report` per entity, and hand them to the comparison renderer.
 **Requirements:** R5, R7
 **Dependencies:** Unit 1, Unit 2
 **Files:**
 - Modify: `scripts/last30days.py`
 - Possibly create: `scripts/lib/fanout.py` if the orchestrator grows past ~60 lines
 - Test: `tests/test_competitor_fanout.py`
 **Approach:**
 - After arg parsing and before the existing `pipeline.run()` call, branch on `args.competitors`:
  - If a list was provided or discovery returned entities, build `entities = [topic, *competitors]`.
  - Spawn one `pipeline.run()` per entity via `ThreadPoolExecutor(max_workers=len(entities))`, passing the same `config`, `depth`, and all sub-run-relevant args (mock, plan, etc.). Respect `--plan` — if a plan is passed it applies to the main topic only; competitors use the internal planner fallback for v1.
  - Collect `{entity: Report}` mapping. A per-entity failure logs a stderr warning and drops that entity from the comparison; the run continues as long as 2 entities succeed.
  - If fewer than 2 entities survive, exit with a clear error.
 - LAW 7-style stderr:
  - If `args.competitors` is set, no list was passed, no web search backend is configured, emit a LAW 7 stderr message pointing to the `--competitors-list` override and exit non-zero. Reuse the tone from `planner.plan_query()` fallback (`scripts/lib/planner.py:125-135`).
 **Execution note:** Start with a failing integration test that exercises the full main → orchestrator → mocked pipeline.run path; the orchestrator is where bugs hide.
 **Patterns to follow:**
 - `scripts/lib/resolve.py:225-239` for ThreadPoolExecutor + as_completed + per-future error handling.
 - `scripts/lib/pipeline.py:310+` for how ThreadPoolExecutor is already used inside a single run (same idiom, outer layer).
 **Test scenarios:**
 - Happy path: main + 2 competitors, all three `pipeline.run()` calls succeed (mocked), orchestrator returns 3 Reports.
 - Happy path: discovery returns the competitor list; orchestrator fans out accordingly.
 - Edge case: one of three competitor pipelines raises — the run continues with the surviving 2 and emits a warning.
 - Edge case: all competitors fail but the main topic succeeds — orchestrator exits non-zero with a clear error rather than silently degrading to a single-entity render.
 - Edge case: `--competitors` set, no backend, no list — orchestrator emits the LAW 7 stderr and exits non-zero before any pipeline call.
 - Integration: wall-clock time for 3 mocked pipelines in parallel is close to the slowest single run, not the sum (timing assertion with generous margin).
 **Verification:**
 - End-to-end test with mocked `pipeline.run()` and mocked competitors discovery produces 3 Reports and hands them to a stubbed renderer.
 - [ ] **Unit 4: Multi-report comparison renderer**
 **Goal:** Compose N `schema.Report`s into a single comparison-mode output, reusing the existing 9-axis scaffold.
 **Requirements:** R8
 **Dependencies:** Unit 3
 **Files:**
 - Modify: `scripts/lib/render.py`
 - Test: `tests/test_render_comparison_multi.py`
 **Approach:**
 - Add `render_comparison_multi(reports: list[schema.Report], *, emit: str) -> str`.
 - Build a synthetic comparison topic: `f"{entity_a} vs {entity_b} vs {entity_c}"`.
 - Reuse `_render_comparison_scaffold()` for the table skeleton. Each entity column is populated from its own Report's top clusters and citations.
 - For the narrative synthesis block, concatenate per-entity highlights, clearly labeled by entity, under a shared "Comparison" header.
 - Preserve existing emit modes (`compact`, `md`, `json`, `context`). In `json` emit, return a `{"entities": [...], "reports": [...]}` shape; single-Report consumers remain unaffected because the single-report render path is untouched.
 **Patterns to follow:**
 - `scripts/lib/render.py:333-392` (`_parse_comparison_entities`, `_render_comparison_scaffold`) — the scaffold is the contract.
 - `scripts/lib/render.py` single-report rendering — for per-entity narrative blocks.
 **Test scenarios:**
 - Happy path: 3 Reports with distinct clusters render into a 3-column table and a "Comparison" section that mentions each entity at least once.
 - Happy path: 2 Reports render as a 2-column table without breaking the scaffold.
 - Edge case: a Report with an empty cluster list renders as "(no significant discussion this month)" in its column rather than crashing.
 - Edge case: Reports with overlapping URLs (same article cited by two entities) dedupe citations at the footer but keep both column entries.
 - Emit variants: `--emit=compact`, `--emit=md`, `--emit=json`, `--emit=context` each produce valid output with all entities represented.
 - Integration: end-to-end snapshot test using fixture Reports, checked against a stored expected output (with a clear update path when the scaffold intentionally evolves).
 **Verification:**
 - Snapshot tests pass. Manual review of one real 3-way comparison confirms readability.
 - [ ] **Unit 5: Docs, SKILL.md mention, and sync**
 **Goal:** Document the new flag so the hosting agent and human users both know it exists, and run the sync script.
 **Requirements:** R1-R8 (surfaces them to users)
 **Dependencies:** Units 1-4
 **Files:**
 - Modify: `SKILL.md`
 - Modify: `README.md` (brief flag reference)
 - Modify: `CHANGELOG.md`
 - Run: `bash scripts/sync.sh`
 **Approach:**
 - Add a compact "Competitor mode" subsection under the existing comparison docs in `SKILL.md`. Document the flag, the default count, the override flag, and the LAW 7 fallback stderr.
 - Keep `README.md` addition to a single example line.
 - CHANGELOG entry mirrors the voice of recent entries (imperative, outcome-first).
 - Sync via `scripts/sync.sh` per CLAUDE.md rules so `~/.claude/`, `~/.agents/`, `~/.codex/` pick up the new SKILL.md.
 **Test scenarios:**
 - Test expectation: none — documentation and sync only. Verification is by inspection and by running `sync.sh` and confirming target directories updated.
 **Verification:**
 - `sync.sh` completes without errors.
 - `SKILL.md` rendered preview mentions `--competitors` in the comparison section.
 ## System-Wide Impact
 - **Interaction graph:** `last30days.py main()` now orchestrates multiple `pipeline.run()` calls instead of one. No other callers of `pipeline.run()` are affected (it remains single-entity).
 - **Error propagation:** Per-entity failures degrade gracefully as long as ≥2 entities survive; fewer survivors exits non-zero. Discovery failure with `--competitors` and no list is fatal.
 - **State lifecycle risks:** Each sub-run uses its own `pipeline.run()` state; no shared mutable config. The `config` dict is read-only in `pipeline.run()` today — verify before committing to shared-reference passing, else deep-copy per sub-run.
 - **API surface parity:** `--competitors` coexists with the existing explicit "A vs B vs C" topic parsing in `planner._comparison_entities()`. Both produce comparable output formats; the only difference is where the entity list came from.
 - **Integration coverage:** The fan-out orchestrator crosses CLI → discovery → N pipelines → render; integration tests in Unit 3 and Unit 4 must exercise the full path end to end, not just unit-level.
 - **Unchanged invariants:** `pipeline.run()` signature and single-entity semantics are unchanged. The single-entity render path in `render.py` is unchanged. No changes to `planner.plan_query()`. No changes to existing flags.
 ## Risks & Dependencies
 | Risk | Mitigation |
 |------|------------|
 | Competitor discovery returns garbage entities for niche topics. | `--competitors-list` override lets the user (or hosting agent) correct it. Unit tests with edge-case fixtures. Log discovery output to stderr under `--debug`. |
 | Token cost scales linearly with N sub-runs. | Default count capped at 3, hard max 6, inherit `--quick` to let users throttle. Wall clock stays parallel. Emit a cost hint to stderr when N ≥ 4. |
 | Merge conflicts against the single-entity render path during refactoring. | Keep the multi-report renderer strictly additive; do not modify the single-Report code path. |
 | Config dict mutation inside sub-runs could leak state between entities. | Verify read-only usage before sharing references. If any sub-component mutates, deep-copy per sub-run before spawning threads. |
 | A SERP extractor that works on Brave fixtures breaks on Exa/Serper result shapes. | Test fixtures for all three backends. Extractor operates on a normalized shape from `grounding.web_search()` (already the case), not raw provider output. |
 | Hosting agent (Claude Code, Codex) unaware of the new flag when it could usefully pass `--competitors-list`. | SKILL.md updated in Unit 5 documents the flag in the same style as `--plan` and `--auto-resolve`. |
 ## Documentation / Operational Notes
 - Beta channel first: per `CLAUDE.md`, experimental changes go to `mvanhorn/last30days-skill-private` on the `/last30days-beta` command. Land this on the private repo first, shake out on real topics for a day or two, then cherry-pick to public.
 - After land-merge: run `scripts/sync.sh` to deploy SKILL.md + scripts to `~/.claude/`, `~/.agents/`, `~/.codex/`.
 - Release notes entry in CHANGELOG.md follows the v3.0.9 voice — outcome-first, one paragraph.
 ## Sources & References
 - Related code: `scripts/lib/resolve.py:179` (`auto_resolve`), `scripts/lib/pipeline.py:162` (`pipeline.run`), `scripts/lib/planner.py:80` (`plan_query` LAW 7 fallback), `scripts/lib/render.py:333` (comparison scaffold)
 - Related PRs: #305 (Step 0.55 category-peer subreddit expansion — the precedent for deterministic peer expansion, merged 2026-04-22)
 - Related plan: `docs/plans/2026-04-22-001-fix-category-peer-subreddit-resolution-plan.md`
@@ -1,352 +0,0 @@
 ---
 > **NOTE (added 2026-05-16):** This plan references `bash scripts/sync.sh`. That script was deleted in [PR #405](https://github.com/mvanhorn/last30days-skill/pull/405); the install workflow is now `npx skills add . -g -y` (symlinks the working tree across every detected harness). For context on why sync.sh went away, see [docs/solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md](../solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md). The decisions captured in this plan remain accurate; only the deploy mechanism changed.
 title: "fix: per-entity resolution, default-2, and stale-path guard for --competitors"
 type: fix
 status: active
 date: 2026-04-22
 origin: docs/plans/2026-04-22-002-feat-competitors-flag-comparison-fanout-plan.md
 ---
 # fix: per-entity resolution, default-2, and stale-path guard for --competitors
 ## Overview
 Three test runs of v3.0.11 `--competitors` surfaced four real bugs plus one product tweak. This plan fixes all of them in a single follow-up:
 1. Competitor sub-runs get no Step 0.55 resolution (no X handle, no subreddits, no GitHub repo). Drake / Kendrick / Travis ran with deterministic-fallback single-word queries while Kanye had the full targeting package. User called it "lazy" and was right.
 2. Two of three test windows (Linear, Coinbase) never invoked the new flag at all. They loaded SKILL.md from `plugins/marketplaces/last30days-skill/` (a Claude-Code-managed git clone pinned to origin/main, which predates PR #308) instead of `plugins/cache/last30days-skill/last30days/3.0.11/`, so `--help` showed no `--competitors` flag and the model fell back to the manual comparison path.
 3. Each competitor sub-run emits a scary `[Planner] No --plan passed... deterministic fallback` stderr line because LAW 7 targets the hosting-model path, not internal fan-out sub-runs.
 4. Default competitor count is 3 (→ 4-way comparison). User wants default 2 (→ 3-way: original + 2 peers). Flag keeps `--competitors=N` to customize.
 ## Problem Frame
 The 3 test runs (Kanye, Linear, Coinbase) showed a pattern:
 | Window | Loaded SKILL.md from | Invoked --competitors? | Per-entity resolution? | Outcome |
 |--------|----------------------|-----------------------|------------------------|---------|
 | Kanye  | cache/3.0.11/ (correct) | Yes | Only for main topic (Kanye) | Drake/Kendrick/Travis thin; Reddit 403 fallbacks |
 | Linear | marketplaces/ (stale) | No — fell back to manual comparison | No | Thin run with noisy subreddits |
 | Coinbase | marketplaces/ (stale) | No — fell back to manual comparison | Main only; keyword-search poisoned pool | Top subs: r/survivor, r/Airpodsmax (noise) |
 Root causes:
 - **Per-entity resolution gap:** `scripts/lib/fanout.py` calls `pipeline.run()` with topic + depth + web_backend + lookback_days only. It does not call `resolve.auto_resolve()` per entity, so sub-runs have no X handle, subreddit, or GitHub targeting. The original plan (`2026-04-22-002`) acknowledged this as a deliberate v1 simplification ("competitor sub-runs use planner defaults"). In practice this produces visibly asymmetric output and triggers downstream retrieval issues (403 fallbacks, keyword-search noise).
 - **Stale-path loading:** Claude Code's skill loader alphabetizes `find` results with `marketplaces/` before `cache/`, and the model reads the first plausible SKILL.md it sees. SKILL.md line 823's `SKILL_ROOT` resolver is the correct path but only fires in engine-invocation blocks, not in the skill-load step.
 - **LAW 7 in sub-runs:** LAW 7 exists because the *hosting reasoning model* is supposed to pass `--plan`. For competitor sub-runs, there is no hosting-model planning — it's an engine-internal fan-out. The warning is a false positive there.
 ## Requirements Trace
 - R1. Default `--competitors` count is 2 peers (3-way comparison: original + 2).
 - R2. Each competitor sub-run performs Step 0.55 resolution (X handle, subreddits, GitHub user/repos, news context) before its pipeline runs — not just the main topic.
 - R3. Sub-runs do not emit the LAW 7 `No --plan passed` warning; they are internal fan-out, not hosting-model calls.
 - R4. The rendered comparison output includes a visible "Resolved entities" block showing per-entity handles/subs/github for debug transparency (answers "did it resolve everyone?" without the user having to read stderr).
 - R5. SKILL.md has a canonical-path self-check at the top: if the reader loaded it from anywhere other than `plugins/cache/last30days-skill/last30days/{VERSION}/`, re-read from the versioned path before proceeding.
 - R6. Version bumps to 3.0.12; CHANGELOG entry; `scripts/sync.sh` deploys.
 ## Scope Boundaries
 - No new discovery strategy. The web-search + regex extraction in `scripts/lib/competitors.py` stays as-is.
 - No new CLI flags beyond the behavior changes above. Specifically: no per-entity override flags like `--competitor-handles`. The hosting-model escape hatch remains `--competitors-list`.
 - No changes to the explicit `A vs B` comparison path (topic-string parsing in `planner._comparison_entities`).
 - No marketplace-clone auto-restore fix — that's Claude Code harness behavior. This plan only guards against the symptom on the skill side.
 ### Deferred to Separate Tasks
 - Caching of per-entity resolution results: separate follow-up once hit rate justifies it.
 - Fan-out rate-limiting tuning (currently `max_workers=len(entities)+1`, capped at 6): defer until we see real-world quota exhaustion.
 - Pre-flight cost hint when N ≥ 4 (noted in `2026-04-22-002` risks): defer.
 ## Context & Research
 ### Relevant Code and Patterns
 - `scripts/last30days.py:205-219` — `--competitors` / `--competitors-list` argparse definition (const=3 today; changing to 2).
 - `scripts/last30days.py:220-290` — `resolve_competitors_args()` validator; update `COMPETITORS_DEFAULT`.
 - `scripts/last30days.py:438-520` — main() fan-out orchestration; currently passes only topic/depth to each `_competitor_runner`.
 - `scripts/lib/fanout.py:40-95` — `run_competitor_fanout()` signature. The `competitor_runner` callable is where per-entity resolution needs to happen.
 - `scripts/lib/resolve.py:179-258` — `auto_resolve()` is the exact per-entity resolver to reuse. Already does X handle + subreddits + GitHub user/repos + news context in parallel via ThreadPoolExecutor.
 - `scripts/lib/planner.py:80-135` — `plan_query()` emits the LAW 7 stderr. A `quiet: bool` keyword or `internal_subrun: bool` flag will suppress it.
 - `scripts/lib/pipeline.py:162-220` — `pipeline.run()` signature. Needs a new keyword to propagate quiet-mode down to the planner.
 - `scripts/lib/render.py:render_comparison_multi` — where the "Resolved entities" block is inserted.
 - `SKILL.md` line 823 — canonical `SKILL_ROOT` resolver already exists but fires in engine bash, not at skill-load time.
 ### Institutional Learnings
 - `docs/plans/2026-04-22-002-feat-competitors-flag-comparison-fanout-plan.md` acknowledged the per-entity-resolution gap as a v1 tradeoff. This plan closes that gap.
 - Kanye run stderr: `[Planner] No --plan passed... deterministic fallback` × 3 (once per competitor sub-run). That's the LAW 7 noise R3 targets.
 - Linear / Coinbase runs loaded `plugins/marketplaces/last30days-skill/CLAUDE.md` as the first hit. That's the stale-path issue R5 targets.
 ### External References
 - None. All patterns are in-repo.
 ## Key Technical Decisions
 - **Per-entity resolve happens inside fanout, not in SKILL.md.** The user-facing promise of `--competitors` is "one flag, engine does the work." Pushing resolution onto the hosting model creates another path-of-least-resistance trap (model skips it, output looks lazy). Auto-resolve inside each sub-run when a web backend is available makes the feature self-contained.
 - **Stale-path guard is a SKILL.md self-check, not a code change.** We cannot stop Claude Code from auto-restoring the marketplace clone. But we can put a 3-line banner at the top of SKILL.md that forces any path-mismatched read to re-read from the versioned cache. Both the marketplace copy (once main catches up) and the cache copy carry the guard.
 - **LAW 7 suppression is opt-in via `internal_subrun=True` keyword.** Do not remove the warning from the default path — it's load-bearing for the hosting-model contract. Add an explicit bypass for engine-internal fan-out only.
 - **Default 2, hard max 6 unchanged.** "Original + 2" matches the Kanye/Drake/Kendrick mental model from the feature description. Still allow `--competitors=N` from 1 to 6.
 - **Resolved block is inside the EVIDENCE envelope, not above it.** Keeps the rendered output structure stable for the synthesis contract (LAW 1–8). The block is context, not output.
 - **Skip auto-resolve when `--mock` or no web backend.** Mirrors the existing `resolve.auto_resolve()` fast-fail and keeps the mock test path deterministic.
 ## Open Questions
 ### Resolved During Planning
 - **Where does per-entity resolve live?** Inside `fanout.run_competitor_fanout`, not in `main()`. Each sub-run calls `auto_resolve()` just before `pipeline.run()`.
 - **Should the hosting model still be able to override?** Yes — `--competitors-list` remains the escape hatch. When an explicit list is passed, the engine still does auto-resolve per entity; the user's list just skips discovery.
 - **Should sub-runs run auto-resolve in parallel with each other?** Yes. The existing `ThreadPoolExecutor` in fanout already parallelizes sub-runs; auto-resolve happens inside each sub-run's thread, so resolve calls for different entities run concurrently.
 - **Default count:** 2 peers (3-way). Confirmed.
 ### Deferred to Implementation
 - Whether to expose a `--no-auto-resolve-competitors` flag for power users who want the fast, shallow behavior. Probably not needed v2; ship auto-resolve always-on and revisit if someone complains about cost.
 - Whether to surface the per-entity resolution context back into the main topic's planner (cross-entity context sharing). Stays deferred.
 - Whether the Resolved block should be collapsible or always inline. Start inline; revisit based on output length feedback.
 ## Implementation Units
 - [ ] **Unit 1: Default `--competitors` to 2 peers**
 **Goal:** Change the bare `--competitors` default from 3 to 2 per user feedback. `--competitors=N` still overrides; range 1..6 unchanged.
 **Requirements:** R1
 **Dependencies:** None
 **Files:**
 - Modify: `scripts/last30days.py` (`COMPETITORS_DEFAULT`, `--competitors` const, stderr messages if any reference 3)
 - Modify: `SKILL.md` Competitor mode section ("discovered 2-6" wording, bare-flag default line)
 - Modify: `README.md` auto-discovered example line (if it references count)
 - Test: `tests/test_cli_competitors.py`
 **Approach:**
 - Change `COMPETITORS_DEFAULT = 3` → `2` in `scripts/last30days.py`.
 - Change argparse `--competitors` `const=3` → `const=2`.
 - Update any SKILL.md / README copy referencing "3 peers" to "2 peers" (default) or "2-6 peers" (range).
 **Patterns to follow:**
 - Existing default constants in `scripts/last30days.py` argparse block.
 **Test scenarios:**
 - Happy path: bare `--competitors` yields count=2, enabled=True, empty explicit_list.
 - Edge case: `--competitors=3` still works (explicit override).
 - Edge case: existing `test_bare_flag_defaults_to_three` test is updated to `test_bare_flag_defaults_to_two` and asserts count=2.
 - Edge case: `--competitors=5` with a `--competitors-list` of length 2 still logs the mismatch warning and uses the list.
 **Verification:**
 - `pytest tests/test_cli_competitors.py -v` passes with the updated default.
 - [ ] **Unit 2: Per-entity Step 0.55 resolution inside fanout**
 **Goal:** Each competitor sub-run auto-resolves its own X handle, subreddits, GitHub user/repos, and news context via `resolve.auto_resolve()` before its `pipeline.run()` call — just like the main topic.
 **Requirements:** R2
 **Dependencies:** None (but Unit 3 should land together so sub-runs don't emit LAW 7 stderr while the resolution context is being passed)
 **Files:**
 - Modify: `scripts/lib/fanout.py`
 - Modify: `scripts/last30days.py` (`_competitor_runner` closure builds the resolved args)
 - Test: `tests/test_competitor_fanout.py`
 - Test: `tests/test_competitors_resolve_integration.py` (new; covers the auto-resolve path)
 **Approach:**
 - `_competitor_runner(entity)` in main() does:
  1. Call `resolve.auto_resolve(entity, config)` when `not args.mock` and a web backend is configured (reuse `_has_backend`).
  2. Extract resolved x_handle, subreddits, github_user, github_repos, context.
  3. Pass them to `pipeline.run()` for that sub-run.
  4. Inject resolved context into a per-entity config copy (so `_auto_resolve_context` does not leak across sub-runs — deep-copy the config or use a local dict).
  5. Store the resolved block on the Report's `artifacts` so the renderer can surface it (Unit 4).
 - When `args.mock` is True or no backend is available, skip auto-resolve (fall through to planner defaults, matching the existing `auto_resolve()` early-return contract).
 - Update `fanout.run_competitor_fanout` docstring to note that auto-resolve happens inside the caller-provided runner.
 **Execution note:** Start with a failing integration test that exercises two-entity fanout + auto-resolve via a mocked `resolve.auto_resolve` and asserts that `pipeline.run` receives the resolved x_handle/subreddits for each entity.
 **Patterns to follow:**
 - `scripts/last30days.py` main topic branch (`if args.auto_resolve and not external_plan`) already calls `resolve.auto_resolve` and propagates results — mirror the shape for competitors.
 - Config isolation: `scripts/lib/pipeline.py:162-220` reads config as-is; use `dict(config)` to avoid cross-sub-run mutation of `_auto_resolve_context`.
 **Test scenarios:**
 - Happy path: 3 entities, mocked `auto_resolve` returns distinct handles per entity; `pipeline.run` receives `x_handle=@drake` for Drake, `x_handle=@kendricklamar` for Kendrick, etc.
 - Happy path: the main topic still uses the user-supplied `--x-handle` / `--subreddits` overrides (not overwritten by auto-resolve for the main). Competitors use their own auto-resolved values.
 - Edge case: `--mock` skips auto-resolve entirely for all sub-runs (no `resolve.auto_resolve` calls).
 - Edge case: `resolve.auto_resolve` returns empty dicts for one entity (low-signal topic) — the sub-run still executes with planner defaults; doesn't crash.
 - Edge case: no web backend configured — auto-resolve returns empty for every entity, sub-runs fall through to planner defaults, no stack trace.
 - Error path: `resolve.auto_resolve` raises — the sub-run logs a warning and continues with planner defaults (does not fail the whole comparison).
 - Integration: config `_auto_resolve_context` from entity A does not leak into entity B's `pipeline.run`. Assert each sub-run gets its own context string.
 **Verification:**
 - New integration test passes.
 - End-to-end smoke (mock mode + explicit list): each sub-run's stderr shows `[AutoResolve]` lines per entity with distinct values.
 - [ ] **Unit 3: Suppress LAW 7 warning for engine-internal sub-runs**
 **Goal:** The `[Planner] No --plan passed... deterministic fallback` warning does not fire during competitor sub-runs. LAW 7 is load-bearing for hosting-model contracts and must stay on the default path; this is an opt-in bypass for internal fan-out only.
 **Requirements:** R3
 **Dependencies:** Unit 2 (so the sub-run call site is already being modified)
 **Files:**
 - Modify: `scripts/lib/planner.py` (`plan_query` signature + conditional stderr)
 - Modify: `scripts/lib/pipeline.py` (`run` signature + propagation)
 - Modify: `scripts/last30days.py` or `scripts/lib/fanout.py` (pass `internal_subrun=True` for competitor runners)
 - Test: `tests/test_planner_v3.py` (or new `tests/test_planner_quiet_mode.py`)
 - Test: `tests/test_competitor_fanout.py` (assert sub-runs don't emit LAW 7 stderr)
 **Approach:**
 - Add a keyword `internal_subrun: bool = False` to `planner.plan_query`. When True, skip the two `print(..., file=sys.stderr)` blocks that emit the LAW 7 banner and the `[Planner] No --plan passed` capability message.
 - Add the same keyword to `pipeline.run()`; pass through to `plan_query`.
 - In main()/fanout, set `internal_subrun=True` for every competitor sub-run's pipeline.run call. The main topic's pipeline.run keeps the default (LAW 7 stays on for the hosting-model path).
 - Also suppress the LAW 7-triggered degraded-run warning block in the render layer for sub-reports when the envelope is going to be merged into a comparison output (or accept that the block is per-entity and surfaces once per entity).
 **Patterns to follow:**
 - Existing keyword-only parameters on `pipeline.run` (`mock`, `x_handle`, etc.).
 - `planner.plan_query` signature is already keyword-only.
 **Test scenarios:**
 - Happy path: `plan_query(..., internal_subrun=True, provider=None, model=None)` returns the deterministic fallback plan WITHOUT writing the LAW 7 stderr block.
 - Happy path: `plan_query(...)` with default `internal_subrun=False` still writes the LAW 7 warning (unchanged behavior).
 - Integration: end-to-end competitor fanout; assert captured stderr contains zero occurrences of `No --plan passed` and zero of `YOU ARE the planner`.
 - Integration: main topic is not part of competitor mode; if the user invokes bare `/last30days OpenAI` without `--plan`, LAW 7 stderr fires exactly once (regression test).
 **Verification:**
 - Running the Kanye-style smoke test shows zero `[Planner] No --plan passed` lines for Drake / Kendrick / Travis sub-runs.
 - [ ] **Unit 4: "Resolved entities" block in comparison output**
 **Goal:** The rendered comparison output includes a visible block listing per-entity handles, subreddits, GitHub user, and resolved context. Answers "did it resolve everyone?" at a glance without reading stderr.
 **Requirements:** R4
 **Dependencies:** Unit 2 (needs resolved data on report artifacts)
 **Files:**
 - Modify: `scripts/lib/render.py` (`render_comparison_multi` and `render_comparison_multi_context`)
 - Test: `tests/test_render_comparison_multi.py`
 **Approach:**
 - When each entity's `Report.artifacts` contains a `resolved` dict (populated by Unit 2), `render_comparison_multi` emits a `## Resolved Entities` block early in the EVIDENCE envelope:
  ```
  ## Resolved Entities
  - **Kanye West**: X @kanyewest | Subs r/Kanye, r/hiphopheads | GitHub: — | Context: BULLY released, UK ban…
  - **Drake**: X @Drake | Subs r/DrakeTheType, r/hiphopheads | GitHub: — | Context: ICEMAN rollout…
  - **Kendrick Lamar**: X @kendricklamar | Subs r/KendrickLamar | GitHub: — | Context: Grammy wins, dormant…
  ```
 - Missing fields render as `—` not empty.
 - When no entity has a `resolved` payload (mock mode, no web backend), omit the block entirely rather than emit an empty section.
 - Context strings are truncated at 120 chars to keep the block scannable.
 **Patterns to follow:**
 - Existing `render_comparison_multi` envelope structure (lines ~395-480 in render.py).
 - Existing per-entity evidence block format (`## {label}`) for consistency.
 **Test scenarios:**
 - Happy path: 3 entities each with a `resolved` artifact → block lists all 3 with their fields.
 - Happy path: 2 entities, one with full resolution, one with partial (x_handle only) → missing fields render as `—`.
 - Edge case: no entity has a resolved artifact → block is omitted entirely.
 - Edge case: context string > 120 chars → truncated with ellipsis.
 - Integration: rendered output passes through the same EVIDENCE envelope comments and synthesis contract (LAW 1–8 unchanged).
 **Verification:**
 - Snapshot tests confirm the block appears in the right spot with the right formatting.
 - End-to-end smoke shows a realistic 3-entity Resolved block in the rendered output.
 - [ ] **Unit 5: SKILL.md canonical-path self-check**
 **Goal:** A top-of-file SKILL.md directive forces any reader (Claude Code, Codex, Hermes, Gemini) to verify they loaded from `plugins/cache/last30days-skill/last30days/{VERSION}/SKILL.md` before proceeding. If loaded from `marketplaces/` or any other path, re-read from the pinned versioned cache.
 **Requirements:** R5
 **Dependencies:** None
 **Files:**
 - Modify: `SKILL.md` (prepend a STEP 0 block before the existing STEP 0 / LAW list)
 **Approach:**
 - Add a numbered first step at the top (before or bundled with existing "STEP 0: ToolSearch preload"):
  ```
  ## STEP 0: Canonical Path Self-Check (must run first)
  Before reading anything else below, verify you loaded this SKILL.md from
  the versioned cache, not the marketplace clone:
      CANONICAL=$HOME/.claude/plugins/cache/last30days-skill/last30days/
      CANONICAL_LATEST=$(ls -d "$CANONICAL"*/ 2>/dev/null | sort -V | tail -1)
  If the SKILL.md you just read is not under $CANONICAL_LATEST, STOP. Re-read
  $CANONICAL_LATEST/SKILL.md and restart from here. Marketplace clones
  (`plugins/marketplaces/last30days-skill/`) are pinned to origin/main and
  can be stale; the versioned cache is the ground truth.
  ```
 - Reinforce in the existing LAW 7 block that `--help` output must be read from the same pinned `SKILL_ROOT` to avoid flag-list skew.
 **Patterns to follow:**
 - Existing STEP 0 ToolSearch preload (top of SKILL.md) for tone / imperative voice.
 - Existing `SKILL_ROOT` resolver snippet (line ~823).
 **Test scenarios:**
 - Test expectation: none — SKILL.md is documentation; no unit test, verified by follow-up user invocation.
 **Verification:**
 - In a fresh Claude Code window, `/last30days Test --competitors` loads SKILL.md, the model executes the STEP 0 self-check, and (if it had loaded from marketplaces/) switches to the cache path before running `--help` or the engine. Observable via the model's announced reasoning / task list.
 - [ ] **Unit 6: Version bump, CHANGELOG, sync**
 **Goal:** Ship 3.0.12 and deploy to all local targets.
 **Requirements:** R6
 **Dependencies:** Units 1-5
 **Files:**
 - Modify: `.claude-plugin/plugin.json` (version 3.0.11 → 3.0.12)
 - Modify: `CHANGELOG.md`
 - Run: `bash scripts/sync.sh`
 **Approach:**
 - CHANGELOG entry under `## [3.0.12]` dated 2026-04-22 covering the four fixes (Fixed: per-entity resolution; Fixed: LAW 7 sub-run noise; Changed: default count 3→2; Added: Resolved entities block; Added: canonical-path self-check in SKILL.md).
 - `sync.sh` deploys to `~/.claude/plugins/cache/last30days-skill-private/...`, `~/.agents/`, `~/.codex/`, Hermes.
 - Manual hot-copy to `~/.claude/plugins/cache/last30days-skill/last30days/3.0.12/` so the public `/last30days` slash command picks up the new version before PR merge (matches the 3.0.11 testing pattern).
 **Test scenarios:**
 - Test expectation: none — packaging only. Verification is by inspection.
 **Verification:**
 - `grep version .claude-plugin/plugin.json` returns `3.0.12`.
 - `sync.sh` exits 0 with "Import check: OK" for each target.
 - Hot-copied 3.0.12 directory contains the new files and `/last30days` picks up the new version (highest-version resolver).
 ## System-Wide Impact
 - **Interaction graph:** Fanout sub-runs now call `resolve.auto_resolve` per entity. Each sub-run is independent; no shared mutable state with other sub-runs or with the main topic.
 - **Error propagation:** `auto_resolve` failures inside a sub-run log a warning and degrade to planner defaults; do not propagate up to abort the comparison. Same contract as today for the main topic.
 - **State lifecycle risks:** Config dict is mutated by `auto_resolve` (via `config["_auto_resolve_context"]`). Must deep-copy per sub-run or scope context to a local mapping — otherwise two sub-runs' context strings race.
 - **API surface parity:** `pipeline.run` gains a keyword (`internal_subrun`); callers that don't pass it get the existing behavior. `planner.plan_query` gains the same. Backward compatible.
 - **Integration coverage:** New integration test for the fanout + auto-resolve + render chain. Existing snapshot tests update to include the Resolved block.
 - **Unchanged invariants:** Single-entity `/last30days` invocations (no `--competitors`) behave identically. Explicit `A vs B` comparison topics behave identically. LAW 7 still fires on the default hosting-model path. `render_compact` path is untouched.
 ## Risks & Dependencies
 | Risk | Mitigation |
 |------|------------|
 | Auto-resolving per competitor triples the WebSearch call volume (4 queries × 3 competitors = 12 extra web searches). | Fast-fail when no backend; user can pass `--competitors-list` to skip discovery but still get auto-resolve. Cost note in CHANGELOG. |
 | Config mutation across sub-runs via `_auto_resolve_context`. | Unit 2 deep-copies config per sub-run before each `auto_resolve` + `pipeline.run` call. Integration test asserts no cross-entity leak. |
 | LAW 7 suppression leaks onto the hosting-model path via a wrong default. | Default `internal_subrun=False`. Only fanout's competitor sub-runs set True. Unit test asserts bare-topic invocation still emits LAW 7. |
 | SKILL.md STEP 0 banner gets ignored by the model (same failure mode as line 823 today). | Put it in the guaranteed-read top band (before LAW 1, above all other content), imperative voice, concrete `STOP` verb. Still not bulletproof but strictly better than current. |
 | Default count change breaks assumptions in downstream tools or existing user muscle memory. | Changelog calls it out as Changed; `--competitors=3` still works for users who want the old default. |
 ## Documentation / Operational Notes
 - Beta channel first: merge behind `/last30days-beta` via the private repo before cherry-picking to public. Follows the same process as 3.0.11.
 - Version 3.0.12 is a fix release; no marketing post required.
 - After merge, add a line to the PR description pointing at this plan.
 ## Sources & References
 - Origin plan: `docs/plans/2026-04-22-002-feat-competitors-flag-comparison-fanout-plan.md`
 - Related PR: #308 (v3.0.11 shipping --competitors)
 - Test windows that surfaced the bugs: Kanye, Linear, Coinbase (2026-04-22 session)
 - Related code: `scripts/lib/fanout.py`, `scripts/lib/resolve.py` (`auto_resolve`), `scripts/lib/planner.py` (`plan_query`), `scripts/lib/render.py` (`render_comparison_multi`)
@@ -1,394 +0,0 @@
 ---
 title: "fix: --competitors runs a full last30days per entity with hosting-model pre-resolve"
 type: fix
 status: active
 date: 2026-04-22
 origin: docs/plans/2026-04-22-003-fix-competitors-per-entity-resolution-plan.md
 ---
 # fix: --competitors runs a full last30days per entity with hosting-model pre-resolve
 ## Overview
 User intent confirmed 2026-04-22: `--competitors` should run a full single-entity `last30days` pipeline for the main topic AND for each discovered peer — three independent full-depth passes, each with its own Step 0.55 resolution, own X handle primary weight, own subreddit targeting, own GitHub repo scoping. Then merge them into the comparison output.
 3.0.12 already built the N-parallel-pipelines orchestration (`scripts/lib/fanout.py`). What it got wrong: it tried to do per-entity Step 0.55 engine-side via `resolve.auto_resolve()`, which requires a web search backend key (BRAVE/EXA/SERPER/PARALLEL/OPENROUTER). Matt runs from Claude Code, which has its own WebSearch tool. The engine has none of those keys, so per-entity auto_resolve silently no-ops and all peer sub-runs fall through to deterministic single-word planner queries.
 Four 2026-04-22 test runs (Warriors, Seattle, Arizona Wildcats, Kanye West) confirmed this via engine receipts:
 - Compact Resolved Entities block shows peers as `X - | Subs - | GitHub - | Context: -`.
 - Sub-run planner lines show `source=deterministic, subqueries=1` — the "I gave up and keyword-searched" shape.
 - Engine footer keeps nudging `💡 You can unlock native grounded web search with BRAVE_API_KEY or SERPER_API_KEY`, which is wrong advice for a Claude Code user who already has WebSearch.
 - Kanye run leaked main topic's `--subreddits` into Drake's and Kendrick's sub-runs (regression bug).
 The fix is to flip the resolution responsibility: the hosting model (Claude Code, Codex, Hermes, Gemini) does Step 0.55 via its own WebSearch tool for every entity, then passes the resolved targeting to the engine via a new `--competitors-plan` JSON flag. Engine fan-out remains — each peer still runs a full `pipeline.run()`. The difference is the peers now arrive with full targeting, equivalent to the main topic, so retrieval is apples-to-apples.
 Why not just reuse vs-mode? vs-mode is a SINGLE `pipeline.run()` with a comparison-optimized plan. It pre-resolves Step 0.55 per entity but merges everything into one retrieval pool with lower-weight `--x-related` for peers, merged subreddits, and cross-entity keyword noise. That is not "three full passes." The user explicitly wants three full passes.
 ## Problem Frame
 3.0.12's architecture was correct; its data dependency was wrong.
 | Capability | 3.0.12 path | Target path (this plan) |
 |---|---|---|
 | Fan out to N parallel pipelines | Yes (`fanout.run_competitor_fanout`) | Same — keep |
 | Per-entity Step 0.55 resolution | Engine-internal `resolve.auto_resolve()` — needs BRAVE/EXA/SERPER/PARALLEL key | Hosting model does it via its own WebSearch, passes to engine |
 | Per-entity targeting threaded into `pipeline.run()` | Main topic only via outer flags; peers via auto_resolve (failing) or nothing | Main topic via outer flags; peers via `--competitors-plan` JSON |
 | Footer nudge | Unconditional BRAVE/SERPER | Suppressed when `--plan` or `--competitors-plan` present |
 | Resolved Entities block in raw save file | Stdout only | Also in `--save-dir` raw file |
 | Override-leak from main into peers | Present (Kanye receipt) | Fixed via explicit per-entity kwargs scrub |
 | Polymarket noise on ambiguous topics | Present (Warriors, Arizona receipts) | `--polymarket-keywords` + auto-skip for single-token-ambiguous |
 The key architectural change is who owns per-entity resolution. The engine stops trying to do it itself; the hosting model does it upstream (it already has WebSearch) and passes results in.
 This is the same pattern `--plan` already uses for the main topic: hosting model generates the plan via its own reasoning, passes it in, engine accepts. We apply the pattern to peers.
 ## Requirements Trace
 - R1. New `--competitors-plan` JSON flag accepting per-entity targeting: `x_handle`, `x_related`, `subreddits`, `github_user`, `github_repos`, `context`. Implies `--competitors`. Per-entity values thread into that entity's `pipeline.run()`. Bypasses engine-internal `auto_resolve` for covered entities.
 - R2. SKILL.md "Competitor mode" rewritten to make the hosting-model path canonical: (a) discover N peers via WebSearch, (b) run Step 0.55 per entity (main + peers) via WebSearch, (c) assemble `--competitors-plan` JSON, (d) invoke engine. Engine-internal auto_resolve remains as headless fallback.
 - R3. The LAW 7-style stderr emitted when `--competitors` has no list, no plan, no backend is reframed: leads with "hosting reasoning model, use your WebSearch to run Step 0.55 per entity and pass `--competitors-plan`." Does not lead with BRAVE_API_KEY.
 - R4. Footer nudge `💡 You can unlock native grounded web search with BRAVE_API_KEY...` is suppressed when `--plan` OR `--competitors-plan` was passed. Signal: hosting model is driving and already has WebSearch.
 - R5. Override-leak fix: competitor sub-runs do not inherit main topic's `--subreddits`, `--x-handle`, `--x-related`, `--tiktok-hashtags`, `--tiktok-creators`, `--ig-creators`, `--github-user`, `--github-repo`. Sub-runs use only their own per-entity targeting (from `--competitors-plan` if provided, else engine-internal auto_resolve if backend, else planner defaults).
 - R6. The `## Resolved Entities` block is also appended to the saved raw file when `--save-dir` is in use. Each entity's effective targeting (whatever was actually passed to its `pipeline.run()`) is visible on audit.
 - R6b. When `--save-dir` is in use with a comparison run, each entity's sub-run ALSO saves its own standalone raw file — same format as a single-entity run. `/last30days Kanye West --competitors` produces `kanye-west-raw.md`, `drake-raw.md`, `kendrick-lamar-raw.md` (one per entity) plus the merged comparison file. Matches the historical vs-mode behavior when it ran as N passes.
 - R7. Polymarket disambiguation: support `--polymarket-keywords "kw1,kw2"` to filter market matches; auto-skip Polymarket when topic is single-token-ambiguous and no override is provided.
 - R8. Default `--competitors` count remains 2 (3-way: main + 2 peers). Unchanged from 3.0.12.
 ## Scope Boundaries
 - No changes to `scripts/lib/fanout.py` architecture. N parallel pipelines stays. Only the data each sub-run receives changes.
 - No changes to the vs-mode (topic contains "vs" / "versus") behavior. That path is independent.
 - No new emit modes. Comparison output format unchanged.
 - No deprecation of `--competitors-list`. Stays as the minimum escape hatch for hosting models that skip per-entity Step 0.55 (names-only).
 ### Deferred to Separate Tasks
 - Cache layer for hosting-model competitor resolution: separate plan once cost evidence exists.
 - Cross-source disambiguation beyond Polymarket: separate plan.
 ## Context & Research
 ### Relevant Code and Patterns
 - `scripts/last30days.py` — `--competitors` / `--competitors-list` argparse block, `resolve_competitors_args` validator, `_main_runner` closure, `_competitor_runner` closure, the `[Competitors] --competitors requires...` stderr block. Primary file for this plan.
 - `scripts/lib/fanout.py` — `run_competitor_fanout` orchestrator. Signature unchanged; `_competitor_runner` closure now builds kwargs from `--competitors-plan`.
 - `scripts/lib/pipeline.py` — `pipeline.run()` signature; no changes required (all per-entity flags already exist as kwargs).
 - `scripts/lib/planner.py` — existing `--plan` parsing and validation, pattern to mirror for `--competitors-plan`.
 - `scripts/lib/render.py` `_render_resolved_entities_block` (added in 3.0.12) — already reads `report.artifacts["resolved"]`; no change needed.
 - `scripts/last30days.py` `save_output` / `render.render_full` — the save path. Needs to include the Resolved Entities block for comparison runs.
 - `scripts/lib/quality_nudge.py` — where the BRAVE/SERPER footer nudge is emitted. Needs a context-aware suppression check.
 - `scripts/lib/polymarket.py` — source adapter. Entry point for `--polymarket-keywords` filter and single-token-ambiguous auto-skip.
 ### Institutional Learnings
 - 3.0.11 plan (`2026-04-22-002`): built the initial fanout, deferred per-entity resolve as "v1 simplification."
 - 3.0.12 plan (`2026-04-22-003`): tried to close the gap via engine-internal `auto_resolve`. Works only with backend keys. Fails silently without.
 - 2026-04-22 test session receipts: confirmed all four fixes in this plan are real, reproducible bugs.
 - User's architectural steer 2026-04-22: "runs a full last30days on all 3 topics" — this plan encodes that explicitly as N full `pipeline.run()` calls with pre-resolved targeting per entity.
 ### External References
 - None. All patterns in-repo.
 ## Key Technical Decisions
 - **`--competitors-plan` is a single JSON flag, not a fan of separate flags.** Mirrors `--plan`. Stable schema: `{entity_name: {x_handle, x_related, subreddits, github_user, github_repos, context}}`. Accept inline JSON or a file path (matches `--plan`).
 - **Hosting-model-driven resolution is the documented default.** Engine-internal `auto_resolve` is the headless / cron fallback. SKILL.md routes hosting models to the JSON-flag path; engine keeps auto_resolve alive for BRAVE/EXA/SERPER users running CI.
 - **Override-leak fix is call-site scrubbing, not a signature change.** `_competitor_runner` builds an explicit kwargs dict per entity from `_subrun_kwargs(entity, plan_entry)`. No closure-default fallthrough from main scope. The 3.0.12 `entity_config = dict(config)` deep-copy pattern extends to every per-entity flag.
 - **Footer nudge becomes context-aware.** Suppressed when `--plan` or `--competitors-plan` present. Not suppressed for bare `--competitors-list` or bare invocations. Headless cron without keys still sees the nudge.
 - **Polymarket disambiguation is additive and conservative.** `--polymarket-keywords` is explicit; auto-skip only fires for a known list of single-token-ambiguous names (states, common nouns). Stderr notes the skip so it is observable and overridable.
 - **Per-entity sub-runs get the full `pipeline.run()` pass.** Same depth, same sources, same API cost per entity as a single-topic run. This is the explicit user intent — three full passes, not one merged pass.
 ## Open Questions
 ### Resolved During Planning
 - **JSON or multi-flag?** JSON. Matches `--plan`.
 - **Default count?** 2 peers (3-way comparison). Unchanged from 3.0.12.
 - **Does engine-internal auto_resolve stay alive?** Yes, for entities not covered by `--competitors-plan` when a backend is configured. Headless/cron users with keys keep the current 3.0.12 behavior.
 - **vs-mode or fanout?** Fanout. User's explicit ask: three full passes, not one merged pass. vs-mode merges into one pipeline with lower peer weighting, which is not what the user wants.
 - **Does the save file need per-entity clusters?** Start with the Resolved block appended. Per-entity cluster sections can follow in a separate task; they are nice-to-have, not blocking.
 ### Deferred to Implementation
 - Exact trace of override-leak source. Candidates: closure capture of `subreddits` in `_competitor_runner`, shared `_auto_resolve_context` leak, Reddit adapter inheriting global config. Test-first; trace at implementation time.
 - Heuristic for "single-token-ambiguous topic" auto-skip. Start with a short hard-coded list (US state names, US city names, common nouns like "Warriors", "Suns", "Jets"); revisit after dogfood.
 - Whether per-entity coverage warnings fire when `--competitors-plan` under-resolves an entity (e.g., only `x_handle`, no subreddits). Start with stderr logging; revisit UX.
 ## Implementation Units
 - [ ] **Unit 1: `--competitors-plan` JSON flag + per-entity kwargs threading**
 **Goal:** New CLI flag accepting per-entity targeting JSON. Each covered entity's `pipeline.run()` receives its own `x_handle` / `x_related` / `subreddits` / `github_user` / `github_repos` / `context`. Skips engine-internal `auto_resolve` for covered entities.
 **Requirements:** R1, R5 (primary leak fix site)
 **Dependencies:** None
 **Files:**
 - Modify: `scripts/last30days.py` (argparse + parse + `_competitor_runner`)
 - Possibly modify: `scripts/lib/fanout.py` (no signature change expected; verify)
 - Test: `tests/test_cli_competitors.py` (extend)
 - Test: `tests/test_competitors_plan_threading.py` (new)
 **Approach:**
 - Add `--competitors-plan` argparse flag. Accepts inline JSON OR a file path (mirror `--plan`).
 - Validation: parse JSON; must be a dict; each value must be a dict; unknown fields log warnings; malformed input exits 2.
 - Schema per entity: optional fields `x_handle` (str), `x_related` (list), `subreddits` (list), `github_user` (str), `github_repos` (list), `context` (str).
 - Case-insensitive matching against `--competitors-list` / discovered entities.
 - Build `_subrun_kwargs(entity, plan_entry)` helper. Returns a complete, explicit kwargs dict for `pipeline.run()` with no closure-default fallthrough from main scope. This helper is the single source of truth for per-entity call args. It also fixes the override-leak (R5) by scrubbing all per-entity flags to None unless the plan (or auto_resolve) sets them.
 - `_competitor_runner(entity)`:
  1. Look up `plan_entry` from `--competitors-plan` (if any).
  2. If plan covers entity fully, build kwargs from it; skip `auto_resolve`.
  3. If plan partially covers or is absent, fall back to `auto_resolve` (3.0.12 behavior) when a backend is configured. Plan values win over auto_resolve values on conflict.
  4. If neither plan nor backend, fall through to `pipeline.run()` with per-entity kwargs all None — engine uses planner defaults for that entity only (no leak).
 - Deep-copy config per sub-run (already done in 3.0.12); merge per-entity `context` into `entity_config["_auto_resolve_context"]` only.
 **Execution note:** Test-first for the override-leak regression (pass `--subreddits=A,B` on main + a peer, assert peer's `pipeline.run(subreddits=...)` is None or peer-specific).
 **Patterns to follow:**
 - `--plan` parsing at `scripts/last30days.py` (inline JSON or file path).
 - 3.0.12's `_competitor_runner` closure for scope; extract the kwargs-build into `_subrun_kwargs` helper.
 - `entity_config = dict(config)` deep-copy pattern from 3.0.12.
 **Test scenarios:**
 - Happy path: `--competitors-plan '{"Drake": {"x_handle":"Drake","subreddits":["Drizzy"]}}'` → Drake's `pipeline.run` receives `x_handle="Drake"` and `subreddits=["Drizzy"]`; no `auto_resolve` call for Drake.
 - Happy path: plan covers 2 of 3 entities, backend configured → covered entities skip auto_resolve; third falls back to auto_resolve.
 - Happy path: plan file path accepted like `--plan` file path.
 - Happy path: case-insensitive entity match (`Drake` in plan, `drake` in list).
 - Edge case: unknown fields in plan entry → logged, ignored, run continues.
 - Edge case: plan entry for entity not in list → ignored with warning.
 - Error path: malformed JSON → exit 2.
 - Error path: top-level JSON is list not dict → exit 2.
 - Regression (leak fix): main `--subreddits=A,B` + `--competitors-list "Drake"` + no plan → Drake's `pipeline.run` receives `subreddits=None` (no leak).
 - Regression (leak fix): same for `--x-handle`, `--x-related`, `--tiktok-*`, `--ig-creators`, `--github-*`.
 - Regression (leak fix): main `--x-handle=kanyewest` + plan `{"Drake":{"x_handle":"Drake"}}` → Drake's sub-run gets `x_handle="Drake"`, NOT `"kanyewest"`.
 - Integration: full main + 2 peers run via `--competitors-plan`; assert each sub-run's effective kwargs match expected per-entity values.
 **Verification:**
 - All new and regression tests pass.
 - Smoke run (mock mode + `--competitors-plan`): stderr shows `[Competitors] Drake: x=@Drake subs=Drizzy` line per entity; no `[AutoResolve]` calls for plan-covered entities; no leak of main topic's flags.
 - [ ] **Unit 2: Reframe LAW 7-style stderr for hosting-model context**
 **Goal:** When `--competitors` has no `--competitors-list`, no `--competitors-plan`, and no backend, stderr tells the hosting reasoning model to use its WebSearch tool for Step 0.55 per entity and pass `--competitors-plan`. Stops leading with BRAVE_API_KEY.
 **Requirements:** R3
 **Dependencies:** Unit 1 (flag must exist)
 **Files:**
 - Modify: `scripts/last30days.py` (the existing `[Competitors] --competitors requires...` block)
 - Test: `tests/test_competitors_no_backend_message.py` (new)
 **Approach:**
 - Rewrite stderr in this order:
  1. "If you are the hosting reasoning model (Claude Code, Codex, Hermes, Gemini, or any agent runtime with a WebSearch tool), YOU should: (a) discover N peers via WebSearch, (b) run Step 0.55 per entity (main + peers), (c) assemble a `--competitors-plan` JSON, (d) re-invoke. Skip this step and quality degrades — peer entities will run with planner defaults."
  2. "If you are running headless (cron, CI, no hosting model), set BRAVE_API_KEY / EXA_API_KEY / SERPER_API_KEY / PARALLEL_API_KEY / OPENROUTER_API_KEY and re-run."
  3. "Minimum escape hatch: `--competitors-list "A,B,C"` skips discovery but does not pre-resolve peers. Use only for quick tests."
 - Exits non-zero as today.
 **Patterns to follow:**
 - Existing LAW 7 stderr in `planner.plan_query` for tone.
 **Test scenarios:**
 - Happy path: stderr leads with "If you are the hosting reasoning model" and names `--competitors-plan` before any backend key.
 - Happy path: stderr explicitly names `--competitors-plan` as the preferred override.
 - Happy path: stderr does NOT say "requires either a configured web search backend OR an explicit --competitors-list" (the current 3.0.12 wording).
 **Verification:**
 - Test asserts ordering and required phrases.
 - [ ] **Unit 3: Suppress BRAVE/SERPER footer nudge when hosting-model-driven**
 **Goal:** The `💡 You can unlock native grounded web search with BRAVE_API_KEY or SERPER_API_KEY` footer is suppressed when `--plan` or `--competitors-plan` was passed (signal: hosting model is driving and already has WebSearch).
 **Requirements:** R4
 **Dependencies:** Unit 1
 **Files:**
 - Modify: `scripts/lib/quality_nudge.py` (or wherever nudge is emitted; verify during implementation)
 - Test: `tests/test_footer_nudge_suppression.py` (new)
 **Approach:**
 - Locate the nudge emission point.
 - Add a suppression check: if `--plan` OR `--competitors-plan` was passed, skip the nudge. Otherwise, current behavior.
 - Don't suppress the nudge for bare `--competitors-list` alone — that path isn't necessarily hosting-model-driven.
 **Test scenarios:**
 - Happy path: `--plan` passed, no backend → nudge does NOT fire.
 - Happy path: `--competitors-plan` passed, no backend → nudge does NOT fire.
 - Happy path: `--competitors-list` only, no backend → nudge fires (current behavior).
 - Happy path: no `--competitors`, no `--plan`, no backend → nudge fires (current behavior unchanged).
 **Verification:**
 - All four scenarios produce expected nudge presence/absence.
 - [ ] **Unit 4: Per-entity save files + Resolved block in each**
 **Goal:** When `--save-dir` is in use with a comparison run, each entity's sub-run saves its own standalone raw file (same format as a single-entity run), and each file includes the `## Resolved Entities` block so audits can see what targeting that entity received. Matches the historical vs-mode behavior when it was N passes.
 **Requirements:** R6, R6b
 **Dependencies:** Unit 1
 **Files:**
 - Modify: `scripts/last30days.py` (`save_output`, the save loop after fanout completes)
 - Possibly modify: `scripts/lib/render.py` (`render_full` branch to include Resolved block when artifact is present)
 - Test: `tests/test_save_raw_competitor_files.py` (new)
 **Approach:**
 - After fanout completes, iterate `report.artifacts["competitor_reports"]`. For each `(entity, entity_report)` tuple, call `save_output(entity_report, emit="md", save_dir=args.save_dir, suffix=args.save_suffix)` — same path a single-entity run takes.
 - Each saved file uses its entity's slug as the filename (`drake-raw.md`, `kendrick-lamar-raw.md`). Main topic keeps the existing `kanye-west-raw.md` filename.
 - Each file includes its own `## Resolved Entities` block (single-entity variant: one row for that entity only). This makes each sub-run's file self-describing — you can see what targeting was used without opening the comparison file.
 - The merged comparison output (stdout) still includes the 3-row Resolved Entities block.
 - Optional: also save a comparison summary file (e.g., `kanye-west-comparison-raw.md`) holding the merged multi-entity render. Start with per-entity files only; comparison summary is a follow-up if stdout-plus-individual-files is insufficient.
 - Single-entity runs unchanged (no additional files, no block change).
 **Patterns to follow:**
 - Existing `save_output` invocation for single-entity runs (line 501 of current `scripts/last30days.py`).
 - Existing slug generation (`slugify(topic)`) for filename consistency.
 - `_render_resolved_entities_block` from 3.0.12 for the single-entity variant.
 **Test scenarios:**
 - Happy path: `--competitors-list "Drake,Kendrick Lamar"` + `--save-dir=/tmp/x` → `/tmp/x/kanye-west-raw.md`, `/tmp/x/drake-raw.md`, `/tmp/x/kendrick-lamar-raw.md` all exist.
 - Happy path: each peer file's first sections include that entity's Resolved Entities block with its own row only.
 - Happy path: single-entity run with `--save-dir` → one file, unchanged from today's behavior.
 - Edge case: entity slug collides with existing file → overwrite (matches single-entity behavior).
 - Edge case: `--save-suffix=v3` → all 3 files get the suffix (`kanye-west-raw-v3.md`, `drake-raw-v3.md`, `kendrick-lamar-raw-v3.md`).
 - Edge case: comparison run with one peer whose sub-run failed → that entity's file is NOT saved; others are.
 - Integration: stderr after save shows three `[last30days] Saved output to <path>` lines, one per entity.
 **Verification:**
 - After `/last30days Kanye West --competitors-list "Drake,Kendrick Lamar" --save-dir=/tmp/x`: `ls /tmp/x/*-raw.md` shows 3 files. Each contains its entity's Resolved block.
 - [ ] **Unit 5: SKILL.md "Competitor mode" rewrite — hosting-model Step 0.55 canonical**
 **Goal:** SKILL.md documents the hosting-model-driven path as canonical: discover N peers via WebSearch, run Step 0.55 per entity, assemble `--competitors-plan`, invoke engine. Engine-internal `auto_resolve` is labeled the headless fallback.
 **Requirements:** R2
 **Dependencies:** Unit 1 (flag must exist before documented)
 **Files:**
 - Modify: `SKILL.md` (Competitor mode subsection)
 - Modify: `README.md` (one-line example update)
 **Approach:**
 - Replace the 3.0.12 Competitor mode subsection with a clear flow:
  1. User invokes with `--competitors` or `--competitors=N`.
  2. Hosting model runs WebSearch for "[topic] competitors" / "[topic] alternatives" → picks top N peers.
  3. Hosting model runs Step 0.55 for main + each peer (x_handle, subreddits, github_user, github_repos, context) — same protocol as vs-mode per SKILL.md §679.
  4. Hosting model assembles a `--competitors-plan` JSON object.
  5. Hosting model invokes the engine with `--competitors-list "A,B,C" --competitors-plan '{...}'`.
  6. Engine fans out N full pipelines (main + peers), each with its own full Step 0.55-grade targeting. Each entity also saves its own `*-raw.md` file when `--save-dir` is set (three full passes → three save files, matching the historical vs-mode behavior). Comparison output merges them for display.
 - Concrete JSON example in SKILL.md showing the schema.
 - Failure-mode warning: a `## Resolved Entities` block with dashes for any entity means hosting model skipped Step 0.55 for that one. Re-run with corrected plan.
 - "Headless fallback" sub-subsection: when BRAVE/EXA/SERPER/PARALLEL/OPENROUTER is set, engine's internal `auto_resolve` handles peers and `--competitors-plan` is optional.
 **Patterns to follow:**
 - SKILL.md "Step 0.55" section for per-entity resolve protocol.
 - SKILL.md "If QUERY_TYPE = COMPARISON" section for the same-protocol-as-vs-mode reference.
 - Tone of existing 3.0.12 Competitor mode prose.
 **Test scenarios:**
 - Test expectation: none — documentation. Verification is a fresh Claude Code window dogfood run.
 **Verification:**
 - `/last30days Kanye West --competitors` in a new window: hosting model does Step 0.55 for Kanye + 2 discovered peers; passes `--competitors-plan`; rendered Resolved block shows non-empty fields for all 3; top voices include at least one peer-specific handle.
 - [ ] **Unit 6: Polymarket disambiguation guard**
 **Goal:** Support `--polymarket-keywords "kw1,kw2"` to filter market matches; auto-skip Polymarket when topic is single-token-ambiguous and no override is provided.
 **Requirements:** R7
 **Dependencies:** None
 **Files:**
 - Modify: `scripts/last30days.py` argparse (`--polymarket-keywords`)
 - Modify: `scripts/lib/polymarket.py`
 - Test: `tests/test_polymarket_disambiguation.py` (new)
 **Approach:**
 - Add `--polymarket-keywords "kw1,kw2"` flag. When provided, Polymarket adapter filters market titles to those whose normalized text contains at least one keyword.
 - Auto-skip rule: if topic is one token AND token matches a known-ambiguous list (US state names, US city names, common sports/color/animal words) AND no `--polymarket-keywords` provided, skip Polymarket with a stderr note.
 - SKILL.md Step 0.55 protocol gets a small addition: for ambiguous topics, hosting model passes `--polymarket-keywords` with topic-specific qualifiers.
 **Patterns to follow:**
 - Existing Polymarket adapter match logic.
 - Single-token detection heuristic.
 **Test scenarios:**
 - Happy path: topic "Warriors", no override → Polymarket skipped; stderr notes the skip.
 - Happy path: topic "Warriors", `--polymarket-keywords "nba,gsw"` → Polymarket runs; matches filtered.
 - Happy path: topic "OpenAI" (no ambiguity) → Polymarket runs as before.
 - Happy path: topic "Arizona Wildcats" (multi-token) → Polymarket runs as before.
 - Edge case: `--polymarket-keywords ""` → treated as empty, no filter.
 **Verification:**
 - Warriors smoke run → Polymarket footer absent OR filtered to nba/gsw markets.
 - [ ] **Unit 7: Version 3.0.13, CHANGELOG, sync, hot-copy**
 **Goal:** Ship 3.0.13 to all local targets.
 **Requirements:** Closes R1-R7
 **Dependencies:** Units 1-6
 **Files:**
 - Modify: `.claude-plugin/plugin.json`
 - Modify: `CHANGELOG.md`
 - Run: `bash scripts/sync.sh`
 - Hot-copy: `~/.claude/plugins/cache/last30days-skill/last30days/3.0.13/`
 **Approach:**
 - CHANGELOG entry groups the fixes: Added `--competitors-plan` JSON flag for per-entity hosting-model pre-resolve. Fixed override-leak from main into peer sub-runs. Changed: LAW 7 stderr framing for hosting-model context. Changed: BRAVE/SERPER footer nudge suppressed when `--plan` / `--competitors-plan` is present. Added: Resolved Entities block persists to saved raw file. Added: `--polymarket-keywords` + auto-skip for ambiguous single-token topics.
 - Beta channel first per CLAUDE.md.
 - Hot-copy so public `/last30days` picks up 3.0.13 immediately.
 **Test scenarios:**
 - Test expectation: none — packaging.
 **Verification:**
 - `grep version .claude-plugin/plugin.json` returns 3.0.13.
 - `sync.sh` exits 0.
 - Hot-copy contains the new files with competitors.py, fanout.py, the updated SKILL.md, and plugin.json 3.0.13.
 ## System-Wide Impact
 - **Interaction graph:** `_competitor_runner` becomes the single source of truth for sub-run kwargs via `_subrun_kwargs(entity, plan_entry)`. Every per-entity flag flows through one helper. No closure-default leaks.
 - **Error propagation:** `--competitors-plan` JSON parse errors exit 2 with stderr (same as `--plan`). Per-entity plan entries with malformed values log warnings and fall back; don't abort the whole run.
 - **State lifecycle risks:** `entity_config = dict(config)` already deep-copies for `_auto_resolve_context`; extend the isolation discipline to every per-entity flag. Verified in Unit 1 regression tests.
 - **API surface parity:** `--competitors-plan` is additive. `--competitors` and `--competitors-list` unchanged. `--plan` unchanged. `--polymarket-keywords` additive.
 - **Integration coverage:** New regression tests for override-leak. New integration test for plan-driven sub-run threading. New nudge-suppression test. New Polymarket disambiguation test.
 - **Unchanged invariants:** `pipeline.run()` signature unchanged. `planner.plan_query` LAW 7 behavior for the default path unchanged. Single-entity render path unchanged. vs-mode behavior unchanged.
 ## Risks & Dependencies
 | Risk | Mitigation |
 |------|------------|
 | Hosting model takes the lazy path and uses `--competitors-list` names-only. | Unit 2 stderr explicitly steers to `--competitors-plan` with Step 0.55 protocol named. Unit 5 SKILL.md docs. Resolved Entities dashes in output make the gap visible. |
 | JSON gets verbose for the hosting model to construct repeatedly. | Schema is small (≤6 fields per entity). Hosting model already runs Step 0.55 for main topic in every comparison run; peers use the same protocol. One JSON block replaces N CLI flags. |
 | Override-leak source is deeper than `_competitor_runner` closure. | Test-first per Unit 1. Receipts from 2026-04-22 Kanye run are reproducible. Trace methodically from call site. |
 | Plan-covered entity bypasses auto_resolve but plan data is incomplete (e.g., no subreddits). | Hosting model's own SKILL.md contract says Step 0.55 must cover all fields. Stderr logs per-entity coverage so under-resolved entities are visible. Next-run correction, not engine-side rescue. |
 | Polymarket auto-skip false-positives on legitimate ambiguous topics with real markets. | Conservative match (single-token + known list). `--polymarket-keywords` override is explicit and unambiguous. Stderr notes the skip. |
 | Footer nudge suppression hides the message from headless users who genuinely need it. | Suppression only fires when `--plan` or `--competitors-plan` is present. Cron / CI runs that pass neither still see the nudge. |
 ## Documentation / Operational Notes
 - Beta channel first per CLAUDE.md (private repo `/last30days-beta`).
 - After merge: hot-copy to `~/.claude/plugins/cache/last30days-skill/last30days/3.0.13/`.
 - CHANGELOG voice should call this out as the feedback-driven follow-up to 3.0.12. Reader should see "we tried engine-internal resolve in 3.0.12; it needs backend keys we don't have; we moved resolution to the hosting model in 3.0.13."
 ## Sources & References
 - Origin plan (3.0.12): `docs/plans/2026-04-22-003-fix-competitors-per-entity-resolution-plan.md`
 - Earlier plan (3.0.11): `docs/plans/2026-04-22-002-feat-competitors-flag-comparison-fanout-plan.md`
 - 2026-04-22 test session receipts: Warriors, Seattle, Arizona Wildcats, Kanye West
 - SKILL.md §551 "If QUERY_TYPE = COMPARISON" and §679 per-entity Step 0.55 protocol
 - Related code: `scripts/lib/fanout.py`, `scripts/last30days.py` `_competitor_runner`, `scripts/lib/render.py` `_render_resolved_entities_block`, `scripts/lib/polymarket.py`, `scripts/lib/quality_nudge.py`
 - Related PRs: #308 (3.0.11), #309 (3.0.12)
@@ -1,454 +0,0 @@
 ---
 > **NOTE (added 2026-05-16):** This plan references `bash scripts/sync.sh`. That script was deleted in [PR #405](https://github.com/mvanhorn/last30days-skill/pull/405); the install workflow is now `npx skills add . -g -y` (symlinks the working tree across every detected harness). For context on why sync.sh went away, see [docs/solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md](../solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md). The decisions captured in this plan remain accurate; only the deploy mechanism changed.
 title: "feat: vs mode runs N full passes and --competitors is vs with auto-discovery"
 type: feat
 status: active
 date: 2026-04-22
 origin: docs/plans/2026-04-22-004-fix-competitors-hosting-model-resolve-and-leak-plan.md.superseded
 ---
 # feat: vs mode runs N full passes and --competitors is vs with auto-discovery
 ## Overview
 Architectural unification driven by user correction 2026-04-22: vs mode and `--competitors` are the same thing. A user typing `/last30days OpenAI vs Anthropic vs xAI` should get a full single-entity last30days pass for each of the three entities — three full pipelines, three saved `*-raw.md` files, merged into one comparison output. A user typing `/last30days OpenAI --competitors` should get the same output after the hosting model auto-picks 2 peers; i.e., `--competitors` is a thin shortcut that expands "topic + `--competitors`" into "topic vs peer1 vs peer2" and then runs the unified vs pipeline.
 Current state diverges from this:
 - **vs mode today**: one `pipeline.run()` with a comparison-optimized plan that merges all entities' targeting into a single retrieval pool. Lower-weight `--x-related` for peers, merged subreddits, cross-entity keyword noise. One saved file.
 - **`--competitors` today (3.0.12)**: N parallel `pipeline.run()` calls via `scripts/lib/fanout.py`, but per-entity Step 0.55 depends on an engine-side web backend key Matt doesn't have. Silently degrades to planner defaults for peers. One saved file (main topic only). Override-leak from main into peers.
 After this plan:
 - **vs mode**: N parallel `pipeline.run()` calls, one per entity, each with its own full Step 0.55-grade targeting, each saving its own `*-raw.md`. Merged into one comparison output.
 - **`--competitors`**: SKILL.md shortcut. Hosting model discovers N peers, builds `"topic vs peer1 vs peer2"`, and invokes the same vs pipeline. No separate orchestration path.
 - **Same fanout machinery (`scripts/lib/fanout.py`)** serves both. One fix, both behaviors improve.
 ## Problem Frame
 The product insight from 2026-04-22 test runs is simple: the user wants three full last30days reports plus a comparison merge. Not one comparison pass with N-way targeting merged into a single retrieval pool. Not one save file. Not "main gets Step 0.55, peers get planner defaults." Three full passes. Three save files. Merged output.
 The historical vs mode did that (it ran as 3 passes, saving 3 files). SKILL.md §551 currently says:
 > "When the user asks 'X vs Y', run ONE research pass with a comparison-optimized plan that covers both entities AND their rivalry. This replaces the old 3-pass approach (which took 13+ minutes and produced tangential content)."
 That change was a latency optimization that removed the user-visible behavior the user wants. The fix is to revert the architectural direction: N passes per entity, in parallel rather than serial (parallelism lowers wall-clock to ~1× a single pass, not N×), with per-entity save files.
 The 3.0.11 `--competitors` flag already introduced parallel N-pass machinery (`fanout.run_competitor_fanout`). The 3.0.12 follow-up tried to wire per-entity Step 0.55 into it but failed when no web backend was configured. The elegant move: stop maintaining two architectures. vs-mode and `--competitors` both use `fanout.py`. `--competitors` becomes a SKILL.md-level shortcut that discovers 2 peers and hands off to vs-mode.
 Four 2026-04-22 test receipts (Warriors, Seattle, Arizona Wildcats, Kanye West) all confirmed the user's pain points:
 - Peers thin because they ran without per-entity handle/sub targeting.
 - Only one `*-raw.md` per run — no per-entity audit.
 - Kanye peers leaked main topic's `--subreddits`.
 - Engine footer nudging `BRAVE_API_KEY` to Claude Code users who already have WebSearch.
 - Polymarket noise on ambiguous topics (Warriors → Glasgow rugby; Arizona → Diamondbacks).
 This plan closes all of them by unifying the architecture and making hosting-model-driven Step 0.55 per entity the canonical path.
 ## Requirements Trace
 - R1. vs mode (any topic containing ` vs ` / ` versus `) runs N full `pipeline.run()` calls in parallel, one per entity. Each sub-run uses its entity's own Step 0.55 targeting (from the hosting model's pre-resolution, passed via a new `--competitors-plan` JSON).
 - R2. `--competitors` (and `--competitors=N`) becomes a SKILL.md-level shortcut: the hosting model (a) discovers N peers via WebSearch, (b) runs Step 0.55 per entity (main + peers), (c) rewrites the topic to `"main vs peer1 vs peer2"`, (d) invokes the engine with `--competitors-plan` containing each entity's targeting.
 - R3. New `--competitors-plan` JSON flag. Schema: `{entity_name: {x_handle, x_related, subreddits, github_user, github_repos, context}}`. Implies vs mode when present with a single-entity topic. Applies per-entity targeting to each sub-run. Accepts inline JSON or a file path (matches `--plan`).
 - R4. Each entity's sub-run saves its own `*-raw.md` file when `--save-dir` is in use. Example: `/last30days "Kanye West vs Drake vs Kendrick Lamar" --save-dir=~/Documents/Last30Days` produces `kanye-west-raw.md`, `drake-raw.md`, `kendrick-lamar-raw.md`. Same filenames a single-entity run of each topic would produce. Matches historical vs-mode behavior.
 - R5. Each per-entity saved file includes its own single-row `## Resolved Entities` block so the audit survives. The merged comparison stdout still shows the full 3-row block.
 - R6. Override-leak fix: no main-topic flags (`--subreddits`, `--x-handle`, `--x-related`, `--tiktok-*`, `--ig-creators`, `--github-*`) leak into peer sub-runs. Every per-entity kwarg is scrubbed at the sub-run call site.
 - R7. LAW 7-style stderr for `--competitors` invocations with no list, no plan, no backend is reframed for hosting-model context: leads with "use your WebSearch to discover peers, resolve Step 0.55 per entity, re-invoke with `topic vs peer1 vs peer2 --competitors-plan '...'`." Does not lead with BRAVE_API_KEY.
 - R8. Footer nudge `💡 You can unlock native grounded web search with BRAVE_API_KEY...` is suppressed when `--plan` or `--competitors-plan` was passed.
 - R9. Polymarket disambiguation: support `--polymarket-keywords "kw1,kw2"` to filter market matches; auto-skip Polymarket when topic is single-token-ambiguous and no override is provided.
 - R10. Default `--competitors` count stays 2 peers (3-way comparison). Unchanged from 3.0.12.
 ## Scope Boundaries
 - No changes to single-entity `pipeline.run()` semantics. Each sub-run in vs mode behaves identically to a bare `/last30days {entity}` invocation.
 - No changes to the planner's comparison-intent logic for single-entity-containing topics. The `_should_force_deterministic_plan` shortcut for vs-topics routes to fanout, not to its current single-pipeline path.
 - No new emit modes. Comparison output format unchanged.
 - No removal of `--competitors-list`. Stays as a minimum escape hatch (names-only, no per-entity targeting) for scripted headless use.
 - No removal of engine-internal `resolve.auto_resolve()` in fanout. Remains as headless / cron fallback for users with BRAVE/EXA/SERPER/PARALLEL/OPENROUTER keys. The dominant Claude Code path bypasses it via `--competitors-plan`.
 ### Deferred to Separate Tasks
 - Explicit "head-to-head" rivalry pass in vs-mode (a supplemental subquery like `"A vs B"` that catches rivalry articles missing from pure entity-scoped passes). Start with N independent passes; add a head-to-head supplemental pass if the rivalry-content gap shows up in dogfood.
 - Cache layer for hosting-model pre-resolution.
 - Cross-source disambiguation (not just Polymarket).
 - Latency knob for users who want the old one-pass vs behavior (probably not needed; parallel N-pass is ~1× wall clock).
 ## Context & Research
 ### Relevant Code and Patterns
 - `scripts/last30days.py` — main(), `_main_runner`, `_competitor_runner`, the competitor enable/discovery branch. Primary file.
 - `scripts/lib/fanout.py` — existing orchestrator (3.0.11). Reused as-is; `competitor_runner` closure is where per-entity kwargs apply.
 - `scripts/lib/planner.py` — `_should_force_deterministic_plan` detects vs-topics via regex. Current path synthesizes ONE comparison plan; new path routes to fanout.
 - `scripts/lib/render.py` — `render_comparison_multi` (3.0.12) + `_render_resolved_entities_block`. Both reused. `render_full` needs a per-entity variant when saving sub-run files.
 - `scripts/last30days.py` `save_output` — where raw files are written. Needs to iterate per entity when competitor_reports artifact present.
 - `scripts/lib/quality_nudge.py` — BRAVE/SERPER nudge emission.
 - `scripts/lib/polymarket.py` — source adapter for `--polymarket-keywords` and ambiguous-topic auto-skip.
 - SKILL.md §551 "If QUERY_TYPE = COMPARISON" and §679 per-entity Step 0.55 protocol — the hosting-model contract that drives per-entity pre-resolution for both vs mode and `--competitors`.
 ### Institutional Learnings
 - 3.0.11 plan (`2026-04-22-002`): built fanout.
 - 3.0.12 plan (`2026-04-22-003`): tried engine-internal per-entity auto_resolve; failed without backend keys.
 - 3.0.13 plan draft (`2026-04-22-004-...superseded`): proposed `--competitors-plan` JSON + vs-mode-shortcut path but kept them separate. User's 2026-04-22 correction unifies them.
 - 2026-04-22 test receipts: Warriors, Seattle, Arizona Wildcats, Kanye West runs all reproduced the per-entity resolve gap.
 - User's architectural steer: "vs mode should work that way too" + "--competitors is just vs mode with auto-discovery." This plan encodes that.
 ### External References
 - None. All patterns in-repo.
 ## Key Technical Decisions
 - **Unify vs-mode and --competitors on one orchestrator.** `fanout.run_competitor_fanout` serves both. vs-mode is "topic contains ' vs '" detection → fanout. `--competitors` is "SKILL.md shortcut → hosting model rewrites topic to vs form → fanout." One code path.
 - **Per-entity targeting via `--competitors-plan` JSON.** Schema `{entity_name: {x_handle, x_related, subreddits, github_user, github_repos, context}}`. Mirrors `--plan`. Applies to both vs-mode and `--competitors` paths. Hosting model passes it after running Step 0.55 per entity.
 - **N save files, one per entity.** Each sub-run writes a `{entity-slug}-raw.md` file when `--save-dir` is set. Matches historical vs-mode behavior. Single-entity runs unchanged.
 - **Revert the "one pass for latency" optimization that removed per-entity passes.** Parallel execution via `ThreadPoolExecutor` means wall-clock is ~max(per-entity-latency), not sum. The old latency concern (13+ minutes for 3 serial passes) does not apply to a parallel fan-out.
 - **Override-leak fix at the call site.** `_subrun_kwargs(entity, plan_entry)` helper returns fully explicit per-entity kwargs; no closure-default fallthrough from main scope.
 - **LAW 7 stderr reframed, not just updated.** Current message treats BRAVE_API_KEY as the solution. New message treats hosting-model Step 0.55 as the solution, with backend keys listed only as the headless fallback.
 - **Polymarket disambiguation is additive and conservative.** `--polymarket-keywords` is explicit; auto-skip only fires for a known-ambiguous single-token list.
 ## Open Questions
 ### Resolved During Planning
 - **vs mode N passes or single-pass?** N passes. User's architectural correction.
 - **Should --competitors still be an engine flag at all?** Yes, kept for headless / cron contexts with backend keys. Dominant Claude Code path is SKILL.md shortcut → vs-mode fanout. Engine flag stays as compatibility surface.
 - **`--competitors-plan` JSON or multi-flag?** JSON. Matches `--plan`.
 - **Default count?** 2 peers → 3-way comparison. Unchanged.
 - **Saved-file naming?** `{entity-slug}-raw.md` per entity, same as single-entity runs would produce.
 ### Deferred to Implementation
 - Exact trace of override-leak path (closure capture vs shared config vs Reddit adapter fallback). Test-first per Unit 2; patch at the right layer.
 - Heuristic for single-token-ambiguous Polymarket auto-skip. Start with a short hard-coded list; iterate.
 - Whether to include a head-to-head rivalry supplemental pass in vs-mode. Ship N-independent passes first; revisit after dogfood if rivalry content is missing.
 - Exact filename convention when the comparison merged output is saved (if saved at all). Not blocking — per-entity files are the primary save artifact.
 ## High-Level Technical Design
 > *This illustrates the intended approach and is directional guidance for review, not implementation specification. The implementing agent should treat it as context, not code to reproduce.*
 ```
 User invokes:
   /last30days "OpenAI vs Anthropic vs xAI"
   OR
   /last30days OpenAI --competitors     (hosting model rewrites to vs form)
   OR
   /last30days OpenAI --competitors-list "Anthropic,xAI"
   OR
   /last30days "OpenAI vs Anthropic vs xAI" --competitors-plan '{...per-entity...}'
           ↓
 scripts/last30days.py main():
   - Detect: topic has " vs " OR --competitors enabled
   - If --competitors and no list/plan: emit LAW 7-style stderr with hosting-model instruction
   - If --competitors with list or discovery: rewrite topic to vs form, continue
   - Parse --competitors-plan JSON, map to entities
           ↓
 fanout.run_competitor_fanout (shared path):
   - For each entity (main + peers):
       - entity_config = dict(config)  [deep copy to prevent leak]
       - kwargs = _subrun_kwargs(entity, plan_entry)  [explicit; no main-topic leak]
       - If plan_entry missing a field AND backend available: auto_resolve() fill
       - pipeline.run(topic=entity, **kwargs, internal_subrun=True)
   - Parallel ThreadPoolExecutor
   - Collect per-entity Reports
   - Attach resolved targeting to each Report.artifacts["resolved"]
           ↓
 scripts/last30days.py after fanout:
   - If --save-dir: save each entity's Report as {entity-slug}-raw.md
     Each file includes its own single-row Resolved Entities block
   - emit_comparison_output → render_comparison_multi (merged stdout)
     Includes full N-row Resolved Entities block
 ```
 ## Implementation Units
 - [ ] **Unit 1: vs-topic detection routes to fanout (not single-pipeline)**
 **Goal:** A topic containing ` vs ` / ` versus ` triggers `fanout.run_competitor_fanout` with the parsed entities. Each entity runs a full `pipeline.run()`. Replace the current single-pipeline-with-comparison-plan behavior.
 **Requirements:** R1
 **Dependencies:** None
 **Files:**
 - Modify: `scripts/last30days.py` (main() — detect vs-topic, route to fanout)
 - Modify: `scripts/lib/planner.py` (remove / bypass the `_should_force_deterministic_plan` special case for vs topics; vs topics no longer go through `plan_query` as a single comparison plan)
 - Test: `tests/test_vs_mode_fanout.py` (new)
 **Approach:**
 - Parse the incoming topic: if it contains ` vs ` or ` versus ` (case-insensitive), split into entities (reuse `planner._comparison_entities`-style logic or move that utility into main()).
 - When vs-entities are detected, route to the same fanout branch `--competitors` uses today. The entity list comes from the topic string; no discovery step needed.
 - Each entity runs `pipeline.run()` with its own plan (either from `--competitors-plan[entity]` or from the engine's per-entity fallback path).
 - For back-compat, if the user passes both a vs-topic AND `--plan`, honor `--plan` for the main (first) entity and use per-entity defaults for peers unless `--competitors-plan` is also provided.
 **Execution note:** Start with an integration test that runs `"A vs B"` via mock mode and asserts fanout was called with two entities + two pipeline.run calls.
 **Patterns to follow:**
 - 3.0.11 fanout wiring in `scripts/last30days.py`'s `--competitors` branch.
 - `planner._comparison_entities` for the split logic.
 **Test scenarios:**
 - Happy path: topic `"A vs B"` → two pipeline.run calls, two Reports returned, merged render.
 - Happy path: topic `"A vs B vs C"` → three pipeline.run calls.
 - Happy path: topic `"A versus B"` → matches the same regex, two pipelines.
 - Edge case: topic `"OpenAI vs"` (trailing empty entity) → treated as single-entity `"OpenAI"`, not vs mode.
 - Edge case: topic contains "vs." (dot, no trailing space) → existing regex tolerates it; verify.
 - Edge case: topic `"A vs B"` plus `--plan` → plan applies to first entity only, peers use per-entity defaults.
 - Integration: full vs-mode run end-to-end in mock mode; verify rendered output, stderr has one `[Competitors] Comparing: A vs B vs ...` line.
 **Verification:**
 - Test assertions pass.
 - Mock-mode smoke of `/last30days "OpenAI vs Anthropic"` shows fanout invocation, per-entity Reports, merged comparison output.
 - [ ] **Unit 2: `--competitors-plan` JSON flag + `_subrun_kwargs` helper + override-leak fix**
 **Goal:** New JSON flag threads per-entity targeting into each sub-run's `pipeline.run()`. A `_subrun_kwargs(entity, plan_entry)` helper is the single source of truth for per-entity kwargs, eliminating override-leak.
 **Requirements:** R3, R6
 **Dependencies:** None (can land alongside or before Unit 1)
 **Files:**
 - Modify: `scripts/last30days.py` (argparse + parse + `_competitor_runner` + `_subrun_kwargs` helper)
 - Possibly modify: `scripts/lib/fanout.py` (no signature change expected; the competitor_runner contract is unchanged)
 - Test: `tests/test_cli_competitors.py` (extend)
 - Test: `tests/test_competitors_plan_threading.py` (new)
 - Test: `tests/test_competitor_subrun_isolation.py` (new, regression)
 **Approach:**
 - Add `--competitors-plan` argparse flag. Accepts inline JSON or file path (mirror `--plan`).
 - Validation: top-level dict; each value is a dict; unknown fields log warnings; malformed input exits 2. Case-insensitive entity matching.
 - Schema: `{entity_name: {x_handle?, x_related?, subreddits?, github_user?, github_repos?, context?}}`.
 - Build `_subrun_kwargs(entity, plan_entry)` — returns an explicit dict with every per-entity flag. No closure-default fallthrough. This is the leak fix.
 - `_competitor_runner(entity)`:
  1. Get `plan_entry` from `--competitors-plan` if present.
  2. Build base kwargs with `_subrun_kwargs(entity, plan_entry)`.
  3. Fill missing fields via `resolve.auto_resolve(entity, entity_config)` only if backend is configured (3.0.12 fallback path).
  4. Call `pipeline.run(topic=entity, internal_subrun=True, **kwargs)`.
  5. Attach `resolved` dict to `report.artifacts`.
 - Verify no per-entity flag from main() leaks via closure. The helper is the only source of per-entity values.
 **Execution note:** Test-first for the override-leak regression. Use the Kanye 2026-04-22 receipt as the failing test input (main `--subreddits=Kanye,hiphopheads` + `--competitors-list "Drake"` → assert Drake's pipeline.run receives `subreddits=None`).
 **Patterns to follow:**
 - `--plan` parsing block in `scripts/last30days.py`.
 - 3.0.12's `entity_config = dict(config)` deep-copy pattern.
 **Test scenarios:**
 - Happy path: `--competitors-plan '{"Drake":{"x_handle":"Drake","subreddits":["Drizzy"]}}'` → Drake's pipeline.run receives `x_handle="Drake"`, `subreddits=["Drizzy"]`. No auto_resolve call for Drake.
 - Happy path: plan covers 2 of 3 entities, backend configured → covered skip auto_resolve; third falls back.
 - Happy path: plan file path accepted like `--plan`.
 - Happy path: case-insensitive entity match.
 - Edge case: unknown fields → warn, ignore.
 - Edge case: plan entry for entity not in list → warn, ignore.
 - Error path: malformed JSON → exit 2.
 - Error path: top-level JSON is list → exit 2.
 - Regression (leak): main `--subreddits=A,B` + `--competitors-list "X"` + no plan → X's pipeline.run gets `subreddits=None`.
 - Regression (leak): same for `--x-handle`, `--x-related`, `--tiktok-hashtags`, `--tiktok-creators`, `--ig-creators`, `--github-user`, `--github-repo`.
 - Regression (leak): main `--x-handle=kanye` + plan `{"Drake":{"x_handle":"Drake"}}` → Drake's sub-run gets `x_handle="Drake"`, NOT `"kanye"`.
 **Verification:**
 - All regression tests pass.
 - Smoke run (mock mode + plan): stderr shows per-entity `[Competitors] {entity}: x=... subs=...` line; no leak from main topic's flags.
 - [ ] **Unit 3: Per-entity save files**
 **Goal:** When `--save-dir` is set in a vs-mode or `--competitors` run, each entity's sub-run saves its own `{entity-slug}-raw.md` file — same format as a single-entity run would produce.
 **Requirements:** R4, R5
 **Dependencies:** Unit 1, Unit 2
 **Files:**
 - Modify: `scripts/last30days.py` (`save_output` iteration after fanout)
 - Modify: `scripts/lib/render.py` (`render_full` includes single-row Resolved Entities block when that entity's `artifacts["resolved"]` is present)
 - Test: `tests/test_save_raw_per_entity.py` (new)
 **Approach:**
 - After fanout completes, iterate `report.artifacts["competitor_reports"]` (or equivalent). For each `(entity, entity_report)`:
  - Call `save_output(entity_report, emit="md", save_dir=args.save_dir, suffix=args.save_suffix)`.
  - Uses entity's `slugify(entity)` for the filename. Same pattern a single-entity run uses.
 - Each saved file invokes `render_full` (or the save-variant). `render_full` now checks for `report.artifacts["resolved"]` and prepends a single-row Resolved Entities block.
 - Stderr logs one `[last30days] Saved output to <path>` line per entity.
 - Single-entity runs unchanged (no extra files, render_full unchanged for them).
 **Patterns to follow:**
 - Existing `save_output` invocation in main() for single-entity runs.
 - `slugify(topic)` for filename.
 - 3.0.12's `_render_resolved_entities_block` (reused, single-row mode).
 **Test scenarios:**
 - Happy path: `/last30days "A vs B vs C" --save-dir=/tmp/x` → `/tmp/x/a-raw.md`, `/tmp/x/b-raw.md`, `/tmp/x/c-raw.md` exist.
 - Happy path: `--competitors-list "Drake,Kendrick" --save-dir=/tmp/x` on topic Kanye → three files: `kanye-west-raw.md`, `drake-raw.md`, `kendrick-lamar-raw.md`.
 - Happy path: each file includes a single-row Resolved Entities block for its entity.
 - Happy path: single-entity run with `--save-dir` → one file, no Resolved block (unchanged).
 - Edge case: `--save-suffix=v3` → all N files get the suffix.
 - Edge case: one entity sub-run failed → its file is NOT saved; the others are.
 - Integration: `ls {save-dir}/*-raw.md` returns N files after a vs-mode run.
 **Verification:**
 - Test assertions pass.
 - Manual vs-mode smoke saves N files.
 - [ ] **Unit 4: LAW 7-style stderr reframe + footer-nudge suppression**
 **Goal:** The `--competitors`-with-no-backend stderr tells the hosting model to do Step 0.55 per entity and pass `--competitors-plan`. The BRAVE/SERPER footer nudge is suppressed when `--plan` or `--competitors-plan` is present.
 **Requirements:** R7, R8
 **Dependencies:** Unit 2 (flag must exist)
 **Files:**
 - Modify: `scripts/last30days.py` (the `[Competitors] --competitors requires...` stderr block)
 - Modify: `scripts/lib/quality_nudge.py` (or wherever footer nudge emits; verify during implementation)
 - Test: `tests/test_competitors_no_backend_message.py` (new)
 - Test: `tests/test_footer_nudge_suppression.py` (new)
 **Approach:**
 - Rewrite stderr in this order:
  1. "If you are the hosting reasoning model (Claude Code, Codex, Hermes, Gemini, or any agent with WebSearch), the recommended path: (a) discover N peers via WebSearch, (b) run Step 0.55 for main + each peer, (c) re-invoke as `/last30days 'topic vs peer1 vs peer2' --competitors-plan '{...}'`. See SKILL.md 'Competitor mode'."
  2. "Headless / cron path: set BRAVE_API_KEY / EXA_API_KEY / SERPER_API_KEY / PARALLEL_API_KEY / OPENROUTER_API_KEY and re-run."
  3. "Minimum escape hatch: `--competitors-list 'A,B,C'` skips discovery but does not pre-resolve peers."
 - Suppress footer nudge when `external_plan` OR `competitors_plan` was passed.
 **Test scenarios:**
 - Happy path: `--competitors` with no backend, no list, no plan → stderr leads with "If you are the hosting reasoning model" and references `--competitors-plan` before naming API keys.
 - Happy path: `--plan` passed → footer nudge does NOT fire.
 - Happy path: `--competitors-plan` passed → footer nudge does NOT fire.
 - Happy path: `--competitors-list` only (no plan, no backend) → footer nudge still fires (hosting model didn't fully engage).
 - Happy path: no `--competitors`, no `--plan` → footer nudge unchanged.
 **Verification:**
 - Tests pass.
 - [ ] **Unit 5: Polymarket disambiguation guard**
 **Goal:** `--polymarket-keywords "kw1,kw2"` filters market matches; auto-skip Polymarket on single-token-ambiguous topics without override.
 **Requirements:** R9
 **Dependencies:** None
 **Files:**
 - Modify: `scripts/last30days.py` (argparse)
 - Modify: `scripts/lib/polymarket.py`
 - Test: `tests/test_polymarket_disambiguation.py` (new)
 **Approach:**
 - Add `--polymarket-keywords "kw1,kw2"`. When provided, Polymarket adapter filters market titles to those whose normalized text contains at least one keyword.
 - Auto-skip: if topic is one token AND matches a known-ambiguous list (US state names, US city names, common sports/color/animal words) AND no `--polymarket-keywords`, skip Polymarket with stderr note.
 - SKILL.md update (small): mention `--polymarket-keywords` in Step 0.55 instructions for ambiguous topics.
 **Test scenarios:**
 - Happy path: topic "Warriors", no override → Polymarket skipped; stderr note.
 - Happy path: topic "Warriors", `--polymarket-keywords "nba,gsw"` → Polymarket runs, filtered.
 - Happy path: topic "OpenAI" → Polymarket runs as before.
 - Happy path: topic "Arizona Wildcats" (multi-token) → Polymarket runs as before.
 - Edge case: `--polymarket-keywords ""` → treated as empty, no filter.
 **Verification:**
 - Warriors smoke → Polymarket footer absent or filtered.
 - [ ] **Unit 6: SKILL.md rewrite — vs mode is the canonical path, `--competitors` is a shortcut**
 **Goal:** SKILL.md documents the unified architecture. vs mode runs N full passes. `--competitors` is a SKILL.md-level shortcut that discovers 2 peers and invokes vs mode with `--competitors-plan`.
 **Requirements:** R1, R2, R10 (surfaces them)
 **Dependencies:** Units 1-4
 **Files:**
 - Modify: `SKILL.md` (§551 "If QUERY_TYPE = COMPARISON" rewrite; Competitor mode subsection rewrite)
 - Modify: `README.md` (one-line example)
 **Approach:**
 - Rewrite §551 to describe the N-pass architecture: "When the user asks 'X vs Y' (or 'X vs Y vs Z'), run Step 0.55 per entity, then invoke the engine. The engine fans out N full pipelines in parallel. Each entity gets its own single-entity-grade coverage. Wall clock is close to a single run."
 - Remove the "ONE research pass with a comparison-optimized plan that replaces the old 3-pass approach" language.
 - Add a `--competitors-plan` JSON example.
 - Rewrite the Competitor mode subsection: "`--competitors` is a shortcut. The hosting model: (1) runs WebSearch to discover N=2 peers, (2) runs Step 0.55 for main + each peer, (3) rewrites topic to `'main vs peer1 vs peer2'`, (4) invokes engine with `--competitors-plan '{...}'`. Engine flag `--competitors` and `--competitors-list` remain for headless fallback."
 - Cross-reference §679 (per-entity Step 0.55 protocol).
 - Warning: a thin `## Resolved Entities` block (dashes for any entity) means the hosting model skipped Step 0.55 for that one.
 **Patterns to follow:**
 - Existing §679 per-entity Step 0.55 protocol for tone.
 - 3.0.12 Competitor mode prose for terseness.
 **Test scenarios:**
 - Test expectation: none — documentation. Verification is dogfood.
 **Verification:**
 - `/last30days "OpenAI vs Anthropic vs xAI"` in a fresh Claude Code window produces 3 save files with populated Resolved blocks and non-dash per-entity targeting.
 - `/last30days OpenAI --competitors` produces same after discovery step.
 - [ ] **Unit 7: Version 3.0.13, CHANGELOG, sync, hot-copy**
 **Goal:** Ship 3.0.13 to all local targets.
 **Requirements:** Closes R1-R10
 **Dependencies:** Units 1-6
 **Files:**
 - Modify: `.claude-plugin/plugin.json`
 - Modify: `CHANGELOG.md`
 - Run: `bash scripts/sync.sh`
 - Hot-copy: `~/.claude/plugins/cache/last30days-skill/last30days/3.0.13/`
 **Approach:**
 - CHANGELOG: group the changes. "Changed: vs mode now runs N full passes in parallel, one per entity — reverting the one-pass optimization to restore per-entity depth. Added: --competitors-plan JSON for per-entity Step 0.55 targeting (applies to vs mode and --competitors). Changed: --competitors is now a SKILL.md shortcut for vs-with-discovery. Added: per-entity *-raw.md save files. Fixed: override-leak from main to peer sub-runs. Changed: LAW 7 stderr framing for hosting-model context. Changed: BRAVE/SERPER footer nudge suppressed when --plan / --competitors-plan present. Added: --polymarket-keywords + auto-skip for ambiguous topics."
 - Beta channel first per CLAUDE.md.
 - Hot-copy so public `/last30days` picks up 3.0.13.
 **Test scenarios:**
 - Test expectation: none — packaging.
 **Verification:**
 - `grep version .claude-plugin/plugin.json` → 3.0.13.
 - `sync.sh` exits 0.
 - Hot-copy contains the new files.
 ## System-Wide Impact
 - **Interaction graph:** vs-mode and `--competitors` share one orchestrator (`fanout.run_competitor_fanout`). `_subrun_kwargs` is the single source of per-entity kwargs. Save loop iterates per entity.
 - **Error propagation:** Per-entity sub-run failure → logged, dropped, continue (3.0.11 behavior unchanged). `--competitors-plan` JSON parse errors exit 2 (same shape as `--plan`).
 - **State lifecycle risks:** `entity_config = dict(config)` deep-copy pattern extends to every per-entity flag (Unit 2 fix). No cross-entity context leak.
 - **API surface parity:** `--competitors-plan` is additive. `--competitors`, `--competitors-list`, `--plan` unchanged. `--polymarket-keywords` additive. vs-mode keeps its topic-string surface.
 - **Integration coverage:** New vs-mode-fanout integration test. New override-leak regression test. New plan-threading test. New nudge-suppression test. New per-entity-save test. New Polymarket disambiguation test.
 - **Unchanged invariants:** `pipeline.run()` signature unchanged. Single-entity render path unchanged. LAW 7 on the default path unchanged (still fires when a single-entity run lacks `--plan`).
 ## Risks & Dependencies
 | Risk | Mitigation |
 |------|------------|
 | vs-mode N-pass latency feels slower for users who remember the one-pass shortcut. | Parallel execution keeps wall-clock ~= max(per-entity-latency), not sum. `--quick` on a vs-topic still applies to each sub-run. CHANGELOG calls out the revert + parallelism. |
 | API cost scales linearly with N (per source). | Default count 2 caps it. Hard max 6 on `--competitors`. vs-mode users opted into N entities explicitly. |
 | Rivalry content ("A vs B" articles) missed in N-independent passes. | Deferred to separate task (head-to-head supplemental pass). Start shipping and observe whether this is actually a gap. |
 | Hosting model skips `--competitors-plan` and uses `--competitors-list` only. | Unit 4 stderr reframe steers explicitly. SKILL.md Unit 6 makes the plan-path canonical. Thin Resolved block in output makes skipped-Step-0.55 visible. |
 | Override-leak fix misses a subtle closure path. | Unit 2 is test-first with the Kanye receipt as the failing input. Regression test asserts every per-entity flag is None unless plan provides it. |
 ## Documentation / Operational Notes
 - Beta channel first per CLAUDE.md.
 - After merge: hot-copy to `~/.claude/plugins/cache/last30days-skill/last30days/3.0.13/`.
 - CHANGELOG explicitly frames the vs-mode change as an architectural revert-with-parallelism, not a regression to the old serial N-pass.
 ## Sources & References
 - Superseded plan: `docs/plans/2026-04-22-004-fix-competitors-hosting-model-resolve-and-leak-plan.md.superseded`
 - Previous plan (3.0.12): `docs/plans/2026-04-22-003-fix-competitors-per-entity-resolution-plan.md`
 - Initial plan (3.0.11): `docs/plans/2026-04-22-002-feat-competitors-flag-comparison-fanout-plan.md`
 - 2026-04-22 test session receipts (Warriors, Seattle, Arizona Wildcats, Kanye West)
 - SKILL.md §551 + §679 — the per-entity Step 0.55 protocol the hosting model uses for both paths
 - Related code: `scripts/lib/fanout.py`, `scripts/last30days.py` `_competitor_runner`, `scripts/lib/planner.py` vs-topic special-case, `scripts/lib/render.py` `_render_resolved_entities_block`, `scripts/lib/polymarket.py`, `scripts/lib/quality_nudge.py`
 - Related PRs: #308 (3.0.11), #309 (3.0.12)
@@ -1,90 +0,0 @@
 ---
 > **NOTE (added 2026-05-16):** This plan references `bash scripts/sync.sh`. That script was deleted in [PR #405](https://github.com/mvanhorn/last30days-skill/pull/405); the install workflow is now `npx skills add . -g -y` (symlinks the working tree across every detected harness). For context on why sync.sh went away, see [docs/solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md](../solutions/workflow-issues/release-consistency-test-cascade-2026-05-16.md). The decisions captured in this plan remain accurate; only the deploy mechanism changed.
 title: "fix: comparison title says (/Last30Days) instead of (Last 30 Days)"
 type: fix
 status: active
 date: 2026-04-22
 ---
 # fix: comparison title says (/Last30Days) instead of (Last 30 Days)
 ## Overview
 User feedback 2026-04-22 on the 3.0.13 release runs (Kanye vs Drake, Mercer Island, Figma): the comparison title currently reads `# Kanye West vs Drake: What the Community Says (Last 30 Days)`. It should read `# Kanye West vs Drake: What the Community Says (/Last30Days)` — attributing the output to the slash command rather than describing the date range generically.
 Single-line change in SKILL.md, three occurrences. No code change.
 ## Requirements Trace
 - R1. Comparison title pattern in SKILL.md changes from `(Last 30 Days)` to `(/Last30Days)` so synthesis outputs read `... What the Community Says (/Last30Days)`.
 - R2. Both the rule statement (line 113) and the COMPARISON-exception statement (line 131) and the synthesis template example (line 1208) all use the new suffix.
 - R3. Version bumps to 3.0.14, CHANGELOG entry, sync, hot-copy. Public cache picks up the new title pattern.
 ## Scope Boundaries
 - No changes to the single-entity output title (no `(/Last30Days)` suffix there — only comparison topics carry it).
 - No changes to engine code. Pure SKILL.md content.
 - No changes to anything else surfaced in the test runs.
 ## Key Technical Decisions
 - **Replace all three occurrences of the suffix string in one pass.** They are identical strings; changing one without the others would cause synthesis-time confusion when the model reaches a different reference.
 - **Ship as 3.0.14, not 3.0.13.x.** Patch-level bump matches the small scope and keeps the release log clean.
 ## Implementation Units
 - [ ] **Unit 1: Replace `(Last 30 Days)` → `(/Last30Days)` in SKILL.md**
 **Goal:** All three SKILL.md references to the comparison title use the new suffix.
 **Requirements:** R1, R2
 **Files:**
 - Modify: `SKILL.md`
 **Approach:**
 - `replace_all` swap of `What the Community Says (Last 30 Days)` → `What the Community Says (/Last30Days)`. Three occurrences, no other strings overlap.
 **Test scenarios:**
 - Test expectation: none — pure documentation. Verification by inspection + dogfood run.
 **Verification:**
 - `grep -c "What the Community Says (/Last30Days)" SKILL.md` returns 3.
 - `grep -c "What the Community Says (Last 30 Days)" SKILL.md` returns 0.
 - [ ] **Unit 2: Version 3.0.14 + CHANGELOG + sync + hot-copy**
 **Goal:** Ship 3.0.14 to all local targets.
 **Requirements:** R3
 **Dependencies:** Unit 1
 **Files:**
 - Modify: `.claude-plugin/plugin.json`
 - Modify: `CHANGELOG.md`
 - Run: `bash scripts/sync.sh`
 - Hot-copy: `~/.claude/plugins/cache/last30days-skill/last30days/3.0.14/`
 **Approach:**
 - CHANGELOG: "Changed: comparison-mode title attribution — `What the Community Says (Last 30 Days)` → `What the Community Says (/Last30Days)`. Surfaces the slash-command identity instead of restating the date range."
 **Test scenarios:**
 - Test expectation: none — packaging.
 **Verification:**
 - `grep version .claude-plugin/plugin.json` → 3.0.14.
 - Hot-copy contains the updated SKILL.md.
 ## Risks & Dependencies
 | Risk | Mitigation |
 |------|------------|
 | Hosting model has the old title pattern memorized from a prior run and re-emits `(Last 30 Days)`. | SKILL.md is read top-to-bottom each invocation. STEP 0 canonical-path self-check (3.0.12) ensures the model loads the new SKILL.md, not the marketplace stale copy. |
 ## Sources & References
 - 2026-04-22 dogfood runs (Kanye West vs Drake, Mercer Island --competitors, Figma --competitors)
 - Related code: `SKILL.md` lines 113, 131, 1208
@@ -1,388 +0,0 @@
 ---
 name: last30days
 description: Research a topic from the last 30 days on Reddit + X + Web, become an expert, and write copy-paste-ready prompts for the user's target tool.
 argument-hint: "[topic] for [tool]" or "[topic]"
 allowed-tools: Bash, Read, Write, AskUserQuestion, WebSearch
 ---
 # last30days: Research Any Topic from the Last 30 Days
 Research ANY topic across Reddit, X, and the web. Surface what people are actually discussing, recommending, and debating right now.
 Use cases:
 - **Prompting**: "photorealistic people in Nano Banana Pro", "Midjourney prompts", "ChatGPT image generation" → learn techniques, get copy-paste prompts
 - **Recommendations**: "best Claude Code skills", "top AI tools" → get a LIST of specific things people mention
 - **News**: "what's happening with OpenAI", "latest AI announcements" → current events and updates
 - **General**: any topic you're curious about → understand what the community is saying
 ## CRITICAL: Parse User Intent
 Before doing anything, parse the user's input for:
 1. **TOPIC**: What they want to learn about (e.g., "web app mockups", "Claude Code skills", "image generation")
 2. **TARGET TOOL** (if specified): Where they'll use the prompts (e.g., "Nano Banana Pro", "ChatGPT", "Midjourney")
 3. **QUERY TYPE**: What kind of research they want:
   - **PROMPTING** - "X prompts", "prompting for X", "X best practices" → User wants to learn techniques and get copy-paste prompts
   - **RECOMMENDATIONS** - "best X", "top X", "what X should I use", "recommended X" → User wants a LIST of specific things
   - **NEWS** - "what's happening with X", "X news", "latest on X" → User wants current events/updates
   - **GENERAL** - anything else → User wants broad understanding of the topic
 Common patterns:
 - `[topic] for [tool]` → "web mockups for Nano Banana Pro" → TOOL IS SPECIFIED
 - `[topic] prompts for [tool]` → "UI design prompts for Midjourney" → TOOL IS SPECIFIED
 - Just `[topic]` → "iOS design mockups" → TOOL NOT SPECIFIED, that's OK
 - "best [topic]" or "top [topic]" → QUERY_TYPE = RECOMMENDATIONS
 - "what are the best [topic]" → QUERY_TYPE = RECOMMENDATIONS
 **IMPORTANT: Do NOT ask about target tool before research.**
 - If tool is specified in the query, use it
 - If tool is NOT specified, run research first, then ask AFTER showing results
 **Store these variables:**
 - `TOPIC = [extracted topic]`
 - `TARGET_TOOL = [extracted tool, or "unknown" if not specified]`
 - `QUERY_TYPE = [RECOMMENDATIONS | NEWS | HOW-TO | GENERAL]`
 ---
 ## Setup Check
 The skill works in three modes based on available API keys:
 1. **Full Mode** (both keys): Reddit + X + WebSearch - best results with engagement metrics
 2. **Partial Mode** (one key): Reddit-only or X-only + WebSearch
 3. **Web-Only Mode** (no keys): WebSearch only - still useful, but no engagement metrics
 **API keys are OPTIONAL.** The skill will work without them using WebSearch fallback.
 ### First-Time Setup (Optional but Recommended)
 If the user wants to add API keys for better results:
 ```bash
 mkdir -p ~/.config/last30days
 cat > ~/.config/last30days/.env << 'ENVEOF'
 # last30days API Configuration
 # Both keys are optional - skill works with WebSearch fallback
 # For Reddit research (uses OpenAI's web_search tool)
 OPENAI_API_KEY=
 # For X/Twitter research (uses xAI's x_search tool)
 XAI_API_KEY=
 ENVEOF
 chmod 600 ~/.config/last30days/.env
 echo "Config created at ~/.config/last30days/.env"
 echo "Edit to add your API keys for enhanced research."
 ```
 **DO NOT stop if no keys are configured.** Proceed with web-only mode.
 ---
 ## Research Execution
 **IMPORTANT: The script handles API key detection automatically.** Run it and check the output to determine mode.
 **Step 1: Run the research script**
 ```bash
 python3 ~/.claude/skills/last30days/scripts/last30days.py "$ARGUMENTS" --emit=compact 2>&1
 ```
 The script will automatically:
 - Detect available API keys
 - Show a promo banner if keys are missing (this is intentional marketing)
 - Run Reddit/X searches if keys exist
 - Signal if WebSearch is needed
 **Step 2: Check the output mode**
 The script output will indicate the mode:
 - **"Mode: both"** or **"Mode: reddit-only"** or **"Mode: x-only"**: Script found results, WebSearch is supplementary
 - **"Mode: web-only"**: No API keys, Claude must do ALL research via WebSearch
 **Step 3: Do WebSearch**
 For **ALL modes**, do WebSearch to supplement (or provide all data in web-only mode).
 Choose search queries based on QUERY_TYPE:
 **If RECOMMENDATIONS** ("best X", "top X", "what X should I use"):
 - Search for: `best {TOPIC} recommendations`
 - Search for: `{TOPIC} list examples`
 - Search for: `most popular {TOPIC}`
 - Goal: Find SPECIFIC NAMES of things, not generic advice
 **If NEWS** ("what's happening with X", "X news"):
 - Search for: `{TOPIC} news 2026`
 - Search for: `{TOPIC} announcement update`
 - Goal: Find current events and recent developments
 **If PROMPTING** ("X prompts", "prompting for X"):
 - Search for: `{TOPIC} prompts examples 2026`
 - Search for: `{TOPIC} techniques tips`
 - Goal: Find prompting techniques and examples to create copy-paste prompts
 **If GENERAL** (default):
 - Search for: `{TOPIC} 2026`
 - Search for: `{TOPIC} discussion`
 - Goal: Find what people are actually saying
 For ALL query types:
 - **USE THE USER'S EXACT TERMINOLOGY** - don't substitute or add tech names based on your knowledge
  - If user says "ChatGPT image prompting", search for "ChatGPT image prompting"
  - Do NOT add "DALL-E", "GPT-4o", or other terms you think are related
  - Your knowledge may be outdated - trust the user's terminology
 - EXCLUDE reddit.com, x.com, twitter.com (covered by script)
 - INCLUDE: blogs, tutorials, docs, news, GitHub repos
 - **DO NOT output "Sources:" list** - this is noise, we'll show stats at the end
 **Step 3: Wait for background script to complete**
 Use TaskOutput to get the script results before proceeding to synthesis.
 **Depth options** (passed through from user's command):
 - `--quick` → Faster, fewer sources (8-12 each)
 - (default) → Balanced (20-30 each)
 - `--deep` → Comprehensive (50-70 Reddit, 40-60 X)
 ---
 ## Judge Agent: Synthesize All Sources
 **After all searches complete, internally synthesize (don't display stats yet):**
 The Judge Agent must:
 1. Weight Reddit/X sources HIGHER (they have engagement signals: upvotes, likes)
 2. Weight WebSearch sources LOWER (no engagement data)
 3. Identify patterns that appear across ALL three sources (strongest signals)
 4. Note any contradictions between sources
 5. Extract the top 3-5 actionable insights
 **Do NOT display stats here - they come at the end, right before the invitation.**
 ---
 ## FIRST: Internalize the Research
 **CRITICAL: Ground your synthesis in the ACTUAL research content, not your pre-existing knowledge.**
 Read the research output carefully. Pay attention to:
 - **Exact product/tool names** mentioned (e.g., if research mentions "ClawdBot" or "@clawdbot", that's a DIFFERENT product than "Claude Code" - don't conflate them)
 - **Specific quotes and insights** from the sources - use THESE, not generic knowledge
 - **What the sources actually say**, not what you assume the topic is about
 **ANTI-PATTERN TO AVOID**: If user asks about "clawdbot skills" and research returns ClawdBot content (self-hosted AI agent), do NOT synthesize this as "Claude Code skills" just because both involve "skills". Read what the research actually says.
 ### If QUERY_TYPE = RECOMMENDATIONS
 **CRITICAL: Extract SPECIFIC NAMES, not generic patterns.**
 When user asks "best X" or "top X", they want a LIST of specific things:
 - Scan research for specific product names, tool names, project names, skill names, etc.
 - Count how many times each is mentioned
 - Note which sources recommend each (Reddit thread, X post, blog)
 - List them by popularity/mention count
 **BAD synthesis for "best Claude Code skills":**
 > "Skills are powerful. Keep them under 500 lines. Use progressive disclosure."
 **GOOD synthesis for "best Claude Code skills":**
 > "Most mentioned skills: /commit (5 mentions), remotion skill (4x), git-worktree (3x), /pr (3x). The Remotion announcement got 16K likes on X."
 ### For all QUERY_TYPEs
 Identify from the ACTUAL RESEARCH OUTPUT:
 - **PROMPT FORMAT** - Does research recommend JSON, structured params, natural language, keywords? THIS IS CRITICAL.
 - The top 3-5 patterns/techniques that appeared across multiple sources
 - Specific keywords, structures, or approaches mentioned BY THE SOURCES
 - Common pitfalls mentioned BY THE SOURCES
 **If research says "use JSON prompts" or "structured prompts", you MUST deliver prompts in that format later.**
 ---
 ## THEN: Show Summary + Invite Vision
 **CRITICAL: Do NOT output any "Sources:" lists. The final display should be clean.**
 **Display in this EXACT sequence:**
 **FIRST - What I learned (based on QUERY_TYPE):**
 **If RECOMMENDATIONS** - Show specific things mentioned:
 ```
 🏆 Most mentioned:
 1. [Specific name] - mentioned {n}x (r/sub, @handle, blog.com)
 2. [Specific name] - mentioned {n}x (sources)
 3. [Specific name] - mentioned {n}x (sources)
 4. [Specific name] - mentioned {n}x (sources)
 5. [Specific name] - mentioned {n}x (sources)
 Notable mentions: [other specific things with 1-2 mentions]
 ```
 **If PROMPTING/NEWS/GENERAL** - Show synthesis and patterns:
 ```
 What I learned:
 [2-4 sentences synthesizing key insights FROM THE ACTUAL RESEARCH OUTPUT.]
 KEY PATTERNS I'll use:
 1. [Pattern from research]
 2. [Pattern from research]
 3. [Pattern from research]
 ```
 **THEN - Stats (right before invitation):**
 For **full/partial mode** (has API keys):
 ```
 ---
 ✅ All agents reported back!
 ├─ 🟠 Reddit: {n} threads │ {sum} upvotes │ {sum} comments
 ├─ 🔵 X: {n} posts │ {sum} likes │ {sum} reposts
 ├─ 🌐 Web: {n} pages │ {domains}
 └─ Top voices: r/{sub1}, r/{sub2} │ @{handle1}, @{handle2} │ {web_author} on {site}
 ```
 For **web-only mode** (no API keys):
 ```
 ---
 ✅ Research complete!
 ├─ 🌐 Web: {n} pages │ {domains}
 └─ Top sources: {author1} on {site1}, {author2} on {site2}
 💡 Want engagement metrics? Add API keys to ~/.config/last30days/.env
   - OPENAI_API_KEY → Reddit (real upvotes & comments)
   - XAI_API_KEY → X/Twitter (real likes & reposts)
 ```
 **LAST - Invitation:**
 ```
 ---
 Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into {TARGET_TOOL}.
 ```
 **Use real numbers from the research output.** The patterns should be actual insights from the research, not generic advice.
 **SELF-CHECK before displaying**: Re-read your "What I learned" section. Does it match what the research ACTUALLY says? If the research was about ClawdBot (a self-hosted AI agent), your summary should be about ClawdBot, not Claude Code. If you catch yourself projecting your own knowledge instead of the research, rewrite it.
 **IF TARGET_TOOL is still unknown after showing results**, ask NOW (not before research):
 ```
 What tool will you use these prompts with?
 Options:
 1. [Most relevant tool based on research - e.g., if research mentioned Figma/Sketch, offer those]
 2. Nano Banana Pro (image generation)
 3. ChatGPT / Claude (text/code)
 4. Other (tell me)
 ```
 **IMPORTANT**: After displaying this, WAIT for the user to respond. Don't dump generic prompts.
 ---
 ## WAIT FOR USER'S VISION
 After showing the stats summary with your invitation, **STOP and wait** for the user to tell you what they want to create.
 When they respond with their vision (e.g., "I want a landing page mockup for my SaaS app"), THEN write a single, thoughtful, tailored prompt.
 ---
 ## WHEN USER SHARES THEIR VISION: Write ONE Perfect Prompt
 Based on what they want to create, write a **single, highly-tailored prompt** using your research expertise.
 ### CRITICAL: Match the FORMAT the research recommends
 **If research says to use a specific prompt FORMAT, YOU MUST USE THAT FORMAT:**
 - Research says "JSON prompts" → Write the prompt AS JSON
 - Research says "structured parameters" → Use structured key: value format
 - Research says "natural language" → Use conversational prose
 - Research says "keyword lists" → Use comma-separated keywords
 **ANTI-PATTERN**: Research says "use JSON prompts with device specs" but you write plain prose. This defeats the entire purpose of the research.
 ### Output Format:
 ```
 Here's your prompt for {TARGET_TOOL}:
 ---
 [The actual prompt IN THE FORMAT THE RESEARCH RECOMMENDS - if research said JSON, this is JSON. If research said natural language, this is prose. Match what works.]
 ---
 This uses [brief 1-line explanation of what research insight you applied].
 ```
 ### Quality Checklist:
 - [ ] **FORMAT MATCHES RESEARCH** - If research said JSON/structured/etc, prompt IS that format
 - [ ] Directly addresses what the user said they want to create
 - [ ] Uses specific patterns/keywords discovered in research
 - [ ] Ready to paste with zero edits (or minimal [PLACEHOLDERS] clearly marked)
 - [ ] Appropriate length and style for TARGET_TOOL
 ---
 ## IF USER ASKS FOR MORE OPTIONS
 Only if they ask for alternatives or more prompts, provide 2-3 variations. Don't dump a prompt pack unless requested.
 ---
 ## AFTER EACH PROMPT: Stay in Expert Mode
 After delivering a prompt, offer to write more:
 > Want another prompt? Just tell me what you're creating next.
 ---
 ## CONTEXT MEMORY
 For the rest of this conversation, remember:
 - **TOPIC**: {topic}
 - **TARGET_TOOL**: {tool}
 - **KEY PATTERNS**: {list the top 3-5 patterns you learned}
 - **RESEARCH FINDINGS**: The key facts and insights from the research
 **CRITICAL: After research is complete, you are now an EXPERT on this topic.**
 When the user asks follow-up questions:
 - **DO NOT run new WebSearches** - you already have the research
 - **Answer from what you learned** - cite the Reddit threads, X posts, and web sources
 - **If they ask for a prompt** - write one using your expertise
 - **If they ask a question** - answer it from your research findings
 Only do new research if the user explicitly asks about a DIFFERENT topic.
 ---
 ## Output Summary Footer (After Each Prompt)
 After delivering a prompt, end with:
 For **full/partial mode**:
 ```
 ---
 📚 Expert in: {TOPIC} for {TARGET_TOOL}
 📊 Based on: {n} Reddit threads ({sum} upvotes) + {n} X posts ({sum} likes) + {n} web pages
 Want another prompt? Just tell me what you're creating next.
 ```
 For **web-only mode**:
 ```
 ---
 📚 Expert in: {TOPIC} for {TARGET_TOOL}
 📊 Based on: {n} web pages from {domains}
 Want another prompt? Just tell me what you're creating next.
 💡 Unlock Reddit & X data: Add API keys to ~/.config/last30days/.env
 ```
@@ -1,310 +0,0 @@
 # V1 vs V2 Comparison Analysis
 **Date:** 2026-02-06
 **Queries tested:** 4 (1 head-to-head, 3 V1-only)
 **Scope:** Quick smoke test, not full 17-query matrix
 ---
 ## Part 1: Head-to-Head -- "kanye west" (NEWS Query)
 ### Dimension-by-Dimension Scoring
 #### 1. Query Parsing Display
 Does it show the `🔍 **{TOPIC}** · {QUERY_TYPE}` line before running tools?
 | Version | Score | Evidence |
 |---------|-------|----------|
 | V1 | 1 | No parsing display at all. Output starts with "## What I learned:" -- jumps straight into synthesis. No acknowledgment of topic or query type before research. |
 | V2 | 1 | No parsing display either. Output starts with "Here's what I found:" then "## What I learned:" -- same problem as V1. |
 **Analysis:** Neither version actually rendered the query parsing display. V2 SKILL.md explicitly requires `🔍 **kanye west** · News` before any tools run, but the agent did not produce it. This is a V2 instruction that failed to land. Both score 1/5.
 Possible cause: The parsing display is supposed to appear *before* tools are called -- it may have been shown during execution but not captured in the final output text. If so, both outputs represent only the post-research synthesis, not the full session. Regardless, based on what is in the output files, neither shows it.
 ---
 #### 2. Source Coverage (Reddit/X/Web counts)
 | Version | Score | Evidence |
 |---------|-------|----------|
 | V1 | 3 | `Reddit: 0 relevant threads` / `X: 30 posts │ ~10 likes` / `Web: 20+ pages`. Two of three sources returned results. Reddit was zero. |
 | V2 | 3 | `Reddit: 0 threads (no results this cycle)` / `X: 29 posts │ 33 likes │ 14 reposts` / `Web: 30+ pages`. Same pattern: two of three returned results. |
 **Analysis:** Nearly identical coverage. Both got zero Reddit results (likely a script/API issue for this topic, not a SKILL.md problem). V2 has slightly more precise X metrics (33 likes, 14 reposts vs. V1's vague "~10 likes"). V2 has more web pages (30+ vs 20+). Both miss the 10+ Reddit threshold for a score of 4+.
 ---
 #### 3. Citation Quality (sparse vs every-sentence)
 | Version | Score | Evidence |
 |---------|-------|----------|
 | V1 | 2 | No inline citations at all. The body text makes claims ("full-page Wall Street Journal apology," "Hellwatt Festival in Italy") but never attributes them to a specific source. The stats box lists "Washington Post, Billboard, AllHipHop" but the body has zero `per @handle` or `per Rolling Stone` attributions. |
 | V2 | 5 | Every bold section ends with a sparse, clean citation. Examples: `"per Rolling Stone"`, `"per The Washington Post"`, `"per Billboard"`, `"per AllHipHop"`, `"per The News International"`. One citation per topic, never chained. Exactly what V2 SKILL.md specifies. |
 **Analysis:** This is the single biggest quality gap between V1 and V2. V1's output reads like a Wikipedia summary -- informative but ungrounded. V2 reads like a researched briefing where every claim has a named source. V2 nails the "sparse citation" rule from its SKILL.md: `"cite 1 source per pattern, short format: 'per @handle' or 'per r/sub'"`.
 V1 quote (no citation): `"He'll headline the new Hellwatt Festival in Italy (July 4-18, 2026)."`
 V2 quote (cited): `"Ye is headlining a brand-new festival at the 103,000-capacity RCF Arena in Italy over three weekends from July 4-18, 2026 — his first-ever live concert in Italy, per Billboard."`
 ---
 #### 4. Summary Structure (bold topic headers, organized sections)
 | Version | Score | Evidence |
 |---------|-------|----------|
 | V1 | 3 | Has a coherent narrative structure with a paragraph of synthesis, then a `**KEY THEMES:**` numbered list. But the opening is a single dense paragraph, not broken into scannable sections with bold headers. |
 | V2 | 5 | Each storyline gets its own bold header: `**BULLY Album — March 20, 2026 via Gamma**`, `**Public Apology for Antisemitism**`, `**Hellwatt Festival in Italy**`, `**Health Concerns**`, `**Grammys Ban**`, `**Kim & Lewis Hamilton Buzz**`. Each is a standalone scannable unit with 1-3 sentences. |
 **Analysis:** V2 follows the SKILL.md template exactly: `**{Topic 1}** — [1-2 sentences, per source]`. V1 uses a blob + list approach which is readable but less scannable. V2 is notably better for a user who wants to skim and find the story they care about.
 V1 structure: 1 dense paragraph -> 5-item `KEY THEMES` list
 V2 structure: 6 bold topic cards, each self-contained -> no KEY THEMES list (but doesn't need one because the structure itself is the organization)
 ---
 #### 5. Stats Box Format (emoji tree vs plain text)
 | Version | Score | Evidence |
 |---------|-------|----------|
 | V1 | 4 | Uses `├─` tree format with emoji: `├─ 🟠 Reddit: 0 relevant threads` / `├─ 🔵 X: 30 posts` / `├─ 🌐 Web: 20+ pages` / `└─ Top voices:`. Minor deviation: says "0 relevant threads (filtered out noise)" instead of the V1 SKILL.md template "0 threads (no results this cycle)". Also omits the `🗣️` emoji on the Top voices line. |
 | V2 | 5 | Perfect match to V2 SKILL.md template: `├─ 🟠 Reddit: 0 threads (no results this cycle)` / `├─ 🔵 X: 29 posts │ 33 likes │ 14 reposts (via xAI)` / `├─ 🌐 Web: 30+ pages │ rollingstone.com, ...` / `└─ 🗣️ Top voices: @honest30bgfan_ (33 likes), @HipHopCrave_ │ Rolling Stone, Washington Post, Complex`. Includes `(via xAI)` notation, `🗣️` emoji, @handles with engagement counts. |
 **Analysis:** V2 is tighter and matches its template exactly. V1 is close but has minor deviations (custom "filtered out noise" text, missing `🗣️` emoji, no @handles or engagement counts on Top voices). V2's inclusion of actual @handles with like counts (`@honest30bgfan_ (33 likes)`) adds credibility.
 ---
 #### 6. Research Grounding (actual research vs generic knowledge)
 | Version | Score | Evidence |
 |---------|-------|----------|
 | V1 | 4 | Clearly grounded: mentions specific details like "Wall Street Journal apology (Jan 26, 2026)," "four-month-long manic episode," "frontal-lobe brain injury," "North West collaborated on 'Piercings on My Hand,'" "Monumental Plaza de Toros." These are specific enough to be from research, not pre-training. Minor generic leakage: the "KEY THEMES" list uses editorial framing ("Accountability arc," "Mental health transparency") that feels more like analysis than research extraction. |
 | V2 | 5 | Every fact is specific and attributed: "12th studio album," "13-track project features Peso Pluma, Playboi Carti, and Ty Dolla Sign," "earlier leak versions used AI-deepfaked vocals, which have reportedly been re-recorded," "103,000-capacity RCF Arena." The AI-deepfaked vocals detail is a standout -- it is clearly from research, not something a model would know from pre-training. The Kim/Lewis Hamilton item (`"X chatter is heavily focused on Kim Kardashian's relationship with Lewis Hamilton"`) is explicitly sourced from X data, not general knowledge. |
 **Analysis:** Both are well-grounded, but V2 has more "could only come from research" details. The deepfaked vocals story, the exact venue capacity, and the explicit X chatter observation are details that prove the synthesis is from the research output, not hallucinated.
 ---
 #### 7. Prompt Quality (invitation to share vision, not dumping prompts)
 | Version | Score | Evidence |
 |---------|-------|----------|
 | V1 | 3 | Ends with: `"Want to dive deeper into any of these threads — the apology, the new albums, the Grammys situation, or Bianca Censori? Just tell me what angle you're interested in."` This is a follow-up invitation, but it is NOT the SKILL.md-specified invitation. It is topic-specific and conversational, which is nice, but it does not ask the user to "share your vision for what you want to create." It misses the prompt-generation angle entirely. |
 | V2 | 5 | Ends with exactly: `"Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into your tool of choice."` This matches the V2 SKILL.md template verbatim. It positions the skill correctly: not a news summarizer but a research-to-prompt pipeline. |
 **Analysis:** V1's closing is friendly but off-brand. It treats the skill as a research tool, not a research-to-prompt tool. V2 correctly frames the next step as "tell me what to create and I'll write the prompt." This is a meaningful difference -- V1 would leave a user thinking they just got a summary, while V2 primes them to get a usable output.
 ---
 ### Head-to-Head Scorecard
 | Dimension | V1 | V2 | Winner |
 |-----------|----|----|--------|
 | 1. Query Parsing Display | 1 | 1 | Tie (both failed) |
 | 2. Source Coverage | 3 | 3 | Tie |
 | 3. Citation Quality | 2 | 5 | **V2 (+3)** |
 | 4. Summary Structure | 3 | 5 | **V2 (+2)** |
 | 5. Stats Box Format | 4 | 5 | **V2 (+1)** |
 | 6. Research Grounding | 4 | 5 | **V2 (+1)** |
 | 7. Prompt Quality (invitation) | 3 | 5 | **V2 (+2)** |
 | **TOTAL** | **20/35** | **29/35** | **V2 wins by 9 points** |
 **V2 is clearly better.** The biggest gaps are citation quality (+3) and summary structure (+2). V2's output reads like a professional research briefing; V1's reads like a decent but unstructured summary.
 ---
 ## Part 2: V1-Only Outputs Analysis
 ### Output 1: "open claw" (GENERAL query)
 **What V1 does well:**
 - Strong research grounding. Mentions exact numbers: "145,000+ GitHub stars," "20,000+ forks," "700+ skills," "341 malicious skills." These are clearly from research.
 - The KEY PATTERNS section is excellent: 5 well-organized patterns with community quotes (`"I give it sudo and let it configure everything"` vs `"prompt injection is terrifying when you give the bot access to your actual bank account"`).
 - Good synthesis of the security vs. enthusiasm tension -- captures the community split accurately.
 - Stats box uses the emoji tree format correctly with `├──` (though note: uses double-dash `──` instead of single `─`, minor inconsistency).
 **What V1 is missing (per V2 SKILL.md features):**
 - No query parsing display (`🔍 **open claw** · General`).
 - No inline citations in the body text. The 5 KEY PATTERNS have no `per @handle` or `per r/sub` attribution. Which Reddit thread said "I give it sudo"? Which X post raised the security concern? We do not know.
 - The stats box says `├── 🟠 Reddit: 25 threads │ ~750+ upvotes` -- the tilde and plus are imprecise. V2 SKILL.md wants exact parsed numbers.
 - Top voices line lists subreddits and handles but no engagement counts: `@grok, @Starlink` -- are these the highest-engagement handles? No like counts shown.
 - No bold topic headers in the body -- it is a single paragraph followed by a numbered list, not the `**{Topic}** — sentence, per source` format V2 requires.
 **V1 Score (estimated):** 22/35
 ---
 ### Output 2: "nano banana pro prompting" (PROMPTING query)
 **What V1 does well:**
 - Correctly identifies two prompting styles (JSON structured vs. natural language "Creative Director") and explains when each works best. This is excellent PROMPTING-type synthesis.
 - KEY PATTERNS are specific and actionable: "85mm lens at f/1.8," "three-point lighting with key at 45 degrees," "text rendering works -- keep text under 3 words for best results (75% success rate)." These are concrete tips a user can apply immediately.
 - Research grounding is strong: cites specific upvote counts ("149-259 upvotes"), subreddit names (`r/nanobanana2pro`), and the Google AI blog.
 - The invitation correctly targets Nano Banana Pro: `"Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into Nano Banana Pro."`
 **What V1 is missing (per V2 SKILL.md features):**
 - No query parsing display.
 - Stats box uses plain text dashes: `- 🟠 Reddit: 5 threads | 638 upvotes | 66 comments` instead of the tree format `├─ 🟠 Reddit:`. Uses `|` pipe instead of `│` box-drawing character. V2 SKILL.md explicitly says: "NEVER use plain text dashes (-) or pipe (|). ALWAYS use ├─ └─ │ and the emoji."
 - No inline body citations. KEY PATTERNS mention Reddit upvote ranges but no specific `per @handle` attributions.
 - Missing `✅ All agents reported back!` header -- just says "All agents reported back!" without the checkmark.
 - Body structure is paragraph + numbered list, not bold topic headers.
 **V1 Score (estimated):** 23/35 (slightly higher than open claw due to better actionability)
 ---
 ### Output 3: "how to best setup clawdbot" (HOW-TO query)
 **What V1 does well:**
 - This is the best V1 output of the batch. It goes beyond synthesis and actually delivers a **Quick-Start guide** with numbered steps, a **Security Hardening** checklist, and a **Budget Option** -- all grounded in research.
 - Excellent research grounding: `"per @shynxbt: Use a free AWS VPS + Claude Haiku model + Telegram bot = fully functional for $0"` -- this is an actual citation with an @handle!
 - Specific, actionable recommendations: exact commands (`curl -fsSL https://clawd.bot/install.sh | bash`), specific model recommendations (Claude Opus 4.5 for best results, GLM 4.7 Flash for local), specific channel advice (Telegram first, WhatsApp QR code fails).
 - Stats box is correct emoji tree format with engagement counts: `@aashatwt (452 likes), @recap_david (329 likes)`.
 - Captures the naming confusion accurately: "Clawdbot -> Moltbot -> OpenClaw."
 **What V1 is missing (per V2 SKILL.md features):**
 - No query parsing display.
 - Body text has no inline citations except the Budget Option section. The 5 KEY PATTERNS have no `per @handle` attribution.
 - Bold topic headers are used only in the Quick-Start and Security sections, not in the KEY PATTERNS or intro.
 - The output delivers the "answer" directly (setup guide) rather than waiting for the user's vision and offering to write a prompt. For a HOW-TO query this might be the right call, but it skips the SKILL.md flow of "show research -> invite vision -> write prompt."
 **V1 Score (estimated):** 26/35 (best of the V1 outputs)
 ---
 ### Patterns Across All V1 Outputs
 **Consistent strengths:**
 1. Research grounding is solid across all three. V1 does not hallucinate -- the facts are clearly from the research output, not pre-training.
 2. KEY PATTERNS lists are consistently useful and actionable.
 3. Stats boxes are present in all outputs (though formatting varies).
 4. The invitation/closing line is present in all outputs.
 **Consistent weaknesses:**
 1. **No query parsing display** in any output (0 for 4, including Kanye West).
 2. **No inline citations** in the body text (except one @handle in the clawdbot output). The research feels real but is unattributed.
 3. **Stats box formatting is inconsistent.** Open claw uses `├──` (double dash), nano banana pro uses `- 🟠` (plain dash + pipe), clawdbot uses `├─` (correct). Three different formats in three outputs.
 4. **Body structure defaults to paragraph + numbered list** instead of bold topic headers. Only clawdbot partially uses bold headers (in the guide section, not the research section).
 5. **No `(via Bird/xAI)` notation** on X stats in any output.
 ---
 ## Part 3: SKILL.md Feature Diff
 ### Features in V2 but NOT V1
 | Feature | V2 Lines | Impact |
 |---------|----------|--------|
 | **Query parsing display** (`🔍 **{TOPIC}** · {QUERY_TYPE}`) | 40-53 | HIGH -- confirms to user the skill understood their request before spending time on research. |
 | **Sparse citation rules** with BAD/GOOD examples | 186-193 | HIGH -- this is the #1 quality differentiator in the Kanye head-to-head. `"per @handle"` format, never chain multiple citations. |
 | **Bold topic headers** template (`**{Topic 1}** — [1-2 sentences, per source]`) | 195-208 | HIGH -- makes output scannable. |
 | **Strict stats template** with "NEVER use plain text dashes" instruction | 217-230 | MEDIUM -- prevents the formatting inconsistency seen across V1 outputs. |
 | **RECOMMENDATIONS source attribution** (each item MUST have Sources: line with @handles) | 178-182 | MEDIUM -- only affects RECOMMENDATIONS queries. |
 | **Reddit 0 results handling** (explicit instruction for what to write) | 229 | LOW -- edge case, but prevents ad-hoc text like V1's "filtered out noise." |
 | **Bird CLI / xAI notation** in stats | 223 | LOW -- cosmetic transparency about data source. |
 | **Step 2 phrasing: "DO WEBSEARCH WHILE SCRIPT RUNS"** | 71-73 | LOW -- execution optimization, no output impact. |
 ### Features in V1 but NOT V2
 | Feature | V1 Lines | Impact | Should Restore? |
 |---------|----------|--------|-----------------|
 | **Use cases block** (4 examples in intro) | 12-17 | LOW | No |
 | **Setup Check section** (3 modes, bash script, "keys are OPTIONAL") | 50-78 | MEDIUM for new users | Yes, for public release |
 | **BAD/GOOD synthesis anti-pattern examples** | 172-191 | MEDIUM-HIGH | YES |
 | **Self-check instruction** ("Re-read your 'What I learned' section...") | 269 | MEDIUM | YES |
 | **Quality Checklist** (5-point checklist before delivering prompt) | 306-324 | HIGH | YES |
 | **Prompt format anti-pattern** ("Research says JSON but you write prose") | 302 | MEDIUM | YES |
 | **"IF USER ASKS FOR MORE OPTIONS"** section | 327-329 | LOW-MEDIUM | YES |
 | **Web-only mode stats template + promo** | 248-259 | MEDIUM for no-key users | For public release |
 | **TARGET_TOOL question template** (4 options) | 272-280 | LOW | No |
 | **Context Memory: explicit "don't re-search" instructions** | 342-358 | MEDIUM | YES |
 | **Output footer emoji + engagement counts** | 366-380 | LOW | YES |
 ### Features in BOTH (Shared)
 | Feature | Notes |
 |---------|-------|
 | Parse User Intent (TOPIC, TARGET_TOOL, QUERY_TYPE) | Same 4 query types, same detection logic |
 | "Don't ask about tool before research" rule | Identical |
 | Research script execution command | Same `python3` command |
 | WebSearch queries by QUERY_TYPE | Same search strategies |
 | "Use user's exact terminology" instruction | V2 shorter but same intent |
 | Judge Agent synthesis logic | Same 5-step weighting process |
 | "Ground in actual research" instruction | Same core instruction, V1 has more examples |
 | RECOMMENDATIONS: extract specific names | Same logic |
 | Prompt format matching | Same instruction |
 | Wait for user's vision | Same |
 | Write ONE perfect prompt | Same structure |
 | Context Memory | V2 shorter version |
 | Output summary footer | Both have it, V1 has emoji |
 | Depth options (quick/default/deep) | Same |
 | "After each prompt: Stay in Expert Mode" | Same |
 ### Overall Assessment
 **V2 is a clear upgrade in output formatting and citation quality.** The three features V2 adds (query parsing display, sparse citation rules, bold topic headers) directly address the three biggest weaknesses seen across all V1 outputs. The Kanye West head-to-head proves it: V2 scores 29/35 vs V1's 20/35.
 **However, V2 dropped several quality guardrails from V1** that do not affect formatting but affect *correctness*: the self-check instruction, the anti-pattern examples, the quality checklist for prompts, and the "don't re-search" context memory rule. These are cheap to restore (under 25 lines total) and protect against subtle failure modes that may not show up in a 1-query test but will appear over dozens of uses.
 ---
 ## Part 4: Verdict
 ### Ship V2 or Not?
 **Ship V2 -- but restore the guardrails first.**
 V2 is unambiguously better on every formatting dimension. The citation quality improvement alone (V1: 2/5 -> V2: 5/5) makes it worth shipping. The bold topic headers and strict stats template fix the inconsistency problems visible across all V1 outputs.
 But V2 dropped 6 guardrail features from V1 that cost almost nothing to include and protect against real failure modes. These should be restored before V2 goes public.
 ### Remaining Gaps
 **Must fix before shipping (affects correctness):**
 1. **Restore the quality checklist for prompts.** This is the test plan's #1 priority item. V1 had a 5-point checklist; V2 reduced it to one line. The checklist is what makes prompts feel polished -- it is the "that's a great prompt" mechanism. Add 8 lines.
 2. **Restore BAD/GOOD anti-pattern examples.** V2 says "ground in actual research" but does not show what *bad* grounding looks like. V1's ClawdBot/Claude Code conflation example is exactly the kind of concrete negative example that prevents real failures. Add 5 lines.
 3. **Restore self-check instruction.** One sentence: "Re-read your 'What I learned' section -- does it match what the research ACTUALLY says?" Zero cost, catches hallucination. Add 2 lines.
 4. **Restore "don't re-search" context memory rule.** V2 only says "only do new research if user asks about a DIFFERENT topic." V1 explicitly bans re-searching and tells the agent to answer from existing research. Add 3 lines.
 **Should fix (polish):**
 5. Restore prompt format anti-pattern ("Research says JSON but you write prose"). Add 2 lines.
 6. Restore "IF USER ASKS FOR MORE OPTIONS" section. Add 2 lines.
 7. Add emoji + engagement counts back to the output summary footer. Edit 3 lines.
 **Skip for now:**
 8. Setup Check section -- add back for public release, not needed for execution.
 9. Web-only mode stats template -- lower priority, most testers have API keys.
 10. TARGET_TOOL question template -- agent handles this naturally.
 ### Query Parsing Display: Investigate
 Both V1 and V2 scored 1/5 on query parsing display. V2 has the feature in its SKILL.md but the agent did not render it in the captured output. This could mean:
 - The display was shown during execution but not captured (likely -- it appears before tools run, and the output files may only contain post-research content).
 - The instruction is not strong enough and the agent skips it.
 **Recommendation:** Verify in a live session whether the parsing display actually appears. If it does not, strengthen the instruction (e.g., "This line MUST be the first thing you output, before any tool calls").
 ### Total Effort
 Restoring all 7 priority items: approximately 25 lines added to V2 SKILL.md. Under 15 minutes of work. The V2 formatting wins are substantial and proven; the V1 guardrails are small and proven. Combining both produces the best version.
 ### Final Score Summary
 | | V1 (Kanye) | V2 (Kanye) | Delta |
 |--|-----------|-----------|-------|
 | Total | 20/35 | 29/35 | **V2 +9** |
 | | V1 (Open Claw) | V1 (Nano Banana) | V1 (Clawdbot) | V1 Average |
 |--|---------------|-----------------|--------------|------------|
 | Estimated Total | 22/35 | 23/35 | 26/35 | **23.7/35** |
 V2 at 29/35 beats every V1 output, including V1's best (clawdbot at 26/35).
 **Decision: Ship V2 with guardrails restored.**
@@ -1,388 +0,0 @@
 ---
 name: last30days
 description: Research a topic from the last 30 days on Reddit + X + Web, become an expert, and write copy-paste-ready prompts for the user's target tool.
 argument-hint: "[topic] for [tool]" or "[topic]"
 allowed-tools: Bash, Read, Write, AskUserQuestion, WebSearch
 ---
 # last30days: Research Any Topic from the Last 30 Days
 Research ANY topic across Reddit, X, and the web. Surface what people are actually discussing, recommending, and debating right now.
 Use cases:
 - **Prompting**: "photorealistic people in Nano Banana Pro", "Midjourney prompts", "ChatGPT image generation" → learn techniques, get copy-paste prompts
 - **Recommendations**: "best Claude Code skills", "top AI tools" → get a LIST of specific things people mention
 - **News**: "what's happening with OpenAI", "latest AI announcements" → current events and updates
 - **General**: any topic you're curious about → understand what the community is saying
 ## CRITICAL: Parse User Intent
 Before doing anything, parse the user's input for:
 1. **TOPIC**: What they want to learn about (e.g., "web app mockups", "Claude Code skills", "image generation")
 2. **TARGET TOOL** (if specified): Where they'll use the prompts (e.g., "Nano Banana Pro", "ChatGPT", "Midjourney")
 3. **QUERY TYPE**: What kind of research they want:
   - **PROMPTING** - "X prompts", "prompting for X", "X best practices" → User wants to learn techniques and get copy-paste prompts
   - **RECOMMENDATIONS** - "best X", "top X", "what X should I use", "recommended X" → User wants a LIST of specific things
   - **NEWS** - "what's happening with X", "X news", "latest on X" → User wants current events/updates
   - **GENERAL** - anything else → User wants broad understanding of the topic
 Common patterns:
 - `[topic] for [tool]` → "web mockups for Nano Banana Pro" → TOOL IS SPECIFIED
 - `[topic] prompts for [tool]` → "UI design prompts for Midjourney" → TOOL IS SPECIFIED
 - Just `[topic]` → "iOS design mockups" → TOOL NOT SPECIFIED, that's OK
 - "best [topic]" or "top [topic]" → QUERY_TYPE = RECOMMENDATIONS
 - "what are the best [topic]" → QUERY_TYPE = RECOMMENDATIONS
 **IMPORTANT: Do NOT ask about target tool before research.**
 - If tool is specified in the query, use it
 - If tool is NOT specified, run research first, then ask AFTER showing results
 **Store these variables:**
 - `TOPIC = [extracted topic]`
 - `TARGET_TOOL = [extracted tool, or "unknown" if not specified]`
 - `QUERY_TYPE = [RECOMMENDATIONS | NEWS | HOW-TO | GENERAL]`
 ---
 ## Setup Check
 The skill works in three modes based on available API keys:
 1. **Full Mode** (both keys): Reddit + X + WebSearch - best results with engagement metrics
 2. **Partial Mode** (one key): Reddit-only or X-only + WebSearch
 3. **Web-Only Mode** (no keys): WebSearch only - still useful, but no engagement metrics
 **API keys are OPTIONAL.** The skill will work without them using WebSearch fallback.
 ### First-Time Setup (Optional but Recommended)
 If the user wants to add API keys for better results:
 ```bash
 mkdir -p ~/.config/last30days
 cat > ~/.config/last30days/.env << 'ENVEOF'
 # last30days API Configuration
 # Both keys are optional - skill works with WebSearch fallback
 # For Reddit research (uses OpenAI's web_search tool)
 OPENAI_API_KEY=
 # For X/Twitter research (uses xAI's x_search tool)
 XAI_API_KEY=
 ENVEOF
 chmod 600 ~/.config/last30days/.env
 echo "Config created at ~/.config/last30days/.env"
 echo "Edit to add your API keys for enhanced research."
 ```
 **DO NOT stop if no keys are configured.** Proceed with web-only mode.
 ---
 ## Research Execution
 **IMPORTANT: The script handles API key detection automatically.** Run it and check the output to determine mode.
 **Step 1: Run the research script**
 ```bash
 python3 ~/.claude/skills/last30days/scripts/last30days.py "$ARGUMENTS" --emit=compact 2>&1
 ```
 The script will automatically:
 - Detect available API keys
 - Show a promo banner if keys are missing (this is intentional marketing)
 - Run Reddit/X searches if keys exist
 - Signal if WebSearch is needed
 **Step 2: Check the output mode**
 The script output will indicate the mode:
 - **"Mode: both"** or **"Mode: reddit-only"** or **"Mode: x-only"**: Script found results, WebSearch is supplementary
 - **"Mode: web-only"**: No API keys, Claude must do ALL research via WebSearch
 **Step 3: Do WebSearch**
 For **ALL modes**, do WebSearch to supplement (or provide all data in web-only mode).
 Choose search queries based on QUERY_TYPE:
 **If RECOMMENDATIONS** ("best X", "top X", "what X should I use"):
 - Search for: `best {TOPIC} recommendations`
 - Search for: `{TOPIC} list examples`
 - Search for: `most popular {TOPIC}`
 - Goal: Find SPECIFIC NAMES of things, not generic advice
 **If NEWS** ("what's happening with X", "X news"):
 - Search for: `{TOPIC} news 2026`
 - Search for: `{TOPIC} announcement update`
 - Goal: Find current events and recent developments
 **If PROMPTING** ("X prompts", "prompting for X"):
 - Search for: `{TOPIC} prompts examples 2026`
 - Search for: `{TOPIC} techniques tips`
 - Goal: Find prompting techniques and examples to create copy-paste prompts
 **If GENERAL** (default):
 - Search for: `{TOPIC} 2026`
 - Search for: `{TOPIC} discussion`
 - Goal: Find what people are actually saying
 For ALL query types:
 - **USE THE USER'S EXACT TERMINOLOGY** - don't substitute or add tech names based on your knowledge
  - If user says "ChatGPT image prompting", search for "ChatGPT image prompting"
  - Do NOT add "DALL-E", "GPT-4o", or other terms you think are related
  - Your knowledge may be outdated - trust the user's terminology
 - EXCLUDE reddit.com, x.com, twitter.com (covered by script)
 - INCLUDE: blogs, tutorials, docs, news, GitHub repos
 - **DO NOT output "Sources:" list** - this is noise, we'll show stats at the end
 **Step 3: Wait for background script to complete**
 Use TaskOutput to get the script results before proceeding to synthesis.
 **Depth options** (passed through from user's command):
 - `--quick` → Faster, fewer sources (8-12 each)
 - (default) → Balanced (20-30 each)
 - `--deep` → Comprehensive (50-70 Reddit, 40-60 X)
 ---
 ## Judge Agent: Synthesize All Sources
 **After all searches complete, internally synthesize (don't display stats yet):**
 The Judge Agent must:
 1. Weight Reddit/X sources HIGHER (they have engagement signals: upvotes, likes)
 2. Weight WebSearch sources LOWER (no engagement data)
 3. Identify patterns that appear across ALL three sources (strongest signals)
 4. Note any contradictions between sources
 5. Extract the top 3-5 actionable insights
 **Do NOT display stats here - they come at the end, right before the invitation.**
 ---
 ## FIRST: Internalize the Research
 **CRITICAL: Ground your synthesis in the ACTUAL research content, not your pre-existing knowledge.**
 Read the research output carefully. Pay attention to:
 - **Exact product/tool names** mentioned (e.g., if research mentions "ClawdBot" or "@clawdbot", that's a DIFFERENT product than "Claude Code" - don't conflate them)
 - **Specific quotes and insights** from the sources - use THESE, not generic knowledge
 - **What the sources actually say**, not what you assume the topic is about
 **ANTI-PATTERN TO AVOID**: If user asks about "clawdbot skills" and research returns ClawdBot content (self-hosted AI agent), do NOT synthesize this as "Claude Code skills" just because both involve "skills". Read what the research actually says.
 ### If QUERY_TYPE = RECOMMENDATIONS
 **CRITICAL: Extract SPECIFIC NAMES, not generic patterns.**
 When user asks "best X" or "top X", they want a LIST of specific things:
 - Scan research for specific product names, tool names, project names, skill names, etc.
 - Count how many times each is mentioned
 - Note which sources recommend each (Reddit thread, X post, blog)
 - List them by popularity/mention count
 **BAD synthesis for "best Claude Code skills":**
 > "Skills are powerful. Keep them under 500 lines. Use progressive disclosure."
 **GOOD synthesis for "best Claude Code skills":**
 > "Most mentioned skills: /commit (5 mentions), remotion skill (4x), git-worktree (3x), /pr (3x). The Remotion announcement got 16K likes on X."
 ### For all QUERY_TYPEs
 Identify from the ACTUAL RESEARCH OUTPUT:
 - **PROMPT FORMAT** - Does research recommend JSON, structured params, natural language, keywords? THIS IS CRITICAL.
 - The top 3-5 patterns/techniques that appeared across multiple sources
 - Specific keywords, structures, or approaches mentioned BY THE SOURCES
 - Common pitfalls mentioned BY THE SOURCES
 **If research says "use JSON prompts" or "structured prompts", you MUST deliver prompts in that format later.**
 ---
 ## THEN: Show Summary + Invite Vision
 **CRITICAL: Do NOT output any "Sources:" lists. The final display should be clean.**
 **Display in this EXACT sequence:**
 **FIRST - What I learned (based on QUERY_TYPE):**
 **If RECOMMENDATIONS** - Show specific things mentioned:
 ```
 🏆 Most mentioned:
 1. [Specific name] - mentioned {n}x (r/sub, @handle, blog.com)
 2. [Specific name] - mentioned {n}x (sources)
 3. [Specific name] - mentioned {n}x (sources)
 4. [Specific name] - mentioned {n}x (sources)
 5. [Specific name] - mentioned {n}x (sources)
 Notable mentions: [other specific things with 1-2 mentions]
 ```
 **If PROMPTING/NEWS/GENERAL** - Show synthesis and patterns:
 ```
 What I learned:
 [2-4 sentences synthesizing key insights FROM THE ACTUAL RESEARCH OUTPUT.]
 KEY PATTERNS I'll use:
 1. [Pattern from research]
 2. [Pattern from research]
 3. [Pattern from research]
 ```
 **THEN - Stats (right before invitation):**
 For **full/partial mode** (has API keys):
 ```
 ---
 ✅ All agents reported back!
 ├─ 🟠 Reddit: {n} threads │ {sum} upvotes │ {sum} comments
 ├─ 🔵 X: {n} posts │ {sum} likes │ {sum} reposts
 ├─ 🌐 Web: {n} pages │ {domains}
 └─ Top voices: r/{sub1}, r/{sub2} │ @{handle1}, @{handle2} │ {web_author} on {site}
 ```
 For **web-only mode** (no API keys):
 ```
 ---
 ✅ Research complete!
 ├─ 🌐 Web: {n} pages │ {domains}
 └─ Top sources: {author1} on {site1}, {author2} on {site2}
 💡 Want engagement metrics? Add API keys to ~/.config/last30days/.env
   - OPENAI_API_KEY → Reddit (real upvotes & comments)
   - XAI_API_KEY → X/Twitter (real likes & reposts)
 ```
 **LAST - Invitation:**
 ```
 ---
 Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into {TARGET_TOOL}.
 ```
 **Use real numbers from the research output.** The patterns should be actual insights from the research, not generic advice.
 **SELF-CHECK before displaying**: Re-read your "What I learned" section. Does it match what the research ACTUALLY says? If the research was about ClawdBot (a self-hosted AI agent), your summary should be about ClawdBot, not Claude Code. If you catch yourself projecting your own knowledge instead of the research, rewrite it.
 **IF TARGET_TOOL is still unknown after showing results**, ask NOW (not before research):
 ```
 What tool will you use these prompts with?
 Options:
 1. [Most relevant tool based on research - e.g., if research mentioned Figma/Sketch, offer those]
 2. Nano Banana Pro (image generation)
 3. ChatGPT / Claude (text/code)
 4. Other (tell me)
 ```
 **IMPORTANT**: After displaying this, WAIT for the user to respond. Don't dump generic prompts.
 ---
 ## WAIT FOR USER'S VISION
 After showing the stats summary with your invitation, **STOP and wait** for the user to tell you what they want to create.
 When they respond with their vision (e.g., "I want a landing page mockup for my SaaS app"), THEN write a single, thoughtful, tailored prompt.
 ---
 ## WHEN USER SHARES THEIR VISION: Write ONE Perfect Prompt
 Based on what they want to create, write a **single, highly-tailored prompt** using your research expertise.
 ### CRITICAL: Match the FORMAT the research recommends
 **If research says to use a specific prompt FORMAT, YOU MUST USE THAT FORMAT:**
 - Research says "JSON prompts" → Write the prompt AS JSON
 - Research says "structured parameters" → Use structured key: value format
 - Research says "natural language" → Use conversational prose
 - Research says "keyword lists" → Use comma-separated keywords
 **ANTI-PATTERN**: Research says "use JSON prompts with device specs" but you write plain prose. This defeats the entire purpose of the research.
 ### Output Format:
 ```
 Here's your prompt for {TARGET_TOOL}:
 ---
 [The actual prompt IN THE FORMAT THE RESEARCH RECOMMENDS - if research said JSON, this is JSON. If research said natural language, this is prose. Match what works.]
 ---
 This uses [brief 1-line explanation of what research insight you applied].
 ```
 ### Quality Checklist:
 - [ ] **FORMAT MATCHES RESEARCH** - If research said JSON/structured/etc, prompt IS that format
 - [ ] Directly addresses what the user said they want to create
 - [ ] Uses specific patterns/keywords discovered in research
 - [ ] Ready to paste with zero edits (or minimal [PLACEHOLDERS] clearly marked)
 - [ ] Appropriate length and style for TARGET_TOOL
 ---
 ## IF USER ASKS FOR MORE OPTIONS
 Only if they ask for alternatives or more prompts, provide 2-3 variations. Don't dump a prompt pack unless requested.
 ---
 ## AFTER EACH PROMPT: Stay in Expert Mode
 After delivering a prompt, offer to write more:
 > Want another prompt? Just tell me what you're creating next.
 ---
 ## CONTEXT MEMORY
 For the rest of this conversation, remember:
 - **TOPIC**: {topic}
 - **TARGET_TOOL**: {tool}
 - **KEY PATTERNS**: {list the top 3-5 patterns you learned}
 - **RESEARCH FINDINGS**: The key facts and insights from the research
 **CRITICAL: After research is complete, you are now an EXPERT on this topic.**
 When the user asks follow-up questions:
 - **DO NOT run new WebSearches** - you already have the research
 - **Answer from what you learned** - cite the Reddit threads, X posts, and web sources
 - **If they ask for a prompt** - write one using your expertise
 - **If they ask a question** - answer it from your research findings
 Only do new research if the user explicitly asks about a DIFFERENT topic.
 ---
 ## Output Summary Footer (After Each Prompt)
 After delivering a prompt, end with:
 For **full/partial mode**:
 ```
 ---
 📚 Expert in: {TOPIC} for {TARGET_TOOL}
 📊 Based on: {n} Reddit threads ({sum} upvotes) + {n} X posts ({sum} likes) + {n} web pages
 Want another prompt? Just tell me what you're creating next.
 ```
 For **web-only mode**:
 ```
 ---
 📚 Expert in: {TOPIC} for {TARGET_TOOL}
 📊 Based on: {n} web pages from {domains}
 Want another prompt? Just tell me what you're creating next.
 💡 Unlock Reddit & X data: Add API keys to ~/.config/last30days/.env
 ```
@@ -1,25 +0,0 @@
 ## What I learned:
 The last 30 days have been one of Kanye West's most significant periods in years. The biggest story is his **full-page Wall Street Journal apology** (Jan 26, 2026) titled "To Those I've Hurt" — a comprehensive open letter addressing his antisemitic remarks and erratic behavior. He attributed his actions to a "four-month-long manic episode" and revealed that a car accident 25 years ago caused a frontal-lobe brain injury that wasn't properly diagnosed until 2023, leading to his bipolar type-1 diagnosis. Multiple sources describe wife **Bianca Censori** as instrumental in getting him to seek treatment during a manic depressive episode.
 On the music side, he's announced **two upcoming albums**: *BULLY* (now scheduled for March 20, 2026) and *IN A PERFECT WORLD*. Daughter **North West** collaborated with him on a track called "Piercings on My Hand." He performed a massive show in Mexico City (Jan 30) at the Monumental Plaza de Toros, and he'll headline the new **Hellwatt Festival** in Italy (July 4-18, 2026).
 The **2026 Grammys** remain contentious — he's reportedly not invited after last year's red carpet drama. Health concerns also surfaced after a January LA outing where he appeared "noticeably bloated and moving with sluggish energy."
 **KEY THEMES:**
 1. **Accountability arc** — The WSJ apology is being widely discussed as either genuine growth or calculated PR
 2. **Mental health transparency** — Brain injury + bipolar diagnosis framing his past behavior
 3. **Bianca Censori's role** — Increasingly seen as a stabilizing force (despite continued provocative public appearances)
 4. **Music comeback** — Two albums announced, active touring in Latin America and Europe
 5. **Grammy exile** — Still persona non grata at major award shows
 ---
 ✅ All agents reported back!
 ├─ 🟠 Reddit: 0 relevant threads (filtered out noise)
 ├─ 🔵 X: 30 posts │ ~10 likes │ casual fan chatter + Bianca Censori discourse
 ├─ 🌐 Web: 20+ pages │ washingtonpost.com, billboard.com, allhiphop.com, euronews.com, rap-up.com
 └─ Top voices: Washington Post, Billboard, AllHipHop, Euronews, The Mirror
 ---
 Want to dive deeper into any of these threads — the apology, the new albums, the Grammys situation, or Bianca Censori? Just tell me what angle you're interested in.
@@ -1,24 +0,0 @@
 ## What I learned:
 OpenClaw (formerly ClawdBot, formerly Moltbot) is an open-source autonomous AI agent created by Peter Steinberger that went massively viral in late January 2026 — hitting 145,000+ GitHub stars and 20,000+ forks. It runs locally on your machine, connects to messaging platforms (Telegram, WhatsApp, Discord, Signal, etc.), and uses LLMs like Claude, GPT, or Gemini to actually perform tasks on your computer — file management, scheduling, web browsing, purchases, and more. Think "JARVIS for everyone."
 The community is simultaneously excited and alarmed. The "ClawHub" skill marketplace has 700+ skills but a VirusTotal/Koi Security audit found **341 malicious skills** doing data exfiltration and crypto theft. A high-severity RCE vulnerability was also disclosed. The #1 most downloaded skill on ClawHub was confirmed malware.
 **KEY PATTERNS from the research:**
 1. **Cost is the top complaint** — API usage burns money fast; many users recommend Gemini CLI (free 1,000 req/day) over Claude/GPT for OpenClaw to control spend
 2. **Security is a dumpster fire** — Supply chain attacks via ClawHub skills, prompt injection risks when browsing the web, RCE vulnerabilities, and orgs are banning it at the EDR level
 3. **Setup is nontrivial** — Even after install, most users get stuck on skills/tools/automation config; the `openclaw onboard` wizard is the recommended path
 4. **The skill ecosystem is powerful but dangerous** — 700+ skills available, but no code signing, no real moderation, and active malware campaigns
 5. **Community is split** — Enthusiasts love the autonomy ("I give it sudo and let it configure everything"), while security folks are terrified ("prompt injection is terrifying when you give the bot access to your actual bank account")
 ---
 ✅ All agents reported back!
 ├── 🟠 Reddit: 25 threads │ ~750+ upvotes │ ~600+ comments
 ├── 🔵 X: 27 posts │ 1,750+ likes │ 325+ reposts
 ├── 🌐 Web: 20+ pages │ Wikipedia, Bloomberg, The Register, Hacker News, Nature, VirusTotal, DigitalOcean, Codecademy, Tom's Hardware
 └── Top voices: r/openclaw, r/cybersecurity, r/clawdbot, r/ArtificialInteligence │ @grok, @Starlink │ Nature, Bloomberg, ACM
 ---
 Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly.
@@ -1,27 +0,0 @@
 Now I have a comprehensive picture. Let me synthesize everything.
 **What I learned:**
 Nano Banana Pro is fundamentally different from older image models — it's a "thinking" model that understands intent, physics, and composition. The community has converged on two distinct prompting styles, and **both work well** depending on the use case:
 1. **JSON structured prompts** — Dominant on Reddit (r/nanobanana2pro) and X. Power users share elaborate JSON objects with nested fields for subject, appearance, lighting, composition, and style. These produce the most consistent, controlled results for portraits, editorials, and product shots.
 2. **Natural language "Creative Director" prompts** — Recommended by Google's official guide. Full sentences describing the scene as if briefing a photographer. Better for cinematic shots, complex edits, and iterative refinement.
 **KEY PATTERNS I'll use:**
 1. **JSON format for maximum control** — The top Reddit posts (149-259 upvotes) all use structured JSON with nested objects: `subject > appearance > hair/skin/expression`, `lighting > key/fill/rim`, `camera > lens/angle/depth_of_field`
 2. **Be a Creative Director, not a tag spammer** — Replace "4k, realistic, beautiful" with specific technical directions: "85mm lens at f/1.8", "three-point lighting with key at 45°", "shallow depth of field with bokeh"
 3. **Provide context for WHY** — Adding purpose ("for a luxury fashion editorial", "for a high-end gourmet cookbook") helps the model infer appropriate styling, plating, lighting
 4. **Edit, don't regenerate** — When 80% is right, ask for the specific change conversationally
 5. **Text rendering works** — Keep text under 3 words for best results (75% success rate), specify font style and placement
 ---
 All agents reported back!
 - 🟠 Reddit: 5 threads | 638 upvotes | 66 comments
 - 🔵 X: 29 posts | 312 likes | 117 reposts
 - 🌐 Web: 10+ pages | blog.google, dev.to, eweek.com, imagine.art, github.com, leonardo.ai, medium.com
 - Top voices: r/nanobanana2pro | @Xmira_belle, @doctorwasif, @chatgptpaglu | Google AI blog, DEV Community
 ---
 Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into Nano Banana Pro.
@@ -1,48 +0,0 @@
 **What I learned:**
 Clawdbot (now officially renamed **OpenClaw**) is a self-hosted, open-source personal AI assistant that connects to messaging apps (Telegram, WhatsApp, Discord, Slack, Signal, iMessage) and uses LLMs to act as an autonomous agent on your behalf. It's roughly one week old as a public project and the community is moving fast — the name has already changed twice (Clawdbot → Moltbot → OpenClaw).
 **KEY PATTERNS from the research:**
 1. **Security is the #1 concern** — Multiple Reddit threads and guides warn that many setups are wide open to the internet with zero auth. Run it on dedicated/isolated hardware (VM, Mac Mini, NAS), never your main machine. Block dangerous commands via allowlist. Never add it to group chats.
 2. **Use the onboarding wizard, not Docker** — Docker was reported as unreliable (shims, bridges). The single-line install script (`curl -fsSL https://clawd.bot/install.sh | bash`) followed by `openclaw onboard` is the smoothest path. Docker is a "no-go" per multiple users.
 3. **Model choice matters a lot** — Claude Opus 4.5 is recommended for best results (trained to resist prompt injection, ~99% resistance). For budget setups, Claude Haiku works at $0. Local models (Ollama/LM Studio) work but cause hallucination and token issues — GLM 4.7 Flash (30B) was recommended as the best local option.
 4. **Telegram is the easiest channel to start with** — Most guides and users start with a Telegram bot token. WhatsApp QR code pairing fails frequently. Get Telegram working first, then expand.
 5. **Sandbox and isolate** — Set `agents.defaults.sandbox.mode` to `"non-main"` for Docker sandboxing. Use a Linux VM or UTM on Mac to segregate traffic. Tailscale for secure remote access.
 ---
 ✅ All agents reported back!
 ├─ 🟠 Reddit: 19 threads │ 415+ upvotes │ 290+ comments
 ├─ 🔵 X: 29 posts │ 815+ likes │ 65+ reposts
 ├─ 🌐 Web: 10+ pages │ Medium, DataCamp, DEV, GitHub, QNAP, docs.openclaw.ai
 └─ Top voices: r/clawdbot, r/LocalLLM, r/AskVibecoders │ @aashatwt (452 likes), @recap_david (329 likes) │ Lukas Niessen on Medium
 ---
 **Here's the consensus best setup path based on what the community actually recommends:**
 ### Quick-Start (30 min)
 1. **Get dedicated hardware** — Mac Mini, old laptop, NAS (QNAP has an official guide), or a VPS (DigitalOcean gist available). Don't use your daily driver.
 2. **Install via script**: `curl -fsSL https://clawd.bot/install.sh | bash`
 3. **Run the wizard**: `openclaw onboard` — it walks through gateway, workspace, channels, and skills
 4. **Connect Telegram first** — create a bot via @BotFather, paste the token
 5. **Set your API key** — Anthropic API key for Claude, or connect Ollama for local models
 6. **Customize SOUL.md** — this controls your bot's personality and behavior
 ### Security Hardening (do this immediately)
 - Bind gateway to localhost only, use Tailscale for remote access
 - Set sandbox mode to `"non-main"`
 - Create an explicit command allowlist (block `rm -rf`, `sudo`, `chmod`)
 - Rotate API keys every 90 days
 - Never add the bot to group chats
 ### Budget Option ($0)
 Per @shynxbt: Use a free AWS VPS + Claude Haiku model + Telegram bot = fully functional for $0.
 ---
 Want me to help you with a specific part of the setup, or do you have a particular use case in mind (home automation, CRM, coding assistant, etc.)?
@@ -1,332 +0,0 @@
 ---
 name: last30days
 description: Research a topic from the last 30 days on Reddit + X + Web, become an expert, and write copy-paste-ready prompts for the user's target tool.
 argument-hint: '"[topic] for [tool]" or "[topic]"'
 allowed-tools: Bash, Read, Write, AskUserQuestion, WebSearch
 ---
 # last30days: Research Any Topic from the Last 30 Days
 Research ANY topic across Reddit, X, and the web. Surface what people are actually discussing, recommending, and debating right now.
 ## CRITICAL: Parse User Intent
 Before doing anything, parse the user's input for:
 1. **TOPIC**: What they want to learn about (e.g., "web app mockups", "Claude Code skills", "image generation")
 2. **TARGET TOOL** (if specified): Where they'll use the prompts (e.g., "Nano Banana Pro", "ChatGPT", "Midjourney")
 3. **QUERY TYPE**: What kind of research they want:
   - **PROMPTING** - "X prompts", "prompting for X", "X best practices" → User wants to learn techniques and get copy-paste prompts
   - **RECOMMENDATIONS** - "best X", "top X", "what X should I use", "recommended X" → User wants a LIST of specific things
   - **NEWS** - "what's happening with X", "X news", "latest on X" → User wants current events/updates
   - **GENERAL** - anything else → User wants broad understanding of the topic
 Common patterns:
 - `[topic] for [tool]` → "web mockups for Nano Banana Pro" → TOOL IS SPECIFIED
 - `[topic] prompts for [tool]` → "UI design prompts for Midjourney" → TOOL IS SPECIFIED
 - Just `[topic]` → "iOS design mockups" → TOOL NOT SPECIFIED, that's OK
 - "best [topic]" or "top [topic]" → QUERY_TYPE = RECOMMENDATIONS
 - "what are the best [topic]" → QUERY_TYPE = RECOMMENDATIONS
 **IMPORTANT: Do NOT ask about target tool before research.**
 - If tool is specified in the query, use it
 - If tool is NOT specified, run research first, then ask AFTER showing results
 **Store these variables:**
 - `TOPIC = [extracted topic]`
 - `TARGET_TOOL = [extracted tool, or "unknown" if not specified]`
 - `QUERY_TYPE = [RECOMMENDATIONS | NEWS | HOW-TO | GENERAL]`
 **DISPLAY your parsing to the user.** Before running any tools, output a single line:
 🔍 **{TOPIC}** · {QUERY_TYPE}
 Searching Reddit, X, and the web for {natural language description of what you'll look for}...
 Example outputs:
 - 🔍 **kanye west** · News — Searching Reddit, X, and the web for the latest kanye west news and discussions...
 - 🔍 **best MCP servers** · Recommendations — Searching Reddit, X, and the web for the most recommended MCP servers...
 - 🔍 **nano banana pro prompting** · Prompting — Searching Reddit, X, and the web for nano banana pro prompting techniques and tips...
 - 🔍 **open claw** · General — Searching Reddit, X, and the web for what people are saying about open claw...
 If TARGET_TOOL is known, mention it: "...for nano banana pro prompting techniques to use in ChatGPT..."
 This text MUST appear before you call any tools. It confirms to the user that you understood their request.
 ---
 ## Research Execution
 **Step 1: Run the research script**
 ```bash
 python3 ~/.claude/skills/last30days/scripts/last30days.py "$ARGUMENTS" --emit=compact 2>&1
 ```
 The script will automatically:
 - Detect available API keys
 - Run Reddit/X searches if keys exist
 - Signal if WebSearch is needed
 ---
 ## STEP 2: DO WEBSEARCH WHILE SCRIPT RUNS
 The script auto-detects sources (Bird CLI, API keys, etc). While waiting for it, do WebSearch.
 For **ALL modes**, do WebSearch to supplement (or provide all data in web-only mode).
 Choose search queries based on QUERY_TYPE:
 **If RECOMMENDATIONS** ("best X", "top X", "what X should I use"):
 - Search for: `best {TOPIC} recommendations`
 - Search for: `{TOPIC} list examples`
 - Search for: `most popular {TOPIC}`
 - Goal: Find SPECIFIC NAMES of things, not generic advice
 **If NEWS** ("what's happening with X", "X news"):
 - Search for: `{TOPIC} news 2026`
 - Search for: `{TOPIC} announcement update`
 - Goal: Find current events and recent developments
 **If PROMPTING** ("X prompts", "prompting for X"):
 - Search for: `{TOPIC} prompts examples 2026`
 - Search for: `{TOPIC} techniques tips`
 - Goal: Find prompting techniques and examples to create copy-paste prompts
 **If GENERAL** (default):
 - Search for: `{TOPIC} 2026`
 - Search for: `{TOPIC} discussion`
 - Goal: Find what people are actually saying
 For ALL query types:
 - **USE THE USER'S EXACT TERMINOLOGY** - don't substitute or add tech names based on your knowledge
 - EXCLUDE reddit.com, x.com, twitter.com (covered by script)
 - INCLUDE: blogs, tutorials, docs, news, GitHub repos
 - **DO NOT output "Sources:" list** - this is noise, we'll show stats at the end
 **Depth options** (passed through from user's command):
 - `--quick` → Faster, fewer sources (8-12 each)
 - (default) → Balanced (20-30 each)
 - `--deep` → Comprehensive (50-70 Reddit, 40-60 X)
 ---
 ## Judge Agent: Synthesize All Sources
 **After all searches complete, internally synthesize (don't display stats yet):**
 The Judge Agent must:
 1. Weight Reddit/X sources HIGHER (they have engagement signals: upvotes, likes)
 2. Weight WebSearch sources LOWER (no engagement data)
 3. Identify patterns that appear across ALL three sources (strongest signals)
 4. Note any contradictions between sources
 5. Extract the top 3-5 actionable insights
 **Do NOT display stats here - they come at the end, right before the invitation.**
 ---
 ## FIRST: Internalize the Research
 **CRITICAL: Ground your synthesis in the ACTUAL research content, not your pre-existing knowledge.**
 Read the research output carefully. Pay attention to:
 - **Exact product/tool names** mentioned (e.g., if research mentions "ClawdBot" or "@clawdbot", that's a DIFFERENT product than "Claude Code" - don't conflate them)
 - **Specific quotes and insights** from the sources - use THESE, not generic knowledge
 - **What the sources actually say**, not what you assume the topic is about
 **ANTI-PATTERN TO AVOID**: If user asks about "clawdbot skills" and research returns ClawdBot content (self-hosted AI agent), do NOT synthesize this as "Claude Code skills" just because both involve "skills". Read what the research actually says.
 ### If QUERY_TYPE = RECOMMENDATIONS
 **CRITICAL: Extract SPECIFIC NAMES, not generic patterns.**
 When user asks "best X" or "top X", they want a LIST of specific things:
 - Scan research for specific product names, tool names, project names, skill names, etc.
 - Count how many times each is mentioned
 - Note which sources recommend each (Reddit thread, X post, blog)
 - List them by popularity/mention count
 **BAD synthesis for "best Claude Code skills":**
 > "Skills are powerful. Keep them under 500 lines. Use progressive disclosure."
 **GOOD synthesis for "best Claude Code skills":**
 > "Most mentioned skills: /commit (5 mentions), remotion skill (4x), git-worktree (3x), /pr (3x). The Remotion announcement got 16K likes on X."
 ### For all QUERY_TYPEs
 Identify from the ACTUAL RESEARCH OUTPUT:
 - **PROMPT FORMAT** - Does research recommend JSON, structured params, natural language, keywords?
 - The top 3-5 patterns/techniques that appeared across multiple sources
 - Specific keywords, structures, or approaches mentioned BY THE SOURCES
 - Common pitfalls mentioned BY THE SOURCES
 ---
 ## THEN: Show Summary + Invite Vision
 **Display in this EXACT sequence:**
 **FIRST - What I learned (based on QUERY_TYPE):**
 **If RECOMMENDATIONS** - Show specific things mentioned with sources:
 ```
 🏆 Most mentioned:
 [Tool Name] - {n}x mentions
 Use Case: [what it does]
 Sources: @handle1, @handle2, r/sub, blog.com
 [Tool Name] - {n}x mentions
 Use Case: [what it does]
 Sources: @handle3, r/sub2, Complex
 Notable mentions: [other specific things with 1-2 mentions]
 ```
 **CRITICAL for RECOMMENDATIONS:**
 - Each item MUST have a "Sources:" line with actual @handles from X posts (e.g., @LONGLIVE47, @ByDobson)
 - Include subreddit names (r/hiphopheads) and web sources (Complex, Variety)
 - Parse @handles from research output and include the highest-engagement ones
 - Format naturally - tables work well for wide terminals, stacked cards for narrow
 **If PROMPTING/NEWS/GENERAL** - Show synthesis and patterns:
 CITATION RULE: Cite sources sparingly to prove research is real.
 - In the "What I learned" intro: cite 1-2 top sources total, not every sentence
 - In KEY PATTERNS: cite 1 source per pattern, short format: "per @handle" or "per r/sub"
 - Do NOT include engagement metrics in citations (likes, upvotes) - save those for stats box
 - Do NOT chain multiple citations: "per @x, @y, @z" is too much. Pick the strongest one.
 **BAD:** "His album is set for March 20 (per @cocoabutterbf; Rolling Stone; HotNewHipHop; Complex)."
 **GOOD:** "His album BULLY is set for March 20 via Gamma, per Rolling Stone."
 ```
 What I learned:
 **{Topic 1}** — [1-2 sentences about this storyline, per source]
 **{Topic 2}** — [1-2 sentences, per source]
 **{Topic 3}** — [1-2 sentences, per source]
 KEY PATTERNS from the research:
 1. [Pattern] — per @handle
 2. [Pattern] — per r/sub
 3. [Pattern] — per source
 ```
 **THEN - Stats (right before invitation):**
 **CRITICAL: Calculate actual totals from the research output.**
 - Count posts/threads from each section
 - Sum engagement: parse `[Xlikes, Yrt]` from each X post, `[Xpts, Ycmt]` from Reddit
 - Identify top voices: highest-engagement @handles from X, most active subreddits
 **Copy this EXACTLY, replacing only the {placeholders}:**
 ```
 ---
 ✅ All agents reported back!
 ├─ 🟠 Reddit: {N} threads │ {N} upvotes │ {N} comments
 ├─ 🔵 X: {N} posts │ {N} likes │ {N} reposts (via Bird/xAI)
 ├─ 🌐 Web: {N} pages │ {domain1}, {domain2}, {domain3}
 └─ 🗣️ Top voices: @{handle1} ({N} likes), @{handle2} │ r/{sub1}, r/{sub2}
 ---
 ```
 If Reddit returned 0 threads, write: "├─ 🟠 Reddit: 0 threads (no results this cycle)"
 NEVER use plain text dashes (-) or pipe (|). ALWAYS use ├─ └─ │ and the emoji.
 **SELF-CHECK before displaying**: Re-read your "What I learned" section. Does it match what the research ACTUALLY says? If you catch yourself projecting your own knowledge instead of the research, rewrite it.
 **LAST - Invitation:**
 ```
 ---
 Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into {TARGET_TOOL}.
 ```
 ---
 ## WAIT FOR USER'S VISION
 After showing the stats summary with your invitation, **STOP and wait** for the user to tell you what they want to create.
 ---
 ## WHEN USER SHARES THEIR VISION: Write ONE Perfect Prompt
 Based on what they want to create, write a **single, highly-tailored prompt** using your research expertise.
 ### CRITICAL: Match the FORMAT the research recommends
 **If research says to use a specific prompt FORMAT, YOU MUST USE THAT FORMAT.**
 **ANTI-PATTERN**: Research says "use JSON prompts with device specs" but you write plain prose. This defeats the entire purpose of the research.
 ### Quality Checklist (run before delivering):
 - [ ] **FORMAT MATCHES RESEARCH** - If research said JSON/structured/etc, prompt IS that format
 - [ ] Directly addresses what the user said they want to create
 - [ ] Uses specific patterns/keywords discovered in research
 - [ ] Ready to paste with zero edits (or minimal [PLACEHOLDERS] clearly marked)
 - [ ] Appropriate length and style for TARGET_TOOL
 ### Output Format:
 ```
 Here's your prompt for {TARGET_TOOL}:
 ---
 [The actual prompt IN THE FORMAT THE RESEARCH RECOMMENDS]
 ---
 This uses [brief 1-line explanation of what research insight you applied].
 ```
 ---
 ## IF USER ASKS FOR MORE OPTIONS
 Only if they ask for alternatives or more prompts, provide 2-3 variations. Don't dump a prompt pack unless requested.
 ---
 ## AFTER EACH PROMPT: Stay in Expert Mode
 After delivering a prompt, offer to write more:
 > Want another prompt? Just tell me what you're creating next.
 ---
 ## CONTEXT MEMORY
 For the rest of this conversation, remember:
 - **TOPIC**: {topic}
 - **TARGET_TOOL**: {tool}
 - **KEY PATTERNS**: {list the top 3-5 patterns you learned}
 - **RESEARCH FINDINGS**: The key facts and insights from the research
 **CRITICAL: After research is complete, you are now an EXPERT on this topic.**
 When the user asks follow-up questions:
 - **DO NOT run new WebSearches** - you already have the research
 - **Answer from what you learned** - cite the Reddit threads, X posts, and web sources
 - **If they ask for a prompt** - write one using your expertise
 Only do new research if the user explicitly asks about a DIFFERENT topic.
 ---
 ## Output Summary Footer (After Each Prompt)
 After delivering a prompt, end with:
 ```
 ---
 📚 Expert in: {TOPIC} for {TARGET_TOOL}
 📊 Based on: {n} Reddit threads ({sum} upvotes) + {n} X posts ({sum} likes) + {n} web pages
 Want another prompt? Just tell me what you're creating next.
 ```
@@ -1,25 +0,0 @@
 Here's what I found:
 ## What I learned:
 **BULLY Album — March 20, 2026 via Gamma** — After years of delays (first announced September 2024), Kanye's 12th studio album finally has a firm release date. The 13-track project features Peso Pluma, Playboi Carti, and Ty Dolla Sign. Sonically it recalls *808s & Heartbreak* and *MBDTF* — Ye mostly sings rather than raps. Notably, earlier leak versions used AI-deepfaked vocals, which have reportedly been re-recorded with his real voice for the official release, per Rolling Stone.
 **Public Apology for Antisemitism** — On January 26, Ye took out a full-page Wall Street Journal ad titled "To Those I've Hurt," publicly apologizing for his antisemitic remarks. He disclosed a previously undiagnosed brain injury from his 2002 car accident and attributed his behavior to a four-month manic episode fueled by bipolar disorder, psychosis, and paranoia. "I lost touch with reality," he wrote. The apology also extended to the Black community, per The Washington Post.
 **Hellwatt Festival in Italy** — Ye is headlining a brand-new festival at the 103,000-capacity RCF Arena in Italy over three weekends from July 4-18, 2026 — his first-ever live concert in Italy, per Billboard.
 **Health Concerns** — A rare January 2026 outing in LA with Bianca Censori reignited concern about Ye's physical appearance. Insiders point to medication side effects, frequent travel, and inconsistent routines, per AllHipHop.
 **Grammys Ban** — Ye is reportedly not welcome at the 2026 Grammy Awards after clashing with organizers last year over his invitation terms, per The News International.
 **Kim & Lewis Hamilton Buzz** — X chatter is heavily focused on Kim Kardashian's relationship with Lewis Hamilton, with users contrasting her new relationship against her marriage to Ye.
 ---
 ✅ All agents reported back!
 ├─ 🟠 Reddit: 0 threads (no results this cycle)
 ├─ 🔵 X: 29 posts │ 33 likes │ 14 reposts (via xAI)
 ├─ 🌐 Web: 30+ pages │ rollingstone.com, washingtonpost.com, complex.com, billboard.com, npr.org
 └─ 🗣️ Top voices: @honest30bgfan_ (33 likes), @HipHopCrave_ │ Rolling Stone, Washington Post, Complex
 ---
 Share your vision for what you want to create and I'll write a thoughtful prompt you can copy-paste directly into your tool of choice.
@@ -1,90 +0,0 @@
 ## v3.3.0 — install everywhere, ship the reliability sweep
 The AI world reinvents itself every month. This skill keeps you current.
 `/last30days` researches your topic across Reddit, X, YouTube, TikTok, Instagram, Hacker News, Polymarket, GitHub, Digg, and 5+ more sources from the last 30 days, finds what the community is actually upvoting, sharing, betting on, and saying on camera, and writes you a grounded narrative with real citations.
 ## What's new in v3.3.0
 ### Install everywhere with one command
 `npx skills add mvanhorn/last30days-skill -g -y` is now the canonical install path for **every harness** — Claude Code, OpenAI Codex CLI, Cursor, Gemini CLI, GitHub Copilot, Windsurf, and 50+ other Agent Skills hosts. The skill auto-detects each harness's skills directory and symlinks in place, so edits propagate live. No more per-harness manual paths in the README.
 ### New emit mode: `--emit=html`
 Shareable, print-friendly HTML briefs. Drop the file in Slack, mail it to a stakeholder, or print it for the meeting. Same data as compact mode, structured for human reading.
 ### New source: Digg
 Digg surfaces curated story clusters from the AI 1000 leaderboard and pulls attributable X-post quotes directly into the brief. Auto-enabled when `digg-pp-cli` is on PATH. Footer line: `⛏️ Digg: N clusters │ K posts │ M authors`. No X auth required for the inline quotes.
 ### YouTube residential-IP routing (`LAST30DAYS_YOUTUBE_SSH_HOST`)
 Running on a datacenter VPS (Hetzner, DigitalOcean, AWS, etc.)? YouTube's bot-wall fingerprints datacenter IP ranges before any cookie check. Set `LAST30DAYS_YOUTUBE_SSH_HOST=<ssh-alias>` and yt-dlp runs over SSH against a residential-IP host instead. One env var, no proxy service required.
 ### macOS Keychain credential source
 When env vars and config files aren't set, the engine now reads credentials from the macOS Keychain. Stores secrets where macOS expects them; nothing on disk in plaintext.
 ### `EXCLUDE_SOURCES` env var
 The inverse of `INCLUDE_SOURCES`. Useful for "everything except TikTok" or "everything except the slow ones."
 ## Reliability sweep
 This release closes a long tail of platform-specific issues that have been accumulating:
 - **Reddit**: subreddits starting with `r` no longer get mangled by `lstrip("r/")`. Browser-like headers + gzip handling fix urllib 403s on the public JSON endpoint. HTTP 402 now triggers the OpenAI/public-JSON fallback chain when ScrapeCreators credits are exhausted.
 - **xAI**: empty or malformed responses now surface in `errors_by_source` instead of silently returning zero results.
 - **Windows**: process cleanup no longer crashes on `os.killpg`. POSIX-style secret-permission warnings skipped. Save-path footer uses forward slashes.
 - **Auth**: comma-separated `SCRAPECREATORS_API_KEY=key1,key2` rotation restored (accidentally dropped in v3.0.6).
 - **YouTube + HN**: SC YouTube + multi-token HN searches unblocked. Transcript-fetch ratio surfaced.
 - **HTTP**: retry budget expanded with exponential backoff on DNS failure. Parallel AI search aligned with current API schema.
 - **OpenClaw**: now works without a ScrapeCreators key. Poll-timing initialized once.
 ## Multi-harness reframe
 `AGENTS.md` is now the canonical project doc; `CLAUDE.md` points at it. The skill is positioned as a multi-harness Agent Skills package, not a Claude-Code-specific tool. SKILL.md's path resolution rewrote `SKILL_ROOT` → `SKILL_DIR`, removing ~80 lines of bash and fixing a real spec-vs-engine divergence bug.
 ## Breaking change
 **`.codex-plugin/plugin.json` removed.** Codex native-plugin users should install via `npx skills add mvanhorn/last30days-skill` or copy the skill to `~/.codex/skills/last30days/`. The `npx skills add` path now reaches every harness uniformly.
 ## Install
 Any harness (recommended):
 ```
 npx skills add mvanhorn/last30days-skill -g -y
 ```
 Claude Code marketplace:
 ```
 /plugin marketplace add mvanhorn/last30days-skill
 ```
 OpenClaw:
 ```
 clawhub install last30days-official
 ```
 Zero config. Reddit, Hacker News, Polymarket, and GitHub work immediately. Run it once and the setup wizard unlocks X, YouTube, TikTok, and more in 30 seconds.
 ## Contributors
 First-time contributors whose fixes shipped in v3.3.0 (most via PR triage salvage — the fix re-applied directly to main with co-author credit when path migration made the original branch un-rebaseable):
 - Dave Morin — portable test-harness paths
 - Alex Key — `removeprefix("r/")` for subreddit names
 - Eric Oberhofer — multi-key rotation restored
 - gujishh — Windows process cleanup
 - Franco Carballar — Reddit browser-like headers
 - Jonathan Oppenheim — Reddit 402 fallback chain
 - Kaustav Mishra — xAI error surfacing
 - [@thinkun](https://github.com/thinkun) — OpenClaw ScrapeCreators-key-optional fix
 Plus every contributor who shipped one of the ~75 PRs merged this cycle. See [CHANGELOG.md](CHANGELOG.md) under `[3.3.0]` for the full PR list and `git log v3.2.0..v3.3.0` for the complete commit graph.
 30 days of research. 30 seconds of work. Thirteen sources. Zero stale prompts.