Quick start and knowledgebase

Get your first task live in minutes.

Start with a normal task. Choose the view your team understands. Add admin rules and agent controls only when the work needs them.

Start now: Create one task and pick Cards, List, tags, or swimlanes.
Admin next: Set access, starter lanes, reminders, and support owner.
Agents wait: Keep agent writes off until scope, files, approvals, and proof are clear.

Start free See first 10 minutes

Signup open

Create the workspace first; pay later from Billing.

Start on Free, add one task, then upgrade only when real users or agent runs need it.

First 10 minutes

Do not configure everything first.

Create one real task, choose the simplest useful view, then stop. Admin and agent setup should wait until there is real work to shape.

Create the first task

Minute 1
Create the workspace
Start free and keep the default workflow.
Minute 3
Add one title
Create a real task before adding fields or agent settings.
Minute 6
Pick the view
Use Cards, List, tag buckets, or swimlanes.
Minute 10
Decide what to skip
Skip agent setup unless this task needs files, approvals, and proof.

Do this first

One task. One view. Then decide if you need admin or agent controls.

The quickstart is intentionally simple at the top. The detailed setup, MCP, migration, and knowledgebase sections are below for teams that need them.

For users5 min
1. Create one task
Type the title, create it, then add date or blocker when delivery matters.
Start free
For admins10 min
2. Set four controls
Set access, starter lanes, reminders, and support owner. Leave deeper settings for later.
Review setup
For agent operators15 min
3. Run read-only MCP smoke
Connect Codex, Claude Code, Cursor, or Cowork read-only after the first task has scope, files, approvals, and proof.
Connect agents

Coming from Jira, Linear, or Azure DevOps?Keep the human workflow. Add agent execution only when it helps.Start with familiar task tracker habits. Open this only if you need the migration bridge.Open bridge

A Jira, Linear, or Azure DevOps ticket

Create one normal task first. Add a clear task brief only when an agent will execute it.

A board, list, status, or tag workflow

Use Cards, List, tag buckets, or swimlanes from the same task data.

Comments, docs, and links spread around

Attach the files, docs, links, architecture notes, and decisions an agent needs before starting.

Done as a status move

Require tests, logs, screenshots, PRs, risk notes, or approval only where proof matters.

Choose one path

Users, admins, and agent operators should each know the next click.

User

I just need tasks

Start free, add one title, then use Cards, List, tags, or swimlanes.

Create first task

Admin

I need control

Set access, statuses, reminders, Done rules, and agent boundaries.

Open admin setup

Agent operator

I need safe AI execution

Connect MCP after the task has scope, files, approvals, and proof.

Connect agents

First workspace path

Get to first value without a setup consultant.

New teams should know exactly what to do next: start the workspace, add one real task, pick a view, set simple admin guardrails, then prepare agent handoff only when needed.

Try the guided path

01What do I do first?
Start free
Create the workspace and keep the default workflow until a real task needs more structure.
Proof: No sales call or setup project blocks the first useful action.
02What should I track?
Add one real task
Type the title and create the task. Defaults add Backlog, Medium priority, starter tags, and a 30 minute estimate; add date, blocker, or description after the task is visible.
Proof: The task appears in Cards, List, tag buckets, and swimlane/status buckets without filling agent or customer fields first.
03How do users work?
Choose the simplest view
Use the view the team already understands, then save filters only when they reduce noise.
Proof: Users can update work without learning an agent workflow first.
04What should admins set?
Admin guardrails
Rename statuses, set reminders, choose role access, and define what Done requires.
Proof: Admins can tighten the workspace without hiring setup support.
05When can agents start?
Add agent control only when needed
Add scope, non-goals, files and docs, allowed actions, approval rules, and proof before an agent claims work.
Proof: Only ready work reaches Codex, Claude Code, Cursor, Cowork, or another MCP client.

Admin setup

Four admin controls to set before inviting the whole team.

Admins do not need a setup project. Start with access, workflow language, reminders, and Done rules. Add agent boundaries only after a real task needs safe execution.

Open workspace rules

