newsjack 0.1.5

package/skills/newsjack-detector/rubric.md

@@ -0,0 +1,160 @@
+# Newsjack Detector Rubric
+
+Use this rubric after the engine returns queued evidence. The engine exposes mechanical scores and `routing.queue_priority`; neither is a PR judgment.
+
+The engine has two discovery lanes:
+
+- `profile_relevance` - profile/topic/competitor queries. These catch highly relevant but sometimes minor stories.
+- `major_news` - curated RSS/Atom feed items. These catch broader major news first, then require a stricter client-relevance judgment.
+
+Do not treat a `major_news` item as pitchable because it is big. The client still needs standing and a journalist shape.
+
+## Story Size
+
+Use `story_size` to calibrate effort, not to approve a pitch. It is a deterministic media-attention proxy based on news-search publication metadata:
+
+- log-scaled estimated monthly traffic
+- domain authority
+- coverage spread across independently surfaced domains
+
+`major` or `high` story size means the opportunity may justify faster review. It does not compensate for stale timing, weak standing, or a bad journalist shape.
+
+## Freshness Gate
+
+For recurring scheduled output, the LLM `story-origin-check` recovers the first-public timestamp and canonical coverage, then the Go CLI `origin-apply` computes the freshness gate. News-search `published_at` values are reliable evidence for article timestamps and should be used to find candidate originals, but they are not alone a same-story or first-publication judgment.
+
+Before assigning `pitch_now`, `develop_angle`, or `monitor`, inspect `freshness_gate.computed_status`:
+
+- `fresh` - eligible for normal judgment.
+- `fresh_new_development` - eligible, but the angle must be about the new development, not the older background story.
+- `stale` - reject as stale.
+- `unverified_no_corroboration`, `unverified_boundary`, `unverified_no_timestamp`, or missing - reject for recurring scheduled output. Track the reason: `unverified_no_corroboration` is a worker/pipeline miss (the clock may be fine, just under-sourced — re-runnable), while `unverified_boundary`/`unverified_no_timestamp` reflect genuinely thin evidence.
+
+Do not reset the clock because an aggregator, syndication partner, or secondary outlet republished an older article.
+
+When citing the story, prefer `story_origin.canonical_coverage_url` when present. It should be the major or most authoritative same-story coverage, such as a primary source, wire, major publisher, or recognized trade, instead of the small pickup that triggered retrieval.
+
+## Verdict Ladder
+
+### pitch_now
+
+Use only when all are true:
+
+- Evidence is fresh: usually `30min`, `4hr`, or `24hr`.
+- The first public story clock is verified as inside the last 24 hours, or the new development is inside the last 24 hours.
+- At least one credible news source exists, preferably `news_search`.
+- The client has direct standing to comment.
+- The client has a real spokesperson or direct domain authority.
+- A specific reporter shape is obvious.
+- No hard brand-safety block applies.
+
+### develop_angle
+
+Use when the signal is real but needs framing:
+
+- Fresh or still within the week.
+- Client standing is plausible but not yet sharp.
+- A journalist shape exists, but the angle needs work.
+- Major-news lane items often belong here when they are important but the client angle is indirect.
+
+Handoff: `angle-generator`.
+
+### monitor
+
+Use when the signal is interesting but not pitch-ready:
+
+- Single-source or weak cross-source confirmation.
+- Early chatter without enough news confirmation.
+- The client might have standing, but the angle is not clear yet.
+- The signal may matter if it gains traction.
+
+### reject
+
+Use when any core gate fails:
+
+- stale
+- freshness unverified in recurring scheduled output
+- no client standing
+- no plausible journalist shape
+- off-beat
+- already seen with no new development
+- weak source quality
+
+## Decay
+
+Decay uses the verified first-public timestamp from `story-origin-check`. Engine `features.decay_bucket` is provisional when evidence comes from aggregators, syndication partners, secondary rewrites, or search results that have not yet been matched to the original/canonical story.
+
+- `30min` - live/breaking. Only use for immediate comment if the client can respond now.
+- `4hr` - same-cycle. Good for reactive comment.
+- `24hr` - still fresh. Good for angle generation or same-day response.
+- `week` - trend/context only. Do not call it breaking.
+- `month` - usually not a newsjack unless paired with a new data point or fresh hook.
+- `unknown` - do not pitch as timely without independent timestamp verification.
+
+## Standing
+
+Strong standing:
+
+- The client operates directly in the affected market.
+- The client has direct market exposure, technical expertise, or a named executive who can speak concretely.
+- The signal names the client's category, customers, regulators, technology, or competitors.
+
+Partial standing:
+
+- The client has adjacent expertise but needs a narrower angle.
+- The client can explain impact but not the core event.
+
+Weak standing:
+
+- The client merely sells into the broad category.
+- The client wants to comment because the topic is popular.
+- The client only has generic thought leadership.
+
+For `major_news` lane signals, standing must explain the bridge from the public story to the client:
+
+- same buyer being affected
+- same regulator or policy surface
+- named competitor or platform move
+- client can explain a non-obvious operational effect
+
+If the bridge is "this is about AI and the client uses AI," reject or monitor.
+
+## Journalist Shape
+
+A useful journalist shape names:
+
+- exact beat
+- outlet archetype
+- why the beat cares now
+- who should not receive it
+
+Bad shapes:
+
+- "business reporter"
+- "AI journalist"
+- "tech media"
+- "industry press"
+
+Good shapes:
+
+- "enterprise AI reporter covering vendor compliance claims after regulator action"
+- "cybersecurity trade reporter covering identity-risk fallout from new enforcement"
+- "retail operations reporter covering labor-cost impact of a same-day policy change"
+
+## Hard Blocks
+
+Block signals built on:
+
+- death
+- violence
+- disaster
+- war
+- abuse
+- sexual violence
+- missing people
+- humanitarian crisis
+- hate crime
+- terror
+- suicide
+
+The only acceptable work around these topics is restrained expert commentary with direct public-interest standing. Promotional hooks are refused.

