Skip to main content
Experimental version.This is the latest in-development version of AI-Implement. Features may change without notice and behavior is not guaranteed. Switch to the latest stable version here.
bd-project-setup wires one project to its tools. It creates the connection to your ticketing system, authorizes it against your workspace, and writes down the bindings that every other bd- skill relies on to know where your issues and repository live. You run it yourself, inside your Claude Code session, as a one-time step per project.

​
When to run it

Run bd-project-setup once per project, right after you’ve installed the skills and reloaded your session. Until it’s done, the other bd- skills have nothing pointing them at your issues.
This assumes the skills are already installed and your session reloaded. If not, start with installation first.

​
Running it

1

Invoke the skill

From your project’s Claude Code session, run:
Answer its prompts about which ticketing system you use and which workspace to bind. The skill handles the rest.
2

Let it detect what's already there

Before writing anything, the skill checks whether the project is already wired up. If a connection, pre-approval, or bindings already exist, it works around them rather than duplicating or clobbering your setup.
This makes the skill safe to re-run. If you’re unsure whether setup finished, just invoke it again.
3

Authorize your workspace

The skill starts the sign-in from within the session. When the grant screen appears, you pick the workspace you want this project bound to.
The workspace you choose in the grant is the one this project will file and read issues in. Pick deliberately — if you have more than one, make sure it’s the right one.
4

Confirm it finished

When the skill is done, your project has a connection, it’s pre-approved so the other skills can use it without prompting each time, and the bindings are recorded for the rest of the suite to read.
Setup is complete. The other bd- skills can now find your issues and repository.

​
What it changes

Running the skill leaves your project with three things in place:
  • A connection to your ticketing system — the link between this project and Linear or Jira.
  • A standing pre-approval — so the other skills can reach it without asking for permission on every run.
  • Recorded bindings — a small record of your ticketing system, workspace, and repository that every bd- skill reads to orient itself.

​
Knowledge graph (optional)

The skill has a second pass that binds this project to a knowledge graph — the shared project memory bd-kg-search queries, and that the planning and landing skills consult before they act. It never runs as part of the setup above. You invoke it deliberately, and it follows the same detect-then-confirm discipline: it reports what it finds and asks before changing anything.
Skipping this is a valid end state, not an unfinished setup. Without a bound graph the knowledge-graph skills simply do nothing, and every other skill carries on unaffected.
1

Point it at an orchestrator

The graph is served by an orchestrator, so the skill asks which one and checks that it answers.If your project doesn’t have a graph yet, the skill can hand off to bd-kg-create to build one, then come back and finish the binding. Declining outright is also recorded, so it stops asking.
2

Register the sign-in callback URLs

Signing in to the graph uses its own callback URLs, separate from the ones your orchestrator’s admin sign-in uses. The skill checks them before asking anyone to sign in, and prints the exact URL to add.
Admin sign-in working does not mean these are registered — they are a different set of URLs on the same provider application. If they are missing, the next step fails in your browser with a redirect-mismatch error.
Add that URL verbatim under Authorized redirect URIs — in Google Cloud Console under APIs & Services → Credentials, or in Microsoft Entra under App registrations → Authentication.
3

Sign in

Approve the sign-in in your browser. This is per person rather than per project, and your identity has to be one the orchestrator allows.Access lasts about an hour. When it expires you sign in again — the binding itself stays intact.
4

Restart and verify

Restart Claude Code so the new connection loads, then run a real search against the graph rather than checking only that it connects.
A search for a term from your project comes back with results. Empty results mean the graph is reachable but isn’t serving your project’s content.
Keeping the graph’s contents current isn’t part of setup — that’s bd-kg-refresh, run when the graph goes stale rather than when a project binds.

​
Key rules

  • One ticketing system per project. A project is bound to Linear or Jira, never both at once. Choose the one that owns this project’s issues.
    Linear is supported across the whole suite. Jira works, but some skills describe it in terms projected from their Linear behavior rather than fully adapted — see ticketing support for which.
  • Give each connection a distinct name. Claude Code stores one login per connection name, and a login points at a single workspace. The name is only a label: a connection can reach the whole workspace you authorize it against, and the team it files into is a separate binding. The same holds for an orchestrator connection bound in the knowledge-graph pass.
    If two projects share a name, they share a login under that name — so authorizing the connection for one project’s workspace silently switches the other project onto it too.
  • Run it once per project. Setup is a one-time step. You don’t repeat it for everyday work — only when you’re onboarding a new project.
  • Re-invoke after a mid-run reload. If your session reloads partway through setup, run bd-project-setup again. It picks up from where it left off and finishes the parts that didn’t complete.