1. Invite people safely
Start with workspace admins and a small user group. Confirm who can create tasks, move work, edit rules, manage billing, and approve agent actions.
Manage access
2. Match the team's workflow
Rename statuses, choose swimlanes, set WIP limits, and keep the first saved views simple: Cards, List, tag buckets, or swimlane/status buckets.
Set rules
3. Define healthy work
Warn on missing dates, stale updates, overdue tasks, time over estimate, missing proof, and Done moves without proof.
Set reminders
4. Add agent boundaries last
Only after a real task is clear, decide which tools, repos, environments, data, approvals, run quota, and proof an agent may use.
Review agents

Choose your starting mode

Start with the simplest setup that makes today's work clear.

buildr-plannr does not force a full process on day one. Start as a lightweight tracker, add admin workflow control when the team needs structure, then enable agent execution only for work with enough files, allowed actions, and proof requirements.

Simple task tracker

Start with a bucket of tagged work.

Small teams that want tasks, owners, status, tags, due dates, comments, and a clean Cards or List view before adding process.

Start with

Create the first real task.
Add owner, date, priority, tag, and status.
Use Cards, List, tag buckets, or swimlane/status buckets.

Add when useful

Custom fields
Time tracking
Stale-work reminders

Proof: A teammate can open the workspace, understand the next action, and update work without training.

Start as a tracker

Custom team workflow

Shape the system around your operating model.

Admins who need custom swimlanes, terminology, roles, permissions, reminder rules, proof rules, imports, and billing controls from day one.

Start with

Rename statuses and swimlanes.
Set role access, invitation rules, and WIP expectations.
Choose what warnings and evidence block Done.

Add when useful

Advanced approvals
Import mapping
Audit exports

Proof: The admin can explain who may do what, when approval is needed, and what Done means before inviting the team.

Review admin controls

Agent execution system

Prepare work that AI agents can safely execute.

Teams using Codex, Claude Code, Cursor, Cowork, or other MCP-capable tools to pick up scoped software tasks.

Start with

Write a clear brief with scope and non-goals.
Attach files and docs, allowed tools, and blocked actions.
Require tests, screenshots, PRs, risk notes, and approval evidence.

Add when useful

Remote MCP
Run quota
Proof before Done rules

Proof: An agent can claim only ready work, act within policy, and return reviewable evidence before Done.

Prepare agent work

Plain-English product terms

Use normal task tracker words. Add agent terms only when they reduce risk.

Teams can start with tasks, statuses, tags, comments, and due dates. These execution terms explain the extra controls that make work safe for humans, admins, and AI agents.

Clear task brief: The clear brief for a task: goal, scope, non-goals, acceptance checks, tools, approvals, and proof required before the work is done.
Files and docs: The files, docs, links, architecture notes, decisions, and environment hints a teammate or agent needs before starting.
Allowed actions: The rules for who or what can act, where they can act, and when a human must approve before changes continue.
Proof before Done: Done means proof is attached: tests, logs, screenshots, pull requests, deployment notes, risk notes, and approvals.
Ready work queue: A prioritized list of work that is safe, unblocked, and ready for a human or AI agent to claim.

How to start

From loose task bucket to safe agent execution.

Start with any shape of work

Use a simple bucket of tagged tasks, a list, cards, or custom swimlanes. The system should adapt to the team instead of forcing a ceremony.

Customize statuses and swimlanes

Admins can model backlog, ready, in progress, review, done, customer validation, human blocked, or any other lane the workspace needs.

Write the task brief

Add scope, non-goals, constraints, expected output, proof, approval rules, and allowed tools before a human or agent starts.

Attach files, docs, and decisions

Give agents the exact files, docs, repo hints, decisions, and environment notes needed to complete the task without guessing.

Turn reminders into quality control

Warn when tasks have no expected completion date, no recent update, overdue due dates, missing proof, or time logged over estimate.

Let agents connect through MCP

Codex, Claude Code, Cursor, Cowork, and other compatible tools can discover ready work, create scoped follow-up tasks, and fetch clear task briefs through the remote MCP endpoint.

Migration playbook

Keep the human workflow. Add the agent execution layer.

Teams moving from Jira, Linear, or Azure DevOps should not throw away working habits. Preserve the useful tracking data, then make agent-owned work safe: clear scope, trusted context, allowed actions, readiness checks, and proof before Done.

Sources: 3
Benchmarks: 9
Setup steps: 12
Agent upgrades: 9

