sondar

name	sondar
description	Use whenever the user asks to monitor AI builder signals, GitHub AI projects, model/app launch opportunities, hot keywords, PMF signals, commercial trend detection, or daily AI radar workflows. Sondar converts early signals into STRIKE/WATCH/IGNORE/KILL decisions with evidence, owner, deadline, metric, and commercial closure; use it instead of producing generic trend summaries.

Sondar

Purpose

Sondar converts early multi-source AI Builder demand signals into accountable commercial decisions. This skill is not a news digest, repo ranking, or keyword tracker. It is a signal-to-action system for deciding whether to act now, watch with an expiry, ignore, or kill.

Core rule:

No signal enters unless it can leave.

Every signal must end as one of:

STRIKE
WATCH
IGNORE
KILL

Trigger Contexts

Use this skill when the user asks for any of the following:

• AI Builder radar, GitHub radar, AI trend monitoring, or hot signal detection
• H2 model launch and AI app launch opportunity analysis
• early PMF signals from GitHub repos, issues, forks, releases, or commits
• commercial action from keywords, repos, model changelogs, or builder behavior
• daily or weekly scheduled signal review
• avoiding information noise in trend reports

Operating Model

Run this state machine:

INGESTED -> EVIDENCE_BUILT -> SCORED -> TRIAGED -> ACTIONED -> CLOSED

Terminal decisions:

STRIKE | WATCH | IGNORE | KILL

Daily scheduled runs must use persistent state. The default state layer is SQLite:

.sondar/state.sqlite

State is required to detect deltas, not just static popularity:

star_delta
fork_delta
issue_pain_delta
release_delta
readme_commercial_diff
builder_repeat_behavior
builder_starred_at
external_tanso_corroboration
WATCH upgrades and expiry
missed-signal audit trail

The minimum executable loop is:

./bin/sondar daily \
  --config config/watchlist.yml \
  --db .sondar/state.sqlite \
  --out-dir .sondar

It outputs:

.sondar/data/signals/YYYY-MM-DD.jsonl
.sondar/reports/YYYY-MM-DD.md

Allowed transitions:

• INGESTED -> EVIDENCE_BUILT: capture source, timestamp, actor, artifact, and evidence.
• EVIDENCE_BUILT -> SCORED: score with the five required dimensions.
• SCORED -> TRIAGED: assign STRIKE, WATCH, IGNORE, or KILL.
• TRIAGED -> ACTIONED: attach owner, deadline, metric, and next action.
• ACTIONED -> CLOSED: record outcome and scoring update.

Special transitions:

• WATCH -> STRIKE: only through the explicit upgrade_trigger.
• WATCH -> KILL: expiry reached or disconfirming evidence appears.
• STRIKE -> KILL: action fails, evidence is invalidated, legal risk appears, or the market is already saturated.

Evidence Sources

Prioritize behavior over attention.

High-value sources:

• GitHub issues, discussions, pull requests, releases, README diffs, commits, forks
• package registry spikes from npm, PyPI, Docker, Homebrew, or similar registries
• model provider changelogs, API docs, pricing pages, SDK changes
• Hugging Face model cards, dataset updates, Spaces, and commit activity
• Hacker News, X replies, YouTube comments, Discord excerpts, job posts, launch pages

Sources are peer-level at ingestion, but evidence is ranked by type and strength. GitHub is no longer privileged by policy; it is one adapter that often produces strong behavior evidence. For every STRIKE and every serious WATCH, check independent corroboration surfaces.

Use gh as the default GitHub retrieval layer. Use tanso bocha and tanso zhihu to corroborate non-GitHub demand translation, especially when a foreign AI Builder signal starts appearing in Chinese developer discussions.

Topics and trending pages are discovery layers only. They can create INGESTED candidates; they cannot justify STRIKE without behavior evidence and buyer pain.

Scoring

Score each candidate 0-3:

novelty
adoption_velocity
commercial_relevance
evidence_quality
urgency

Decision gates:

STRIKE = total >= 11 AND commercial_relevance >= 2 AND evidence_quality >= 2 AND action possible within 48h
WATCH  = total 7-10 OR missing one key proof point
IGNORE = total < 7 OR weak commercial path OR generic hype
KILL   = duplicate, stale, unverifiable, pure punditry, legally risky, reputation risky, already saturated, or strategically wasteful

If scoring conflicts with judgment, state the conflict in rationale and choose the decision that best protects commercial focus.

Required Output Contract

For each signal, output:

{
  "signal_id": "sig-YYYYMMDD-001",
  "captured_at": "YYYY-MM-DDTHH:MM:SSZ",
  "sources": ["https://example.com/source"],
  "entities": ["repo-or-company-or-model"],
  "keywords": ["keyword"],
  "summary": "One sentence describing the signal.",
  "evidence": [
    {
      "claim": "Specific claim supported by the source.",
      "source": "https://example.com/source",
      "confidence": 0.8
    }
  ],
  "scores": {
    "novelty": 0,
     
     
     
     
  
   
   
   
   
   
   
   
     
     
     
  
   

Human Delivery Contract

Human-facing delivery is a decision explanation, not a raw field dump.

For every primary STRIKE and WATCH, answer:

1. What is it?
2. What changed in the active window?
3. Which sourced claims form the evidence chain?
4. Which evidence supports each score?
5. Why did the decision gates produce this result?
6. Which missing or negative evidence would upgrade, downgrade, or falsify it?

Show every evidence claim together with its source. Make score reasoning traceable to evidence, and state missing proof explicitly. Aggregate IGNORE, KILL, and queue-overflow reasons in the human report; keep their complete records in JSONL and SQLite.

Do not confuse completeness with length. A long list of links, raw scoring features, or repeated closed signals is noise unless it makes the decision reproducible.

Decision Rules

🔴 CHECKPOINT · Before STRIKE Execution

Before executing any STRIKE, stop and verify:

• The evidence has primary behavior, buyer/deployment context, independent corroboration, and a clear provenance chain, or the rationale explicitly accepts the missing corroboration risk.
• The action can ship within 48 hours.
• The owner is named.
• The success metric is observable within 7 days.
• Legal, trademark, platform-policy, and reputation risks have been checked.

If any item fails, downgrade the signal to WATCH or KILL.

STRIKE

Use STRIKE only when a 48-hour commercial action exists.

Valid STRIKE actions:

• landing page with CTA
• outbound list and message
• demo or prototype
• paid research brief
• integration spike
• customer interview campaign
• content asset with CTA
• partner or customer pitch
• benchmark
• Chinese repo, template, or workflow guide

Valid metrics:

• 5 qualified replies
• 3 demo bookings
• 1 paid pilot ask
• 20 waitlist signups
• 20 stars from target users
• integration works against live API

WATCH

Use WATCH when the signal is plausible but missing one key proof point.

WATCH must include:

• upgrade_trigger
• expiry_at
• next_review_at

Default expiry is 7 days. If the trigger does not fire by expiry, convert to KILL.

IGNORE

Use IGNORE for low-value or insufficient-fit signals.

Required reason categories:

• duplicate
• low novelty
• no buyer
• no evidence
• stale
• irrelevant
• generic hype

KILL

Use KILL for signals that should not return without new evidence.

Required reason categories:

• false
• strategically harmful
• legally risky
• reputation risky
• commercially dead
• already captured by competitor
• spam or fake traction

Daily Workflow

Morning:

1. Load thesis-driven watchlist config.
2. Ingest the last 24 hours of candidate signals.
3. Snapshot repo, builder, issue, release, README, and external evidence state.
4. Diff against previous snapshots.
5. Build evidence bundles.
6. Score each candidate.
7. Output at most one STRIKE.
8. Output at most three WATCH items.
9. List clear IGNORE and KILL decisions.

Midday:

1. Execute every STRIKE action.
2. Create the commercial artifact.
3. Record owner, deadline, metric, and distribution channel.

End of day:

1. Update closure_update.
2. Promote triggered WATCH items to STRIKE.
3. Expire or kill stale WATCH items.
4. Record false positives and missed clues.

It is acceptable to output No STRIKE today. Do not manufacture action to make a report look productive.

Weekly Workflow

1. Review all STRIKE outcomes.
2. Review all expired WATCH items.
3. Run a missed-launch audit: sample real model/app launches from the week, trace the earliest observable signal, and compare against the system's detection.
4. Keep only sources, keywords, and scoring rules that produced commercial movement or improved judgment.
5. Update scoring notes.

Red-Team Safeguards

• Do not overfit to GitHub. Check at least two non-GitHub corroboration surfaces for serious signals.
• Maintain an outlier bucket with at most three low-confidence, high-upside anomalies.
• Add negative evidence for fake stars, copied code, no maintainer history, no docs, no pricing path, and no buyer mapping.
• Measure downstream commercial options, not workflow completion.
• Audit misses weekly so ignored signals can teach the system.

Blacklist

Do not output:

• generic trend summaries
• top repo lists without a decision
• keyword lists without evidence
• interesting buckets
• deferred action without expiry
• WATCH without upgrade trigger
• STRIKE without owner, deadline, metric, and 48-hour action
• source collection without deletion
• LLM-only confidence without evidence

Reference Loading

Read references/scoring.md when scoring a real signal batch. Read references/examples.md when unsure how to classify a signal. Use templates/sondar-action-brief.md for any STRIKE. Use schemas/signal.schema.json when generating machine-checkable records.