Concept Map
A request, an implementation and a passing test establish different things. codeArbiter gives each stage an owner. A lane selects the path for the work; skills define its procedures; agents perform bounded author or reviewer roles. Gates require decisions or evidence before the next transition.
Follow who acts next, what they produce, and what permits continuation. That is the mental model behind the operating guides and exact reference.
Follow one change from request to PR
Section titled “Follow one change from request to PR”A saved-search export starts as an idea. Its specification defines ordering, escaping and empty results. A plan maps those criteria to tasks. The implementation owner chooses direct implementation or useful delegation, applies meaningful checks, and requests independent review where risk or policy requires it. The coordinator reports progress and continues authorized work, respecting explicit user pauses and real consequential decisions.
This map follows the full feature lane and its Open a PR exit. Rows identify roles; arrows show execution order. TDD runs inside task authoring, and delegated work returns to its caller.
Follow the work, not a catalog
A feature request becomes a reviewed pull request
The requested outcome authorizes scoped feature work. Maintain its spec and plan, follow actual dependencies, implement directly or delegate useful units, and report observed checks. Real user stops, host permissions, security controls and delivery authority remain effective.
Rows identify roles. Gold commands enter or define a procedure; blue skills coordinate work; green agents perform bounded roles. Arrows cross rows in execution order. A dashed arrow reuses a procedure rather than calling its entry again. Dashed nodes are conditional roles selected for the work.
Chapter 1 / 4
Define the change
What behavior is being agreed to?
Link to this chapter- command
/ca:feature
Resolve existing work before classifying a new request. Resume its actual unfinished step and preserve the selected representation.
Result: The selected lane, current scope and exact artifact route.
full lane → New full-lane work enters brainstorming.
Source for step 1 - skill
brainstorming
Refine the agreed outcome into observable criteria and exclusions. Ask about consequential unresolved choices while retaining decisions already made.
Result: A saved specification with criteria and actual open decisions.
criteria → Return the selected specification and actual open decisions directly to planning.
Source for step 2 - skill
writing-plans
Describe coherent tasks, relevant paths, actual dependencies and checks under existing authorization. Maintain in-scope methods with a reason and preserve source identity.
Result: A useful working plan; missing requirements and structural failures remain explicit.
ready plan → The coordinator receives the maintained plan and selects useful authorized work.
Source for step 3 - skill
executing-plans
Select meaningful work using actual task dependencies. Preserve blocked members and authored scope while allowing independent work to continue.
Result: A bounded task scope handed to the implementation owner.
Source for step 4
Before continuing: A maintained specification and linked plan with observable criteria, actual dependencies and unresolved choices kept visible.
Continuations, returns and repeat paths
- Select useful scope. The coordinator hands the named scope to the implementation owner and resumes from its actual results. Next: subagent-driven-development: select. Owning contract
Chapter 2 / 4
Build and verify each task
Who writes, and what proves this task?
Link to this chapter- skill
subagent-driven-development: select
Inspect the selected scope, criteria, actual dependencies and current work. Engine eligibility is advisory; inspect outstanding workers before redispatch after interruption.
Result: Useful next work with the relevant requirements and checks.
implement → Implement directly or assign a useful bounded unit; delegation is conditional.
Source for step 5 - agent · if applicable
Optional backend, frontend or infrastructure author
Choose direct implementation for focused work. Delegate when isolation, parallel work or expertise helps, supplying bounded relevant context. A delivery receipt does not grant execution permission.
Result: Scoped work performed directly or by an appropriate author.
verify approach → The implementer follows the verification approach suited to the assigned work.
Source for step 6 - skill
tdd: select and prove the approach
Use genuine regression RED/GREEN for confirmed fixes, criterion-focused feature checks and passing characterization baselines for refactors. Non-executable changes use relevant validation.
Result: Observed evidence and pending checks returned to the caller.
Inspect all six TDD phases
- Obligations: map required claims to meaningful proving checks.
- Baseline: observe target RED for a fix or passing characterization before refactoring; prefer test-first features.
- Implement: run the scoped proving checks and affected existing contracts, preserving assertions.
- Verify obligations: keep missing or failed evidence visible and rerun affected checks.
- Coverage: meet the declared profile and critical-path requirements; report unmeasured scope.
- Lint and handoff: run applicable quality tools and return actual commands, results and limitations.
return → Return actual results so the caller can assess criteria, source applicability and remaining work.
Source for step 7 - skill
subagent-driven-development: verify
Compare the result with criteria and run applicable checks. Record commands, working directories, outcomes and limitations. Reuse evidence only while its checked source and inputs remain applicable.
Result: Observed verification and pending checks; task status is not test evidence.
Source for step 8
Before continuing: Implemented work with actual check results and pending verification, returned to the caller.
Continuations, returns and repeat paths
- Continue independent work. Choose the next task by actual dependencies; an unrelated failure does not prohibit useful authorized work. Next: subagent-driven-development: select. Owning contract
- Review where warranted. Use applicable independent review for the combined change when risk or policy calls for it. Next: Risk-selected reviewers. Owning contract
- Record scoped progress. Ordinary work can record implementation progress without manufacturing an independent review receipt. Next: subagent-driven-development: record progress. Owning contract
- Repair affected checks. An unexplained failure or missing requirement remains outstanding. Repair the work and rerun the appropriate checks without weakening assertions. Next: tdd: select and prove the approach. Owning contract
Chapter 3 / 4
Review and report progress
What evidence and next work return to the caller?
Link to this chapter- agent · if applicable
Risk-selected reviewers
Review the combined relevant diff when risk or policy requires it. Use specialist reviewers for applicable security, dependency or migration concerns and avoid duplicate per-task reviewer cascades.
Result: Applicable findings against the actual reviewed source.
findings → When independent reviewers are dispatched, aggregate their complete findings and unit outcomes.
Source for step 9 - agent · if applicable
finding-triage
Route a dispatched review batch through finding triage and verdict aggregation. Preserve blockers, incomplete units and out-of-scope findings without inventing a successful review.
Result: One triaged verdict with its actual evidence limits.
results → Return applicable review results; implementation status must not conceal failures or missing checks.
Source for step 10 - skill
subagent-driven-development: record progress
Use the selected writer to record completed implementation. HTML accept-scope can record DONE without a receipt; it cannot clear pending or blocked members. Keep verification and independent acceptance distinct.
Result: Completed implementation, actual checks and unresolved issues returned to the caller.
to caller → The scoped invocation returns to its coordinator with work and evidence, not directly to commit.
Source for step 11 - skill
executing-plans: report and continue
Report changes, checks and next work, then continue within existing authorization. Honor a user-requested pause, consequential decision, or actual host/security restriction for the affected work.
Result: The next authorized scope or an honest delivery handoff.
Source for step 12
Before continuing: Current implementation progress, applicable review and check results, and the next authorized work.
Continuations, returns and repeat paths
- Correct blocking findings. Resolve affected findings within existing scope, rerun relevant checks and refresh changed review conclusions. Next: Optional backend, frontend or infrastructure author. Owning contract
- Next authorized scope. Continue normal authorized work while preserving real dependencies and any explicit user-requested pause. Next: subagent-driven-development: select. Owning contract
- Authorized delivery. Hand current scope, actual check results and remaining work to the commit owner only when committing is authorized. Next: commit-gate. Owning contract
Chapter 4 / 4
Commit and open the PR
Which action is actually authorized?
Link to this chapter- skill
commit-gate
Use the commit owner only when committing is authorized. It checks the selected staged work, applicable tests, secrets and specialized controls, with fresh behavioral proof.
Result: A selectively staged commit and observed gate results.
committed → The branch-finishing owner checks current-head readiness and the selected delivery action.
Source for step 13 - skill
finishing-a-development-branch
Retain an existing open-PR choice. Ask for branch disposition only if it is unclear. Merge and discard require their own explicit authorization and applicable evidence.
Result: The selected terminal action supported by current branch state.
reuse → Execute the PR contract in place; do not re-invoke its command.
Source for step 14 - command
/ca:pr procedure, reused by finishing
Finishing executes the PR procedure in place; the command is not re-invoked. For a committed branch, verify the explicit base-to-HEAD subject, including secrets and specialized checks, without creating another commit.
Result: Current-head readiness and required review for the authorized PR.
review → PR creation includes its own path-selected review and verdict.
Source for step 15 - agent
PR reviewers, finding-triage and verdict-aggregator
Apply the PR path matrix and review funnel, including security review for CI/deployment/infrastructure changes. Resolve blockers and report the PR URL, current head and observed checks.
Result: An open PR. Exact-head hosted CI and explicit merge authority still govern integration.
Source for step 16
Before continuing: An authorized open PR with its current source and observed checks. Merge and publication remain separate actions.
Continuations, returns and repeat paths
An open PR, its source identity and observed check state. Merging and publishing remain separate decisions.
Other workflows have different endpoints
Section titled “Other workflows have different endpoints”Compare the sprint, dependency, decision, release and initialization routes. Their maps preserve the same Commands / Skills / Agents language but follow each owning contract. A release crosses a mandatory PR and hosted-publication boundary; initialization ends in context, not a manufactured pull request. Role membership alone does not establish an execution sequence.
Five connections make the model useful
Section titled “Five connections make the model useful”Work has a governing definition. A feature specification describes observable behavior; a linked plan describes how to implement and verify it. The project architecture and roadmap operate at a broader scale. An item on the task board is not a substitute for any of them.
A decision has a scope. Clarifying product behavior, deciding architecture and authorizing a merge establish different things. Keep the user’s existing authorization and actual choices; updating a plan does not itself require another permission reply. An accepted architecture decision records a choice, while implementation and verification need their own evidence. SMARTS can help compare genuine alternatives without replacing the decision owner.
Context is selected, not guessed. Repository policy, decisions and source-backed knowledge inform the work that touches them. Provenance helps identify stale derived knowledge. Just-in-time injection points a file read toward its relevant governing record; it does not load the whole repository or prove compliance with every rule.
Review is not authorship. The coordinator selects useful work and relevant roles. The implementer makes the bounded change; applicable reviewers challenge it under their own contracts. The caller examines actual check results and their source scope. An author’s summary cannot turn an unrun check into a pass.
Evidence names its boundary. A local passing test applies to the exercised behavior and source.
A task marked DONE records implementation progress, not passing checks or independent review.
An explicit attestation claim needs its own actual evidence. A PR URL establishes an open
proposal, not a merge or deployment. An audit packet assembles the records available for its window;
missing records must remain visible as missing.
Start with the problem you are trying to understand
Section titled “Start with the problem you are trying to understand”A concrete example
Section titled “A concrete example”Suppose the export request also introduces a new parser dependency. The feature lane still owns the requested behavior. The dependency procedure governs the proposed package before installation. The test obligations establish what the CSV must do. A security-relevant path can bring in its controlling policy and applicable reviewers. These are related controls, not permission to replace one procedure with another or dispatch every reviewer on every task.
If the parser decision remains unresolved, it is surfaced rather than hidden in implementation.
If the implementation fails a regression, the failure requires correction and a fresh run.
If a task is marked DONE but a required check is unrun, report verification as pending. Continue
independent authorized work while resolving the actual gap. Each problem returns to its owner.
The worked first feature has inspectable drafts and local test evidence. Its illustrative conversation is deliberately separate from captured test results. Use it to see the records, not as proof that the same execution occurred in your repository.
Put the model to work
Section titled “Put the model to work”Name the next intended change, the record that defines it, the role that should act, and the condition that permits continuation. Then identify what evidence you expect back and where the lane stops for you. A reader who can answer those questions can choose a guide without memorizing an internal catalog.
For a blocked or interrupted installation, use Troubleshooting. For uncertain work state, use Resume and recover. For hands-on practice with a separate verifier, use Arbiter Academy.