busa-radar

Busa Radar

App UI Screenshots

Overview

Use this skill as the operator's market-intelligence desk. One Busabase-backed App-in-Skill merges three complementary functions that share a snapshot, a watchlist, and the review model:

Radar (passive monitoring): the agent periodically checks a watchlist of competitors and market sources — pricing pages, changelogs, landing pages (diffs), Product Hunt category launches, competitor app-store/G2 reviews, funding/hiring news — and files normalized signals with change highlights via scripts/ingest_signals.mjs. The operator triages each signal in the app: act / watch / ignore / needs info.
Research (active deep dives): the operator queues research questions; the agent drafts a research brief (scope, sources, expected depth) for approval, then runs deep multi-source research and files a cited report via scripts/file_report.mjs. The operator reads, annotates, rates confidence, and asks follow-ups in the app.
Trends (demand signals): keyword/topic trend movers — rising search queries, community topic volume, category interest — collected by the agent (optionally cross-read from a busa-seo snapshot) and filed via scripts/ingest_trends.mjs, turned into opportunity cards the operator approves or ignores.

Collection and research are genuine external operations a browser cannot perform (browser automation, web search, cross-skill file reads). The AirApp itself only reads and writes Busabase — it never fetches remote pages, posts anywhere, or mutates remote systems beyond the configured Busabase Space.

Default behavior is AirApp-first. Unless the user explicitly asks only for explanation, collect/research what's due and give the user the clickable AirApp URL (or the local preview URL when local preview is explicitly requested). Use chat-only mode only when the user says "纯聊天", "chat only", "不要打开 UI", or similar; then present numbered signals (Signal #1) and take verdicts in chat.

Mandatory Dependencies

Read and follow $kelly-app-skill-creator for product behavior, visual quality, responsive layout, and the complete canonical content/busa-radar-app/ artifact.
Read and follow $busabase for connection, target Space, node discovery, ChangeRequests, review, and merge behavior.
Read and follow $busabase-app-creator for resource modeling, AirApp runtime limits, security, validation, and deployment.

If a dependency is unavailable, preserve this skill's local artifact and product contracts, stop before the unavailable Busabase operation, and report the exact missing dependency. Do not invent a second data backend.

Boundary

Collection and research are read-only over public pages and the operator's own analytics. Respect robots.txt and site terms of service, throttle politely, and never scrape private, gated, or personal data.
The AirApp reads and writes Busabase records only. It must not fetch remote pages, post anywhere, or mutate remote systems.
Handoffs to sibling skills (busa-writer content briefs, busa-feedback roadmap candidates) and any outbound artifacts are approval-required: The operator approves in the app, then scripts/execute_decisions.mjs prints the concrete operation for the agent to carry out. It performs no external side effects itself.
Never store crawl credentials or API keys in Busabase. Secrets live only in local env files referenced by name.
Never commit payload JSON files, env files, or raw crawled content.

Busabase Resources

Nine Bases under one application Folder (busa-radar), declared in content/busa-radar-app/app/js/config.js and the generated template sidecars under content/:

watchlist: monitored competitors, categories, keywords, and communities, with per-source method (browser_agent/manual) JSON-encoded on each row. signals_7d is computed client-side from signals, never stored twice.
signals: normalized competitor-monitoring signals — headline, change summary, why-it-matters, severity, evidence, optional before→after diff, proposed action, and the human triage verdict.
questions: research questions moving through brief_needs_review → researching → report_ready → closed, with embedded follow-up questions.
briefs: agent-drafted research briefs (scope, planned sources, expected deliverable) awaiting approval. A question's status is derived client-side from its linked brief's status — approved → researching, blocked → closed — never written back separately.
reports: cited research reports — sections with citation chips, sources, annotations, and the operator's 0-5 confidence rating.
movers: rising keyword/topic trend movers with a momentum series for the sparkline.
opportunities: opportunity cards turned from sustained movers, with a proposed next-step handoff (handoff_content_brief → busa-writer, handoff_roadmap_candidate → busa-feedback) and the human verdict.
sync-log: append-only history of ingest/file-report/execute-decisions runs.
settings: one row (record-id: "config") with product profile, cadence, research defaults, and trend sources.

Resources provision lazily through an idempotent Busabase ChangeRequest the first time the app runs in a Space; see references/radar-schema.md for exact field shapes.

First Run And Onboarding

On invocation, check the watchlist and signals Bases. If both are empty, guide setup before any monitoring or research: ask, turn by turn, products and positioning (what the operator sells, to whom, and against whom), watch targets and sources (competitors/categories/keywords/communities, each with monitored source URLs and a method), research defaults (default depth, source policy, citation requirement, max sources), and trend sources (which search/community/category signals to collect). Write the answers into a settings row and watchlist targets with:

node skills/busa-radar/scripts/ingest_signals.mjs payload.json

(a first monitoring pass auto-creates watchlist targets/sources on the fly; see the Monitoring Workflow below).

Local App

Default behavior is AirApp-first — give the user the clickable AirApp URL. Start pnpm --dir content/busa-radar-app dev only when local preview/debugging is explicitly requested.

Required app views (hash routes):

