Introduction
Implement With AI
Give a coding agent the right Runlane docs context before it changes your app.
Use this page when you want a coding assistant to add Runlane to an existing TypeScript project. The goal is simple: give the agent enough product context, Markdown docs, and implementation constraints that it can move quickly without inventing APIs or taking shortcuts.
Runlane docs expose Markdown for agents:
| Need | URL or request |
|---|---|
| Docs map | /llms.txt |
| Full processed docs | /llms-full.txt |
| One page as Markdown | Append .md, such as /introduction/quick-start.md |
| Header-based Markdown | Request the normal page with Accept: text/markdown |
Example:
curl -H "Accept: text/markdown" https://www.runlane.sh/introduction/quick-startCopy-Paste Prompt
Paste this into your coding assistant after giving it access to your project:
Implement Runlane in this project.
Before changing code:
1. Read Runlane docs as Markdown, not rendered HTML.
2. Fetch https://www.runlane.sh/llms.txt for the docs map.
3. Fetch the required docs below with ".md" appended, or request the normal URL with "Accept: text/markdown".
4. Do not assume Runlane APIs from memory. Treat the docs as the source of truth.
5. Inspect this project before proposing changes:
- package manager and dependency conventions
- existing async, background job, queue, cron, or worker code
- database and runtime configuration
- deployment and worker model
- environment variable conventions
- validation and schema style
- logging and error handling style
- test structure and verification commands
Required Runlane docs:
- https://www.runlane.sh/introduction.md
- https://www.runlane.sh/introduction/quick-start.md
- https://www.runlane.sh/concepts.md
- https://www.runlane.sh/concepts/job-shapes.md
- https://www.runlane.sh/concepts/tasks-and-runs.md
- https://www.runlane.sh/concepts/queues.md
- https://www.runlane.sh/concepts/workers.md
- https://www.runlane.sh/concepts/retry-vs-release.md
- https://www.runlane.sh/concepts/lanes-storage-and-transport.md
- https://www.runlane.sh/concepts/local-development.md
- https://www.runlane.sh/configuration.md
Pick the integration path from the docs:
- Use @runlane/lane-local for local development, tests, demos, and first integration.
- Use a production lane only when this project already has the required infrastructure or the task explicitly includes adding it.
- If production uses Postgres and SQS, read:
- https://www.runlane.sh/contracts/postgres-sqs-lane.md
- https://www.runlane.sh/contracts/postgres-storage.md
- https://www.runlane.sh/contracts/sqs-transport.md
- https://www.runlane.sh/configuration/cli.md
- If the app needs schedules, read https://www.runlane.sh/concepts/schedules.md.
- If the app needs operator tooling, read https://www.runlane.sh/concepts/operator-apis.md.
- If the app needs custom storage or transport, read:
- https://www.runlane.sh/contracts.md
- https://www.runlane.sh/contracts/adapter-authoring.md
- https://www.runlane.sh/contracts/testing.md
Implementation rules:
- Keep Runlane runtime and lane configuration centralized.
- Define tasks with payload schemas at the boundary where work enters Runlane.
- Keep task handlers close to the domain code they execute.
- Wire the producer path that calls trigger(), runNow(), or schedules based on the docs and the project need.
- Wire the execution path: local executeNext() or worker() for development, executeDelivery(message) for delivered wakeups, or the documented production worker shape.
- Wire tick() only where the docs require maintenance for schedules, releases, retries, expired leases, cancellation cleanup, or outbox recovery.
- Do not hand-roll storage, transport, retry, release, schedule, cancellation, or lease behavior.
- Do not duplicate adapter-owned option schemas or hide contract failures behind wrappers.
- Do not add fake integrations, no-op workers, placeholder task handlers, or untested production config.
Verification:
- Add focused tests for the project behavior being moved into Runlane.
- Prove at least one end-to-end path: trigger a run, execute it through the selected execution path, and assert the observable result.
- If schedules, retries, releases, cancellation, or operator APIs are used, test those behaviors explicitly.
- Run the project's normal typecheck, lint, and test commands.
- Report the Runlane docs you used, files changed, verification commands, and any production infrastructure still required.Required Reading Path
If the agent has limited context, start with these pages in order:
| Step | Page | Why it matters |
|---|---|---|
| 1 | Runlane | Product model and the smallest durable primitives. |
| 2 | Quick Start | First runnable local integration. |
| 3 | Primitives | The nav-order mental model for tasks, runs, workers, and lanes. |
| 4 | Job Shapes | Whether the project needs background jobs, schedules, polling, or inline execution. |
| 5 | Tasks And Runs | Task schemas, ids, idempotency, singleton keys, concurrency keys, and run lifecycle. |
| 6 | Queues | Provider-neutral routing and capacity policy. |
| 7 | Workers | Polling workers, drain workers, delivered wakeups, leases, and heartbeats. |
| 8 | Retry Vs Release | The difference between failure pressure and business waiting. |
| 9 | Lanes, Storage, And Transport | The boundary that prevents agents from reimplementing adapter behavior. |
| 10 | Configuration | How runtime, lane, adapter, CLI, and deployment config fit together. |
Conditional Pages
Add these pages when the project needs the corresponding capability:
| Need | Read |
|---|---|
| Local-only dev or tests | Local Development, Local Lane Example |
| Scheduled jobs | Schedules |
| Inline durable execution | Current-Process Execution |
| Operator tooling | Operator APIs, Cancellation, Rerun And Manual Retry, Pruning |
| Production Postgres and SQS | Postgres + SQS Lane, Postgres Storage, SQS Transport, Runlane CLI |
| Custom adapters | Contracts, Adapter Authoring, Testing, Vocabulary |
What The Agent Should Avoid
The common failure mode is not moving too slowly. It is moving before understanding the boundary.
- Do not treat SQS, a cron job, or an in-memory queue as the durable source of truth.
- Do not skip payload validation because the caller "already has types."
- Do not invent wrapper APIs around Runlane until the project has a real repeated pattern.
- Do not put
tick()inside a delivery handler just to make a demo pass. - Do not use the local lane as a production durability boundary.
- Do not call a transport wakeup a job. Storage owns runs; transport wakes workers.
The first good implementation is usually small: one local lane, one task, one trigger path, one execution path, and tests that prove the behavior. Expand to production lanes, schedules, and operator APIs only when the project needs those capabilities.