newsjack 0.1.5

package/skills/reactive-comment/examples.md

@@ -0,0 +1,284 @@
+# Reactive Comment - Worked Examples
+
+Four realistic examples showing the expected shape: input query and profile
+before, YAML verdict after. These are not templates to blast. They show
+what the gate should accept, kill, or pause.
+
+---
+
+## Example 1: Clean Fit, Draft
+
+### Before
+
+```yaml
+profile:
+  name: "Jane Doe"
+  title: "Co-founder & CTO"
+  company: "Acme Security"
+  expertise_areas:
+    - "application security for SaaS startups"
+    - "secrets management in CI/CD"
+  do_not_comment_on:
+    - "cryptocurrency"
+    - "criminal cases"
+    - "competitor product comparisons"
+  proof_points:
+    - claim: "BlackHat 2024 talk on CI/CD secret leakage"
+      verifiable_at: "https://blackhat.com/us-24/briefings/schedule/#leak"
+    - claim: "10 years building auth systems at Stripe and Okta"
+      verifiable_at: "https://linkedin.com/in/janedoe"
+  contact_block: |
+    Jane Doe, Co-founder & CTO, Acme Security
+    jane@acme.security
+    linkedin.com/in/janedoe
+  response_cap_per_week: 5
+query:
+  source: "SourceOfSources"
+  journalist_name: "Alex Rivera"
+  journalist_outlet: "TechCrunch"
+  query_text: "Looking for CTOs at Series A-B SaaS startups: has Copilot/Cursor changed how secrets leak into your repos? Real anecdotes welcome. No vendor pitches. Deadline EOD Friday."
+  deadline_iso: "2026-05-22T23:59:00-07:00"
+  received_at_iso: "2026-05-20T08:14:00-07:00"
+recent_context:
+  journalist_bylines:
+    - title: "GitHub Copilot's hidden cost: a year of leaked tokens"
+      url: "https://techcrunch.com/2026/03/14/copilot-leak-year"
+      published_iso: "2026-03-14"
+internal_state:
+  responses_to_this_source_this_week: 2
+```
+
+### After
+
+```yaml
+verdict: draft
+fit_score: 84
+fit_reasoning: |
+  Direct fit on CI/CD secrets and SaaS application security. The query asks
+  for CTOs discussing Copilot/Cursor secret leakage, and the profile has a
+  BlackHat proof point on CI/CD secret leakage plus auth tenure at Stripe
+  and Okta. The journalist's recent byline is on leaked tokens. "No vendor
+  pitches" is compatible because the response offers an operator anecdote,
+  not a product pitch.
+decay_flags:
+  hours_until_deadline: 56
+  is_fresh: true
+  warning: null
+draft_response:
+  subject: "Re: AI-code secret leakage, CTO at Acme Security"
+  body: |
+    Hi Alex,
+
+    Your March piece on Copilot's leaked-token year matches what we saw from the founder side at Acme. After we instrumented Cursor and Copilot against our repos earlier this year, AI-suggested code raised our secret-leak rate roughly 3x before we put server-side scanning in front of every push. The pattern worth flagging is autocompletion of `.env.example` files with real values, not malice, just muscle memory. Happy to go on record: 10 years building auth at Stripe and Okta before Acme, plus the CI/CD secrets talk at BlackHat 2024.
+
+    Jane Doe, Co-founder & CTO, Acme Security
+    jane@acme.security
+    linkedin.com/in/janedoe
+provenance:
+  - claim: "BlackHat 2024 CI/CD secret leakage talk"
+    sourced_from: "profile.proof_points[0]"
+  - claim: "10 years building auth at Stripe and Okta"
+    sourced_from: "profile.proof_points[1]"
+  - claim: "TechCrunch byline on Copilot leaked tokens"
+    sourced_from: "recent_context.journalist_bylines[0]"
+  - claim: "Acme instrumented Cursor and Copilot, roughly 3x secret-leak rate"
+    sourced_from: "USER MUST CONFIRM"
+slop_check:
+  banned_words_found: []
+  emdash_count: 0
+  placeholders_found: []
+  ai_tells_found: []
+  passed: true
+anti_spray:
+  responses_to_this_source_this_week: 2
+  cap: 5
+  passed: true
+next_action: |
+  Confirm the Cursor/Copilot instrumentation and 3x figure before sending.
+  If the number is directional, change it to "noticeably raised." Send
+  manually from your mail client. Do not auto-send.
+```
+
+---
+
+## Example 2: Adjacent Topic, Hard Kill
+
+### Before
+
+```yaml
+profile:
+  name: "Jane Doe"
+  title: "Co-founder & CTO"
+  company: "Acme Security"
+  expertise_areas:
+    - "application security for SaaS startups"
+    - "SOC 2 Type 2 readiness for sub-100-headcount teams"
+  do_not_comment_on:
+    - "cryptocurrency"
+    - "competitor product comparisons"
+  proof_points:
+    - claim: "Led SOC 2 Type 2 readiness at Acme Security"
+      verifiable_at: "https://acme.security/security"
+  contact_block: |
+    Jane Doe, Co-founder & CTO, Acme Security
+    jane@acme.security
+query:
+  source: "Featured"
+  journalist_name: "Sam Lin"
+  journalist_outlet: "CoinDesk"
+  query_text: "How are SaaS CTOs thinking about on-chain authentication for B2B SSO? Looking for comments on wallet-based identity and enterprise readiness."
+  deadline_iso: "2026-05-23T17:00:00-07:00"
+internal_state:
+  responses_to_this_source_this_week: 1
+```
+
+### After
+
+```yaml
+verdict: kill
+fit_score: 0
+kill_reason: |
+  The query is about on-chain authentication and wallet-based identity.
+  Your profile's `do_not_comment_on` includes cryptocurrency. The SaaS SSO
+  angle is adjacent, but the requested comment would land inside crypto
+  coverage at CoinDesk. Hard veto.
+why_not_your_fight: |
+  You will be tempted because "SSO" is close to your work. The actual piece
+  is about wallet-based identity. Anything useful you say will be excerpted
+  into a crypto-auth story, and then you will spend time clarifying a
+  position your profile already told us not to take. Skip it.
+suggested_alternative: |
+  If this topic matters to you, publish your own post on why wallet-based
+  SSO is not ready for mainstream SaaS. That gives future reporters a clean
+  reason to come to you without violating the profile.
+decay_flags:
+  hours_until_deadline: 72
+  is_fresh: true
+  warning: null
+anti_spray:
+  responses_to_this_source_this_week: 1
+  cap: 5
+  passed: true
+```
+
+---
+
+## Example 3: Missing Proof, Ask
+
+### Before
+
+```yaml
+profile:
+  name: "Maya Patel"
+  title: "VP Engineering"
+  company: "Northstar Data"
+  expertise_areas:
+    - "data platform reliability"
+    - "incident response for enterprise analytics teams"
+  do_not_comment_on:
+    - "layoffs"
+    - "criminal cases"
+  proof_points:
+    - claim: "Built Northstar's incident review process after a 2024 warehouse outage"
+      verifiable_at: "https://northstar.example.com/engineering/outage-review"
+  contact_block: |
+    Maya Patel, VP Engineering, Northstar Data
+    maya@northstar.example.com
+query:
+  source: "Qwoted"
+  journalist_name: "Priya Mehta"
+  journalist_outlet: "InformationWeek"
+  query_text: "Looking for CISOs at companies with 500-5,000 employees to discuss how AI governance policies are being structured. Need examples of internal policy language and ownership."
+  deadline_iso: "2026-05-21T18:00:00-07:00"
+recent_context: null
+internal_state:
+  responses_to_this_source_this_week: 0
+```
+
+### After
+
+```yaml
+verdict: ask
+missing_info:
+  - "The query asks for CISOs. Profile says VP Engineering. Are you the accountable security-policy owner, or is this outside your title scope?"
+  - "The query requires companies with 500-5,000 employees. What is Northstar's current headcount?"
+  - "The query asks for internal AI governance policy language. Add a proof point or paste approved policy language that can be quoted."
+  - "Recent context is missing. Paste 1-2 recent Priya Mehta bylines or rerun with browse enabled."
+why_we_paused: |
+  Drafting now would guess title scope, company size, policy ownership, and
+  journalist context. Any one of those could make this a clean kill.
+decay_flags:
+  hours_until_deadline: 30
+  is_fresh: true
+  warning: null
+anti_spray:
+  responses_to_this_source_this_week: 0
+  cap: 5
+  passed: true
+```
+
+---
+
+## Example 4: Strong Fit, Cap Refusal
+
+### Before
+
+```yaml
+profile:
+  name: "Owen Chen"
+  title: "Founder"
+  company: "Ledgerfield"
+  expertise_areas:
+    - "restaurant payroll compliance"
+    - "tip-credit law for multi-state hospitality groups"
+  do_not_comment_on:
+    - "immigration enforcement"
+  proof_points:
+    - claim: "Testified to the California Senate Labor Committee on tip-credit compliance in 2025"
+      verifiable_at: "https://senate.ca.gov/archive/tip-credit-hearing-2025"
+  contact_block: |
+    Owen Chen, Founder, Ledgerfield
+    owen@ledgerfield.example.com
+  response_cap_per_week: 5
+query:
+  source: "HelpAB2BWriter"
+  journalist_name: "Dana Ortiz"
+  journalist_outlet: "Restaurant Business"
+  query_text: "Need payroll operators who can explain the practical impact of the new state tip-credit rules for restaurant groups operating in 3+ states. Deadline tomorrow noon ET."
+  deadline_iso: "2026-05-20T12:00:00-04:00"
+recent_context:
+  journalist_bylines:
+    - title: "Restaurant chains brace for state wage-law divergence"
+      url: "https://restaurantbusiness.example.com/labor/state-wage-law-divergence"
+      published_iso: "2026-05-01"
+internal_state:
+  responses_to_this_source_this_week: 5
+```
+
+### After
+
+```yaml
+verdict: kill
+fit_score: 78
+kill_reason: |
+  Topic fit is real: restaurant payroll compliance, multi-state tip-credit
+  rules, and a recent journalist byline on state wage-law divergence. Cap
+  is the blocker. You have already drafted 5 Help A B2B Writer responses
+  this rolling week.
+why_not_your_fight: |
+  This is exactly why the cap exists. A good-fit sixth response still makes
+  the account look like it is spraying. If this is better than one of the
+  five already drafted, retire one of those first. Otherwise hold it.
+suggested_alternative: |
+  Turn the point into a short owned post on how multi-state restaurant
+  groups should audit tip-credit exposure. It can support the next query
+  without spending another source-platform slot.
+decay_flags:
+  hours_until_deadline: 20
+  is_fresh: true
+  warning: "Less than 24 hours until deadline."
+anti_spray:
+  responses_to_this_source_this_week: 5
+  cap: 5
+  passed: false
+```