#/overview: intel command desk — human-attention panel (signals to triage, briefs awaiting approval, reports ready to read, follow-ups running), watchlist freshness, this week's top signals, top trend movers, research pipeline mini-status.
#/signals and #/signals/<id>: the radar feed — source-type badge, watch target, headline, change summary, severity, detected time, triage state. Detail shows before→after diff highlights, evidence links, the agent's why-it-matters note, triage buttons (Act / Watch / Ignore / Needs info), a Review note textarea, and stable refs like Signal #1.
#/watchlist and #/watchlist/<id>: monitored targets with per-source method, last check, 7-day signal counts, status; detail shows sources, recent signal history, and notes.
#/research and #/research/<id>: research desk. Questions table with status (brief_needs_review → researching → report_ready → annotated/closed). Detail switches by stage: brief stage shows the agent-drafted brief with approve/request-changes/block; report stage shows the cited report, annotations, confidence rating, and a follow-up box that files an agent task.
#/trends: trend movers with source badge, volume proxy, delta arrow, inline SVG momentum sparkline, and linked opportunity cards carrying an approvable next step.
#/settings: sanitized config — watchlist summary, research defaults, trend sources, data provider, onboarding state. Never expose secret values.

Demo mode:

?demo=<scene> opens deterministic mock data: overview, signals, research, trends, detail (a signal detail with a pricing-page diff).
lang=en or lang=zh forces UI chrome language for screenshots.
Deep links like /?demo=research&lang=en#/research must work.
Demo mode never reads or writes Busabase and decision buttons are disabled — a demo notice explains decisions are not persisted.

UI language: English and Chinese chrome with Auto default (navigator.languages), an explicit selector persisted locally, and domain content kept in its original language.

Monitoring Workflow

Cadence comes from settings.cadence_monitor (default daily). On a monitoring run, iterate the configured watchlist sources with method browser_agent (browser automation or web search in the agent session; manual sources are supplied by the user as payloads).
For each changed source, build a normalized signal: headline, 1-3 sentence change summary, why_it_matters, severity, evidence links, and — for page changes — a before→after diff.lines block. Propose a triage (act|watch|ignore|needs_info) and, when acting is obvious, a concrete handoff.
Write signals through the single write path: save the payload JSON, then run node scripts/ingest_signals.mjs <payload.json>. The script validates, dedupes by target+source+content hash, merges, auto-creates/refreshes the watchlist target and source, and appends a sync log entry.
Dedupe rules: a signal whose content_hash already exists is skipped; re-detections of the same change must not create new rows. Prefer one signal per change, not per crawl.
The operator triages in the app: Act = approve (queues the handoff), Watch = leave in review with a note, Ignore = done, Needs info = blocked.

Research Workflow

The operator asks a question (in chat or as a follow-up in the app). File it with a drafted brief: node scripts/file_report.mjs <payload.json> with a brief block — scope, planned sources, depth, expected deliverable. The question enters brief_needs_review; include payload.question to create it if it doesn't exist yet.
The operator reviews the brief in #/research/<id>: approve (question moves to researching), request changes, or block.
After approval, run the deep multi-source research within the brief's scope and source policy. Every claim that matters must carry a citation.
File the report with node scripts/file_report.mjs <payload.json> with a report block. The script validates the citation shape (every section's source_ids resolve; every source has title+url), links the report to its question, and flips the question to report_ready.
The operator reads, annotates, rates confidence (0-5), and asks follow-ups in the app; follow-ups are appended onto the question's followups[] field for another research round.

Trends Workflow

Cadence from settings.cadence_trends (default weekly). Collect keyword/topic movers from the configured trend sources: rising search queries, community topic volume, category interest.
Optionally cross-read a busa-seo snapshot (read-only): node scripts/ingest_trends.mjs <payload.json> /path/to/busa-seo/content/busa-radar-app/.data/<snapshot>.json imports rising queries when present and degrades gracefully when absent.
ingest_trends.mjs dedupes movers by keyword+source, updates volume/delta/momentum for existing movers, and can add opportunity cards.
Turn sustained movers into opportunity cards with a proposed_next_step (content brief → busa-writer, roadmap candidate → busa-feedback). The operator approves or ignores each card in #/trends.

Decisions Workflow

The operator's verdicts write directly onto the item record (status, decision_verdict, decision_comment, decided_at) through busabase-sdk. From a standalone local preview the write merges immediately (trusted operator); from the deployed AirApp it creates a pending ChangeRequest for the trusted process to merge.
Before executing anything, run node scripts/execute_decisions.mjs (dry-run). It prints the concrete operation for every approved signal/brief/opportunity: handoff_content_brief → busa-writer, handoff_roadmap_candidate → busa-feedback, add_watch_source → watchlist target id, start_research → question id. No external side effects.
After the operator confirms the dry-run, perform the handoffs (invoke the sibling skill or update the watchlist), then run node scripts/execute_decisions.mjs --apply to mark the approved signals/opportunities done and log the run. Approved briefs are left alone — their lifecycle naturally advances when the report is filed.

Safety Defaults

Treat handoffs, outbound artifacts, and anything customer-visible as approval-required.
Keep crawls polite: cache, throttle, and store only the minimal excerpt needed for the diff and evidence.
Redact tokens and personal data from signals, reports, logs, and UI state.
Keep ingestion idempotent via stable ids and content hashes so repeated runs never duplicate rows.
If a source cannot be verified (A/B tests, geo-variants), file the signal as needs_info/blocked rather than guessing.

Useful Commands

node skills/busa-radar/scripts/ingest_signals.mjs payload.json
node skills/busa-radar/scripts/ingest_trends.mjs payload.json [kelly-seo-snapshot.json]
node skills/busa-radar/scripts/file_report.mjs payload.json
node skills/busa-radar/scripts/execute_decisions.mjs
node skills/busa-radar/scripts/execute_decisions.mjs --apply
pnpm --dir skills/busa-radar/content/busa-radar-app dev

In normal use, invoke /busa-radar, let the skill collect/research what's due, and open the AirApp.