> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withboundary.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Use Boundary With AI Coding Agents

> Prompt AI coding agents to add Boundary to existing or new LLM workflows.

Boundary exposes an agent-ready skill at `/skill.md` and LLM documentation indexes at `/llms.txt` and `/llms-full.txt`. Use them when you want an AI coding agent to add deterministic acceptance, repair, rejection, and logging around model output.

The best agent workflow is narrow: find where LLM output becomes trusted, add a contract there, and verify the accepted and rejected paths.

## What the Boundary skill does

The Boundary skill teaches an agent to:

* inspect the minimal model-output path before editing
* keep the user's current provider, prompt, and application architecture
* define a Zod schema plus named Boundary rules
* call the provider inside `contract.accept()`
* return raw provider text from the run function
* gate side effects on `result.ok`
* add `createBoundaryLogger()` only when production analytics are requested
* verify accepted, repaired, rejected, empty, and provider/runtime failure paths

## Install the skill

Point the agent at your Boundary docs domain:

<Prompt description="Install the Boundary skill in your AI coding agent." actions={["copy", "cursor"]}>
  npx skills add [https://docs.withboundary.com](https://docs.withboundary.com)
</Prompt>

If your agent cannot install skills directly, give it the docs links:

```text theme={null}
Use these Boundary docs resources before editing:
- https://docs.withboundary.com/skill.md
- https://docs.withboundary.com/llms.txt
- https://docs.withboundary.com/llms-full.txt
```

## Existing project prompt

Use this when adding Boundary to an app that already calls a model:

```text theme={null}
You are integrating Boundary into an existing codebase.

Do not scan or rewrite the entire repository. First identify the minimal LLM output path:
1. the provider or model call
2. parsing or schema validation
3. where parsed output is trusted by application code
4. existing retry or repair behavior
5. existing logging or telemetry

Then propose the smallest Boundary integration that:
- validates model output before application use
- adds semantic rules beyond schema validation
- repairs only when safe
- rejects invalid output deterministically
- logs pass, repair, rejection, empty output, and provider/runtime failure outcomes

Use current Boundary APIs:
- @withboundary/contract
- defineContract
- structured rules
- contract.accept()
- result.ok
- createBoundaryLogger from @withboundary/sdk only when analytics are requested

Do not replace the model provider.
Do not rewrite unrelated architecture.
Do not continue execution after Boundary rejects output.
Return the files to change, the contract to add, and a verification checklist before editing.
```

## New project prompt

Use this when starting a new Boundary-protected flow:

```text theme={null}
Create a new Boundary-protected LLM flow.

The flow should:
- call the existing or chosen model provider
- return the raw provider text from the Boundary run function
- parse structured output through Boundary
- validate it with a Boundary contract
- apply named semantic rules beyond schema validation
- attempt repair when safe
- reject invalid output deterministically
- log the outcome when analytics are configured
- expose enough metadata for analytics without logging raw sensitive data by default

Keep provider code, contract code, and application-use code separate.
Application code may only trust result.data when result.ok is true.

Include tests or fixtures for:
- clean pass
- repaired pass
- contract rejection
- empty response
- provider/runtime failure
```

## Contract-writing prompt

Use this when the agent needs to design the schema and rules:

```text theme={null}
Write a Boundary contract for this LLM output.

First identify:
- the output schema
- the product decision this output controls
- domain rules that must be true
- fields that are safe to repair
- fields that must never be guessed
- rejection conditions
- logging fields needed for debugging

Then produce:
- a Zod schema
- a defineContract() call
- named structured rules with name, description, fields, and check
- repair-friendly rule messages
- tests or fixtures for pass, repair, and rejection

Do not rely on schema validation alone.
Do not repair values that require external truth, such as prices, permissions, account limits, balances, or eligibility.
```

## Debugging prompt

Use this when a Boundary run fails:

```text theme={null}
Debug this Boundary failure.

Classify the failure as one of:
- schema failure
- semantic rule failure
- repair failure
- empty response
- provider/runtime failure
- logging or analytics classification issue

Then identify:
- the rule that blocked the output
- whether repair should have been attempted
- whether the candidate should be preserved for review
- whether the run should count toward contract pass rate
- whether empty output or provider/runtime failure was classified separately from contract rejection
- the smallest code, contract, prompt, or logging change needed

Do not hide provider/runtime failures inside generic validation errors.
Do not write rejected output to application state.
```

## Logging and analytics prompt

Use this when adding hosted Boundary observability:

```text theme={null}
Add Boundary logging and analytics to this contract.

Use createBoundaryLogger from @withboundary/sdk.
Keep raw inputs and outputs off by default.
Capture repair messages and failure metadata.
Configure environment from the runtime environment when available.
Use redaction before enabling raw payload capture.
Ensure missing API keys do not break local contract execution.

Verify logs include:
- contract name
- environment when configured
- outcome
- attempts and max attempts
- failure category
- rule blockers
- repairs when capture.repairs is enabled
```

## Exploration checklist

Ask the agent to search for these patterns before editing:

```text theme={null}
Provider calls:
- openai.responses.create
- openai.chat.completions.create
- anthropic.messages.create
- generateObject
- generateText
- model.invoke
- fetch calls to model gateways

Parsing and validation:
- JSON.parse
- z.parse
- safeParse
- response_format
- json_schema
- output_text
- message.content

Trusted use:
- database writes
- queue jobs
- tool execution
- workflow status updates
- outbound webhooks
- user-visible rendering

Existing controls:
- retry loops
- repair prompts
- fallback values
- review queues
- app logging and telemetry
```

## Example fixtures

Use small fixtures when adding tests:

```json valid-output.json theme={null}
{
  "tier": "warm",
  "score": 62,
  "reason": "Visited pricing twice and opened the onboarding email."
}
```

```json semantic-invalid-output.json theme={null}
{
  "tier": "hot",
  "score": 25,
  "reason": ""
}
```

```json repairable-output.json theme={null}
{
  "tier": "hot",
  "score": 68,
  "reason": "High intent, but score is below the hot threshold."
}
```

```text empty-response.txt theme={null}
```

```json provider-error.json theme={null}
{
  "error": "provider timeout"
}
```

These fixtures should exercise different outcomes. Empty output and provider/runtime errors should not be treated as semantic rule rejections.

## Anti-patterns

Do not let the agent:

* replace the model provider unless that is the requested task
* treat schema validation as sufficient
* continue execution after Boundary rejects output
* write rejected `cleaned` data to the database as a fallback
* count empty output or provider/runtime failures as contract rejections
* repair values that require external truth
* enable raw prompt or output capture without an explicit data-handling decision
* rewrite unrelated architecture while adding the contract

## Verification checklist

Before the integration is complete, verify:

* clean valid output passes
* repairable output repairs and then passes
* semantic invalid output rejects with a named rule blocker
* empty output is classified separately
* provider/runtime failure is classified separately
* logs include outcome, attempts, contract name, environment, and rule blockers when logging is configured
* no side effect runs unless `result.ok` is true