Keep from Jira, Linear, or Azure DevOps	Add before an agent starts
A task has a title, status, owner, and comments.	Add clear scope, non-goals, acceptance checks, and a named reviewer.
Context is spread across comments, docs, and links.	Attach the files, docs, architecture notes, and prior decisions before the agent starts.
Anyone with access can move or edit the task.	Limit the agent to approved tools, repos, environments, data, and actions.
The next task is whichever card is in the right column.	Prioritize by readiness, blockers, permissions, approvals, and run quota.
Done is a status move or a closing comment.	Require tests, logs, screenshots, PRs, risk notes, or approval proof.

From Jira

Deep workflow configuration, boards, backlog grooming, due dates, automation rules, comments, links, and work logs.

Market benchmark

Jira boards let admins add, delete, rename, move, and map workflow statuses to columns.
Column constraints and kanban backlog settings help teams spot bottlenecks and manage larger backlogs.
Jira automation captures process triggers, but agent execution still needs task-scoped files, allowed actions, and proof gates.

Keep

Issue keys, summaries, descriptions, priority, assignee, labels, links, due dates, estimates, and comments.
Board columns and workflow states that people already understand.
Automation intent such as assignment, linking, work logging, and escalation triggers.

buildr-plannr upgrade

Convert vague Jira descriptions into clear briefs with scope, non-goals, allowed tools, acceptance checks, and rollback notes.
Turn linked Confluence, repo, support, and architecture references into files and docs agents can use.
Replace status-only completion with proof before Done: tests, logs, screenshots, PRs, risk notes, and reviewer acceptance.

Setup path

Import active work first, then archive or export stale history separately.
Map Jira statuses to visible swimlanes and keep custom blocker lanes such as Needs human input.
Create saved views for human triage, ready-for-agent work, missing files or docs, and proof review.
Require clear briefs, files and docs, approvals, and proof before any imported task can enter Ready for agent.

Agent-readiness gap

A Jira issue can describe the work and workflow state, but agents need a verified brief that separates scope, non-goals, allowed tools, trusted files and docs, approval gates, and proof.

Agent readiness gate

Imported Jira work is ready for agents only after the clear brief, files and docs, allowed actions, and proof requirements are complete.

Execution control

Use scoped MCP/API tokens and approval gates before agents mutate imported Jira work.

Proof standard

Done requires mapped Jira context plus tests, screenshots or logs, pull request links, risk notes, and reviewer acceptance before the lane changes to complete.

Jira columns Jira automation Jira AI agents

From Linear

Fast issue capture, team workflows, display options, imports, triage, relations, projects, cycles, and lightweight views.

Market benchmark

Linear custom views create durable filtered views of issues, projects, or initiatives that teams can save and share.
Display options let teams group, order, and lay out issues around human planning habits.
Linear agents work alongside teams, but the planning layer still needs portable contracts, workspace policy, and evidence gates for external agent tools.

Keep

Issue titles, descriptions, workflow states, priority, estimates, labels, comments, relations, projects, initiatives, and dashboards where available.
Team-specific workflow language such as Backlog, Todo, In Progress, In Review, Done, and Canceled.
Clean display options such as grouping by status, assignee, project, priority, cycle, or focus.

buildr-plannr upgrade

Add agent-specific readiness queues instead of relying only on human workflow status.
Persist workspace planning defaults so humans and MCP clients see the same custom statuses, fields, and views.
Attach allowed actions, approval history, reminder policy, and time signals to each issue before agent execution.

Setup path

Run a small pilot import and verify which concepts should be kept versus left behind.
Map Linear workflow states into buildr-plannr swimlanes and saved views.
Create one human planning view and one agent execution view before inviting the wider team.
Require evidence and approvals before imported tasks can move from In Review to Done.

Agent-readiness gap

Linear can stay fast for human planning, but external agents need ready-work queues, token-scoped actions, expected proof, and shared workspace defaults instead of inferring intent from issue prose.

Agent readiness gate

Imported Linear work is ready for agents only when the issue explains what an agent may do, which files and docs are trusted, and what proof is required.

Execution control

Use ready-work queues, run quota, and MCP workspace customization so coding agents do not assume the old Linear workflow shape.

Proof standard

Done requires preserved Linear intent plus evidence attachments, approval history, time signals, and an explicit acceptance check that an agent or human can verify.

Linear imports Linear custom views Linear workflows Linear display options Linear agents

From Azure DevOps

Structured boards, work items, backlogs, sprints, queries, delivery plans, analytics, and Microsoft ecosystem integration.

Market benchmark