package/skills/reactive-comment/rubric.md

@@ -0,0 +1,280 @@
+# Reactive Comment Rubric
+
+Every query gets one score and then runs through the refusal gates. The
+score decides whether drafting is even eligible. The gates decide whether a
+draft is allowed to leave the model.
+
+Trace: all criteria are compressed from the source design's sections on
+Topic fit, Anti-spray rubric, Anti-hallucination rubric, Decay rubric,
+Banned-word list, Em-dash check, Sentence-shape blocks, Placeholder tells,
+and the three output modes.
+
+## Score Bands
+
+| Fit score | Verdict |
+|-----------|---------|
+| 85-100 | `draft`, if every gate passes |
+| 65-84 | `draft`, if every gate passes and any weak spots are named |
+| 40-64 | `kill`, unless one missing fact could push the score over 65, then `ask` |
+| 0-39 | `kill` |
+
+Drafting requires **65+ and clean gates**. A high score never overrides a
+hard veto.
+
+## Weighted Fit Score
+
+### 1. Specific Expertise Match - 40 Points
+
+> Does the query's exact ask intersect the profile's exact expertise?
+
+- **0 points:** No real intersection, only broad adjacency.
+- **10 points:** Same general industry, wrong problem.
+- **20 points:** Same problem family, but the query asks for a narrower
+  experience the profile does not show.
+- **30 points:** Strong topical fit, with one missing scope detail such as
+  company stage, geography, title, or customer type.
+- **40 points:** Direct fit. The query asks for something the profile
+  explicitly names.
+
+Red flags:
+
+- "software" treated as expertise
+- "founder" treated as permission to comment on every business topic
+- query asks for a title the user does not hold
+- query asks for first-hand experience and the profile only supports
+  analysis
+
+### 2. Proof-Point Support - 25 Points
+
+> Can the response make a substantive claim backed by the profile?
+
+- **0 points:** No proof point backs the answer.
+- **8 points:** A proof point exists, but only supports a generic bio line.
+- **16 points:** A proof point supports the topic, but not the specific
+  angle the query requests.
+- **25 points:** At least one proof point directly backs the claim the
+  draft would make.
+
+For `draft`, 100% of concrete claims need provenance. Allowed sources:
+
+- `profile.proof_points[i]`
+- `recent_context.journalist_bylines[i]`
+- `"USER MUST CONFIRM"`
+
+No general-knowledge claims. No invented stats. No fabricated expert
+credentials.
+
+### 3. Do-Not-Comment and Identity Fit - 15 Points
+
+> Is the query inside the user's declared lane?
+
+- **0 points:** The query touches `profile.do_not_comment_on`, asks for a
+  credential or title not in profile, or would force a competitor/product
+  comparison the profile forbids. This is a hard veto.
+- **8 points:** The query is adjacent to a do-not topic but can be answered
+  cleanly without entering it.
+- **15 points:** No conflict with do-not topics, title, employer, stage, or
+  identity.
+
+Hard-veto examples:
+
+- profile says no cryptocurrency; query asks for on-chain auth
+- profile says no competitor comparisons; query asks Cursor vs. Copilot
+- query asks for CISOs; profile only shows CTO
+- query asks for Series A-B; profile has no funding-stage proof
+
+### 4. Journalist Context and Real Personalization - 10 Points
+
+> Is there a real anchor to the journalist's beat?
+
+- **0 points:** The draft would need to fake familiarity with the
+  journalist's work.
+- **5 points:** Recent context is unavailable; neutral score. Open with the
+  user's credential instead of pretending.
+- **7 points:** Recent context shows the journalist covers the broad beat.
+- **10 points:** A recent byline or post matches the query's topic and can
+  be referenced specifically by URL, title, or topic.
+
+Never praise generically. "Saw your recent piece" requires a supplied
+recent-context title or URL.
+
+### 5. Outlet, Source, and Requirement Hygiene - 10 Points
+
+> Does the response respect the outlet, source platform, and query terms?
+
+- **0 points:** Outlet matches `profile.outlets_to_skip`, the query says
+  "no vendors" and the only angle is vendor-coded, or a source-platform
+  rule blocks the response. Outlet skip is a hard veto.
+- **4 points:** The outlet is acceptable, but the draft would brush against
+  a requirement or source-platform norm.
+- **7 points:** Requirements are mostly satisfied, with one minor caveat
+  that should be stamped.
+- **10 points:** Outlet passes filters, query requirements are met, and the
+  response is visibly human-reviewed rather than automated spray.
+
+Examples:
+
+- "No vendor pitches" means no product pitch.
+- "Real anecdotes only" means analysis is not enough.
+- "Academics only" means operators do not qualify.
+- Featured/HARO should share one cap when the profile treats them as one
+  source family.
+
+## Hard Gates
+
+Any hard-gate failure overrides the score.
+
+### Decay Gate
+
+- `hours_until_deadline > 24`: fresh.
+- `12 < hours_until_deadline <= 24`: proceed with warning.
+- `2 < hours_until_deadline <= 12`: proceed with tight-window warning.
+- `0 <= hours_until_deadline <= 2`: `ask` unless recent context is already
+  loaded and every other gate is clean.
+- `hours_until_deadline < 0`: `kill`.
+
+If `received_at_iso` is older than 48 hours, warn that the user is late in
+the source queue.
+
+### Anti-Spray Gate
+
+Default cap: 5 responses per source per rolling week.
+
+- If `profile.response_cap_per_week` is missing, use 5.
+- If it is above 10, `ask` for justification before drafting.
+- If `responses_to_this_source_this_week >= cap`, `kill`.
+- If `responses_to_this_source_this_week >= cap * 0.8`, proceed only with a
+  warning.
+
+Always stamp:
+
+```yaml
+anti_spray:
+  responses_to_this_source_this_week: 0
+  cap: 5
+  passed: true
+```
+
+### Anti-Hallucination Gate
+
+Refuse or downgrade if any concrete claim lacks provenance.
+
+Concrete claims include:
+
+- people
+- companies
+- products
+- publications
+- employers
+- customer anecdotes
+- statistics
+- prior bylines
+- conference talks
+- funding stage
+- headcount
+- geography
+
+If the claim could be true but is not in profile or recent context, source
+it as `"USER MUST CONFIRM"` and flag it in `next_action`. If that would make
+the draft misleading, return `ask` instead.
+
+### Slop Gate
+
+Block the draft if the body contains any of these case-insensitive
+substrings:
+
+```text
+world-class
+innovative
+leading
+revolutionary
+best-in-class
+we are committed to
+cutting-edge
+synergy
+synergies
+game-changing
+thought leader
+thought leadership
+next-generation
+robust
+seamless
+leverage
+leveraging
+unparalleled
+industry-leading
+groundbreaking
+disrupting
+disruptive
+we are excited to
+thrilled to announce
+proud to announce
+transform the way
+redefining
+reimagine
+unlock
+empower
+empowering
+comprehensive solution
+end-to-end solution
+holistic
+turn-key
+turnkey
+mission-critical
+move the needle
+deliver value
+add value
+```
+
+The word `leading` can appear only as plain grammar inside supplied profile
+material, never as self-awarded praise in the draft.
+
+### AI-Tell Gate
+
+Block the draft if the body contains:
+
+- an em dash character
+- "it's not just X, it's Y"
+- "this isn't just X, it's Y"
+- "X isn't just Y. It's Z."
+- "in a world where"
+- "whether you're X or Y"
+- "not only X but also Y"
+- "at the intersection of X and Y"
+- a triple dash list
+- title case marketing phrases in the middle of a sentence
+
+### Placeholder Gate
+
+Block placeholder leakage:
+
+- `{...}`
+- `[...]` when used for fields such as company, name, title, topic, outlet,
+  date, or "your X"
+- `<<...>>`
+- `__...__`
+- `{{first_name}}` or similar mail-merge fields
+
+### Identity Gate
+
+The response comes from the user, not from the agent.
+
+Refuse if:
+
+- the draft mentions being an AI or assistant
+- the draft uses a name other than `profile.name`
+- the contact block is rewritten instead of appended verbatim
+- the bio invents a title, employer, credential, or publication
+
+## Output Gate
+
+Before returning:
+
+- exactly one YAML block
+- no surrounding prose unless requested
+- one query only
+- one verdict only
+- `anti_spray` always present
+- `slop_check` present on drafts and any slop downgrade
+- `provenance` present on drafts
+- `next_action` says manual review and manual send on drafts

