Skip to content

What is CortexBuild?

In plain English

AI coding agents are great at writing plausible code — but they don't know the unwritten conventions your team already follows, so they quietly break them. CortexBuild reads your repo, captures those conventions as rules, and feeds them to every AI tool you use, plus runs every change through a fixed review pipeline.

The problem it solves

Every existing codebase has implicit conventions: how errors are handled, how auth is wired, how tests are structured, which patterns are banned. A generic AI agent can't see those conventions, so it produces pull requests that look right but violate your team's tribal knowledge.

CortexBuild turns that tribal knowledge into machine-enforced rules so future agent work obeys it — instead of relearning (and re-breaking) it every time.

Who it's for

  • Any team adopting AI coding tools — Copilot, Claude Code, Codex, Cursor — that wants those tools to respect their codebase, not a generic average.
  • IT and non-IT teams alike. You don't need to be a compiler engineer. The onboarding command does the analysis; you review plain-English rules and keep or drop them.
  • Built for existing repos. CortexBuild works on the systems you already have — the messy, real, already-shipped codebase. It relies on the conventions your code already encodes, so it leans on existing convention signal rather than scaffolding from an empty repo.

The mental model

Two ideas carry the whole product:

  1. Rules as a single source of truth (SSoT). You author governance rules once. CortexBuild renders them into the native format of every AI tool — .github/copilot-instructions.md, CLAUDE.md, AGENTS.md, .cursor/rules/ — so the same policy applies no matter which tool or model runs.

  2. A fixed agent review pipeline. Changes flow through a fixed, auditable sequence of specialised agents:

Planner → Critic → Builder → Tester → Security → Optimizer → PR Reviewer

Every change is planned, reviewed, built, and verified before it lands.

A third loop closes over time: a recurrence ledger records defects and their fixes so the same class of failure is caught earlier next time.

When a phase fails

The pipeline is not a stateful engine that can get permanently "stuck" — every phase (Planner, Critic, Builder, …) is an ordinary agent turn against files already on disk (plan.md, git, the local telemetry ledger), so recovery is ordinary re-invocation once you know which phase you were in.

Licensed commands. The command below, like every CortexBuild command except auth, needs your own active licence — see Install and run cortexbuild auth activate first if you see license required.

Run cortexbuild session-start (or --json) at the start of any session — it now reports whether something is in flight: the last governed phase recorded, whether a session plan.md exists and is approved, and a one-line "resume with …" suggestion. It stays silent when there is nothing to resume.

cortexbuild session-start --json
# {"plan_present": true, "plan_approved": false, "last_phase": null,
#  "in_flight": true, "resume_suggestion": "resume with: get explicit user
#  approval on plan.md ..."}

For the full resume/retry/re-plan decision tree — when to retry Builder in place versus return to Planner, and how to record an approval or an explicit override so the next session-start reflects it — see the bundled skill-resume-governed-task (.claude/skills/skill-resume-governed-task.md / .github/skills/skill-resume-governed-task.md after a render).

What you actually get

When you onboard a repo, CortexBuild writes a .cortexbuild/ folder containing a human-readable onboarding report, a structural + dependency-graph analysis, a technical-debt heatmap, and a starter rule pack — all committed to your repo, under your control.

Beyond onboarding, the platform gives you:

  • An always-current code graph — cortexbuild graph keeps the per-repo module-dependency graph fresh incrementally, and cortexbuild workspace graph rolls repos up into a cross-repo dependency map so a control plane can see how features connect across frontend, backend, and mobile.
  • Portable memory — cortexbuild memory session save|restore carries a tag-only working-context snapshot across devices and teammates ("continue where Alice left off"), scoped to a stable repo identity and consent-gated when synced.
  • Feature observability — cortexbuild features shows every capability's tier, entitlement, and real utilization (including unused entitled features), with admin enable/disable that is subtract-only, signed, and audit-logged.

What CortexBuild does — and does NOT — do today

It does: analyse your repo, render rules to the AI coding tools you already use (Copilot, Claude Code, Codex, Cursor), score conformance, run an offline eval, and record a recurrence ledger. The deterministic checks (eval, render --check, ledger guards) run with no LLM; optional rule synthesis (--with-rule-synthesis) is propose-only.

It does NOT (yet): run the agents itself or open pull requests on its own. Your existing AI coding tools execute the rendered harness; CortexBuild makes them consistent, governed, and auditable. In-process agent execution and an autonomous PR engine are not part of the product.

Next

→ Install the CLI, then Onboard Your Repo.