Azure Boards backlogs help teams plan, track, and organize user stories, features, and bugs across multiple teams.
Delivery Plans give cross-team calendar visibility into work, dependencies, and schedule risk.
Queries and portfolio hierarchy support management reporting, but agent execution still needs issue-level clear briefs, files and docs, and proof controls.

Keep

Epics, features, user stories, tasks, bugs, owners, priorities, iteration intent, links, and delivery-plan dependencies.
Queries that teams use for triage, bulk updates, dashboards, and cross-team reporting.
Sprint and backlog planning habits that give managers delivery visibility.

buildr-plannr upgrade

Keep portfolio structure, then add agent execution contracts (clear briefs) at the issue level.
Turn query-driven triage into ready-work queues for missing files or docs, blocked work, approvals, and proof review.
Use proof requirements and MCP permissions to make agent execution auditable outside the Microsoft suite.

Setup path

Choose the backlog levels that should become projects, milestones, or issue links.
Map Azure work item states into human swimlanes and agent readiness lanes.
Convert delivery-plan risks into dependencies, blockers, target dates, and file/doc requirements.
Rebuild critical queries as saved views for human triage, agent claims, overdue work, and evidence gaps.

Agent-readiness gap

Azure Boards can retain portfolio control, but agents need a smaller clear brief that makes dependency, permission, environment, billing, security, and verification risk explicit.

Agent readiness gate

Imported Azure Boards work is ready for agents only after dependencies, target dates, files and docs, allowed actions, and verification proof are explicit.

Execution control

Use allowed actions and approval gates when agents touch repositories, environments, billing surfaces, or customer-facing work.

Proof standard

Done requires backlog hierarchy plus dependency review, target-date health, test evidence, deployment or log proof, and a risk note tied to the original work item.

Azure Boards backlogs Azure Delivery Plans Azure queries

MCP quickstart

Remote MCP endpoint

Give coding tools a governed way to ask what to do next. The remote MCP surface starts at /api/mcp. Agents authenticate with scoped planner API tokens and fetch workspace customization, one-call preflight guidance, deterministic knowledgebase answers, ready work, task health reminders, scoped task creation, clear task brief reads and updates, files and docs, task search, status updates, comments, time logs, proof, and approvals without leaving their coding tool.

Connect an agent

Endpoint, scoped token, preflight decision. Then let the tool see ready work.

/api/mcp

1. Point the client at /api/mcp
Use the same remote endpoint for Codex, Claude Code, Cursor, Cowork, or another MCP client.
2. Use a scoped agent token
Start read-only, then add task write scopes only after the first smoke passes. The current write scope is still named issues:write for API compatibility.
3. Run preflight before writes
Call buildr_plannr.get_agent_preflight and read firstSessionDecision: tracking and admin setup can start, but agent writes wait until the gate passes.

Pick your client

Give each tool one clear first action.

Start read-only. Let the client prove the endpoint, list tools, and run preflight before it claims work or writes proof.

Codex

Read-only first

First setup action: Create a scoped agent API token in workspace settings.
First safe call: initialize
First write gate: First write allowed only after workspace customization, agent preflight, task reminders, and one owner-approved smoke task pass.

Claude Code

Read-only first

First setup action: Add the buildr-plannr remote MCP URL to the client configuration.
First safe call: initialize
First write gate: First write allowed only after read-only terminal smoke, task brief review, and owner approval for comment or proof scopes.

Cursor

Read-only first

First setup action: Add the remote MCP endpoint to the workspace-level MCP configuration.
First safe call: initialize
First write gate: First write allowed only after IDE task preflight, selected task brief and files check, and owner approval for claim, status, or time scopes.

Cowork

Read-only first

First setup action: Create a dedicated agent identity for Cowork.
First safe call: initialize
First write gate: First write allowed only after queue preflight, run quota check, retained smoke proof, and workspace-owner approval for claim, cancel, or proof scopes.

Public launch claims need proof first

Call buildr_plannr.get_launch_readiness before saying the product is launch-ready.

Release owners and agents can fetch implementation readiness, public-launch blockers, recurring release proof, capture plans, and proof templates from the same MCP endpoint. This keeps launch claims tied to retained proof instead of chat memory or optimistic status updates.

Implementation proof

Read the product readiness summary and keep the proof document path attached to the release note.

Public-launch blockers

