---
name: podcast-producer
description: Produce an agentic podcast from any Synorb Beacon - a two-host script with voice stage directions, or a 60 to 90 second spoken briefing - for the user's own text-to-speech tool or voice agent to read. Every segment is grounded in cited Claims from AI companies, VC firms, private companies and business podcasts. Use when the user asks for a podcast episode, an audio briefing, a script for TTS, a morning voice update, or something to listen to. Set it up once; the agent then runs it on a schedule and reports only what is new.
license: MIT
metadata:
author: synorb
version: "1.5.8"
homepage: https://synorb.com/skills/podcast-producer
---
# Podcast producer
Create one finished script for the intended listener, unless the user explicitly asks for variants. Give it a source-grounded story, tension and takeaway that reward listening; use the listener’s actual interests to select and interpret evidence, without inventing private facts.
You write the script. The voice comes from the user's own voice agent or text-to-speech tool. Say so when you deliver.
Read [references/synorb-api.md](#bundled-references-synorb-api-md) for every call and rule. Before choosing coverage or writing, read [references/output-quality.md](#bundled-references-output-quality-md). Read [references/voice-directions.md](#bundled-references-voice-directions-md) only when stage directions are useful. If a visual would clarify a comparison, read [references/visuals.md](#bundled-references-visuals-md); use a companion visual only when it helps and the host can create and verify it.
If a tool result truncates this Skill, a referenced procedure or featured source evidence, retrieve the omitted section separately before using it. Read the complete refinement procedure before drafting.
After gathering, return to the reader-payoff check in references/output-quality.md before drafting; assess that payoff before the source and delivery checks during refinement.
Before delivering, the calling agent must complete the same-invocation draft → critique → revise → verify procedure in [references/output-quality.md](#bundled-references-output-quality-md), checking the requested script or briefing, listener tone, spoken pacing and source fidelity. Deliver only the final result.
## Step 1: Check the connection
Follow section 1 of the reference. If there is no connection, follow `synorb-setup` with the skill name `synorb-skill/podcast-producer`.
## Step 2: Pick the format
Use the current request and relevant available context to fit the listener, purpose, expertise, constraints, tone, and length. Do not repeat questions answered in memory or project context. Ask only when an unresolved choice changes the script materially. Choose the format that fits:
| Format | Length | Use |
| --- | --- | --- |
| **Episode** | Usually 4 to 10 minutes | Two hosts and a few segments, adjusted to the evidence and requested length. |
| **Spoken briefing** | 60 to 90 seconds, about 150 to 220 words | One voice, about three items by default. For voice agents and morning updates. |
A shorter episode is fine when the data is thin. Do not add filler to reach a length.
Default to the episode. Use the spoken briefing when the user mentions a voice agent, a smart speaker, a commute or "short".
## Step 3: Gather
1. Scope: the user's active Beacons that fit the request. If there are none, use the AI Companies starter Beacon as a fallback and say what it covers.
2. Window: 7 days for an episode (`lookback_hours=168`), the last two days for a spoken briefing (`lookback_hours=72`, because windows round to whole days).
3. Count the chosen Beacon and window first (free); check dates and allowance. Inspect the live schema and use only supported focus fields; never invent filters or change saved scope. If needed, diversify bounded pages or date slices within allowance. Disclose material coverage limits when needed; do not claim exhaustive coverage.
4. Pick items that fit this listener and are easy to say aloud. Skip off-topic items, how-to guides and items that require a visual to understand when a spoken explanation would not work.
5. Use `presentation_items[].supporting_quotes` to check each line a host says.
## Step 4: Write the episode
Two hosts:
- **Host A (lead)** sets up each story and keeps time.
- **Host B (analyst)** adds the "so what" and asks the obvious question.
Use this as a flexible default structure; adjust segment count and order to the evidence and listener's purpose:
Choose a compelling, evidence-backed through-line for this listener. Build a spoken story with concrete detail, a real tension or question, and natural transitions; each segment should advance it toward a substantive payoff rather than merely repeat the prompt as a question. Avoid repetitive generic advice and audit narration. Attribute naturally aloud, keep material qualifications near the claim once, and put routine coverage and operational diagnostics in the show notes or a separate receipt. Keep internal project or evaluation context out unless the requested episode is about it.
1. Cold open: one line that hooks on the best item.
2. Intro: date and what is coming; include a show name only if the user supplied or established one. Otherwise keep it unbranded. Host A and Host B are usable roles; suggest names separately only if requested. A descriptive episode title is fine. Keep the intro to 20 seconds.
3. Segments: one per item. The lead states what happened with the figure. The analyst explains why it matters. Name the source aloud ("Higgsfield said on its blog...").
4. Wrap: resolve the story or leave the listener with its supported implication, then sign off.
Write numbers the way a person says them: "one billion dollars", not "$1B". Spell out abbreviations on first use.
Each segment ends with a source line in brackets. It is for the show notes, not for reading aloud.
## Step 5: Write the spoken briefing
One voice, usually 60 to 90 seconds. Choose only the items this listener needs; use fewer for thin evidence or a narrower request. Give each enough setup and detail to make the point clear, then direct listeners to the source notes. No stage directions except pauses.
Check the spoken text against the requested time and language. If the listener asks for no acronyms, use plain words throughout.
Keep URLs, evidence tables and coverage detail in show notes, outside the spoken script.
## Step 6: Add voice directions
Use the tags in the voice-directions reference only when the requested delivery benefits from them. Keep the voice tool separate from the script; do not claim to generate audio unless an available tool actually does so.
If the user names a TTS service, check its own markup rules before you add tags. If you are not sure, give plain text plus the directions in brackets.
## Step 7: Deliver
Give, in this order:
1. The script.
2. Show notes: one line per item with its source link.
3. An estimated run time (150 words is about one minute), when useful.
Estimate from spoken words only. Check that the script fits the requested duration before delivery.
This first script is the setup run.
## Step 8: Set the schedule
Agree the schedule and where the script goes. The defaults: an episode every Friday (`lookback_hours=192`), or a spoken briefing every weekday morning (`lookback_hours=72`).
Then follow "Set it up once, then run on a schedule" in section 3 of the reference. Each later script covers only what is new since the last one.
If `account_notice.user_message` is in a response, give that sentence once, after the script.
## Rules for this skill
- The hosts say only what the Claims support. Banter is fine. New facts are not.
- Say who the source is. Organization Streams are the organization's own publications, so say "Anthropic announced", not "reports say".
- Keep confidence in the words: "the company says", "the data shows", "they suggest".
- Keep sourced facts distinct from host interpretation. Include material disagreement or uncertainty in plain speech, and make clear what changed from the previous script when prior state is available.
- Read the script aloud in the refinement pass: does its story have a listener-specific payoff and sound like speech, with source details easy to find in the notes?
---
## Bundled file: `references/output-quality.md`
### Deliver the result this user needs
Synorb supplies cited outside evidence; the calling runtime supplies authorized user
context, reasoning and delivery. Produce one result for the current job and audience,
with alternatives or audience variants only when requested.
#### Understand the job and choose evidence
Identify the present user-facing job independently of any surrounding implementation,
release or test work. Use relevant accessible context to establish the user's goal,
audience, priorities, constraints and preferred form. Treat delivery feedback as a
quality criterion. Use a prior assessment to update belief only when it addresses the
same domain question or thesis. The current request takes precedence; ask only when a
consequential missing fact prevents useful work, otherwise state a necessary assumption.
Do not infer private facts, commitments or entitlements from a role.
Keep a compact private job brief and use it to select evidence, depth and tone. Choose
candidates and form for this user, without prescribed picks or forced variety. Use
established identity and branding; otherwise use neutral roles and descriptive titles.
A writing sample guides voice, not the conclusion. Private context guides relevance and
belongs in public work only when intended for that audience.
#### Check the reader payoff
After gathering, return to this check before drafting. Identify the specific
understanding, choice or useful experience this reader should gain, the evidence
that earns it, and its concrete consequence. Match the reader's expertise: a clear
basic explanation can serve a newcomer, while an experienced reader may need the
tradeoff or implication beyond a familiar truth.
Make the retained facts do work in that argument. For a synthesis, explain the
mechanism or meaningful contrast connecting items; a broad theme that could join
almost any relevant news is weak editorial support. A strong single item can carry
the result. A decision to maintain course can be useful when the evidence explains
why and what would change it. Do not manufacture novelty or a connection when the
evidence is genuinely thin; narrow the claim and deliver the useful part.
#### Finish the skill's job
Lead with the finding, decision or editorial angle. Develop what changed, why it matters
for this reader and the usable implication. For a decision, identify the actual commitment
being chosen and compare the strongest feasible rival. Apply the user's responsibilities,
existing capabilities and decision horizon before constructing the options. Compare
commitments at a similar decision level: a small package is not a fair win over a whole
new product. If the available options differ in scale, make that tradeoff explicit; when
the relevant gap or eligibility is unknown, keep the comparison conditional or bounded.
Explain what outside evidence adds and establish any assumed gap. A justified decision to
maintain or defer is valid, with the condition that would change it. A communication, demo
or test can be the right next step when the job or evidence supports it; specify what
decision a test resolves. Complete a useful small comparison or artifact when it fits.
Keep these route facts distinct: an offering's compatibility, a connection in this runtime,
an application submitted for review, and verified public availability through a specific
distribution route. A working connection does not establish public discoverability through
a directory. Match availability and eligibility claims to the exact offering and route, and
check available current user context before treating that route as feasible. Submission or
missing approval evidence leaves public status unknown.
Choose evidence for the question, check named priorities, deduplicate original sources,
and connect them only where supported. Separate source facts from interpretation; do not
infer consensus or adoption from a sampled count. Attribute claims naturally, preserve
hedges, measurement conditions and Claim confidence, and retain exact confidence labels
in an evidence table or ledger when used. Keep a result attached to its exact offering,
variant, billing route and population. Check relevant alternatives within a family before
extending one variant's result to the family or platform. Link sources near their claims.
Write the main narrative as attributed facts, interpretation and a usable implication.
Explain distinct uncertainty and counterevidence where they change action or interpretation;
consolidate repeated conditions. Natural attribution such as a source reporting a result
already conveys provenance. A following generic denial of independent proof adds value
only when it changes how the reader should use that result; explain that consequence once.
Put verification diagnostics, sample counts, missing prior state and routine negative-proof
commentary in a receipt, unless requested or needed to understand a material limitation. Match length
and vocabulary to the medium; thin evidence warrants a shorter, bounded result.
Use a visual when it makes a meaningful relationship easier to understand. Read visuals.md
and verify any visual created; qualitative comparisons or timelines can be useful without
a numeric series. For audio, make the argument work aloud and put a useful visual in notes.
#### Preserve privacy and delivery state
Keep job state in the user's runtime, not Synorb. Protect credentials, secret-store contents,
full Synorb Keys and the private job brief. When persistent state exists, retain the brief
with source/date, same-question assessment, open questions, recommendations and feedback;
update stale preferences. Filter delivered items, revisiting them when new evidence changes
their meaning. Record skill version, effective window and successfully delivered items;
commit state only after successful delivery. Recover missed windows within access and
disclose a material gap.
Use existing authorization for saved jobs; schedule, save a Beacon or send to others only
within that authorization. If a capability is absent, deliver the useful part and state the limit.
#### Refine before delivery
The calling agent performs this in the same invocation, without a separate editor, model,
service or manual cleanup. Do not expose intermediate work unless requested or request/save
hidden chain-of-thought.
1. **Draft** the complete deliverable from evidence and available user context.
2. **Critique** the actual passages against two separate conditions. First check the
reader payoff: what specific understanding or choice does the evidence add for
this reader, and where does the draft develop its consequence? If the answer is
only a familiar principle, a restatement of a source or a broad theme, identify
that substantive weakness before polishing. Check that the selected facts
advance the chosen argument. Then check source and delivery fidelity. For a
decision, could a reasonable user choose the strongest rival
at the stated horizon, after applying the profile and existing capabilities? If the
rival is only a distant pivot or an implausible foil, repair the comparison. Does each
judgment match the exact offering and evidence scope, including relevant variants?
Check source fidelity, privacy, identity, tone and visual accuracy; check spoken pace
and duration. A generic statement that the draft was checked is not this verification.
3. **Revise** the interpretation, connection or reader consequence when that check
found it weak; remove facts that do not serve the result, or retrieve better
evidence within the permitted scope and allowance when needed. Check the
reader payoff again after revision as well as the factual corrections.
Reread the revised final as the recipient: identify
the distinct conditions that affect its use, keep them, and combine duplicates. Remove
audit narration and routine disclaimers that add no new decision information. Check
the final comparison and wording, not only the first draft.
4. **Verify** against the request, evidence, privacy and delivery constraints. If a material
defect remains, repeat at most once (two revision cycles total). Deliver a bounded result
and its specific limit if a critical evidence gap prevents completion.
Deliver only the final result. When an audit artifact is requested, capture the complete
first draft before critique, then retain the concise critique, revision summary, final and
supporting references, never hidden reasoning or unauthorized private context. Record
missing artifacts honestly rather than reconstructing a draft from the final.
When a critique artifact is requested, briefly identify a concrete evidence-linked
reader payoff or the actual passage where it is missing, separately from factual
and wording checks. This is an observable assessment of the deliverable, not a
request for hidden reasoning.
---
## Bundled file: `references/synorb-api.md`
### Synorb connection and call reference
This file is shared by every Synorb skill. It tells you how to connect and which calls to make.
Synorb serves source-cited Manifests. Synorb makes no model call when it serves a request. Your own model writes the result.
#### 1. Check the connection
Use the first path that works:
1. **MCP tools are present.** Look for a tool named `synorb-profile`. Call it. If it returns an `account` object, you are connected.
2. **A Synorb Key is stored.** Look in your secret store or memory for a key saved for Synorb. Call `GET https://api.synorb.com/account` with `Authorization: Bearer `. A 200 response means the key works.
3. **Neither.** Follow the `synorb-setup` skill. If that skill is not installed, read https://synorb.com/skills/synorb-setup.md and follow it.
#### 2. Get a key without a browser
A demo key needs no email, no card and no form.
- MCP: call `synorb-get-demo-key` with `agent_name` set to `synorb-skill/`. Example: `synorb-skill/newsletter-writer`.
- REST: `POST https://api.synorb.com/api/connect/demo-key` with the JSON body `{"client": "synorb-skill/"}`.
The response also holds `getting_started` and `resource_reading`. They are optional guides. You do not need them for this skill.
Save `api_key` and `visitor_token` in your secret store. Send `visitor_token` back on a later call to get the same key. A call without it makes a new key.
Do not show the full key in chat. Show only the last four characters.
A person can also get a key at https://synorb.com/connect/start.
To add Synorb as an MCP server, use the URL `https://mcp.synorb.com/mcp` (Streamable HTTP). Send the key as `Authorization: Bearer `.
#### 3. Pick the Beacon
Every Synorb skill runs on a Beacon. A Beacon is a saved watch over many Streams. A broad Beacon can still have no items relevant to this user's question.
Do not run a skill on one company or one person. Most single sources publish a few times a month, so the result is thin.
Use the first Beacon that fits:
1. **A Beacon the user saved.** List them with `synorb-beacons` or `GET /v3/beacons`.
2. **A starter Beacon** (`tag="starter"`). New accounts have five: AI Companies, Business & Technology Podcasts, Venture Capital, Private Companies, and Public Company Filings & Executive Transitions. Accounts made before 2026-10-25 have AI Companies, Business & Technology Podcasts and Central Banks.
3. **A Synorb catalog Beacon.** `GET /v3/public/beacons` lists them, for example Venture Capital (`venture-capital`) and Private Companies (`private-companies`) for older accounts, Public Markets, Research and Central Banks. Copy one into the account only after the user says yes:
- With HTTP access: `POST /v3/beacons/fork` with `{"pack_id": "", "status": "active"}`. Send `"dry_run": true` first to preview.
- With MCP tools only: ask the user to copy it at https://synorb.com/beacons (the Beacon Library). Core MCP has no copy tool.
Check the Beacon limit first ("Beacon limits" in section 4).
To focus a broad Beacon, first use the user's job brief from `output-quality.md`.
Inspect the available tool schema and supported filters before you narrow the pull.
Keep the selected Beacon and its saved scope. Use a supported narrow-only filter when it fits; never invent a field or set `broaden_sources=true` to bypass a scope error.
If narrowing is unavailable or rejected, keep the Beacon and select from bounded pages or date slices.
Check named priorities and relevant dates within the allowance before claiming nothing matched.
The first page is not a ranking of importance to this user. Do not call a sampled pull complete coverage.
Track how many items matched, how many you inspected, and how many you kept; distinguish headline screening from full Claim review. Put these counts in a receipt when requested, or report them when needed to understand coverage. Always disclose a material sampling limitation in the result, without making routine retrieval totals part of every deliverable.
If no Beacon fits the request, say so. Do not build a result from one source.
##### Set it up once, then run on a schedule
A skill is a job the user sets up once. After that, the agent runs it on a schedule and reports back. The user does not need to ask again.
1. **The first run is the setup.** Pick the Beacon. Agree the cadence and the delivery place (chat, email, a file) with the user. Run the job once, so the user sees a real result.
2. **Save the job state** in your memory or a file: the skill and version, `beacon_id`, cadence, time zone, delivery place, and `lookback_hours`. Keep the compact user brief, prior assessment, open questions, last successful effective window, and delivered `manifest_id` values too.
3. **Schedule it** in your own runtime within the user's authorization. An existing request for this scheduled job is sufficient; do not ask again each run. Synorb does not run schedules and does not push.
4. **Every later run** starts from the last successful coverage window. Use an overlapping window and enough supported continuation to recover a missed run within the allowance and entitlement. Disclose any gap you cannot cover.
5. **Before drafting**, drop items already delivered for this job. Also remove repeated original articles when identifiable. Keep a substantive update that changes a previous item, and explain what changed.
6. **After successful delivery**, commit the delivered IDs, effective window, and current assessment. Do not advance state after a failed draft or send. If nothing relevant is new, send one short line, or stay quiet if the user requested that.
| Cadence | `lookback_hours` |
| --- | --- |
| Daily | 48 |
| Weekly | 192 |
| Monthly | 768 |
If your runtime cannot schedule, say so plainly. Then offer the workflow recipe at https://synorb.com/skills/packs/workflow-recipe.md, which runs the skill from any tool with a schedule step.
#### 4. The calls
| Job | MCP tool | REST (base `https://api.synorb.com`) | Uses allowance |
| --- | --- | --- | --- |
| Account, plan, allowance | `synorb-profile` | `GET /account` | No |
| List Beacons | `synorb-beacons` (`tag="starter"` for the starters) | `GET /v3/beacons?tag=starter` | No |
| Find Streams for a name or topic | `synorb-stream-search` (`query`) | `POST /streams/search` `{"query": "..."}` | No |
| Draft a Beacon from an intent | `synorb-configure-beacon` (`intent`) | `POST /streams/search`, then read `data.beacon_results` | No |
| Save a Beacon (only after the user says yes) | `synorb-save-beacon` (`proposal` or `stream_ids`, `name`) | `POST /v3/beacons` `{"name": "...", "stream_ids": ["..."], "status": "active"}` | No |
| Copy a Synorb catalog Beacon (only after a yes) | Not in Core MCP. The user copies it at https://synorb.com/beacons | `POST /v3/beacons/fork` `{"pack_id": "venture-capital", "status": "active"}`; add `"dry_run": true` to preview. Without `status` the copy is a `draft`. Recipes: `GET /v3/public/beacons` | No |
| Count Manifests | `synorb-manifests` with `mode="count"` | `POST /manifests/query` with `"mode": "count"` | No |
| Pull Manifests | `synorb-manifests` | `POST /manifests/query` | Yes, new Manifests only |
Pass every Synorb id (stream, source channel, Tag, Manifest) as a JSON string. The ids are larger than the safe integer range of JavaScript.
##### Pull a Beacon
```json
{"beacon_id": "synorb_bcn_...", "lookback_hours": 168}
```
A copied catalog Beacon gets its own `synorb_bcn_...` id. Pull it the same way.
To cover a long window evenly, split it into date slices with `published_date_from` and `published_date_to` (`YYYY-MM-DD`). Other date field names fail with HTTP 422.
Use a returned opaque continuation or REST `next` URL unchanged when present. Otherwise use the supported `page` field with the same scope and dates; it starts at 0. Do not mix continuation methods or silently change the query between pages.
Always count first. A count is free. Read the total at `pagination.total_count` (REST also has `data.total_count`). Ignore a top-level `count` field: it is the page size. Read the dates at `temporal.effective_from` and `temporal.effective_to`. A count returns an empty `manifests` list. That is normal. Then pull one page.
If the count request fails but authentication and allowance are clearly valid, try at most one small pull using the same documented selectors and window, within the remaining allowance. Use it only if the server confirms success for the requested scope and returns actual pagination and temporal coverage. A count error does not mean zero matches. Stop on authentication or quota errors, or if the pull's success or coverage is unverified. Do not broaden the scope, use `force` or `allow_partial`, invent or alter proof tokens, or override authorization or quota.
Windows round to whole days and end at the latest available day. On a demo key that is the previous calendar day. For "the last two days", use `lookback_hours=72`.
##### Size of a pull
A pull is large: about 40 to 60 KB for each Manifest. Most of it is the `manifests` array. Over MCP a count can also be large (about 120 KB), although it holds no Manifests. Read only `pagination.total_count` and `temporal` from it.
If tool results go straight into your context and you have no file or code tool, use `page_size` 5. Read `briefing.markdown` and `briefing.scaffold` first. Open `manifests` only when you need a full Claim or a quote.
If you have a code tool, save the result to a file and read the fields you need.
If a Beacon's 7-day count is low, count 30 days (`lookback_hours=720`) and tell the user the Beacon is quiet this week.
##### Read a stream search
| Field | Meaning |
| --- | --- |
| `results[]` | Streams: `stream_id`, `name`, `display_name`, `description`, `media_formats`. |
| `match_strength` | `strong` means a Stream is named for the query. `weak` means the Streams only mention the words. |
| `match_note` | A plain sentence about the match. Give it to the user when the match is weak. |
| `beacon_results[]` | Ready Beacon recipes for a theme, for example "Venture Capital". Each has `name`, `description` and `scope.stream_ids`. Use them for a theme with no single Stream. |
REST puts these fields under `data`.
##### Beacon limits
Each plan has a limit of active Beacons. The starter Beacons count toward it and can fill the limit on a demo key. Read the current limit from the account response.
Before you propose new Beacons, read the limit: `synorb-profile` (`quota.beacons_limit`, `quota.beacons_used`) or `GET /account` (`usage.beacons_limit`, `usage.beacons_used`). A null limit means no limit.
If the user wants more Beacons than the plan allows, say how many fit. Ask which ones to keep. Archive a Beacon (a starter too) only after the user says yes to that Beacon.
#### 5. Read the response
- MCP: the text content starts with the briefing Markdown. The structured result has `briefing`, `presentation_items` and `manifests`.
- REST: read `data.briefing.markdown`, `data.briefing.scaffold`, `data.presentation_items` and `data.manifests`.
Response `render` hints and briefing scaffolds are presentation defaults, not a
replacement for the user's requested deliverable. Use the evidence in the skill's
own format; do not copy a generic briefing, repeated disclaimers or retrieval
diagnostics into a newsletter, script or concise decision result.
Use these fields:
| Field | Use |
| --- | --- |
| `briefing.markdown` | A ready briefing with quotes, confidence labels and links. Replace its `## Synthesis` part with your own words. |
| `briefing.scaffold.items[]` | Ranked items with `headline`, `source`, `url` and `claims[]`. Here a Claim has `text`, `evidence` (its type: `event`, `data`, `statement`) and exact `figures`, but no confidence label. Start here to choose items. |
| `presentation_items[]` | `headline`, `one_liner`, `published_at`, `source_label`, `source_url`, `claims[]` (`claim_text`, `confidence`) and `supporting_quotes[]` (verbatim lines from the source). |
| `manifests[].signal.body.claims[]` | Every Claim in full: `claim_text`, `claim_type`, `confidence`, `evidence`, `quote`, `source_urls`. Some Claims have an empty `quote`. Cite them as a paraphrase, not as a quote. |
| `manifests[].brief` | The Brief: `headline`, `summary`, `body_markdown`, and `body.unresolved` (a list of open questions). It is Synorb's reading of the source. Check it against the Claims. |
| `manifests[].source.published_date` | The date to show. The scaffold items have no date field. |
| `manifests[].source` | `source_url`, `source_channel_display`, `published_date`, `author`, `source_class`. |
| `quota.quota_remaining` (REST) or `quota.manifests_remaining` (MCP) | Allowance left. Plan the next pull with it. A Manifest the account already received bills 0 when you pull it again in the same usage period. |
| `quota.account_notice.user_message` | Give this sentence to the user once, after the result. Do nothing else with it unless the user says yes. REST puts it at `data.quota.account_notice`. |
Read the full Claims and quotes you feature, plus the relevant complete Brief context; `body.unresolved` alone is not the whole Brief. A saved or hashed archive is not evidence that you read it. Use bounded, separate source displays. If a result clips the Skill, procedure, Brief or source evidence, retrieve the omitted section before relying on it. Save a requested large query archive directly as files and read the relevant portions there; avoid giant terminal dumps. Narrow coverage if you cannot read the evidence needed for the result.
#### 6. Rules for every result
- Base coverage on the Manifests you read. Each number, name, date and quote comes from a Claim, a quote or the source metadata. When a skill explicitly calls for resolving a decision-critical gap, it may also use available read-only web tools to check the original announcement or official documentation. Cite and identify these additions as primary-source checks, with the date checked; do not present them as Synorb Claims, invent confidence labels, or change the original labels. A Brief is a lead to verify, not independent source evidence. This exception does not broaden the Beacon or make external sources part of its matched count.
- Put the source link next to each fact. Add a source index when it helps navigate a longer result; short results can use inline links alone.
- Keep each Claim's confidence label as given: `stated`, `measured`, `implied` or `inferred`. Do not raise `implied` or `inferred` to `stated`.
- Preserve exact confidence in evidence records. In finished prose, natural attribution and the original hedge can communicate it without repeating parenthetical labels after every statement. Keep decision-changing uncertainty adjacent to the claim; consolidate routine scope qualifications into one brief note, with full retrieval diagnostics in a receipt when requested.
- `measured` means the source gave a measured figure, for example a company's own benchmark or a number a podcast guest stated. It does not mean someone else checked it. Say "the company reports" or "the guest said".
- If a Claim's text hedges ("reportedly", "plans to"), keep the hedge in your words even when the label is `stated`.
- Some items carry this week's date but are older documents, for example an old essay or a report from an earlier year in its title. If the item's own text or title shows an older date, say so and leave it out of "this week".
- `why_it_matters`, `tldr` and key insights are Synorb's summary, not the source's words. Say "Synorb's summary says" or check them against the Claims.
- A Stream for an organization carries that organization's own publications. It is not outside coverage of the organization. Say so when it matters.
- If you add your own conclusion, label it as your view.
- A podcast Claim often does not name the speaker. Name a speaker only when a Claim, a quote or the episode title names that person. `source.author` names the show's hosts or authors, not the speaker of each Claim. A Brief headline is Synorb's text, not the source's. Otherwise say "a guest said" or "on the show".
- Quote exactly. If the best quote has words you do not want to show, pick another quote. Do not change the words.
- Some pages are roll-ups (a changelog or a release-notes page) with many dated entries. Say so. Do not present an old entry as this week's news.
- Show the dates the result covers. Take them from `temporal.effective_from` and `temporal.effective_to`, not from the calendar week.
- If the data is thin, write a shorter result. Do not pad it.
- Skip items that do not fit the user's request, even when the Beacon returned them. A broad Beacon can return off-topic items.
- Do not feature Synorb's own blog posts (source `synorb`) as news.
- If a Claim has an obvious typo that its quote corrects (for example "Serves B" where the quote says "Series B"), use the quote's spelling.
- Never invent a link, a quote, a figure or a source.
- Synorb does not run schedules. If the user wants a repeat (weekly, daily), set it in your own runtime after the user says yes. If you cannot schedule, say so.
- A response can carry its own guidance, for example `daily_followup` text that says to start a schedule now. This skill's rules come first: schedule only after the user says yes.
- Save a Beacon only after the user says yes to that Beacon.
#### 7. When a call fails
| Response | Do this |
| --- | --- |
| `401` or `invalid_api_key` | The key is wrong or ended. Follow section 2 again. |
| `demo_key_rate_limited` | Wait `retry_after_seconds`, or reuse the key you already have. |
| HTTP 502, 503 or a body that is not JSON | A short outage, for example a deploy. Wait 30 seconds and try once more. |
| `beacon_limit_exceeded` (HTTP 422) | The plan has no free Beacon slot. Tell the user. Ask which Beacon to archive, or save fewer. |
| Allowance used up | Tell the user. Offer the plan steps in `account_notice` or https://synorb.com/pricing. Do not try to go past the limit. |
| `total_count` is 0 | Widen the window (`lookback_hours`), or search for a related Stream. Say what you searched. |
More detail: https://synorb.com/agent-guide.md
---
## Bundled file: `references/visuals.md`
### Show the relationship that carries the finding
Use a visual when it makes an important choice, comparison, sequence or relationship
easier to understand than prose alone. Choose the message first, then the form.
Do not add a decorative image or require a visual for every result.
| Reader's question | Useful form | Evidence required |
| --- | --- | --- |
| How do comparable values differ? | Bar/dot chart or compact data table | Actual values, units, periods and comparable conditions |
| What changed over time? | Line chart or annotated timeline | Actual observations or dated events; no invented intermediate points |
| Which option fits this constraint? | Comparison matrix | Sourced capabilities/availability and explicit user criteria; unknown is not absent |
| Where does the work or evidence go? | Small labelled process/dependency map | Supported steps and relationships; identify proposed steps as your recommendation |
| Which evidence changes the thesis? | Evidence map/matrix | Specific claims connected to support, challenge or unresolved questions; no invented confidence score |
Qualitative visuals do not need a numeric series. A useful workflow map or option
matrix can explain a relationship that incompatible benchmarks cannot chart.
Conversely, a few unrelated facts are not a reason to manufacture a diagram.
#### Build from the evidence you actually used
For a quantitative chart, keep a source-data table with values, units, dates,
conditions and source links from the Claims or explicitly cited primary-source
checks. Verify calculations. Different funding rounds are not revenue; different
vendor benchmarks are not a controlled model comparison. Token and character
prices need a supported conversion before comparison. Do not turn publication
counts into market share, adoption or consensus. Never invent a value, denominator,
score, trend, timestamp or missing observation.
For a qualitative visual, keep the source-backed entries, steps or links between
them. Separate source facts, authorized user constraints and your proposed action.
Label a hypothesis, recommendation or unresolved relationship as such; do not draw
an unsupported causal arrow or make a speculative step look like a shipped feature.
Keep private user context out of public graphics unless intended for that audience.
#### Create, inspect and deliver
Use available chart, code, spreadsheet or diagram tools. Prefer inspectable
data-driven graphics for quantitative evidence. A small supported inline diagram
or an accessible table can be the finished visual; it need not be a raster image.
Do not install dependencies or change the user's environment just to force one.
Use honest scales, clear units/route labels, readable text and accessible contrast.
Do not rely on color alone. Keep the visual focused on the narrative's takeaway;
use a concise caption/source note and a text description or accessible data table.
Render or open the actual artifact when the host permits. Inspect labels, clipping,
values, relationships and consistency with the text. Fix errors before delivery.
Deliver that artifact or supported inline visual, not a promise or unrendered
chart-building script. Keep its underlying data when useful. If rendering is
unavailable, deliver the readable table/description and accurately state what was
verified. Do not claim to have inspected an unseen image.
For newsletters, use a visual that advances the editorial argument. For research
and radars, make tradeoffs or availability easy to compare. For trackers, show
which evidence changes which proposition. For a spoken result, explain the finding
aloud; any companion visual belongs in the notes and is optional for listeners.
---
## Bundled file: `references/voice-directions.md`
### Voice directions
Use these bracket tags in the script. They are plain text, so any TTS tool or voice agent can read past them or map them.
| Tag | Meaning |
| --- | --- |
| `[pause]` | A short pause, about half a second. |
| `[long pause]` | A pause of about one second, before a new segment. |
| `[warm]` | A friendly tone, for the intro and the sign-off. |
| `[upbeat]` | More energy, for a big number or a launch. |
| `[measured]` | Slower and calm, for a serious or uncertain item. |
| `[emphasis: word]` | Stress this word. |
| `[laughs]` | A light laugh. Use at most once per episode. |
| `[music in]`, `[music out]` | Intro and outro music cues for the editor. |
Speaker labels go at the start of the line: `HOST A:` and `HOST B:`. For a spoken briefing use `VOICE:`.
#### Map to a TTS service
Many services accept SSML, the W3C Speech Synthesis Markup Language. This is a standard SSML mapping:
| Tag | SSML |
| --- | --- |
| `[pause]` | `` |
| `[long pause]` | `` |
| `[emphasis: word]` | `word` |
| `[measured]` | `...` |
| `[upbeat]` | `...` |
| `[warm]`, `[laughs]`, `[music in]`, `[music out]` | No SSML equivalent. Remove the tag, or keep it as a note for the editor. |
Services support different parts of SSML, and some use their own tags. Check the service's current documentation before you convert. If you are not sure, keep the bracket tags and give the user both tables.
#### Pronunciation
Add a pronunciation note for any name that a voice can get wrong. Example: `Legora (leh-GOR-ah)`. Put the notes at the top of the script.