AI SDK Agent Rules

A TypeScript toolkit for building AI applications across model providers and UI frameworks.

Overview

The root guide covers provider architecture, security rules, and the checks to run before finishing. Larger design decisions and contributor workflows live in separate documents.

Documents

├── 
├──  · symlink → AGENTS.md
├── architecture
│   └── 
├── contributing
│   ├── decisions
│   │   ├── Accepted decisions relevant to the change
│   │   └── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   └── 
└── packages
    └── ai
        └── 

Techniques in this file

01

Give requests and responses different schema policies

User-facing options should be restrictive and optional unless null has meaning. Provider responses instead use nullish fields and minimal schemas so upstream API changes can be tolerated.

Source excerpt starting at line 226.
**Provider Options Schemas** (user-facing): - Use `.optional()` unless `null` is meaningful- Be as restrictive as possible for future flexibility **Response Schemas** (API responses): - Use `.nullish()` instead of `.optional()`- Keep minimal - only include properties you need- Allow flexibility for provider API changes

02 / Hard prohibitions

Make URL validation explicit at each fetch

Every getFromApi call must specify validateUrl, with different values for provider-returned URLs and configured base URLs. The rule also names credentialedOrigin to prevent credentials following an off-origin response.

Source excerpt starting at line 239.
- Every `getFromApi` call in this repository must set `validateUrl` explicitly  (the option is optional for backwards compatibility with external callers, but  omitting it skips validation — never rely on that; the  `ai-sdk/require-validate-url` oxlint rule fails `pnpm check` otherwise). Use  `true` when the URL comes from a provider response body (image/audio/video  download or a polling URL); use `false` only for URLs built from a configured  `baseURL`.- Pass `credentialedOrigin` when a response URL may legitimately carry the API  key on its first hop, so credentials are withheld off-origin.- See [contributing/secure-url-handling.md](contributing/secure-url-handling.md).

03 / Router files

Consult accepted decisions before changing architecture

The guide routes new dependencies, API design, patterns, and infrastructure through the ADR index. Contradicting an accepted decision triggers discussion before implementation.

Source excerpt starting at line 198.
This repo uses ADRs in `contributing/decisions/` to capture important architecture decisions. Before making changes that touch architecture (new dependencies, new patterns, API design, infrastructure), check existing ADRs: 1. Read `contributing/decisions/README.md` for the index of decisions.2. Read any accepted ADRs relevant to your area of work. Follow the decisions and implementation patterns they specify.3. If you encounter a pattern in the code and wonder "why is it done this way?", check whether an ADR explains it.4. If your work would contradict an existing accepted ADR, stop and discuss with the human before proceeding.

04 / Hard prohibitions

Use approved JSON parsing utilities

Production code must use parseJSON or safeParseJSON from provider-utils instead of JSON.parse directly. The prohibition identifies the shared replacement and gives security as its rationale.

Source excerpt starting at line 152.
Never use `JSON.parse` directly in production code to prevent security risks.Instead use `parseJSON` or `safeParseJSON` from `@ai-sdk/provider-utils`.

05 / Verification by change type

Define completion artifacts by task type

Bug fixes call for a reproduction, regression tests, implementation, manual verification, and a changeset. New features and internal refactors have separate lists, with explicit room to adjust for scope and visibility.

Source excerpt starting at line 280.
A complete bug fix typically includes: 1. **Reproduction example**: Create/update an example in `examples/` that demonstrates the bug before fixing2. **Unit tests**: Add tests that would fail without the fix (regression tests)3. **Implementation**: Fix the bug4. **Manual verification**: Run the reproduction example to confirm the fix5. **Changeset**: Describe what was broken and how it's fixed

Ideas for your repo

  1. Separate user-input schema policy from upstream-response tolerance.
  2. Make URL validation and credential forwarding explicit at each network boundary.
  3. Check recorded architecture decisions before introducing new patterns.
  4. Define completion artifacts by task type and visibility.
Sponsored byModem

Give your agents the whole story.

These instructions explain how to work in AI SDK. Modem shows your agents what customers said, who is affected, and what changed.

See how Modem works