# Sondar > 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. - Skill: `geekjourneyx/sondar` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add geekjourneyx/sondar` - Raw SKILL.md: https://api.skillmd.com/api/skills/geekjourneyx/sondar/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: geekjourneyx (https://skillmd.com/u/geekjourneyx) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/geekjourneyx/sondar --- # 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: ```text 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: ```text INGESTED -> EVIDENCE_BUILT -> SCORED -> TRIAGED -> ACTIONED -> CLOSED ``` Terminal decisions: ```text STRIKE | WATCH | IGNORE | KILL ``` Daily scheduled runs must use persistent state. The default state layer is SQLite: ```text .sondar/state.sqlite ``` State is required to detect deltas, not just static popularity: ```text 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: ```bash ./bin/sondar daily \ --config config/watchlist.yml \ --db .sondar/state.sqlite \ --out-dir .sondar ``` It outputs: ```text .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`: ```text novelty adoption_velocity commercial_relevance evidence_quality urgency ``` Decision gates: ```text 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: ```json { "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, "adoption_velocity": 0, "commercial_relevance": 0, "evidence_quality": 0, "urgency": 0 }, "decision": "STRIKE|WATCH|IGNORE|KILL", "rationale": "Why this decision is correct.", "owner": "person-or-agent", "deadline": "YYYY-MM-DDTHH:MM:SSZ", "metric": "Observable success or failure metric.", "next_action": "Concrete next action.", "watch": { "upgrade_trigger": "Only required for WATCH.", "expiry_at": "Only required for WATCH.", "next_review_at": "Only required for WATCH." }, "closure_update": "open" } ``` ## 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.