The launch needs a durable pair of artifacts: documentation in a private GitHub repository and a brief in Notion, with the Notion URL recorded in the repository’s README. This example is the write-side workflow that creates both and cross-links them without trusting a success message. Every write gets its own checkpoint, and the run is done only when you have checked both providers yourself. Open Bright →

​
Check first, then write with one checkpoint each

  1. Query both connections first. Confirm the intended repository and page do not already exist. Re-creating something that exists is the classic connected-write mistake.
  2. Checkpoint one: the repository. The agent presents the owner, the visibility, the name, and the files it will create. You approve. The repository and its initial files are created.
  3. Checkpoint two: the Notion page. A separate checkpoint presents the workspace, the page title, and the planned sections. You approve. The page is created.
  4. Checkpoint three: the cross-link. The agent updates only the new README with the page’s live URL. You approve.
Each checkpoint is a tool-approval card: Allow once while you are learning the flow, always-allow for tools you trust. Connection authorization decides what the provider permits; the approval decides what runs now.

​
Verify at the provider

The agent rereads both GitHub and Notion and compares the actual state against the promised end state. Do the same yourself. The run is done when you have verified it, not when the last tool call returned. “Tool returned success” is not the finish line. The verification pass:
  • Open every created record at its provider.
  • Check its visibility: private means private.
  • Follow every cross-link.
  • Compare what each record says with the agent’s summary.
Summaries drift from reality in both directions: a step marked complete that is not, or a claim about the product that nothing supports. The provider-side check catches both. Where a record is wrong, correct it before anyone consumes the artifacts.

​
Correct tightly, then verify again

When a record needs a fix, run a follow-up that touches only that record and does only that fix. Re-run the same provider-side check afterward. A correction that rewrites three artifacts to fix one field is how a verified state becomes an unverified one.
Scope every correction: one follow-up, one target, one change. If the fix is bigger than that, it is a new run with its own checkpoint, not a correction.

​
What good looks like

  • Both providers were queried before anything was created.
  • Each write had its own checkpoint naming owner, visibility, and contents.
  • Every created record was opened at the provider, and every cross-link was followed.
  • The corrected state, not the first summary, is what got handed off.

​
Good to know

  • Each write is its own checkpoint, and each checkpoint is a tool-approval card. Allow once while learning the flow; always-allow for tools you trust.
  • Connection authorization decides what the provider permits. The approval decides what runs now.
  • The cross-link checkpoint updates only the new README.
  • A correction is one follow-up, one target, one change. Anything bigger is a new run with its own checkpoint.
  • The run is done when you have verified it at the provider, not when the last tool call returned.

​
Next step

Keep the mode cheat sheet and copy/paste prompts close in the Quick reference.