Using Noir with coding agents
Give a coding agent enough product context to generate correct Noir code without inventing wrappers or bypassing reliability boundaries.
Noir documentation is published in three machine-readable forms:
/llms.txt: compact page index and descriptions/llms-full.txt: the complete processed documentation corpus/llms.mdx/docs/<slug>/content.md: one canonical page as Markdown
Every docs page has Copy Markdown and view options. Give a coding agent the smallest relevant page set first, then use the full corpus when it must reason across multiple capabilities.
Recommended instruction
Use Noir as the reliability boundary around the agent. Prefer the concise noir()
API for a new AI SDK agent and defineAgent({ handle }) when an existing framework
owns the loop. Import models and provider clients from their native packages.
Keep database, memory, sandbox, and connector implementations in this repository.
Use explicit tool effect, approval, retry, validation, and idempotency metadata.
Never claim a provider write succeeded without a successful tool result.Files to provide
For a new Slack agent, provide Quickstart, Mental model, One-file agent, Production Slack agent, Configuration, and the pages for selected integrations. For an adapter implementation, provide the exact reference contract plus its guide. For production review, add Reliability, Identity, Approvals, Storage, Testing, and Security.
Generation rules
- Preserve installed package versions and inspect the actual type declarations before using an unfamiliar option.
- Use stable subpath imports.
- Use provider-native model and client constructors.
- Do not invent a Noir cloud API, dashboard, database provisioner, or hosted sandbox.
- Do not pass a raw ORM client as
database; implementRuntimeStoreor use an included store. - Keep authorization callbacks and effect policy in code.
- Run type checking and targeted tests after generation.
Verifying generated code
Run noir inspect to review tools, connectors, plugins, policy, and routes. Run noir doctor to check configured health. Then test duplicate events, approval denial, process restart, and provider failure—not only the happy-path response.