Inspect launchProof.blockers before public claims; beta activation, customer language, admin terminology, and manual accessibility proof stay visible until externally captured.

Recurring release proof

Attach release browser QA and exact run links for every release candidate instead of saying tests passed from memory.

Proof templates

Use the capture plans and markdown templates to record fields, pass criteria, retention targets, and no-change rationales.

initialize

MCP JSON-RPC method supported by the planner endpoint.

tools/list

MCP JSON-RPC method supported by the planner endpoint.

tools/call

MCP JSON-RPC method supported by the planner endpoint.

Client setup guides

Connect Codex, Claude Code, Cursor, Cowork, or any MCP client.

Clients: 5
Capabilities: 31
Write-ready: 5
Smoke steps: 52

Smoke proof before writes: Each client gets a deterministic smoke packet: handshake, safe reads, workspace policy, write gate, and retained proof.
Safe-read checks: 25
Proof checks: 13

Copy this smoke path

Prove MCP works before enabling writes.

Send these read-only JSON-RPC calls to https://plannr.buildrlab.com/api/mcp with Authorization: Bearer $BUILDR_PLANNR_AGENT_TOKEN.

Read calls: 6
Write calls: 0
Final check: buildr_plannr.get_launch_readiness

01 initialize

Confirm the endpoint

Read only

The server returns buildr-plannr server info.

Proof: Endpoint, token, transport, and MCP protocol are valid.

JSON request

{
  "jsonrpc": "2.0",
  "id": "initialize",
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "clientInfo": {
      "name": "buildr-plannr-smoke",
      "version": "1.0.0"
    },
    "capabilities": {}
  }
}

02 tools/list

Discover planner tools

Read only

The response lists buildr_plannr.get_agent_preflight.

Proof: The client can see the planner contract before guessing.

JSON request

{
  "jsonrpc": "2.0",
  "id": "tools/list",
  "method": "tools/list"
}

03 buildr_plannr.get_agent_preflight

Read agent preflight

Read only

The response returns recommended next actions and policy warnings.

Proof: Agents can see blockers and safe next steps before work starts.

JSON request

{
  "jsonrpc": "2.0",
  "id": "tools/call",
  "method": "tools/call",
  "params": {
    "name": "buildr_plannr.get_agent_preflight",
    "arguments": {}
  }
}

04 buildr_plannr.get_workspace_customization

Read workspace rules

Read only

Statuses, swimlanes, fields, WIP limits, and evidence policy are returned.

Proof: The client will not hard-code the wrong workflow.

JSON request

{
  "jsonrpc": "2.0",
  "id": "tools/call",
  "method": "tools/call",
  "params": {
    "name": "buildr_plannr.get_workspace_customization",
    "arguments": {}
  }
}

05 buildr_plannr.list_task_reminders

Check delivery risks

Read only

The response returns stale, overdue, missing-date, or missing-time warnings.

Proof: Risky work is visible before anyone claims a task.

JSON request

{
  "jsonrpc": "2.0",
  "id": "tools/call",
  "method": "tools/call",
  "params": {
    "name": "buildr_plannr.list_task_reminders",
    "arguments": {
      "severity": "warning",
      "limit": 3
    }
  }
}

06 buildr_plannr.get_launch_readiness

Read launch proof

Read only

Launch blockers, capture plans, and evidence templates are returned.

Proof: Public launch claims stay tied to retained evidence.

JSON request

{
  "jsonrpc": "2.0",
  "id": "tools/call",
  "method": "tools/call",
  "params": {
    "name": "buildr_plannr.get_launch_readiness",
    "arguments": {}
  }
}

No claim, write, time, proof, or approval tool is called here. Enable write scopes only after this proof is retained.

Safe first run

Give every coding agent the same first 10 minutes.

Before Codex, Claude Code, Cursor, Cowork, or a generic MCP client changes work, it should prove the endpoint, read the workspace rules, choose safe work, and leave auditable proof. This keeps agent execution predictable even when each client has a different UI.