package/skills/relevance-coarse-filter/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: relevance-coarse-filter
+description: "Cheap, high-recall first-pass filter that removes obvious junk from a detector candidate pool before expensive story-origin research and PR judgment. Decides keep, monitor_only, or reject — never ranks, writes angles, verifies dates, or decides whether to pitch."
+when_to_use: "Use as the coarse relevance pass of the newsjack-detector pipeline, or whenever a candidate signal pool needs cheap junk removal before expensive newsworthiness judgment. Designed to run on a low-cost model."
+---
+
+# Relevance Coarse Filter
+
+You are **relevance-coarse-filter**, the cheap first gate of a newsjacking pipeline. Your only job is to remove obvious junk before story-origin research and expensive newsworthiness judgment run on the survivors.
+
+You are deliberately **recall-biased**: false positives are cheap here, false negatives are expensive. When in doubt, keep.
+
+You do **not**: rank signals, choose best bets, write angles, run story-origin research, compute freshness or 24h cutoff status, or decide whether to pitch. Those belong to later passes (`story-origin-check`, then the detector's rubric judgment).
+
+## Inputs
+
+Evaluate **one signal at a time** against the client profile. For each signal you receive:
+
+- signal id, title, excerpt/evidence
+- source/lane and detector `profile_matches`
+- `story_size.band` when present
+- the client profile (company, topics, competitors, standing terms, regulators/customers/categories) as matching context
+
+## Decision
+
+Return exactly one decision per signal.
+
+Allowed decisions: `keep`, `monitor_only`, `reject`.
+
+Allowed reasons: `relevant_news`, `plausible_client_bridge`, `major_news_no_bridge`, `keyword_collision`, `not_news`, `owned_docs_or_product_page`, `seo_landing_page`, `competitor_or_promotional`, `low_reach_x_post`, `safety_risk`, `duplicate`, `off_beat`, `no_profile_bridge`.
+
+## Rules
+
+- Only `reject` clear junk: keyword collisions, obvious non-news, docs/product/SEO pages, evergreen content, low-reach single X posts, safety-risk hooks, or plainly off-beat items.
+- If the client, a named competitor, a profile topic, a profile standing term, a regulator/customer/category named in the profile, or a direct synonym appears anywhere in the title, excerpt, evidence, or `profile_matches` — do not reject as `no_profile_bridge`. Use `keep` or `monitor_only`.
+- A named competitor counts even when it is not the headline subject. If a story is framed around Meta, China, a regulator, an acquirer, a partner, or a blocked deal but the company affected is a profile competitor, keep it for the next stage.
+- **Never `reject` a `high` or `major` `story_size.band` signal — the ceiling is `monitor_only`, even when you see no bridge at all.** A big story is always worth surfacing: a good PR person can often find an opaque angle, and our job is to suggest and let the human decide, not to make the drop call. Use `keep` when the bridge is concrete, `monitor_only` when it is weak, absent, or a likely keyword collision. Still record the *real* reason (`keyword_collision`, `off_beat`, `no_profile_bridge`, etc.) in `reason` — the report uses it to rank and flag the suggestion (e.g. ⚠ possible keyword match). The engine enforces this deterministically (`big_story_recall`), so a `reject` here is wasted: it will be upgraded to `monitor_only` anyway.
+- For moderate-to-large stories, err toward breadth: a remote but coherent connection should survive so downstream passes can decide whether there is a real way in.
+- **Promotional / owned content** — a press release (`publication_type` `brand_content`/`newswire`, or a dateline release excerpt) or vendor-authored contributed/thought-leadership, *especially from a named competitor* — is rarely a real opportunity, because pitching a competitor's own content only amplifies them. Do not `reject` it on this basis (preserve recall and let triage make the call); mark it `monitor_only` with reason `competitor_or_promotional` so the standing-triage pass can gate it. The high/major-band ceiling rule above still wins: never `reject` a big-band signal.
+- Use `no_profile_bridge` only when you can explain that no profile entity, competitor, topic, standing term, or plausible buyer/regulator/category bridge appears in the candidate.
+- Preserve evidence URLs. Each decision cites the URLs it used.
+
+## Output
+
+Return only JSON. No prose before or after it.
+
+```json
+{
+  "signal_id": "engine signal id",
+  "decision": "keep | monitor_only | reject",
+  "reason": "allowed reason",
+  "rationale": "One short sentence explaining the filter decision.",
+  "confidence": "high | medium | low",
+  "evidence_urls": ["https://..."],
+  "relevance_basis": "Why this is plausibly relevant or why it is junk."
+}
+```
+
+## Handoff
+
+Your decision is collected into a `decisions` array and applied by `newsjack filter-apply`: `keep` and `monitor_only` survive to story-origin research; `reject` is dropped. You do not run that step.