daily-brief

name	daily-brief
description	Prepare a source-grounded daily information brief for recurring or user-selected topics; orchestrates `topic-radar` JSON output and does not implement its own source fetchers.

Daily Brief

Contract

Prereqs:

• The topic-radar script is available for source acquisition, ranking, cache, and JSON output through its portable skill alias (reporting.topic-radar) and rendered script reference ($HOME/.hermes/plugins/reporting/skills/topic-radar/scripts/topic-radar.sh).
• Network access is available for live source lookups unless the user explicitly accepts offline/sample output.
• Home-scope external-lookup policy has been satisfied when live sources are queried.
• Personal memory, when available, is used only for stable topic/source preferences and never as evidence for news claims.

Inputs:

• Natural-language brief request, such as "AI news this week", "what should I watch today", "morning brief", or a focused topic.
• Optional topic list, timeframe, source preference, freshness requirement, audience, and depth.
• Optional monthly trend-backfill request for a fixed historical month or year-to-date set of months.
• Optional instruction to force latest/live results, which maps to topic-radar --refresh.
• Stable preferences from memory, such as recurring AI/Tech interests or preferred report style.
• Optional request to keep local history, plus an explicit record folder when the user wants durable tracking.

Outputs:

• Concise brief in the user's language with source links for material claims.
• Topline items, topic sections, and optional follow-up angles for deeper reading.
• Freshness and source-health note covering generatedAt, windowDays, cache state, refresh mode, and source errors from topic-radar JSON.
• Explicit separation between observed source signals and agent inference.
• Optional history records under the user-selected record folder.
• Optional monthly trend records with fixed-window metadata when the user asks for durable archive backfill.

Exit codes:

• N/A (instruction-first workflow; no standalone entrypoint)

Failure modes:

• topic-radar is unavailable, fails, or returns malformed JSON; report the command failure and do not invent a brief.
• Live sources are unavailable or rate-limited; include source gaps from topic-radar and synthesize only from returned items.
• Returned items are too thin for the requested topic/window; say so and offer a narrower or broader follow-up query.
• Memory is unavailable or irrelevant; continue from the user's request without treating that as a blocker.
• Durable history was requested but no record folder is known; ask the user to choose a folder before writing records.
• Record folder writes fail; report the path and failure, but still provide the brief if source synthesis succeeded.

Entrypoint

• None. This is an instruction-first workflow skill. Execute it by invoking topic-radar and synthesizing its JSON output.

Skill Roles

• daily-brief is the user-facing daily entrypoint. It owns intent resolution, preference steering, source-health explanation, and concise synthesis in the user's language.
• topic-radar is the lower-level radar engine. It owns source fetching, source fallback behavior, cache, ranking, clustered JSON/Markdown output, and source-specific errors.
• polymarket-readonly is the market-only helper behind topic-radar's Polymarket source. Use it directly only when the user specifically asks for Polymarket markets, odds, order books, or wallet/public market details.

Do not split source fetchers, ranking, cache, RSS/API parsing, or Polymarket fallback logic into daily-brief. If those behaviors need to change, update topic-radar.

Outcome Routing

The user asks for a readable brief. This parent invokes topic-radar as its internal collection engine, selects cache or refresh behavior from the freshness request, allocates temporary raw output through the workflow state-out path, and returns synthesis plus source health. The user does not need to select source fetching, cache, artifact, or transport bookkeeping.

Direct topic-radar remains a distinct outcome only for source-level scans, custom source controls, or machine-consumable raw output.

Workflow

1. Resolve the brief intent.

   • Default underspecified daily information requests to AI/Tech unless the user names another topic.
   • Use the user's explicit timeframe when given. For "today", "this week", or "these days", state the absolute date/window in the reply.
   • Ask only if the topic or audience is ambiguous enough that a reasonable default would produce the wrong brief.

2. Apply stable preference steering.

   • Use memory only for recurring interests, source preferences, and output style.
   • Do not cite memory as news evidence.
   • Do not write or update memory unless the user explicitly asks for that.