01Connect
Add the production or dev /api/mcp endpoint and pass a scoped agent token through Authorization or x-api-key.
Proof: The client can call initialize and the server name identifies buildr-plannr.
02Discover tools
Call tools/list and confirm buildr_plannr.get_agent_preflight plus task-named aliases such as buildr_plannr.search_tasks are available before any task mutation.
Proof: The client records the planner tool list and supported input schemas.
03Read rules
Call get_client_bootstrap, get_agent_preflight, get_launch_readiness, search_knowledgebase, list_task_reminders, and get_workspace_customization. Read firstSessionDecision before deciding whether agent writes can start.
Proof: The agent sees swimlanes, WIP limits, labels, proof rules, launch blockers, stale-work warnings, blocked actions, and the start-or-wait write gate.
04Check launch proof
Inspect launchProof.readyForPublicLaunch, blockers, capturePlans, and templates before public release notes, marketing claims, or launch summaries.
Proof: The client records whether launch proof is ready, which public-launch blockers remain, and which artifacts must be attached.
05Select safe work
Inspect list_ready_work or search_tasks and choose one low-risk task with a clear brief, files or docs, allowed actions, and approval rules.
Proof: The task has owner approval, scope, non-goals, allowed tools, constraints, verification commands, and expected proof.
06Prove write control
Claim one test task, post status, log time, attach proof, and release or complete the claim through MCP.
Proof: The workspace audit trail shows the client respected run quota, allowed actions, time tracking, and proof before Done.

Codex

Coding agents working in a repo checkout.

MCP ready

Use an agent-scoped token for autonomous runs and a user-scoped token for assisted human sessions.

Setup

Create a scoped agent API token in workspace settings.
Register the remote server URL as https://plannr.buildrlab.com/api/mcp or the dev URL for non-production testing.
Pass the token with either Authorization: Bearer <token> or x-api-key.

Verify

Call initialize and confirm the buildr-plannr server info.
Call tools/list and confirm planner tools are visible.
Call tools/call with buildr_plannr.get_agent_preflight as the safe first planner call before reading context or claiming work.

Recommended scopes: read:workspace, read:issue, claim:work, write:status, write:evidence
First safe calls: initialize, tools/list, buildr_plannr.get_client_bootstrap
First write gate: First write allowed only after workspace customization, agent preflight, task reminders, and one owner-approved smoke task pass.

Config snippet and write gate

{
  "mcpServers": {
    "buildr-plannr": {
      "url": "https://plannr.buildrlab.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ${BUILDR_PLANNR_AGENT_TOKEN}"
      },
      "note": "Codex should call buildr_plannr.get_agent_preflight and read firstSessionDecision before any write-capable tool."
    }
  }
}

Keep write and claim scopes disabled until the handshake, firstSessionDecision, workspace customization, and one approved test task prove the client can follow workspace rules. Scope names may still say read:issue or issues:write for API compatibility.

Capabilities: workspace customization, Cards/List/Tags/Swimlanes view preset contract, label taxonomy, rules center discovery, agent preflight, market standards, launch readiness proof, static knowledgebase search, task reminders, ready work discovery, agent claim queue, task creation, claim leases, agent status posts, claim cancellation, task briefs, task brief updates, files and docs, comments, time logging, evidence.

Claude Code

Terminal-based coding assistants that can call remote MCP tools.

MCP ready

Prefer a narrow agent token with read-work, files-and-docs, comment, and proof scopes first.

Setup

Add the buildr-plannr remote MCP URL to the client configuration.
Store the planner token in the client secret store or environment.
Keep write-capable scopes off until the workspace rules allow them.

Verify

Call initialize and confirm the buildr-plannr server info.
Call tools/list and inspect the input schema before the first run.
Call tools/call with buildr_plannr.get_agent_preflight and follow the recommended next actions before enabling write scopes.

Recommended scopes: read:workspace, read:issue, read:context-pack, write:comment
First safe calls: initialize, tools/list, buildr_plannr.get_client_bootstrap
First write gate: First write allowed only after read-only terminal smoke, task brief review, and owner approval for comment or proof scopes.

Config snippet and write gate

{
  "mcpServers": {
    "buildr-plannr": {
      "url": "https://plannr.buildrlab.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ${BUILDR_PLANNR_AGENT_TOKEN}"
      },
      "note": "Claude Code should call buildr_plannr.get_agent_preflight and read firstSessionDecision before any write-capable tool."
    }
  }
}

Capabilities: workspace customization, Cards/List/Tags/Swimlanes view preset contract, label taxonomy, rules center discovery, agent preflight, market standards, launch readiness proof, tool discovery, static knowledgebase search, task reminders, claim leases, task creation, task briefs, task brief updates, agent comments, approval requests, evidence.

