|
| 1 | +--- |
| 2 | +name: weekly-signal-diff |
| 3 | +description: | |
| 4 | + Use when the user wants a weekly structural diff on AI, software, or another |
| 5 | + fast-moving market. Starts from 10 suggested categories and 30 suggested |
| 6 | + companies when no watchlist exists, then adapts the scan using Open Brain |
| 7 | + memory, current priorities, and prior digests. Best for prompts like "run my |
| 8 | + weekly signal diff", "what changed this week that matters to me", "track this |
| 9 | + market", or "turn this week's news into structural shifts". Optional live |
| 10 | + search upgrade: if OpenRouter access is available, prefer the Perplexity |
| 11 | + Sonar family for fresh web-grounded retrieval with citations. |
| 12 | +author: Jonathan Edwards |
| 13 | +version: 1.0.0 |
| 14 | +--- |
| 15 | + |
| 16 | +# Weekly Signal Diff |
| 17 | + |
| 18 | +## Problem |
| 19 | + |
| 20 | +A wall of news does not tell the user what structurally changed. Most weekly |
| 21 | +roundups over-index on headlines, underweight economics and dependency shifts, |
| 22 | +and ignore what the user actually cares about. This skill turns a noisy week |
| 23 | +into a small set of structural changes, weighted by Open Brain memory. |
| 24 | + |
| 25 | +## When to Use |
| 26 | + |
| 27 | +- Weekly market review or Sunday/Friday ritual |
| 28 | +- "Run my weekly signal diff" |
| 29 | +- "What changed this week that matters to me?" |
| 30 | +- "Track this market and tell me the structural shifts" |
| 31 | +- "Turn this pile of news into a decision-grade diff" |
| 32 | +- Ongoing automation that writes a weekly digest back to Open Brain |
| 33 | + |
| 34 | +## Required Context |
| 35 | + |
| 36 | +Gather as much as the environment allows: |
| 37 | + |
| 38 | +- the user's active projects, bets, and recurring interests |
| 39 | +- prior weekly digests or adjacent summaries stored in Open Brain |
| 40 | +- the desired freshness window (default: last 7 days) |
| 41 | +- any preferred outlets, banned sources, or explicit watchlist entities |
| 42 | + |
| 43 | +If the user has not provided categories or companies, read |
| 44 | +[references/starter-universe.md](references/starter-universe.md) and use it as |
| 45 | +a bootstrap layer only. |
| 46 | + |
| 47 | +If live web access is available and the user wants current coverage, read |
| 48 | +[references/live-search-upgrade.md](references/live-search-upgrade.md) and use |
| 49 | +the strongest search mode the environment supports. |
| 50 | + |
| 51 | +## Process |
| 52 | + |
| 53 | +1. Establish the frame. |
| 54 | + - Confirm the topic space, freshness window, and whether the goal is |
| 55 | + personal awareness, operator strategy, investor tracking, or content prep. |
| 56 | + - If the user says nothing, default to a 7-day operator-style review. |
| 57 | + |
| 58 | +1. Pull Open Brain context first. |
| 59 | + - Search for active projects, current priorities, recurring entities, recent |
| 60 | + captures, and the last 2-4 weekly digests. |
| 61 | + - Tool names vary by client. Use the available Open Brain search, list, and |
| 62 | + capture tools in the environment rather than assuming fixed names. |
| 63 | + - Extract a short relevance profile: what the user is building, what they |
| 64 | + keep revisiting, what they are worried about, and what they are trying to |
| 65 | + learn. |
| 66 | + |
| 67 | +1. Build the watchlist. |
| 68 | + - Start from the suggested 10-category / 30-company starter universe if the |
| 69 | + user has not defined a watchlist. |
| 70 | + - Treat the starter list as a scaffold, not a contract. |
| 71 | + - Re-rank or replace items using Open Brain context: |
| 72 | + - promote companies, categories, or themes the user mentions often |
| 73 | + - demote low-signal items |
| 74 | + - add personal-priority entities even if they are outside the starter set |
| 75 | + - Preserve some baseline discovery. Personalization should shape the scan, |
| 76 | + not collapse it into only known favorites. |
| 77 | + |
| 78 | +1. Gather the week's evidence. |
| 79 | + - Prefer fresh, source-backed information with links or citations. |
| 80 | + - If live search is available, perform a broad sweep first, then targeted |
| 81 | + follow-ups on the top candidate shifts. |
| 82 | + - If live search is not available, work from the user's provided sources and |
| 83 | + say that the diff is source-bounded. |
| 84 | + - Ignore pure announcement theater unless it changes economics, |
| 85 | + distribution, regulation, dependency, geography, or buyer behavior. |
| 86 | + |
| 87 | +1. Ask the structural questions on every candidate signal. |
| 88 | + - What constraint shifted? |
| 89 | + - Who gained or lost leverage? |
| 90 | + - What got cheaper, harder, faster, or more defensible? |
| 91 | + - What dependency got exposed? |
| 92 | + - What business model or pricing assumption weakened? |
| 93 | + - What changed in regulation, geography, or distribution? |
| 94 | + - Why does this matter for the user's actual projects, workflows, or market |
| 95 | + view? |
| 96 | + |
| 97 | +1. Score before writing. |
| 98 | + - Keep only the few signals that represent real change. |
| 99 | + - A good weekly diff usually has 3-7 structural shifts. |
| 100 | + - Merge duplicates, drop weak stories, and explicitly label speculation as |
| 101 | + speculation. |
| 102 | + |
| 103 | +1. Produce the weekly diff. |
| 104 | + |
| 105 | +Use this default structure: |
| 106 | + |
| 107 | +- `Coverage note` — what was scanned, how it was personalized, and the date |
| 108 | + window |
| 109 | +- `Structural shifts` — 3-7 items, each with: |
| 110 | + - what changed |
| 111 | + - why it matters in general |
| 112 | + - why it matters to this user |
| 113 | + - supporting evidence or citations |
| 114 | +- `What changed from last week` — new, rising, fading, or resolved themes |
| 115 | +- `Watch next` — entities, constraints, or questions to monitor |
| 116 | +- `Actions` — optional follow-ups, only if the evidence supports them |
| 117 | + |
| 118 | +1. Capture the durable output. |
| 119 | + - Save the final digest back into Open Brain when capture tools are |
| 120 | + available. |
| 121 | + - Prefer one durable weekly summary plus separate captures only for truly |
| 122 | + important follow-up items. |
| 123 | + - Include provenance: week ending date, topic scope, and major entities |
| 124 | + covered. |
| 125 | + |
| 126 | +## Output |
| 127 | + |
| 128 | +When this skill works correctly, the user gets: |
| 129 | + |
| 130 | +- a concise weekly structural diff instead of a headline roundup |
| 131 | +- a clear explanation of why the shifts matter to them specifically |
| 132 | +- citations or source links when live search is available |
| 133 | +- a durable weekly digest saved back into Open Brain for future comparison |
| 134 | + |
| 135 | +## Guardrails |
| 136 | + |
| 137 | +- The goal is `diff, not digest`. |
| 138 | +- Do not force all 30 suggested companies into the final output. They are there |
| 139 | + to prevent blank-page syndrome, not to create fake coverage. |
| 140 | +- Do not mistake product launches, benchmark screenshots, or funding headlines |
| 141 | + for structural change unless they move a real constraint. |
| 142 | +- Keep general market analysis separate from personalized implications. |
| 143 | +- If evidence is thin, say the week was thin. |
| 144 | +- If the environment lacks live search, be explicit about the freshness |
| 145 | + limitation. |
| 146 | +- If the user's interests are unclear, use the starter universe and explain |
| 147 | + that it is a bootstrap pass. |
| 148 | + |
| 149 | +## Notes for Other Clients |
| 150 | + |
| 151 | +- This skill is portable across Claude Code, Codex, Cursor, and similar clients |
| 152 | + because the core behavior is procedural. |
| 153 | +- Adapt Open Brain tool names to the local environment. |
| 154 | +- For scheduled runs, pair the skill with the user's automation system and keep |
| 155 | + the same structure every week so diffs stay comparable. |
| 156 | +- If OpenRouter is available, prefer a Perplexity Sonar web-search model for |
| 157 | + the retrieval pass, then use the local AI client or model to do the actual |
| 158 | + synthesis if that split is more ergonomic. |
0 commit comments