3. Choose the topic-radar query.

   Use topic radar for source collection:

   reporting.topic-radar $HOME/.hermes/plugins/reporting/skills/topic-radar/scripts/topic-radar.sh
   --preset ai-news --format json --refresh

   Write temporary raw collection output under:

   agent-out path-for --domain projects --topic daily-brief

   Other variants:

   • Default daily AI/Tech brief (cached):

     $HOME/.hermes/plugins/reporting/skills/topic-radar/scripts/topic-radar.sh --preset ai-news --format json
     

   • Focused topic:

     $HOME/.hermes/plugins/reporting/skills/topic-radar/scripts/topic-radar.sh --preset ai-news --format json --topic "<topic>"
     

   • Broad scan across research, open source, markets, and model ecosystem:

     $HOME/.hermes/plugins/reporting/skills/topic-radar/scripts/topic-radar.sh --preset radar --format json
     

   • Monthly trend archive:

     $HOME/.hermes/plugins/reporting/skills/topic-radar/scripts/topic-radar.sh --preset radar --report monthly --month 2026-01 --format json
     

   • Partial current-month trend archive:

     $HOME/.hermes/plugins/reporting/skills/topic-radar/scripts/topic-radar.sh --preset radar --from 2026-05-01 --to 2026-05-15 --format json
     

4. Parse the JSON output.

   • Prefer brief.clusters for the first synthesis pass when present.
   • Use signalTier and signalMetrics to keep early-watchlist items out of Topline claims and preserve visible evidence such as HN points/comments or GitHub stars/forks.
   • Topline uses high/medium signal items.
   • Put low-star or low-HN-engagement items in Early Watchlist; they are topic samples, not popularity or adoption evidence.
   • Use items and sections to add source links and avoid unsupported claims.
   • Carry through errors and cache metadata instead of hiding source failures.

5. Write the daily brief.

   • Lead with 3-5 high-signal bullets.
   • Use compact sections such as Models/Products, Agents/Developer Tools, Enterprise Adoption, Safety/Governance, and Research/Open Source, adapted to the brief language.
   • Keep each material claim source-linked.
   • Mark inference explicitly when connecting multiple source signals.
   • Include a short freshness/source-status note with the absolute date/window, cache/refresh state, and source gaps.

6. Write monthly trend records when requested.

   • Use topic-radar fixed-window JSON, not rolling --days, for historical month records.
   • For year-to-date backfill, create one record per month. Treat the current month as partial through the current absolute date unless the user gives a different end date.
   • Lead each monthly record with 3-6 source-grounded trends, then sections for product/model releases, agents/developer tools, infrastructure, research/open source, market/community signals, and source gaps as applicable.
   • Mark inference explicitly when describing trend movement across several source items.
   • Do not cite older local records as evidence for the month; cite the source links returned for that fixed window.
   • Use trends/YYYY/YYYY-MM-<topic-slug>.md for rendered monthly trend records and raw/monthly/YYYY/YYYY-MM-<topic-slug>.json for the source JSON when the selected record folder supports this layout.
   • Append index.jsonl entries with recordType: "monthly-trend", periodStart, periodEnd, completePeriod, briefPath, rawPath, sourceCount, sources, tags, and source errors when available.

7. Write history records only when requested.

   • Do not hardcode a record location. Use the user's provided folder, an existing project record folder the user points to, or ask the user to choose one before writing durable records.

   • Do not initialize git, create remotes, or push the record folder unless the user explicitly asks for repository setup.

   • Use date-first storage with topic/query metadata:

     <record-folder>/
     ├── README.md
     ├── index.jsonl
     ├── briefs/YYYY/MM/YYYY-MM-DD-<slug>.md
     ├── raw/YYYY/MM/YYYY-MM-DD-<slug>.json
     └── topics/<topic-slug>.md
     

   • Create README.md when absent to document the local schema and source-citation expectations.

   • Write the rendered brief to briefs/YYYY/MM/YYYY-MM-DD-<slug>.md.

   • Append one JSON object to index.jsonl with relative paths plus generatedAt, date, topic, query, window, language, sourceCount, sources, tags, and errors when available.

   • Store the topic-radar JSON under raw/ when available and useful for future trend tracking; skip it if the user wants markdown-only records.

   • Update topics/<topic-slug>.md only for explicit tracking requests or when the user asks for a topic timeline. Keep these notes concise and source-linked.

Output Style

• Match the user's language. Preserve precise English names for models, companies, APIs, repositories, and standards.
• Keep the brief skimmable. Prefer source-grounded bullets over long narrative.
• Do not present heuristic ranking as objective importance.
• Do not make trading, investment, product, or legal recommendations from the brief alone.

Direct Usage Timing

• Use daily-brief when the user wants a readable daily information entrypoint, personalized synthesis, or "what matters now" answer.
• Use topic-radar directly when the user wants raw source sections, JSON/Markdown radar output, source tuning, or a machine-consumable digest.
• Use polymarket-readonly directly when the question is specifically about Polymarket markets, prices, public odds, or read-only wallet/activity research.