notion-workers AGENTS.md

Repository instructions for a monorepo, meaning one repository containing several separate deployed projects, called Notion Workers. Each worker is its own npm project that connects an outside service to Notion.

In plain words
What is it for?
Use them when building or editing a worker, especially its TypeScript entry point, package files, deployment settings, capability integrations, or tests.
Why use it?
They explain that commands and files belong to an individual worker rather than a shared project root. They also prevent naming, deployment, configuration, and API mistakes when adding or changing workers.

Instructions file for CodexOpenCode

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add instructions/colebemis/notion-workers/agents-md
Clone the repo
git clone --depth 1 https://github.com/colebemis/notion-workers

Made for: Codex, OpenCode.

Per session 987 This file is loaded in full into every session.
When invoked 987 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00987 $0.00987
Opus 5 $0.00494 $0.00494
Sonnet 5 $0.00197 $0.00197
Haiku 4.5 $0.00099 $0.00099

Measured 2d ago against content hash d3710966d767, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

notion-workers AGENTS.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

AGENTS.md · 49 lines

How it starts

The opening of the file, as written. The whole thing — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Notion Workers monorepo

This repo holds all of my Notion Workers. Each top-level directory (e.g. firecrawl/) is one deployed worker: a self-contained npm project with its own package.json, lockfile, src/index.ts, and workers.json.

For the full Notion Workers platform guide — capability API (tools, syncs, automations, webhooks, OAuth), sync patterns, testing, and debugging — read .agents/INSTRUCTIONS.md. Skills for sync work live in .agents/skills/, and .examples/ has one compilable reference example per capability type — when it and INSTRUCTIONS.md disagree on API shape, trust .examples/.

Conventions

  • All ntn and npm commands run from inside a worker's directory, not the repo root. There is no root package.json and no shared dependencies.
  • Workers are named after the upstream service they wrap (firecrawl, openlibrary), no -worker suffix. Directory name, package.json name, and deployed worker name (deploy --name) all match.
  • workers.json is committed (it holds the workspace/worker IDs that link a directory to its deployed worker — IDs, not secrets). This deviates from the official scaffold's .gitignore. Never gitignore it here, and never delete it for an existing worker: without it, ntn workers deploy creates a new worker instead of updating.
  • Secrets are never committed. Local dev reads .env (gitignored); deployed workers read env vars set via ntn workers env set / ntn workers env push. If you add a new secret, push it before deploying code that needs it.
  • Each worker has a short README.md: what it does, its capabilities, and required env vars. Keep it current when you change capabilities.
  • A worker may have its own AGENTS.md (with a CLAUDE.md symlink, like the root). Worker-specific rules there OVERRIDE these norms — read it before touching that worker. Example: twitter/ forbids the standard local-exec verify loop because of its token handling.
  • Tool schemas use the j builder (import { j } from "@notionhq/workers/schema-builder"). SDK ≥ 0.4.0 no longer accepts raw JSON Schema objects in tool() — some examples in .agents/INSTRUCTIONS.md predate this; .examples/tool-example.ts shows the current API.
  • Every tool input property is required. The SDK rejects schemas whose properties aren't all in required; .nullable() means present-but-null, not omittable. Agent callers omit fields they don't need and fail validation, so keep tool inputs to fields the caller will always send.
  • No "type": "module" in worker package.json files. ntn workers exec --local (CLI 0.16.0) fails on ESM workers with Cannot read properties of undefined (reading 'run'). CJS mode works locally and deploys identically (requires typescript ≥ 5.8 to type-check importing the ESM SDK). new-worker.sh strips this from new scaffolds automatically.

Read the full file on GitHub · 49 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 49 lines · 987 tokens per session scan A d3710966d767

Subscribe to this mod's changes

notion-workers AGENTS.md is an instructions file published in the GitHub repository colebemis/notion-workers (126 stars, last pushed 1mo ago), licensed MIT. It adds 987 tokens to every session, about $0.0049 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other instructions, from other repositories

spec-kit AGENTS.md

AGENTS.md instructions for github/spec-kit, covering agents.md, about spec kit and specify, quickstart — add a new integration in 5 steps, integration architecture and integrationmanifest — file tracking.

github/spec-kit · 7,104 tokens

codex AGENTS.md

AGENTS.md instructions for openai/codex, covering rust/codex-rs, the codex-core crate, code review rules, crate api surface and model visible context.

openai/codex · 5,182 tokens

vscode buildNext.instructions.md

Working notes and architecture documentation for the new esbuild-based build system in build/next. Use when making changes to the new build pipeline (transpile/bundle commands, NLS plugin, source-map handling, resource copying, or self-hosting watch tasks).

microsoft/vscode · 6,785 tokens

langchain AGENTS.md

AGENTS.md instructions for langchain-ai/langchain, covering global development guidelines for the langchain monorepo, corridor security analysis, project architecture and context, monorepo structure and development tools & commands.

langchain-ai/langchain · 4,345 tokens

vscode oss-third-party-notices.instructions.md

Instructions for microsoft/vscode, covering vs code oss third-party-notices pipeline, architecture, pipeline flow in ci, applying the notice (cutover) and fallback chain (never fail the build).

microsoft/vscode · 5,001 tokens

next.js AGENTS.md

Instructions for vercel/next.js, covering next.js development guide, codebase structure, monorepo overview, core package: packages/next and other important packages.

vercel/next.js · 7,296 tokens