Launch day is close, and the material that decides readiness lives in two places: repositories on GitHub and pages in Notion. This example is a read-only review across both connections that ends in one citable report. The agent reads, cites, and separates fact from inference. You decide what survives into the launch issue. Open Bright → A read-only launch-review session citing connected-source records

​
Connect both, then start read-only

  1. Open Capabilities, choose Apps, and select Connect on the GitHub and Notion rows. Both connect through OAuth.
  2. Set the composer mode to Ask (⌘.) so the review reads without changing anything.
  3. Write the brief into the prompt:

​
Approve read tools one card at a time

Even a read-only review crosses tool-approval boundaries, one card per protected action. While you are still learning the workflow, approve read tools one at a time. You can switch to always-allow for tools you trust. Pending approvals wait in the Waiting on you strip above the composer, so a review pauses rather than fails when you are away.

​
Read the report like an auditor

  • Citations make it reviewable. Exact record titles and links mean every claim can be checked at its source in seconds.
  • Facts, inferences, and gaps must be separated. “The migration guide exists” is a fact with a link. “The guide is probably current” is an inference. “Notion has no launch checklist” is only supportable if the agent actually searched for one.
  • Counts deserve a recount. A summary that says “eight guides” should match an inventory you can count yourself. Summaries drift; inventories do not.
  • Mind the boundary between connected and public. Material found through public search is not the same as material inside the connected account’s scope. Ask the report to label which is which.
Privacy check: a connected-source report can include details the decision never needed: account identifiers, email addresses, internal page or user IDs. Read the report before it is shared, and redact what the audience does not need.

​
Run the protocol end to end

  1. Start with a provider and scope inventory: what is connected, and what can it reach.
  2. Approve read tools only when the target and purpose are visible on the card.
  3. Require exact record titles, links, timestamps, and owners for every claim.
  4. Redact emails and provider-internal identifiers from the ordinary report.
  5. Check summary counts against the raw inventory.
  6. Separate connected private scope from publicly searchable material.
  7. Promote only verified conclusions into the issue or document that tracks the launch.

​
What good looks like

  • The review read two connections and wrote nothing.
  • Every claim in the report carries a citation someone else can open.
  • Facts, inferences, and unavailable evidence are visibly separated.
  • The conclusions that survived scrutiny are on an issue, not just in a session.

​
Good to know

  • GitHub and Notion both connect through OAuth in Capabilities.
  • Every protected action shows one approval card, even in a read-only review. Approve a read tool only when its target and purpose are visible on the card.
  • Pending approvals wait in the Waiting on you strip above the composer. A review pauses rather than fails when you are away.
  • Always-allow is available for tools you trust. Use it after the workflow is familiar, not before.
  • The prompt says to perform no external writes. Read the report before it is shared, and redact emails and provider-internal identifiers.

​
Next step

When the review says the launch is ready, create the artifacts with Create and cross-link GitHub and Notion artifacts.