Cursor

IDE users who want task context next to code changes.

MCP ready

Use per-workspace tokens; rotate them when an IDE workspace is shared or handed over.

Setup

Add the remote MCP endpoint to the workspace-level MCP configuration.
Use a token scoped to the current workspace and agent profile.
Keep the planner task ID in the prompt so comments and evidence attach to the right work item.

Verify

Call initialize and confirm the buildr-plannr server info.
Call tools/list and confirm planner tools are visible.
Call tools/call with buildr_plannr.get_agent_preflight for the workspace and selected task before opening generated code changes.

Recommended scopes: read:issue, read:context-pack, claim:work, write:status, write:time
First safe calls: initialize, tools/list, buildr_plannr.get_client_bootstrap
First write gate: First write allowed only after IDE task preflight, selected task brief and files check, and owner approval for claim, status, or time scopes.

Config snippet and write gate

{
  "mcpServers": {
    "buildr-plannr": {
      "url": "https://plannr.buildrlab.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ${BUILDR_PLANNR_AGENT_TOKEN}"
      },
      "note": "Cursor should call buildr_plannr.get_agent_preflight and read firstSessionDecision before any write-capable tool."
    }
  }
}

Capabilities: workspace customization, Cards/List/Tags/Swimlanes view preset contract, label taxonomy, rules center discovery, agent preflight, market standards, launch readiness proof, static knowledgebase search, task reminders, task search, task creation, claim leases, agent status posts, files and docs, task brief updates, status updates, time logging, approval requests.

Cowork

Team agents that claim and execute queued work.

MCP ready

Use an agent token pinned to the Cowork agent ID so it cannot post as another actor.

Setup

Create a dedicated agent identity for Cowork.
Grant only the task and agent scopes needed by that agent role.
Configure the remote endpoint and token in the agent runtime.

Verify

Call initialize and confirm the buildr-plannr server info.
Call tools/list and confirm planner tools are visible.
Call tools/call with buildr_plannr.get_agent_preflight before selecting queue work.

Recommended scopes: read:workspace, read:ready-work, claim:work, cancel:claim, write:evidence
First safe calls: initialize, tools/list, buildr_plannr.get_client_bootstrap
First write gate: First write allowed only after queue preflight, run quota check, retained smoke proof, and workspace-owner approval for claim, cancel, or proof scopes.

Config snippet and write gate

{
  "mcpServers": {
    "buildr-plannr": {
      "url": "https://plannr.buildrlab.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ${BUILDR_PLANNR_AGENT_TOKEN}"
      },
      "note": "Cowork should call buildr_plannr.get_agent_preflight and read firstSessionDecision before any write-capable tool."
    }
  }
}

Capabilities: workspace customization, Cards/List/Tags/Swimlanes view preset contract, label taxonomy, rules center discovery, agent preflight, market standards, launch readiness proof, static knowledgebase search, task reminders, ready work discovery, agent claim queue, task creation, claim leases, task brief updates, claim cancellation, status updates, comments, approval requests, evidence.

Generic MCP client

Any MCP-compatible client that can call streamable HTTP JSON-RPC.

MCP ready

Choose the narrowest token scope that allows the client to perform its exact workflow.

Setup

Set the server URL to /api/mcp.
Send JSON-RPC 2.0 requests over HTTPS.
Pass a scoped token and keep client logs redacted.

Verify

Call initialize.
Call tools/list.
Call tools/call with buildr_plannr.get_agent_preflight for one safe read-only packet.

Recommended scopes: read:workspace, read:issue, read:tools
First safe calls: initialize, tools/list, buildr_plannr.get_client_bootstrap
First write gate: Keep generic clients read-only until a named client profile is certified for the exact write workflow.

Config snippet and write gate

{
  "mcpServers": {
    "buildr-plannr": {
      "url": "https://plannr.buildrlab.com/api/mcp",
      "headers": {
        "x-api-key": "${BUILDR_PLANNR_AGENT_TOKEN}"
      },
      "note": "Generic MCP client should call buildr_plannr.get_agent_preflight and read firstSessionDecision before any write-capable tool."
    }
  }
}

Capabilities: workspace customization, Cards/List/Tags/Swimlanes view preset contract, label taxonomy, rules center discovery, agent preflight, market standards, launch readiness proof, static knowledgebase search, task reminders, initialize, tools/list, tools/call, claim leases, task creation, search, read-only onboarding.