package/skills/newsjack-monitor-setup/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: newsjack-monitor-setup
+description: "Set up a newsjack monitoring profile for a company so newsjack-detector can run on a schedule. Guides the user through company standing, topics, competitors, proof assets, spokespeople, RSS feed selection, and optional X trend monitoring."
+when_to_use: "User wants to set up monitoring, create or configure a monitor profile, schedule recurring newsjack scans, choose RSS/news feeds, or prepare a profile for newsjack-detector. For a general 'what is newsjack / where do I start' first contact, use the getting-started flow instead of this skill."
+---
+
+# Newsjack Monitor Setup
+
+You are **newsjack-monitor-setup**, the monitoring-setup skill for newsjack.sh. Your job is to create a monitor profile that `newsjack-detector` can run on the user's chosen schedule without guessing the company, beat, or news sources.
+
+## Decision Path
+
+Setup has two modes. If the user only wants a profile, return a monitor profile JSON object with relevant RSS feeds, `x_news` enabled by default, and optional X trend preferences. When the CLI launches setup, complete the full profile, schedule, mock-test, live-test, review, and starring flow below.
+
+If the user only asks for a profile, stop here: return the JSON and run commands without writing files or running the setup flow below.
+
+Run this only when the CLI launches you for auto-setup or hands you a runtime schedule target. It installs and verifies a working monitor end to end. User-facing steps ask for choices or confirmation; CLI steps must be followed by a concrete check.
+
+1. **Pick a frequency.** Ask the user using the scheduling options in [Scheduling](#scheduling).
+
+2. **Save the profile.** `newsjack monitor init <slug> --profile profile.json` (slug is optional; it defaults to a slug of the company name). This also scaffolds an inert `brief.md` in the monitor directory (path returned as `brief_path`).
+
+2b. **Seed the client brief.** The brief is the source of truth for what this client will and won't pitch and how to present the scan — `newsjack-detector` reads it at triage and rendering time. From what the user told you in onboarding, fill in the scaffolded `brief.md`: **Audience** (who they ultimately reach — this sets pitch altitude), **We pitch** (concrete fair-game story shapes), **We never pitch** (hard exclusions — off-topic categories, policy/process if irrelevant, competitor-owned content), and any **How to surface** preference. Write only what the user actually said; leave a section as the inert comment if you have nothing real for it. Tell the user the file is theirs to edit and that feedback on future runs updates it.
+
+3. **Install the schedule.** `newsjack monitor schedule <slug> --runtime <runtime> --every "<frequency>"`, where `<frequency>` is `8am and 2pm`, `daily 8am`, or `1h`. The CLI applies the deterministic per-slug jitter described in [Scheduling](#scheduling).
+
+4. **Mock test.** `newsjack monitor test <slug> --mock`. Confirm the CLI detector pipeline runs cleanly before spending live calls.
+
+5. **Live agent run.** Run the monitor once inside the selected agent harness, not as a standalone CLI smoke test. The agent should run `newsjack monitor run <slug>`, then use the installed `newsjack-detector` skill to complete LLM analysis and render `run.md` from the JSON artifacts. Do not treat `newsjack monitor test <slug> --live` as the end-to-end live test; that flag only runs the CLI detector against live sources and does not complete the agent/skill report workflow.
+
+6. **Review with the user.** Show the agent's `run.md` - the strongest stories, or a clear "no pitch-ready items" summary, plus the artifact/report paths. Always surface a few real examples from the live run that were worth mentioning, even when none are pitch-ready, so the user has some idea what the monitor checked. Ask whether they want to change topics, competitors, feeds, proof assets, frequency, or exclusions. If they do, update the profile or schedule, then rerun the mock smoke test and the live agent run before finishing. When the feedback is about **what to pitch or surface** (e.g. "too policy-heavy," "stop showing me that category," "this one is exactly right"), capture it in `brief.md` — a new *We never pitch* rule, a *How to surface* line, or a dated *Example* — so the policy sticks for every future run, not just this one.
+
+7. **Ask the user if they want to support this project by starring the repo.** See [Starring](#starring) below.
+
+## Inputs
+
+Ask only for missing facts that materially change the profile. If the user gives a website, use it as context, but do not invent proof claims you cannot support from user input or the page.
+
+Required:
+
+- company name
+- website
+- one-sentence description
+- 6-8 core broad beat topics, usually 2-3 words each; one-word beats are fine when natural
+- 3-6 competitors or adjacent major companies
+- 10-20 static search terms for retrieval: broad beat terms plus qualified entity-watch terms, each traceable to user input, the client's materials, named entities, or fresh coverage
+- 2-5 standing areas
+- 2-5 proof assets
+- 1-3 likely spokespeople
+- 2-5 RSS feed URLs
+- X trend preference: `location` or `none` by default; `personalized` only when user-context OAuth is available
+
+Optional:
+
+- client-specific exclusions
+- geography
+- target beats
+- location WOEIDs for X trends if the user chooses `location`
+
+General tragedy and human-suffering exclusions are not profile fields. Those live in detector doctrine.
+
+## Editing Existing Setup
+
+The monitor profile is the setup file. Installed monitors store it at `~/.newsjack/monitors/<slug>/profile.json`; direct/fixture runs may pass another path with `--profile` such as `fixtures/newsjack-detector-agent/profile.<slug>.json`.
+
+If the user wants the monitor to look at different news, edit `profile.json`: `topics`, `search_terms`, `competitors`, and `feed_urls`. If the user wants to change what gets pitched or shown after collection, edit the adjacent `brief.md` instead.
+
+## Building the Profile
+
+Work these steps in order. They produce the profile JSON; nothing here writes files or schedules anything.
+
+1. **Understand the company.** Identify what it sells, who buys it, and what public stories it can credibly comment on.
+
+2. **Define standing.** Standing is not "we use AI." It is the specific expertise, customer exposure, first-party data, or operational experience that earns permission to comment.
+
+3. **Pick broad beat topics.** Topics are the durable meaning layer, not today's live stories, not internal feature names, not competitors, and not named platforms/products. Aim for 6-8 core 2-3 word beats; one word is fine when it naturally names a real beat. They should describe the client's broad world without trying to carry every retrieval query. Good for an accounting-firm software client: `accounting firms`, `CPA firms`, `tax software`, `small business`, `tax policy`, `firm staffing`, `business compliance`. Good for a local-search client: `local search`, `small business`, `AI search`, `local marketing`, `customer reviews`, `search rankings`, `marketing analytics`. Bad: `Google Maps`, `Intuit`, `innovation`, `growth`, `tax workflow digitization`, `AI practice management for accounting firms`, `Ramp Stack launch`, `Firm360 Claude Connector`, `CPA shortage` unless the user explicitly says that is their standing.
+
+4. **Pick competitors.** Include direct competitors plus major platforms whose moves would affect the client. Keep canonical names here even when they are ambiguous: `Ada`, `Aura`, `Good Move`, `Notion`.
+
+5. **Pick static search terms.** Search terms are the detector's retrieval aperture. When `search_terms` are present, the CLI retrieves with them instead of raw `topics + competitors`, so include the short broad beat topics here too. Then add qualified entity-watch terms for ambiguous companies, products, regulators, or competitors: `Ada customer service`, `Aura identity theft`, `Good Move cash house buyer`, `Atlassian Confluence AI`. A term is allowed only if it traces to user input, the client's website/materials, a named competitor/product/regulator, or fresh current coverage. Do not seed terms from model memory of what has been "hot" in the sector, and do not store live-story phrases here unless the user explicitly promotes them.
+
+6. **Pick proof assets.** Include concrete evidence the user can actually supply: product pages, customer examples, benchmark claims, data, case studies, certifications, methodology.
+
+7. **Select feeds.** Choose 2-5 feed URLs from the catalog unless the user gives a better source. Explain why each feed belongs.
+
+8. **Choose X social sources.** Set `x_news.enabled` to `true` by default. Ask whether to use location trends or no X trends; mention personalized trends only if the user has user-context OAuth configured. Explain the tradeoff briefly. Location trends should include WOEIDs.
+
+## Feed Catalog
+
+Read `../newsjack-detector/references/rss-feeds.json` before selecting feeds.
+
+Use the catalog as the default source of feed choices. Pick feeds by beat:
+
+- Tech/AI/SaaS/startups: `techmeme`, `google-news-technology`, `google-news-business`
+- Consumer privacy/data brokers: `ftc-press`, `google-news-technology`, `google-news-us`
+- UK property/regulation: `govuk-news`, UK Google News Business if supplied or manually selected
+- Healthcare/biotech: `google-news-health`, `google-news-science`
+- Finance/crypto/public-company compliance: `sec-press`, `google-news-business`
+- Media/publishing: `mediagazer`, `techmeme`
+- U.S. policy/public affairs: `memeorandum`, `google-news-us`
+
+Avoid overly broad feeds unless the client has standing to comment on broad public affairs. Do not select `google-news-world` for a normal company unless geopolitics or supply chain is central to the client.
+
+## X Trend Preference
+
+Enable `x_news` by default for every profile. X News has a much better shape than raw post search because it returns story clusters, hooks, summaries, entities, and clustered post IDs. Treat it as a discovery lane, not final proof, because the summaries are generated from X posts and can be wrong.
+
+Ask whether the user wants X trends during monitoring:
+
+- `personalized`: Uses the authenticated user's personalized X trends. Do not choose this for normal bearer-token installs; it requires user-context OAuth and is unavailable with app-only bearer tokens. It is biased by the account.
+- `location`: Uses X WOEID trends for one or more locations. Better for local/regional PR, public affairs, real estate, events, or market-specific consumer brands. Requires an app bearer token with access to the trends endpoint.
+- `none`: Best when the user wants only RSS/news search and does not want X trend noise.
+
+If the user chooses `location`, ask for target geography and save both labels and WOEIDs when known. Common WOEIDs:
+
+- Worldwide: `1`
+- United States: `23424977`
+- United Kingdom: `23424975`
+- Canada: `23424775`
+- Toronto: `4118`
+- San Francisco: `2487956`
+- New York City: `2459115`
+- London: `44418`
+
+Do not make `location` the default for a generic SaaS company. Prefer `none` unless geography is important. If the user is unsure, choose `none` for low-noise company monitoring.
+
+## Scheduling
+
+Ask the user how often the monitor should run before saving the schedule. Use AskUserQuestion or similar with these options:
+
+- `8am and 2pm (recommended)`: Best default for most teams; catches morning news and early-afternoon developments without hourly noise.
+- `Every morning at 8am`: Best when the user wants a daily digest.
+- `Hourly`: Best for high-urgency accounts with enough standing and appetite to react quickly.
+
+Use local time unless the user specifies a timezone. Use these schedule values when calling `newsjack monitor schedule`: `8am and 2pm`, `daily 8am`, or `1h`. For the selected schedule, generate a cron expression with a stable random minute in `[1, 59]`, never `0`.
+
+Prefer deterministic jitter per monitor: `minute = (fnv32a(slug) % 59) + 1`. Reruns should produce the same cron and should not fight an existing user schedule. This is skill doctrine; do not require the user-facing launcher prompt to repeat it.
+
+Daily and weekly schedules also need jitter. Avoid common collision points such as `0 * * * *`, `0 0 * * *`, and `0 9 * * 1`; use the same deterministic minute rule and avoid default hours such as midnight or Monday 09:00 unless the user asks for them.
+
+Apply this for OpenClaw cron, Hermes cron, Claude Code Routine, Codex, and any other scheduler runtime.
+
+This spreads load across the Newsjack/Medialyst backend so we don't get a thundering-herd spike at the top of every hour.
+
+## Starring
+
+After the live run is approved, use AskUserQuestion (or similar) to ask whether they'd like to support this project by starring the `newsjack` repository on GitHub. Offer two options: "Yes, star the repo" and "No thanks".
+
+If yes and the `gh` CLI is available:
+
+```bash
+gh api -X PUT /user/starred/elvisun/newsjack
+```
+
+If `gh` is missing or the command fails, share the manual link `https://github.com/elvisun/newsjack`. If no, thank them and complete setup without starring.
+
+## Profile Format
+
+Use this JSON shape only when the user asks for a profile without running the full setup flow. Full setup is action-oriented: after scheduling, mock testing, live agent run, review, and starring, complete the workflow conversationally instead of returning a JSON blob.
+
+```json
+{
+  "profile": {
+    "company": "Company",
+    "website": "https://example.com",
+    "description": "One sentence.",
+    "topics": ["broad beat topic"],
+    "competitors": ["Competitor"],
+    "search_terms": ["broad beat topic", "qualified entity-watch term"],
+    "feed_urls": ["https://..."],
+    "x_news": {
+      "enabled": true
+    },
+    "x_trends": {
+      "mode": "none",
+      "woeids": [],
+      "locations": []
+    },
+    "spokespeople": ["Founder or CEO"],
+    "proof_assets": ["Specific proof"],
+    "standing": ["Specific standing area"],
+    "exclusions": []
+  },
+  "feed_rationale": [
+    {
+      "feed": "https://...",
+      "why": "Specific reason this feed belongs"
+    }
+  ],
+  "x_news_rationale": "Enabled by default because X News returns story clusters rather than random individual posts.",
+  "x_trends_rationale": "Why this X trend mode was selected, including geography if location-based.",
+  "run_commands": {
+    "hourly_major_news": "newsjack detector run --profile profile.json --feed-only --save --new-only --max-age-hours 48",
+    "profile_relevance": "newsjack detector run --profile profile.json --save"
+  },
+  "missing_inputs": [
+    "Question or missing proof that would materially improve the profile"
+  ]
+}
+```
+
+Keep `exclusions` empty unless the user gives a client-specific no-go topic.

package/skills/newsjack-monitor-setup/examples.md

@@ -0,0 +1,106 @@
+# Newsjack Monitor Setup Examples
+
+## Local Falcon-Style Profile
+
+```json
+{
+  "profile": {
+    "company": "Local Falcon",
+    "website": "https://www.localfalcon.com",
+    "description": "Local SEO and AI search visibility platform for geo-grid rank tracking, Google Business Profile visibility, and AI search monitoring.",
+    "topics": [
+      "local search",
+      "small business",
+      "AI search",
+      "local marketing",
+      "customer reviews",
+      "search rankings",
+      "marketing analytics"
+    ],
+    "competitors": [
+      "BrightLocal",
+      "Whitespark",
+      "Semrush Local",
+      "Yext",
+      "Local Viking"
+    ],
+    "search_terms": [
+      "local search",
+      "small business",
+      "AI search",
+      "local marketing",
+      "customer reviews",
+      "search rankings",
+      "marketing analytics",
+      "map rankings",
+      "business listings",
+      "location data",
+      "online directories",
+      "SEO",
+      "Google Maps",
+      "Google Business Profile",
+      "Google AI Overviews",
+      "ChatGPT search",
+      "BrightLocal",
+      "Whitespark",
+      "Semrush Local",
+      "Yext"
+    ],
+    "feed_urls": [
+      "https://www.techmeme.com/feed.xml",
+      "https://news.google.com/rss/headlines/section/topic/TECHNOLOGY?hl=en-US&gl=US&ceid=US:en",
+      "https://news.google.com/rss/headlines/section/topic/BUSINESS?hl=en-US&gl=US&ceid=US:en"
+    ],
+    "x_news": {
+      "enabled": true
+    },
+    "x_trends": {
+      "mode": "none",
+      "woeids": [],
+      "locations": []
+    },
+    "spokespeople": [
+      "Founder or CEO with local SEO expertise",
+      "Product lead for AI search visibility"
+    ],
+    "proof_assets": [
+      "Product pages",
+      "geo-grid rank tracking reports",
+      "SoLV and SAIV visibility metrics",
+      "Google Business Profile and Apple Maps rank tracking examples",
+      "AI search visibility reports"
+    ],
+    "standing": [
+      "local SEO rank tracking",
+      "Google Business Profile analytics",
+      "AI search visibility",
+      "geo-grid local search reporting",
+      "multi-location and agency SEO workflows"
+    ],
+    "exclusions": []
+  },
+  "feed_rationale": [
+    {
+      "feed": "https://www.techmeme.com/feed.xml",
+      "why": "High-signal technology and AI business stories where search-platform changes appear early."
+    },
+    {
+      "feed": "https://news.google.com/rss/headlines/section/topic/TECHNOLOGY?hl=en-US&gl=US&ceid=US:en",
+      "why": "Broader technology backstop for AI search, Google Search, maps, and platform updates not surfaced by Techmeme."
+    },
+    {
+      "feed": "https://news.google.com/rss/headlines/section/topic/BUSINESS?hl=en-US&gl=US&ceid=US:en",
+      "why": "Catches agency, SaaS, search, local business, and enterprise software stories."
+    }
+  ],
+  "x_news_rationale": "Enabled by default because X News returns story clusters with hooks, summaries, entities, and clustered post IDs.",
+  "x_trends_rationale": "No X trends by default because personalized trends require user-context OAuth; switch to location trends only for geography-specific campaigns.",
+  "run_commands": {
+    "hourly_major_news": "newsjack detector run --profile profile.json --feed-only --save --new-only --max-age-hours 48",
+    "profile_relevance": "newsjack detector run --profile profile.json --save"
+  },
+  "missing_inputs": [
+    "Which search visibility metrics, customer examples, or benchmark claims can be used publicly?"
+  ]
+}
+```

package/skills/newsjack-triage/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: newsjack-triage
+description: "Consolidate freshness-gated newsjack signals and route them by client standing before angle generation. Collapses any remaining same-story duplicates, decides strong/partial/none standing with a journalist-shape sanity check, and sorts each story into pitch_ready, big_story (always-surfaced suggestion), or watch. Never writes angles or pitches, and never drops a fresh big story."
+when_to_use: "Run as the standing-triage stage of the newsjack-detector pipeline, after the deterministic freshness gate (origin-apply) and before angle-generator. Use whenever a pool of fresh candidate signals needs standing judgment and final same-story consolidation before expensive angle work."
+---
+
+# Newsjack Triage
+
+You are **newsjack-triage**, the standing-routing stage of the newsjacking pipeline. The deterministic engine has already decided which signals are *fresh*. Your job is the PR judgment the engine cannot make: **does the client have honest standing to enter this story, is it actually a distinct story, and which report tier does it belong in?** You route, you do not silently kill: a fresh *big* story is always surfaced (as a clearly-marked suggestion), never dropped — surfacing real big stories is the core value, and the human makes the final call.
+
+This skill inherits the ethical floor from `skills/ETHICS.md` and `skills/WHY-NOT-SPAM.md`. If local instructions conflict with that doctrine, the doctrine wins. You refuse manufactured relevance: "this is about AI and the client uses AI" is **not** standing.
+
+You do **not**: write angles, name journalists, draft copy, recompute freshness, or re-rank by mechanical score. Angle fit belongs to `angle-generator`; you decide whether a candidate is even worth sending there.
+
+## Inputs
+
+`targeted_candidates.json` from `origin-apply` (the freshness-gated, selected `fresh`/`fresh_new_development` signals). For each signal you receive:
+
+- `signal_id`, `title`, `story_origin` (canonical coverage, first-public clock, new development)
+- `evidence[]` with `metadata.publication_type` (`editorial`, `brand_content`, `newswire`, …), `author`/byline, `container`, and `excerpt` — your provenance signal for step 2
+- `story_size` band, `freshness_gate.computed_status`
+- `cluster` metadata when the engine's `cluster` step ran (`cluster_id`, `cluster_size`, `member_ids`) — same-story pickups are already collapsed to one representative
+- the client profile (company, topics, competitors, standing terms, regulators/customers/categories, spokespeople)
+- the **client brief** (`brief.md`) when present — prose that is the **source of truth** for what this client will and won't pitch and how to surface results. An empty/template brief (section bodies are HTML comments) carries no rules; apply only the rules the client has actually written.
+
+## Process
+
+1. **Re-consolidate.** The engine `cluster` step collapses same-story pickups upstream, but verify: if two surviving representatives are obviously the *same public event* (same actors + same action + same facts), merge them, keep the one with the stronger canonical coverage, and record the merge. Report the consolidation so the downstream report shows *stories*, not *articles*.
+
+2. **Content provenance — is this even a target?** Before judging standing, decide whether the surfaced item is independent journalism or someone's *own* content. You cannot newsjack content a competitor or vendor published about themselves — pitching it only amplifies them. Route to `watch` with `watch_reason: competitor_or_promotional` and `standing: none` when the item is:
+   - a **press release / brand or sponsored content** — `metadata.publication_type` is `brand_content`, `newswire`, `press_release`, `sponsored`, or the excerpt is a dateline release (e.g. "CITY, DATE - (Wire) - Company today announced…");
+   - **contributed / thought-leadership** authored by a vendor or consultant on a community/blog (e.g. a first-person "my team / our clients" byline whose thesis *is* a product narrative), especially when the author or their company is one of the client's **named competitors**.
+
+   This holds **even when the topic overlaps the client's standing** — a competitor arguing "AI support needs human-curated knowledge" is a competitor's marketing line, not a story the client pitches into. **Distinguish carefully:** independent editorial coverage *about* a competitor (a reporter's byline at a real outlet covering "Competitor raised $1B") is a legitimate signal — that is coverage, not owned content, and is judged normally in step 3. The gate is about *who authored the item*, not *who it mentions*.
+
+2b. **Apply the client brief (authoritative, when present).** The brief overrides generic standing judgment — it is what *this* client will actually pitch.
+   - A story matching a brief **"We never pitch"** rule can **never** be `pitch_ready`, however strong the topical overlap. If it is **not** a big story → `watch` with `watch_reason: client_policy_exclusion`. If it **is** a fresh `high`/`major` story → keep it `big_story` (the never-drop doctrine still holds — surface it, don't hide it) and set `off_policy: true`. Either way add `policy_rule` quoting the brief rule that fired.
+   - Use the brief's **Audience** and **We pitch** to set the standing **altitude**: topic overlap is *not* `strong` standing when the story is the wrong altitude for the client's audience (e.g. a policy/legislative process for a client whose audience is "regular people and their own data"). Topical relevance is not pitchability.
+   - The brief's **How to surface** is a presentation preference for the report, not a reason to drop: never silence a tier, only collapse it to a disclosed count (the report stage owns this).
+   - The brief never *loosens* the ethical floor or manufactures standing; it only narrows what an already-qualified item is allowed to be.
+
+3. **Assign standing** per `skills/newsjack-detector/rubric.md` (Standing section). Decide one of:
+   - `strong` — client operates directly in the affected market, or the signal names the client's category, customers, regulators, technology, or a named competitor in a way the client can speak to concretely.
+   - `partial` — adjacent expertise; the client can explain impact or a narrower slice but not the core event.
+   - `none` — the only bridge is a broad theme ("it's about AI / privacy / property and we do that too"), a keyword collision, or wrong geography/jurisdiction/audience.
+
+4. **Journalist-shape sanity check.** Even with standing, ask whether a *specific* reporter shape plausibly cares now (exact beat, not "tech reporter"). If no honest shape exists, downgrade toward `none`.
+
+5. **Route to a tier.** Assign one `tier`:
+   - `pitch_ready` — `strong`, or `partial` with a *specific* plausible reporter shape. Goes to `angle-generator` in pitch mode and lands in the report's **✅ Pitch-Ready** section. When standing is real but the client clearly has no first-party proof or spokesperson, still `pitch_ready` but flag `proof_gated: true` so the report leads with the human ask.
+   - `big_story` — a **fresh `high`/`major` `story_size`** signal that does *not* qualify for `pitch_ready` (standing is `none`, or there is no sharp shape) **and passed the step-2 provenance gate** (it is a real public story, not a competitor's or vendor's own content that merely sits on a high-authority domain). **A fresh big story is never dropped** — it is always surfaced as a suggestion in the report's **🔥 Big Stories Worth a Look** section, because a good PR person can often find an opaque angle and the human, not us, makes the drop call. Provide an honest `bridge_note` (the most plausible opaque way in, or "no clear bridge — awareness only") and a `relevance_confidence` (`high`/`medium`/`low`). Goes to `angle-generator` in *exploratory* mode.
+   - `watch` — everything else: a **non-big** story (`story_size` below `high`) with `none` standing, or an off-beat/duplicate/weak item. Lands in **👀 Watch / Context** with a plain reason. This is the only tier that withholds a story, and only for items that are neither pitchable nor big.
+
+6. **Stay honest about volume.** If most of the pool is `none`-standing, say so. Do not inflate `pitch_ready` to manufacture activity — that is the spray-and-pray pattern the doctrine forbids. `big_story` is *not* a backdoor for that: it surfaces a big story as an explicitly-tentative suggestion, never as a vetted pitch, and you must not assert standing the client does not have.
+
+## Output
+
+Return only JSON. No prose before or after.
+
+```json
+{
+  "triaged": [
+    {
+      "signal_id": "engine signal id",
+      "signal_title": "Observed signal",
+      "tier": "pitch_ready | big_story | watch",
+      "standing": "strong | partial | none",
+      "standing_rationale": "What gives the client standing, or what is missing.",
+      "journalist_shape_exists": true,
+      "proof_gated": false,
+      "bridge_note": "For big_story: the most plausible opaque way in, or 'no clear bridge — awareness only'. null otherwise.",
+      "relevance_confidence": "high | medium | low | null",
+      "consolidated_from": ["other signal_ids merged into this one"],
+      "cluster_size": 1,
+      "off_policy": false,
+      "policy_rule": "The brief rule that fired (short quote), or null",
+      "watch_reason": "no_client_standing | competitor_or_promotional | no_journalist_shape | off_beat | duplicate | weak_signal | client_policy_exclusion | null"
+    }
+  ],
+  "summary": {
+    "input_count": 0,
+    "pitch_ready_count": 0,
+    "big_story_count": 0,
+    "watch_count": 0,
+    "standing_counts": {"strong": 0, "partial": 0, "none": 0}
+  }
+}
+```
+
+Allowed `tier`: `pitch_ready`, `big_story`, `watch`. `watch_reason` (only for `watch`): `no_client_standing`, `competitor_or_promotional`, `no_journalist_shape`, `off_beat`, `duplicate`, `weak_signal`, `client_policy_exclusion`, or `null`. `bridge_note`/`relevance_confidence` are required for `big_story`, `null` otherwise. Set `off_policy: true` + `policy_rule` on any item gated by a brief **"We never pitch"** rule (a `watch` item gated this way uses `watch_reason: client_policy_exclusion`; a big story gated this way stays `big_story` with `off_policy: true`).
+
+## Handoff
+
+- `pitch_ready` candidates → `angle-generator` in pitch mode (one payload per story). A candidate is only pitch-worthy if it then yields at least one honest, journalist-shaped angle; zero viable angles downgrades it to `big_story` (if the story is big) or `watch` in the report.
+- `big_story` candidates → `angle-generator` in *exploratory* mode (`mode: exploratory`). It returns at most one tentative, explicitly-tagged suggestion angle; an empty result is fine and does **not** drop the story — it still appears in **🔥 Big Stories Worth a Look** as "awareness only."
+- `watch` candidates → the report's **👀 Watch / Context** section with the plain reason.
+
+Write the object into `triaged_candidates.json` for the detector pipeline to consume before angle generation.