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.
A project mapping connects a ticketing-system scope (a Linear team or a Jira JQL clause) to a target GitHub repository and controls exactly how AI-Implement dispatches and runs implementations for that scope. Each mapping is stored in the orchestrator’s SQLite database and can be created, edited, or deleted through the admin UI at /admin. You need at least one mapping for the orchestrator to do any work.
The New project stepper doesn’t expose every field. Seven are set afterwards, by opening the project’s Edit dialog:
  • workflowFile and branchPrefix — under Source below
  • extraEnv — under Runner
  • planningWorkflowFile — under Planning
  • maxTurns, maxIterations, and maxJobMinutes — under Capacity
paused comes from neither dialog — it’s the Pause / Resume button on the project’s row.

Ticketing

string
default:"linear"
The ticketing system this mapping watches for issues. Accepted values: linear or jira. The orchestrator can mix Linear and Jira mappings within a single deployment; each mapping picks one provider.
string
required
Identifier for the ticketing scope this mapping watches.
  • For Linear, use your team’s identifier — the short prefix shown in issue numbers, e.g. ENG in ENG-42. The orchestrator matches polled issues to this repo by that key.
  • For Jira, choose any label you like. Jira has no equivalent team concept, so the jql clause in ticketingConfig does the scoping instead.
object
Provider-specific configuration for issue discovery. The shape depends on ticketingProvider:
The extra configuration fields for Jira are used as follows:
  • jql scopes which issues this mapping watches.
  • repoFieldValue is the option value of the AI-Implement Repo custom field.
  • The two …Override fields are optional customfield_NNNNN IDs you only need to set when Jira auto-discovery by name is ambiguous.
See Jira manual custom-field setup for more detailed information.

Source

string
required
GitHub organization name or username that owns the target repository (e.g. my-org).
string
required
Name of the target GitHub repository (e.g. my-api). Combined with owner, this tells the orchestrator where to dispatch workflow runs.
string
default:"main"
Branch that Claude creates pull requests against. Set this to master or your primary branch name if it differs.
string
Extra path segment prepended to every branch this project creates. Set it to pr and a branch that would have been ai-implement/… becomes pr/ai-implement/….
Useful when a repo’s branch protection or CI rules key off a particular prefix. Leave unset for no prefix.
string
default:"claude-implement.yml"
Name of the GitHub Actions workflow file to dispatch for implementation runs. Change the default only if you’ve renamed or customized the workflow file in the target repo.
string
Repository of skills to make available to Claude during this project’s runs, as an owner/repo shorthand or a full git URL. Cloned into the workspace before implementation begins.Leave unset to run without project skills. For /ai-implement comment-triggered runs, set the matching repo variable instead — see AI_IMPLEMENT_SKILLS_REPO.
array
Extra glob patterns treated as sensitive for this project, on top of the built-in list. A run that stages a matching file is blocked before it commits — see Blocked by a security guardrail.
Patterns match against both the full path and the file name, so *.pem catches certs/server.pem.
array
Glob patterns exempted from the sensitive-files check for this project. Useful for a fixture or example file whose name resembles a real credential.
Allow patterns are checked first and override the built-in list as well as your own additions — a file matching one is never blocked. Keep this list as narrow as you can.

Runner

string
default:"github-actions"
Where implementation runs execute.
  • github-actions — Claude runs inside a standard GitHub Actions job in the target repo. No additional infrastructure required.
  • fly-machines — Claude runs inside a Fly Machine launched by the orchestrator. Requires the Fly sessions app to be configured.
string
default:"autonomous"
How the Claude session behaves during a run.
  • autonomous — Claude works to completion without human interaction.
  • interactive — Claude pauses and waits for feedback at decision points.
  • hybrid — Claude proceeds autonomously but surfaces questions when it is uncertain.
number
default:"2"
Number of CPUs allocated to the Fly Machine for each run. Only applies when executionMode is fly-machines.
number
default:"4096"
Memory allocated to the Fly Machine in megabytes. Only applies when executionMode is fly-machines. Minimum: 256.
object
A flat key-value object of additional environment variables to inject into the Fly Machine environment at dispatch time. Only applies when executionMode is fly-machines. Example: {"DATABASE_URL": "postgres://..."}.

Claude provider

string
default:"anthropic"
The Claude provider used by the dispatched workflow.
  • anthropic — Uses the Anthropic API or Claude Code OAuth token, whichever is configured as an org secret in the target repo.
  • bedrock — Uses AWS Bedrock via GitHub OIDC. Requires awsRegion to also be set.
string
AWS region that hosts your Bedrock inference profile (e.g. us-west-2). Required when provider is bedrock. Ignored for the anthropic provider.
provider=bedrock is not supported when executionMode is fly-machines. Use executionMode=github-actions for Bedrock runs.

Planning

boolean
default:"true"
Whether to run a planning phase before implementation. When enabled, the orchestrator dispatches the planning workflow first, Claude posts structured analysis to the issue, and then implementation proceeds.See AI planning phase for details.
string
default:"claude-plan.yml"
Required when planningEnabled is true.Name of the GitHub Actions workflow file dispatched for the planning phase.
boolean
default:"true"
Reserved for a future manual-approval gate. It does not currently affect dispatch behavior — implementation always starts automatically once planning succeeds, whatever this is set to.See AI planning phase for what actually happens between the two phases.
boolean
default:"false"
When true, the orchestrator merges this project’s child pull requests into their shared grouping branch once checks pass, so a parent issue’s children collect without manual merging.Applies only to issues that belong to a parent/child group — see Feature-branch grouping. Ordinary single-issue runs are unaffected.
This never merges into defaultBranch. The final pull request from the grouping branch into your default branch always waits for a human.

Capacity

number
default:"3"
Maximum number of AI implementation runs that can be in progress simultaneously for this team. If the limit is reached, newly eligible issues are held until a slot opens.
number
default:"50"
Cap on Claude conversation turns per implement pass. Applies to both Anthropic and Bedrock providers.Lower values surface decisions earlier and cut cost; higher values let Claude work through harder problems without aborting mid-pass.
number
default:"3 (Anthropic), 2 (Bedrock)"
Cap on implement/review cycles in the feedback loop. The Bedrock default is lower for provider reliability.Each iteration is one implementreview pass; the cycle stops early when review approves the diff.
number
default:"90"
Cap on the GitHub Actions job timeout in minutes. GitHub Actions execution mode only — Fly Machines and local Docker have no equivalent timeout.
These three caps also exist as repo variables for /ai-implement comment-triggered gap-fill runs.:
  • AI_IMPLEMENT_MAX_TURNS
  • AI_IMPLEMENT_MAX_ITERATIONS
  • AI_IMPLEMENT_MAX_JOB_MINUTES
See the Run caps variables section.

Lifecycle

boolean
default:"false"
When true, the orchestrator skips this mapping during polling — no planning runs, no implementation dispatches, no gap-fill triggers. Existing in-flight runs continue, but no new work is picked up until you unpause.Useful for temporarily disabling a mapping without deleting and recreating it.