| name | continuous-monitor |
| description | Unattended, scheduled monitoring of external sources (arXiv, OpenAlex, Crossref, Semantic Scholar, PubMed, bioRxiv/medRxiv, GDELT, Hacker News) for operator-selected current-events DOMAINS (monitoringDomains[], weighted, momentum-ranked, digest output) or for a research topic (the topic-bound special case), gated end to end through a mandatory human Editorial Gate before anything publishes. An OPTIONAL methodology pack (enable the `continuous-monitor` pack AND configure a domain or a topic's continuousMonitoring block). Use this skill when the user wants to enable, inspect, or manually run continuous monitoring for a domain or topic, review a run's digest or candidate recommendations, or check the Continuity Log for a skipped/failed source. Triggers on 'continuous monitoring', 'monitor this domain', 'monitor this topic', 'monitoring digest', 'schedule research monitoring', 'check for new sources', 'run the monitoring pipeline', 'review monitoring recommendations'. |
| version | 0.16.25 |
| argument-hint | <domain-or-topic-id> [<run-id>] |
| allowed-tools | Read, Bash, Glob, Grep |
continuous-monitor — scheduled external-source monitoring with a mandatory human gate
Continuous monitoring is a methodology pack (SPEC §7b): it contributes a
background research-discovery capability the same way competitive-analysis or
trend-modeling contribute a research dimension, except its normal caller is a
scheduled GitHub Actions workflow rather than an interactive dimension-analyst
fan-out. Enable the bundled continuous-monitor pack (scripts/pack-toggle.sh continuous-monitor on) AND opt a topic in via its own continuousMonitoring
block in harness.config.json (see
How to enable continuous research monitoring) —
both gates must be on; either one alone does nothing (research-harness-template#483).
Why this pack is invoked two different ways
Every other pack in this harness is invoked by an agent reading its SKILL.md
inside an interactive Claude Code session. This pack's actual production
callers are .github/workflows/monitor.yml (Phase 1: run the pipeline, open a
review PR) and .github/workflows/monitor-gate.yml (Phase 2: react to that PR
closing, publish or reject) — both invoke this pack's scripts/ directly by
path, exactly the way packs/channels/diataxis's scripts/render-diataxis.sh
is invoked directly rather than through a chat turn. The canonical sources of
those two workflows ship inside this pack (workflows/, delivered by copier —
.github/workflows/* itself is copier-excluded, #517); an instantiated clone
materializes them with bash scripts/install-monitoring-workflows.sh, and
verify.sh's gate_monitoring_workflow_sync keeps every installed copy
byte-identical to its pack source. A pack's scripts/
directory has always been callable this way; continuous monitoring is simply
the first pack whose primary caller is unattended CI rather than a human
prompt. This SKILL.md documents the same pipeline for interactive/manual use
(inspecting a run, re-triggering it by hand, debugging a stuck topic) — it is
not a second implementation, just the human-facing entry point onto the exact
same scripts the workflows call.
Pipeline
Source Connectors -> Interest-Inference -> Recommendation Engine
-> [review PR: the Editorial Gate] -> Output Router -> reports/<topic>/findings/
| Script | What it does |
|---|
scripts/run-monitoring.sh <subject> <run-id> | Phase 1 orchestrator. <subject> resolves against monitoringDomains[] first (#521 -- first-class current-events domains, runs under reports/_monitoring/<id>/runs/), then a topic's continuousMonitoring block (topic-bound runs under reports/<topic>/monitoring/runs/). Checks the pack gate, runs enabled Source Connectors under a budget, scores via Interest-Inference, momentum-ranks with prior-coverage suppression (#523), writes recommendations.json and the versioned digest.md (#524). Stops before the Editorial Gate. |
scripts/render-digest.sh <recommendations.json> <subject> <run-id> | Renders the per-run digest (format marker Digest format: v1): per candidate a headline, domain/weight, momentum evidence, relevance, prior-coverage status, and source URLs. The review PR's body in Actions; the operator's in-session review surface. |
scripts/run-with-budget.sh | Wraps one connector in a hard wall-clock timeout; fails closed and logs to the Continuity Log rather than partial-succeeding. |
scripts/connectors/{arxiv,openalex,crossref,semantic-scholar,pubmed,biorxiv,gdelt,hn}.sh | The eight keyless Source Connectors. Query-taking connectors accept <query> as a JSON array of atomic terms/phrases (what run-monitoring.sh passes from queryTerms[]) or a plain string treated as one term, and dispatch per the target API's own query grammar (#513): phrase-quoted boolean OR in one request (arXiv, PubMed, GDELT) or one request per term with merge/dedup (HN, OpenAlex, Crossref, Semantic Scholar). GDELT detects its HTTP-200 plaintext rate-limit notice and retries once after GDELT_RETRY_DELAY_SECONDS (default 6) before failing closed with the true cause (#515). |
scripts/interest-inference.sh | Scores candidates against the monitored topic's own concordance nodes (--topic, #514) plus the topic's queryTerms as a first-class signal, with a TF-IDF fallback when neither matches. |
scripts/recommend.sh | interest-match (cross-source merge + momentum ranking with recorded factors, prior-coverage suppression via , #523) and (coverage-gap suggestions) modes. |
Manual invocation
Run a monitoring pass for one subject by hand (the same call monitor.yml
makes) -- <subject> is a monitoringDomains[] id or a topic id:
bash "$CLAUDE_PROJECT_DIR/packs/monitoring/continuous-monitor/scripts/run-monitoring.sh" <subject> "run-$(date -u +%Y%m%dT%H%M%SZ)-manual"
Review the digest (the in-session equivalent of the review PR's body, #525)
and inspect the raw result -- <run-dir> is
reports/_monitoring/<subject>/runs/<run-id> for a domain,
reports/<subject>/monitoring/runs/<run-id> for a topic:
cat "<run-dir>/digest.md"
jq . "<run-dir>/recommendations.json"
Gate the batch in-session (merge/close of the review PR is the Actions
equivalent): accept with true, reject with false -- accept appends the
batch to the prior-coverage memory and, for a topic-bound subject, publishes
findings via the Output Router:
bash "$CLAUDE_PROJECT_DIR/packs/monitoring/continuous-monitor/scripts/run-gate-and-publish.sh" <subject> <run-id> "<run-dir>/recommendations.json" true
Every recommendation reaching this file has already passed schema validation
(schemas/monitoring-recommendation.schema.json) but has not yet passed
the Editorial Gate — merging or closing the PR monitor.yml opens from it is
what decides accept/reject; do not hand-run output-router.sh against it
without going through editorial-gate.sh first (it enforces NFR6: every
recommendation must already carry a valid gate stamp).
Check the Continuity Log for a skipped or failed source:
jq -c 'select(.event_type != "gate_rejected")' "reports/<topic-id>/monitoring/continuity-log.jsonl"
Constraints
- Every connector is keyless by default (NFR2/NFR3);
SEMANTIC_SCHOLAR_API_KEY/
NCBI_API_KEY are optional rate-limit enhancements, never required.
- Every recommendation carries at least one MIF citation (NFR5), enforced in
code — a citation-less recommendation raises rather than being produced.
- No recommendation reaches
reports/<topic>/findings/ without an explicit
Editorial Gate accept (NFR6) — the fail-safe default on an undecided
recommendation is reject, never accept-by-omission.