Knowledgebase

Ask how to set up human and agent workflows.

This finder uses curated static answers and keyword matching only. It does not send questions to an AI model, so teams can rely on repeatable onboarding guidance.

Pick the closest path

Users

Admins

Buyers

Agent operators

Guide

What should I do first after signing up?

Create one real task, pick the simplest view, and add a date or move it to Blocked when it has none.

Do this next

Open the create task form and type one real task title.
Add only the task title if you want the fastest path; buildr-plannr puts it on the board immediately.

Full answerOpen

Detailed stepsOpen

Open first task

Guide

How is buildr-plannr different from Jira, Azure DevOps, or Linear?

Jira, Azure DevOps, and Linear track human work. buildr-plannr prepares work so AI agents can safely execute it.

Do this next

Use normal tasks, tags, lists, cards, and swimlanes for human work.
Clear task briefs, also called task contracts, turn vague tickets into scope, non-goals, tools, constraints, acceptance checks, and approval rules.

Full answerOpen

Detailed stepsOpen

Compare positioning

Guide

What can start now, and what should wait?

Start normal task tracking now. Wait on agent writes until scope, files, approvals, quota, and proof are clear.

Do this next

Start: create one real task with a title, status, tag, and expected date or blocker.
Start: choose Cards, List, tag buckets, or swimlanes from the same task data.

Full answerOpen

Detailed stepsOpen

Open quickstart

Guide

Should we buy buildr-plannr if we already use Jira, Linear, or Azure DevOps?

Keep your tracker for human-only work. Pilot buildr-plannr when agents need clear tasks, limits, and proof.

Do this next

Keep the existing tracker when the team only needs human-owned issues, boards, lists, statuses, and reports.
Pilot buildr-plannr beside the existing tracker when one task needs an AI agent to execute safely.

Full answerOpen

Detailed stepsOpen

Choose a licence

Get your first task live in minutes.

Create the workspace first; pay later from Billing.

Do not configure everything first.

Create the workspace

Add one title

Pick the view

Decide what to skip

One task. One view. Then decide if you need admin or agent controls.

1. Create one task

2. Set four controls

3. Run read-only MCP smoke

Users, admins, and agent operators should each know the next click.

I just need tasks

I need control

I need safe AI execution

Get to first value without a setup consultant.

Start free

Add one real task

Choose the simplest view

Admin guardrails

Add agent control only when needed

Four admin controls to set before inviting the whole team.

1. Invite people safely

2. Match the team's workflow

3. Define healthy work

4. Add agent boundaries last

Start with the simplest setup that makes today's work clear.

Start with a bucket of tagged work.

Shape the system around your operating model.

Prepare work that AI agents can safely execute.

Use normal task tracker words. Add agent terms only when they reduce risk.

From loose task bucket to safe agent execution.

Start with any shape of work

Customize statuses and swimlanes

Write the task brief

Attach files, docs, and decisions

Turn reminders into quality control

Let agents connect through MCP

Keep the human workflow. Add the agent execution layer.

Deep workflow configuration, boards, backlog grooming, due dates, automation rules, comments, links, and work logs.

Fast issue capture, team workflows, display options, imports, triage, relations, projects, cycles, and lightweight views.

Structured boards, work items, backlogs, sprints, queries, delivery plans, analytics, and Microsoft ecosystem integration.

Remote MCP endpoint

Endpoint, scoped token, preflight decision. Then let the tool see ready work.

1. Point the client at /api/mcp

2. Use a scoped agent token

3. Run preflight before writes

Give each tool one clear first action.

Codex

Claude Code

Cursor

Cowork

Call buildr_plannr.get_launch_readiness before saying the product is launch-ready.

Connect Codex, Claude Code, Cursor, Cowork, or any MCP client.

Prove MCP works before enabling writes.

Confirm the endpoint

Discover planner tools

Read agent preflight

Read workspace rules

Check delivery risks

Read launch proof

Give every coding agent the same first 10 minutes.

Codex

Claude Code

Cursor

Cowork

Generic MCP client

Ask how to set up human and agent workflows.

What should I do first after signing up?

How is buildr-plannr different from Jira, Azure DevOps, or Linear?

What can start now, and what should wait?

Should we buy buildr-plannr if we already use Jira, Linear, or Azure DevOps?