Welcome to LoomAI

LoomAI is an AI-driven, multi-agent ticket orchestrator that turns tickets into reviewable pull requests automatically. You configure where tickets come from and which repos the work lands in; the orchestrator runs the work; you keep the human-in-the-loop checkpoint at PR review.

How it works at a glance

1. You mark a ticket ready in your source — label it (e.g. ai-eligible) on GitHub Issues, or move it to a Ready status on Jira / Shortcut.
2. The orchestrator picks it up and creates a record — the in-flight work item you watch on the Dashboard.
3. A team of AI agents works the ticket end to end: PM → Architect → Test Author → Developer → QA → DevOps — requirements, design, failing tests, implementation, adversarial review, then commit and ship.
4. A pull request opens in every affected repo, and the ticket gets a comment with the results.
5. You review and merge. Done means "ready for your review," never "merged."

Your account

LoomAI is multi-tenant: everything you create — credentials, modules, Lanes, runs — belongs to your account and is invisible to other accounts. You also bring your own Claude credential, so your runs bill to your own Anthropic plan. Sign in with the account you were invited with; there's no self-signup.

Setup: from zero to first PR

The pieces stack in this order — each step is used by the one after it:

Claude credential → service credentials → modules → a Lane → label a ticket.

Step 1 — Add your Claude credential

Open Settings → Credentials (the gear in the top bar). At the top, under Anthropic, choose an auth mode and paste the secret:

• OAuth token (subscription) — generated with claude setup-token on your machine. Runs bill to your Claude subscription; usually the cheaper option.
• API key (metered) — a key from the Anthropic Console; runs bill per token.

Pick a Default model while you're here — it's the biggest cost/quality lever, and individual Lanes can override it later.

This step is required: an account with no Claude credential can't run anything — runs fail immediately with an authentication error that links you back here.

All secrets are encrypted at rest and never shown again after saving; the UI only ever displays the last few characters so you can tell which key is loaded.

Step 2 — Add service credentials

Still in Settings → Credentials, under Reusable credentials, add the secrets for the services your tickets and repos live in:

• GitHub PAT — used by GitHub Ticketing and Version Control modules. Scopes matter here — this is the most common setup failure:
  • Classic PAT: the full repo scope (public_repo is not enough — private repos read as 404).
  • Fine-grained PAT: resource owner = the repo's owner, Repository access must include your target repos, permissions Contents: R/W, Pull requests: R/W, Metadata: R (+ Issues: R/W for Ticketing).
• Jira Cloud — site URL, account email, and API token, if your tickets live in Jira.
• Shortcut — an API token, if your tickets live in Shortcut.
• Bitbucket Cloud — account email and API token (Repositories R/W + Pull requests R/W), if your repos live in Bitbucket.
• Azure DevOps PAT — Code: Read & write, if your repos live in Azure Repos (the organization is set on the module).
• Discord / Slack webhook — only if you want run notifications in a channel.

Each credential gets a name and a Verify button — verify as you go, it's much easier than debugging a failed run later. Credentials are reusable on purpose: many modules can point at one credential, so rotating a token is a one-field edit.

If Verify fails with "not found": a private repo the token can't see returns 404 — it reads as "doesn't exist" but almost always means scopes or the fine-grained allow-list. The fix steps are in Troubleshooting.

Step 3 — Create your modules

Modules are the building blocks a Lane attaches to. Go to the Modules section in the sidebar. Two are required:

• Ticketing (GitHub, Jira Cloud, or Shortcut) — where tickets are discovered. Points at a credential from Step 2.
• Version Control (GitHub, Bitbucket Cloud, or Azure Repos) — where branches are pushed and PRs open. Also points at a credential.

The rest are optional and can wait until after your first run: Messaging (Discord/Slack notifications), Coding Standards (a markdown standard injected into every workspace), Blueprints (a per-repo docs/memory layer the agents read), and Agent Tuning (per-agent custom instructions). See Modules.

Step 4 — Create a Lane

A Lane ties it all together: one ticketing source, one or more repos, and the modules to use. Go to Lanes → New Lane:

1. Name it and leave Enabled checked.
2. Ticketing — select your Ticketing module. The form adapts to the tracker: set a discovery label (e.g. ai-eligible) on GitHub, or a Ready status on Jira / Shortcut, as the per-ticket trigger. See Lanes for the full lifecycle (and, on status trackers, why mapping In Progress matters).
3. Version Control — select your Version Control module.
4. Workspace Repos — add at least one repo (owner/repo; on Azure, project/repo) and give it a role (e.g. primary). Press Verify on each row to confirm the credential can reach it. A Lane with several repos gives the agents a multi-repo workspace — cross-repo tickets open a PR in each affected repo.
5. Save. The Lane starts polling immediately.

Everything else on the Lane form — the lifecycle (label transitions or status moves), model override, silent mode, AGENTS.md and Blueprints generation — is optional tuning, covered in Lanes.

Step 5 — Mark a ticket ready and watch

Mark a real ticket ready — apply your discovery label (GitHub) or move it to your Ready status (Jira / Shortcut). Within a poll cycle (about 30 seconds) it appears on the Dashboard as a record in Picked Up, then walks through Planning → Coding → Reviewing → Finalizing. Click the row to watch the agents work live. When it lands on Done, the PR is open and waiting for your review.

Tip for your first run: start with a small, well-described ticket — a clear title, the expected behavior, and any constraints. The PM agent turns the ticket text into requirements, so the better the ticket reads, the better the PR.

Quick checklist

#	Where	What	Required
1	Settings → Credentials	Anthropic OAuth token or API key + default model	Yes
2	Settings → Credentials	GitHub PAT (and/or Jira, Shortcut, Bitbucket, webhooks)	Yes
3	Modules	Ticketing module + Version Control module	Yes
4	Lanes	A Lane: modules attached, ≥ 1 verified repo, Ready trigger (label or status), enabled	Yes
5	Your ticket tracker	Mark a ticket ready — discovery label or Ready status	Yes

Where to go next

• Dashboard — reading run states, finding runs, triaging failures.
• Lanes — discovery, the lifecycle (labels or statuses), multi-repo workspaces, and the optional tuning.
• Modules — all six module kinds in depth.
• Analytics — spend, throughput, and success rate across all your runs.
• Troubleshooting — symptom-by-symptom fixes: PAT scopes, repos that won't verify, tickets not picked up, failed runs.