Modules

Modules are reusable building blocks of configuration. A Lane doesn't hold tokens or service settings itself — it attaches modules, and each module points at a credential from Settings → Credentials. That indirection is the point: rotate a token or rename a channel in one place and every Lane using it picks up the change.

There are six module kinds. Two are required before a Lane can run; four are optional add-ons:

Kind	What it does	Required?
Ticketing	Where tickets are discovered (GitHub Issues, Jira Cloud, or Shortcut)	Yes
Version Control	Push branches and open PRs (GitHub, Bitbucket Cloud, or Azure Repos)	Yes
Messaging	Discord / Slack pings on PR opened or run failed	No
Coding Standards	Injects your house style into every workspace	No
Blueprints	Lets agents read per-repo .agent/ docs before exploring	No
Agent Tuning (beta)	Adds custom instructions to individual agents	No

Every module has a name, an enabled toggle, and (where it talks to a service) a credential picker — you can select an existing credential or create one inline. The adapter (GitHub vs Jira, Discord vs Slack) is chosen at creation and fixed afterwards; to switch providers, create a new module.

Ticketing

Defines a ticket source for Lanes to poll.

• GitHub — a label tracker. Point it at one repo (owner + repo); tickets are that repo's issues, driven by labels. An optional API base URL supports GitHub Enterprise.
• Jira Cloud — a status tracker: Lanes drive it by native workflow statuses (Ready → In Progress → Done, etc.). The site URL and account live in the Jira credential; optionally set a project key to scope discovery to one project (blank = every project the credential can see). Status moves go through Jira transitions — the target status must be reachable from the ticket's current status in your Jira workflow, or the move is skipped (and logged). So the statuses you map on a Lane have to be connected in the workflow.
• Shortcut — a status tracker too: Lanes drive it by workflow states. An API token in the Shortcut credential is all it needs; done/archived stories are skipped on discovery. Unlike Jira there are no transition constraints — a state is set directly by name. (Comments are posted, and labels can still be applied where a stage maps to one.)

Which tickets actually get picked up is decided on the Lane — its discovery labels (label trackers) or its Ready status (status trackers), not the module. The module is just "where to look and with what access."

Version Control

Supplies the access a Lane uses to clone repos, push branches, and open PRs.

• GitHub, Bitbucket Cloud, or Azure Repos, each backed by a credential of the matching type. Azure additionally takes the organization on the module, and its repos are named project/repo (not owner/repo).
• Default base branch — what PRs target when nothing more specific is set. A Lane (or an individual repo on a Lane) can override it; the precedence is per-repo → Lane → this module → main.

One Version Control module is shared across all of a Lane's workspace repos, so the credential must be able to reach every repo on the Lane — the Verify button on each Lane repo row checks exactly that.

Messaging

Sends a ping to a channel at key moments. Adapters: Discord and Slack, each backed by a webhook credential.

The module carries the channel identity — optional bot username, icon/avatar, and (Slack) a channel override. Which events it fires on is chosen per Lane: when you attach the module, you pick its hooks — PR opened, Run failed, or both. The same module can be attached to many Lanes with different hooks on each.

Coding Standards

A markdown document of your team's standards. When attached to a Lane, it's written into every repo of the workspace as CODING-STANDARD.md at the start of each run, and the agents treat it as a normative file — naming, patterns, things to avoid.

There's no credential here; the module is the content. Keep it focused: rules that change what the agent writes, not general philosophy.

Blueprints

Gives the agents a memory layer: per-repo "where things are and how data flows" docs in a .agent/ directory inside the repo. With a Blueprint module attached, the planning and coding agents read these docs before exploring the codebase — which materially cuts exploration time and tokens on larger repos.

• Root directory — where in each repo the docs live (default .agent).
• The one adapter today is Markdown (filesystem) — docs are plain markdown committed in the repo itself.

You usually don't write .agent/ docs by hand — the indexer generates them. Both generation controls live on the Lane’s Blueprints section (see Lanes), along with the writeback mode that governs whether runs update the docs as they learn.

Agent Tuning (beta)

Customizes the agents themselves. For each of the six agents (PM, Architect, Test Author, Developer, QA, DevOps) you can write extra instructions, applied at run time. Additions only — the standard agent behavior is preserved, your text layers constraints on top.

Use it for per-Lane working agreements: "always update the changelog," "prefer integration tests," "never touch generated files." Leave an agent's box empty to keep it unchanged.

Creating and editing

Each kind has its own list page under Modules in the sidebar, with a form per module. A few behaviors to know:

• Inline credential creation — the credential picker lets you create a new credential without leaving the form.
• Disable instead of delete — unchecking Enabled takes a module out of service without breaking the Lanes that reference it.
• Deleting is protected — a module still referenced by a Lane can't be deleted; detach it from the Lane first.