---
name: newsletter-writer
description: Write a weekly newsletter issue in the user's own voice from any Synorb Beacon (AI companies, VC firms, private companies, business and technology podcasts, or a Beacon the user saved), with every item cited to its source. Use when the user asks for a newsletter, a weekly roundup, a digest of what happened this week, or an issue for subscribers, investors or a team. 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/newsletter-writer
---

# Newsletter writer

Write one finished issue for the known audience: make a compelling, source-grounded argument that matters to those readers and sounds like the user. Produce audience variants only when explicitly requested. Use actual reader priorities and constraints to select, interpret and frame evidence; do not invent private facts.
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). If a visual would strengthen the issue's argument, read [references/visuals.md](#bundled-references-visuals-md) and create and verify it when tools permit.
The adaptable issue template is in [assets/issue-template.md](#bundled-assets-issue-template-md).

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 complete issue, reader voice, public identity and strongest supported editorial connection. 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/newsletter-writer`.

## Step 2: Learn the voice and the reader

Use the current request first, then relevant available memory, project context, and prior issue feedback. Do not ask again for a preference or reader already known. Ask only when an unresolved choice materially changes the issue. Find, in this order:

1. A sample of the user's writing, if one is available. If none is available, use a plain, direct voice; ask for a sample only when the user wants close voice matching.
2. The reader and the decision or purpose: investors, founders, a team, the public, or the specific audience the user named.
3. The Beacon or Beacons the issue covers (section 3 of the reference). Default to the user's active Beacons. If there are none, use the AI Companies starter Beacon.
4. The window. Default to the last 7 days (`lookback_hours=168`).

Keep a compact private job brief with the reader, purpose, relevant priorities, constraints, expertise, depth, and tone. Keep private context out of subscriber copy unless the user intends to publish it. A writing sample guides voice, not the conclusion.

## Step 3: Gather

1. Count each chosen Beacon and window first (free); note `total_count`, effective dates and allowance. Inspect the live tool schema before narrowing. Use only supported focus fields; never invent filters or change saved Beacon scope.
2. Pull bounded pages, or diversify with date slices if needed to check the user's named priorities, within the allowance. Check quota before each additional pull. Disclose material coverage limits when needed; a sampled pull is not exhaustive coverage.
3. Before drafting, dedupe by `manifest_id` and repeated original articles when identifiable. Drop items already delivered unless new evidence materially changes their meaning.

## Step 4: Choose

Choose only as many items as the reader's purpose needs; five to eight is a loose guide, not a target. Rank candidates by their significance to this reader and the issue’s purpose; choose the kinds of stories the evidence and audience warrant.

Drop items with no Claim the reader can use. Drop items that are off-topic for this reader. Drop near-duplicates. Keep one item per story.

## Step 5: Write

Use the template as a default and change its sections, order or length when the reader's purpose calls for it. For each selected item:

- A headline in the user's voice. Do not copy the source title word for word.
- A concise account built from the Claims. Give each story the depth the reader needs and keep exact figures as given.
- The source link inline, with the publisher and the date.
- If a Claim is `implied` or `inferred`, say so in plain words ("the company suggests").

Build one public editorial argument from the strongest supported connection between items, when one exists; explain its concrete significance to this reader. Make it an issue readers would want to read, not a consulting memo about the author’s internal project. If the evidence does not support a connection, let the strongest item carry the issue rather than manufacture one. Use an established newsletter name only if supplied; otherwise use a descriptive issue title, and offer naming ideas only when asked. Do not carry private project or evaluation details into subscriber copy merely because they are available. Keep source facts distinct from your analysis; include material counterevidence, uncertainty and the change from the last issue when relevant. Use `briefing.scaffold.recipe` as a guide. Keep the private editorial brief separate from public copy.

## Step 6: Footer

Add this footer by default:

> Sources via [Synorb](https://synorb.com). Every item links to its original publisher.

Remove it if the user says so. Remember that choice for later issues.

## Step 7: Deliver

Give the issue as Markdown. This first issue is the setup run.

## Step 8: Set the schedule

Agree the schedule and where the issue goes. The default is every Monday at 7:00 (`lookback_hours=192`).
Then follow "Set it up once, then run on a schedule" in section 3 of the reference. Each later issue covers only what is new since the last one, deduped by `manifest_id`.
If `account_notice.user_message` is in a response, give that sentence once, after the issue.

## Quality check before you send

- The chosen angle earns a specific insight or practical consequence for these readers; each retained fact advances it.
- A connection between stories is explained through a supported mechanism or meaningful contrast. If there is no useful connection, the strongest item carries the issue.
- Every item has a working source link from the data.
- Every figure matches a Claim.
- No item says a company was covered by others when the source is the company itself.
- The reader’s interests visibly change the selection and interpretation, and the issue develops an argument rather than a generic action plan.
- The issue reads like the user, not like a press release.

<!-- Generated from https://synorb.com/skills/newsletter-writer (repo: Synorb/skills). The bundled files below are part of this skill. -->

---

<a id="bundled-assets-issue-template-md"></a>
## Bundled file: `assets/issue-template.md`

<!-- Adapt sections, order, and length to the reader and evidence. This is a starting point, not a required layout. Keep private editorial context outside public copy. -->
### {Issue title}

<!-- Include an established newsletter name only when supplied; the issue title can be descriptive. -->

*{Date range, for example 18 to 24 October 2026}*

{Opening in the user's voice, shaped around the reader's purpose and the strongest supported finding.}

#### {Optional section, for example Money}

##### {Headline in the user's voice}

{Concise account from the Claims, with exact figures as given.} ([{Publisher}]({source_url}), {date})

#### {Optional section, for example Launches}

##### {Headline}

{Body.} ([{Publisher}]({source_url}), {date})

#### {Optional quick hits, only when useful}

- {One line.} ([{Publisher}]({source_url}))
- {One line.} ([{Publisher}]({source_url}))

{Optional counterpoint, uncertainty, or change since the prior issue, when material. Keep sourced facts separate from the editor's view.}

---

Sources via [Synorb](https://synorb.com). Every item links to its original publisher.

---

<a id="bundled-references-output-quality-md"></a>
## 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.

---

<a id="bundled-references-synorb-api-md"></a>
## 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 <key>`. 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/<this skill name>`. Example: `synorb-skill/newsletter-writer`.
- REST: `POST https://api.synorb.com/api/connect/demo-key` with the JSON body `{"client": "synorb-skill/<this skill name>"}`.

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 <key>`.

#### 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": "<slug>", "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

---

<a id="bundled-references-visuals-md"></a>
## 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.