The Persona-Register Split
The split is about responsibilities, not a cast of characters. The orchestrator interprets the request and coordinates its route. An author produces a bounded change. Reviewers challenge that work against defined obligations. A caller decides what the returned evidence permits next. Those jobs need different instructions and inputs, even when the same model family performs them.
A persona is the role’s communication and decision posture. A skill is a procedure. An agent charter describes a bounded worker. None of those labels, by itself, proves process isolation, a complete context, enforced read-only access, or correctness. The installed host and the workflow’s actual evidence determine those boundaries.
Follow a task across the role rows
Section titled “Follow a task across the role rows”The map opens inside the feature task loop. Use the other chapters to see how the request reaches it and how verification, commit and PR follow. Rows identify kinds of participants; they are not three consecutive phases and not a list of commands you must type.
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.
For a saved-search export, an author might receive the CSV requirement, selected file paths, relevant source and selected verification approach. Its return identifies what changed and the observed checks, including failures and anything not run. The caller assesses that evidence and routes independent review when the scope requires it. An author’s completion report does not establish that a test passed or an independent reviewer ran.
The roster
Section titled “The roster”The orchestrator owns routing and decisions about continuation. It selects the applicable lane, supplies context and respects the required stops. It is not automatically the person who approves the work, and its summary does not authenticate a human decision.
Authors own bounded implementation. The backend-author, frontend-author and infra-author
charters have write-capable tools for their jobs. The task’s scope and project mapping select the
author; the name alone does not authorize unrelated edits. These are not the only write-capable
roles anywhere in the product.
Reviewers challenge, rather than silently repair. Security, authentication/cryptography, dependency, migration, coverage, architecture and design review apply under their owning route’s conditions. A tribunal lens executor is a separate review role reused with selected lens cards. Do not dispatch every reviewer for every change merely because its name appears in the roster. A read-only review requirement belongs to the charter and supported host path, not to a blanket claim that every agent labelled a reviewer lacks all write tools.
The generic funnel returns a verdict. finding-triage classifies the deduplicated results and
preserves out-of-scope findings. verdict-aggregator returns the single read-only batch result.
An errored or deferred unit remains visible; incomplete collection cannot become PASS by omission.
A report writer is an explicit exception. checkpoint-aggregator has a Write tool and runs
after the verdict in the periodic checkpoint path. Its role is to persist the selected report,
not to approve code. This is why a generic review can remain non-writing while a checkpoint
produces a file. The charter’s classification: reviewer metadata does not erase its writer
behavior. See Checkpoints for the complete route.
Discovery and decision roles have other outputs. Scouts and mappers return evidence about existing source; graders and challengers assess proposals. An inventory, a recommendation, a verdict and a persisted report are distinct deliverables. The agent reference preserves each charter’s tools and exact contract.
Where it’s decided
Section titled “Where it’s decided”The canonical persona and safety instructions are distinct from project context. The mode-aware turn path composes the safety core and active mode body at the applicable turn boundary. SessionStart establishes startup state.
This separation allows the product’s stable safety and interaction instructions to remain apart from the repository’s changing purpose, stack, decisions and task state. It does not mean that the model magically remembers every project document or rereads everything on every turn. Just-in-time context is one advisory mechanism for surfacing file-specific pointers; an owning skill’s required-reading list is another explicit obligation.
Give the worker enough context, not the whole conversation
Section titled “Give the worker enough context, not the whole conversation”A task needs its intended behavior, boundaries, relevant files and verification obligation. The caller may implement it directly or delegate when a bounded specialist or parallel work helps. Delegation does not require a fresh author and reviewer pair for every task. Each dispatched worker still needs explicit inputs; shared conversation history is not a substitute for relevant context.
For typed work, the coordinator reads the selected artifact identities, obligations, dependency state and selected task through the supported engine. Task context is a bounded packet, not the whole graph. Expand referenced criteria or prerequisites when the assigned work needs them. Eligibility is advisory; a context ticket is not required to start authorized work. A displayed task title or copied checkbox is not an equivalent input. Existing Markdown work retains its own contract.
Project-level documents still matter. CONTEXT.md describes the intended project and stage;
tech-stack.md supplies actual commands and the scope-to-author mapping; security controls apply
where the work touches a security boundary. If required information is absent, surface the gap
rather than choosing a plausible test runner or silently broadening the task.
Narrow scope keeps inputs relevant without claiming a universal token saving or accuracy improvement.
What this means in practice
Section titled “What this means in practice”Invoke or describe the work through the lane. Do not treat internal agent names as another public command menu. Expect the caller to explain which procedure and specialist are relevant and what will return. The public command, internal skill and worker are complementary interfaces to one workflow, not competing ways to bypass its controls.
For a parallel batch, paths that would be mutated by two units require isolation or serialization. Every unit must be accounted for as DONE, ERRORED or DEFERRED. Those transport outcomes do not prove feature completion or passing checks. The funnel preserves problems and contradictions in the returned verdict; the caller continues independent work and resolves affected failures.
A narrowly scoped reviewer can miss something outside its assigned context. A complete batch means that the specified work was accounted for, not that every possible defect was excluded. Confirm the review matrix, inputs and failure states before accepting a reassuring summary.
Inspect a Dispatch
Section titled “Inspect a Dispatch”Start with the public command and follow its owning skill. Identify the condition for each worker, the permitted paths, required inputs, expected output and return destination. Open the charter to inspect tools and restrictions. Then compare those expectations with the actual run’s scope and fresh results, not merely the names visible in a transcript.
Claude Code uses its native agent route where supported. Codex’s packaged resource charters and host-provided threads are not evidence of enforced read-only isolation on every path. Pi has its own supervised child route and capability boundaries. Consult host differences and the artifact authority limits for the installed workflow. An allowed inline fallback is a particular contract exception, not permission to simulate an isolated reviewer whenever spawning is inconvenient.
Inspect the packaged role names
The current role names below are lookup destinations, not additional commands. The owning skill still determines which roles participate. Read each charter’s tools and output contract rather than assuming its family label establishes a security boundary.
Authors: backend-author, frontend-author, infra-author.
Scoped reviewers: security-reviewer, auth-crypto-reviewer, dependency-reviewer, migration-reviewer, coverage-auditor, architecture-drift-reviewer, design-quality-reviewer, tribunal-lens-reviewer.
Discovery: scout, map-structure, map-deps.
Decision assessment: grader, decision-challenger.
Read-only result processing: finding-triage, verdict-aggregator.
Explicit report persistence: checkpoint-aggregator. This writer remains distinct from the read-only funnel, even though its classification is reviewer.
When a worker fails, preserve its terminal state and relevant diagnostics. Do not invent its missing verdict or treat another worker’s success as coverage of the failed scope. Return through Investigation or Resume and recover, then finish through Review and ship only when the real evidence supports it.