Setup & integrations

Setup first. Integrations only when useful.

The workbench runs without Jira, ServiceNow, or MCP. Fill the registry, investigate live repos, then add optional syncs.

01

Clone next to your repos

Sibling layout is the default. Parent-child also works — point local_path at each checkout.

~/src/my-org/
├── ai-engineering-workbench/
├── service-a/
└── service-b/
02

Fill knowledge in units

Plan once (cheap sibling list), then one service per agent turn with internal architecture notes. Separate prompt stitches overall architecture — resumes if quota dies mid-setup.

prompts/bootstrap-knowledge-plan.md
prompts/bootstrap-knowledge-unit.md
prompts/bootstrap-architecture-overview.md
# or small estate:
prompts/fill-service-registry.md
03

Run one real enquiry

Confirm the agent resolves services and inspects live repos (siblings + gh), not only YAML.

npm run start -- --request "…"
prompts/investigate.md

Service registry sources

Where can the registry come from?

Output is always knowledge/service-registry.yaml. Terraform and Helm are discovery inputs — not a live feed from state.

Source How you use it
Sibling / parent-child folders Ground truth for local_path — start here
GitHub / GitLab via gh List org repos when checkouts are incomplete
Terraform Module names, service tags, repo outputs as discovery hints
Helm charts Chart names and image.repository → candidate services
Manual YAML Always valid — edit knowledge/service-registry.yaml directly

Many siblings? Prefer the unitized bootstrap (plan once, one service per turn) so a token-quota cut does not trash a half-finished setup — see workflows/bootstrap-knowledge.md . Infra-assisted fill: fill-service-registry-from-infra.md

Jira

How Jira integration works

Three levels — start with paste-only analysis. API sync is optional for active incidents.

Analyse a ticket (no API)

Easy

Paste the ticket, run prompts/jira-analysis.md, optionally draft with prompts/compose-jira.md. You paste the reply into Jira.

Sync active incidents (API)

Medium

API token in .env → npm run sync:incidents -- --provider jira → context/active-incidents.md. Pull-only; human still owns outbound updates.

Jira MCP / custom (later)

Harder

Optional read access during investigation. Do not auto-post comments. Enterprise/custom work if you need deeper automation.

Incident sync (optional)

cp .env.example .env
# JIRA_BASE_URL, JIRA_EMAIL, JIRA_API_TOKEN
npm run sync:incidents -- --provider jira --dry-run
npm run sync:incidents -- --provider jira

Full guide: knowledge/integrations/jira.md

Also optional

Other integrations

  • → Incident → MR — Logs → RCA → fix → draft PR; human reviews — workflows/incident-to-mr.md
  • → Incident automation — Pull: local Docker + PD id (open source). Push: always-on Docker webhook for paying customers
  • → Unitized knowledge bootstrap — Plan + one-service units — token-effective, resumable
  • → ServiceNow — Same incident sync path: --provider servicenow
  • → Chat / Slack / Teams — Compose drafts only — never auto-send
  • → MCP (Datadog, search, …) — Configure in Cursor / Codex when useful
  • → GitHub CLI — PRs and remotes when a local checkout is missing
Open repo on GitHub Try the demo