Concepts

CONCEPTS · OVERVIEW

Maverick is built on six ideas. Each one answers a single question about AI-assisted change, owns part of the pipeline, and is enforced by an artifact you can read and a command that checks it. Hover a concept to see where it lives.

1. prdwhat & why
2. specspec-driven◆
3. techspechow, here
4. tasksgraph
5. buildone subtask◆
6. verifyevidence
7. securitystrict
8. reviewdecision◆
9. prrationale◆

CONTEXT grounding from maverick new feeds every stage

Context engineeringWhat does the agent need to see?Task briefWhat changes, and how do we know?PlanningHow is it built here, in what order?VerificationWhere is the proof it works?ReviewDoes the diff do what was promised?Human in the loopWho decides, and with what power?

Why these six

An AI coding agent is fast, fluent and confident. Those are exactly the properties that make its mistakes hard to see. Each concept closes one gap between "the agent says it is done" and "a person can merge this with confidence":

Gap	What goes wrong without it	Concept that closes it	Where it shows up
The agent does not know the codebase	It invents paths, duplicates helpers, edits the wrong layer	Context engineering	Grounding from maverick new, maverick instructions
Nobody agreed on the outcome	The implementation quietly becomes the specification	Task brief	PRD.md, SPEC.md, AC-NN ids
The approach is invisible until the diff	Design mistakes surface after hundreds of lines	Planning	TECHSPEC.md, subtasks/
"Tests pass" is a claim	Weakened tests, drive-by changes, leaked secrets	Verification	verify, guard, security, deps
Plausible is not correct	The reviewer reads the explanation, not the change	Review	REVIEW.md, review --diff, readiness
Accountability drifts to the tool	Broad permissions, silent approvals, auto-merge	Human in the loop	Trust, permission ceilings, hooks, approval gates

How they fit together

Context feeds every stage. The brief and the plan are written before code, so a human can correct them while they are cheap. Verification and review happen after, against what the brief promised. Human decisions sit at the joints: approving a behavior spec, saying yes before each subtask, recording the review decision and merging.

           ┌──────────────────── context (grounding) ─────────────────────┐
  idea ──▶ │ BRIEF ─▶ PLAN ─▶ BUILD ─▶ VERIFY ─▶ REVIEW ─▶ PR            │ ──▶ merge
           │  PRD    TECHSPEC  subtask   evidence   REVIEW.md  PR-DRAFT   │   (human)
           │  SPEC◆  tasks     ◆yes      gates      ◆decision  ◆open     │
           └──────────────────────────────────────────────────────────────┘
                                    ◆ = a human decides

Read in order

1 · Context engineeringGive the agent the smallest set of real files, tests and commands it needs.2 · Task briefState the outcome as acceptance criteria someone can check.3 · PlanningGround the approach in real code and split it into a task graph.4 · VerificationCollect evidence from the diff, not claims from the agent.5 · ReviewCheck the diff against every criterion, then decide.6 · Human in the loopTrust, permission ceilings, hooks and the decisions only a person makes.

Beyond the six

Loop engineeringLeave an agent running on a planned task: the harness decides every iteration, keeps what makes nothing worse and rolls back the rest.MemoryWhy every line exists, the contracts finished tasks leave, rules learned from mistakes, and where a reviewer should look first.The proof layerParallel lanes guided by the code graph, an arena of providers, a flight recorder for loops, signed proof receipts and flows as typed graphs.

New to Maverick? Start with The Maverick Method for the stage-by-stage view, then come back here for the reasoning behind each stage.