Copilot CLI · 13 min
“Make two options in an existing form default to on.”
- Taskfrontend-change-builder
+ frontend-quality-and-validation-evidence
- SkippedAnalysis · Independent review
Engineering control plane for AI coding agents
Describe the outcome. Get a scoped, validated change.
There is no fixed skill set. For each task, rd-skills composes the professional knowledge that task needs from 800 source files, finds the owning code, and validates after the final edit. An ordinary local change can finish right there — deeper analysis and independent review join only when a concrete question calls for them.
engineering-control-plane
$ Payment callbacks sometimes create the same order twice. Find the cause and fix it.
$
- Knowledge files
- 800
- Runtime skills
- 26
- JIT items
- 154
- Primary professional
- 1
- Agent roles
- 4
- Host adapters
- 5
Knowledge files
189 skills + 611 references, composed per task
Runtime skills
1 control + 25 professional at the host top level
JIT items
Loaded only behind the selected professional
Primary professional
Per assignment, always — ownership is never shared
Agent roles
Split by authority and tool boundary, not persona
Host adapters
Projected onto each host's real capabilities
Derived at build time from the upstream registry. None of these is a number of skills a task loads — they describe what a task can draw from.
Composed per task
There is no fixed skill set.
Every assignment composes its own knowledge from 800 source files: one primary professional, the Layer 3 skills its selector authorises for this evidence, and only the references whose load conditions fire. Here is the same installation on two real tasks.
Copilot CLI · 80 min
“Find out why an integration job fails on one machine, and fix it if the cause is confirmed.”
- Analysis
- Taskintegration-change-builder
+ checklist, solution-optimality
- Review
- Task
Twenty-five professionals, each able to draw on its own authorised subset of Layer 3 skills, give up to ~1014 distinct professional + Layer 3 combinations — before a single reference is counted. That is the space the selector chooses from, not a prediction: evidence rules make almost all of them unreachable for any one task, which is exactly the point.
Sessions anonymised: task wording generalised, every project path, address and repository name removed.
The problem
Coding is not engineering.
The question is not whether a model can write code. It is whether it knows what should change, who owns the decision, what must stay invariant, when evidence is insufficient, and what actually proves the work is complete.
Ordinary AI coding
- Request
- Find code
- Edit
- Run a test
- Done
What stays undecided
- Edits a caller instead of the owner
- Adds an abstraction nothing needs yet
- Tests something other than the change
- Validates before the last edit
- Reviews its own work
- Reports a pass it cannot support
- Leaves the unknown unstated
rd-skills
- Request
- Repository boundary
- Professional guidance
- The right owner
- Verify actual risk
- Independent check
- Current results
What each step decides
- Reads the current code before changing it
- Finds the owning code and checks nearby consumers
- Applies guidance suited to the task and its risks
- Makes the smallest complete change it can support
- Validates after the final edit
- Adds an independent reviewer when a concrete risk needs one
- Reports files, results, limits and open decisions
Core model
Three systems. One engineering task.
Three control systems act on every task at once: the boundary decides what may change, the skills decide how it is done professionally, and assurance decides why anyone should believe it is finished.
01
Implementation first
What is the simplest correct path?
The default route for an implementation request is the task agent: inspect, edit, self-check, then fresh targeted validation. No mandatory brief, contract, handoff or review stands in front of it.
- Inspect
- Edit
- Self-check
- Fresh validation
- Report
02
Professional knowledge
Whose judgment does this need?
Each assignment gets exactly one primary professional, then the Layer 3 skills its selector authorises for this evidence, and only the references whose load conditions actually fire.
- Primary Professional
- Foundation
- Domain
- Targeted References
03
Evidence-driven depth
What would justify going deeper?
Analysis, a brief, a dependency plan and independent review are added because a real question or risk demands them — never because of a level, a file count or a fixed state machine.
- Analysis
- Brief
- Dependency Plan
- Independent Review
When they conflict, this is the order
- Engineering correctness
- Professional routing accuracy
- Quality of professional judgment
- Context and token cost
- Execution time
How it works
One request. Seven steps. Two optional branches.
This is the whole ordinary path. There is no mandatory brief, task contract, handoff or review standing in front of it — those are added only when the engineering facts call for them.
- 01
Request
You describe the result you want, in plain language. You do not need to investigate the repository first.
- 02
Pick the professional
Main selects one primary professional and the Layer 3 skills the evidence calls for. It never reads your business code itself.
- 03
Inspect
The task agent finds the owner, the tests and the callers by itself. An unknown local file is discovery work, not a reason to escalate.
- 04
Edit
The smallest complete change that supports the request. Read scope can widen; write scope cannot.
- 05
Self-check
Behaviour, impact and structure, checked against what the change was supposed to do.
- 06
Fresh validation
Run after the final material edit. A later edit makes earlier proof stale, so it does not count.
- 07
Report
Changed files, results, proof limits, and any decision still waiting on you.
The implementing agent discovers local files, owners and tests as part of the task. It asks for deeper analysis when an unresolved decision could change the implementation, and stops for any missing authorization or user-owned decision.
Four mechanisms, four questions
These are not four stages every change passes through. Each one answers a different question, and only the ones with a question to answer show up.
Analysis
Do we know how to make the change correctly?
Resolves a specific uncertainty from current source, or answers an explicit analysis or diagnosis request. It does not edit.
Task
Who makes the change?
Inspects the owner, tests, and consumers, then edits within the assigned scope and checks its work.
Validation
Does the change pass the relevant checks?
Runs tests, builds, lint, or other appropriate observations after the final relevant edit. The Task performs this work.
Review
Do we need an independent second judgment?
A separate agent inspects the actual change or artifact and reports concrete defects and limits. It does not repair them.
Validation is an activity, not a fifth agent role. A reviewer can examine tests and their results, but independent review never replaces running the checks.
Added only on demand
Depth is not chosen by a level or a file count. It is chosen by whether an unresolved question would actually change the implementation.
Analysison demand
A decision that would change the implementation is still unresolved.
Worth it when
- Competing owners
- Unclear invariant
- Shared consumers or contracts
- Concurrency, transaction, recovery
- Migration, authority, integration
Not a trigger
- Unknown local file, owner, test or caller
- A small question the implementation can answer
Independent reviewon demand
You ask for it, or independent judgment measurably raises confidence.
Worth it when
- You requested a review
- A material semantic question remains in the current source
- An important failure is poorly covered by local tests
Not a trigger
- File count
- Task count
- Number of edits
- Finishing, by itself
How to tell it is working
You should be able to audit it without reading the diff.
A control plane is only useful if you can recognise when it is doing its job — and when it is performing ceremony instead. These are the signals, straight from the project's usage guide.
Normal behaviour
Behaviour to question
- A small change finishes after relevant checks, without another agent reviewing it.Every change waits for Analysis, a design document, and independent Review.
- The Task agent searches for files, tests, and callers itself.Missing file paths alone cause a separate planning round or a request for you to research the repository.
- An unresolved compatibility or authorization decision prompts a focused investigation or question.Work stops for a vague risk label without a concrete missing fact or affected action.
- The original Task repairs an ordinary review defect and reruns targeted validation.Every repair automatically starts another Review.
- An unavailable check is reported with the attempted operation and actual failure.The result claims success for a check that did not run.
rd-skills reuses your existing authorization for bounded, reversible work. It asks when the decision is yours: new scope, intended product behaviour, a compatibility break, or authority for a destructive, privileged, production or irreversible action.
Architecture
A control plane, not another agent runtime.
Six responsibility planes constrain the same task simultaneously. When the Task Agent edits a file, its skills, execution level, evidence obligations and authority all apply at once.
Authority
What the user and the host actually permit.
- User authorization
- Host enforcement
- Write/effect boundaries
- Environment risk calibration
Knowledge
Which expertise is in context, and why it was loaded.
- Control
- Professional
- Foundation
- Domain
- Targeted References
Role
Fixed tool boundaries — not a fixed order.
- Main
- Analysis
- Task
- Review
Coordination
What gets added, and only when it is needed.
- Implementation-first
- Optional analysis
- Optional brief
- Optional dependency plan
- Optional review
Evidence
What can be re-checked by whoever reads it next.
- Current source
- Actual tool results
- Post-final-edit validation
- Diff when needed
- Proof limits
Delivery / QA
How the runtime is built, shipped and proven.
- Host product surfaces
- Build / package / install
- Routing, context and professional validators
These are responsibility planes, not six sequential workflow stages.
Boundary
A control plane that adds no runtime of its own.
rd-skills is non-intercepting and host-native. It ships prompts, profiles, knowledge and markdown — not a shadow execution environment sitting between you and your agent.
What it has
- A control prompt
- Four agent profiles
- Three layers of professional knowledge
- Optional markdown artifacts
- Validation after the final edit
- Independent review on demand
What it deliberately has not
- Executable hooks
- An interception bridge
- A second sandbox
- A private runtime evidence store
- An internal task-state engine
Control rules stay inspectable, host permission boundaries stay explicit, and the agent is never pulled away from the engineering task in order to satisfy an internal protocol.
Agent roles
Separation of responsibility by design.
Roles are split by authority and tool boundary, not by personality. Professionalism comes from skills, which is why four fixed agents can cover a large number of engineering domains.
- 01
Main
Dispatch only.Can
- Select the expertise
- Dispatch within the authorized scope
- Pass real results through
Deliberately cannot
- Read the target source
- Edit
- Execute
- Review
- 02
Analysis
Read-only, on demand.Can
- Resolve one source-backed engineering question
- Read, search and consult external primary sources
- Hand an executable observation back to be run
Deliberately cannot
- Edit or mutate
- Dispatch
- Issue the independent review
- 03
Task
The default implementer.Can
- Inspect, implement or repair, self-check
- Locate the owner, tests and callers itself
- Run targeted validation after the final edit
Deliberately cannot
- Dispatch or reroute
- Independently review itself
- 04
Review
Independent, when it earns its place.Can
- Read the current diff or artifact
- Read every changed file, owner, tests and consumers
- Run read-only checks and report findings
Deliberately cannot
- Edit or repair
- Dispatch
- Read external sources independently
An implementation request goes straight to the task agent. An unknown local owner, file, test or caller is that agent's discovery work — not a reason to start analysis.
Skill architecture
Expertise without context explosion.
The host sees 26 top-level skills. The remaining 154 items stay behind the selected professional and load only when the current decision needs them — none of the knowledge is removed, only deferred.
Step 1 · one primary professional
Use analysis-agent for ambiguous or missing intent: slice desired behavior, boundaries, constraints, and completion signals. Skip an accepted Brief or repository-independent answers fully determined by user facts.
Step 2 · authorised Layer 3 · 4 candidates · loaded only as this task's evidence calls for
4 targeted references, each with its own load condition154 JIT items exist in total — this task sees only what its evidence justifiesFull contract →
Do not load every skill, and do not starve the decision either. Load what supports the current design, implementation or verification — and nothing that only matches a keyword.
- Source skills
- 189
- Top level
- 26
- JIT only
- 154
Professional skills
Engineering judgment, organised by decision ownership.
Not a Java skill or a React skill. Each professional owns a class of engineering decision; languages, platforms and domains arrive underneath it as Layer 3.
change-intake-compiler
Use analysis-agent for ambiguous or missing intent: slice desired behavior, boundaries, constraints, and completion signals. Skip an accepted Brief or repository-independent answers fully determined by user facts.
Intake, analysis and planning4 Layer 34 refs
engineering-change-analysis
analysis-agent: source-backed implementation-preparation, causal diagnosis-only, or repository source-backed-answer; skip source-free, implementation-ready, or accepted-artifact work.
Intake, analysis and planning47 Layer 37 refs
high-risk-design-review
Use review-agent for a high-risk Engineering Brief when a critical path, architecture boundary, material risk, or multiple downstream tasks need deeper design evidence. Skip ordinary work without those signals.
Impact, domain and architecture7 Layer 31 refs
engineering-artifact-review
Use review-agent for an ordinary Engineering Brief, Task Plan, acceptance, or contract artifact. Exclude high-risk design and release-readiness approval.
Impact, domain and architecture1 Layer 31 refs
data-api-contract-changer
Analyze an API, schema, migration, or compatibility decision with analysis-agent, or implement its bounded contract change with task-agent. Do not select it when no data or public-contract surface is affected.
Implementation owners12 Layer 34 refs
frontend-change-builder
Use task-agent for bounded frontend component or browser changes involving interaction, accessibility, API failures, security, or regression proof. Skip backend-only work and design exploration without implementation.
Implementation owners13 Layer 311 refs
quality-test-gate
Use analysis-agent to map acceptance to validation, task-agent to add or run bounded tests, and review-agent to assess proof coverage. Skip work with no material change or already-fresh complete validation.
Quality, security, reliability and delivery gates12 Layer 34 refs
security-privacy-gate
analysis-agent: analyze permissions, secrets, sensitive data, trust boundaries and injection; task-agent: implement controls; review-agent: assess evidence. Skip self-review or no security/privacy lifecycle impact.
Quality, security, reliability and delivery gates17 Layer 34 refs
ai-code-review-refactor
Use review-agent on implementation or repair diffs for hallucinated APIs, unsupported assumptions, unsafe abstractions, and dependency or regression risks. Skip work without a diff or after reviewer edits.
Independent review, incident and routing governance32 Layer 35 refs
incident-response-coordinator
Use analysis-agent for active multi-responder incident command, cadence, mitigation, communications, or handoff. Skip ordinary diagnosis, reliability design, release approval, post-incident docs, and execution.
Independent review, incident and routing governance2 Layer 32 refs
Evidence
A result is only current if nothing has changed since.
There is no mandatory evidence ledger. What remains is the part that was always doing the work: read the source now, validate after the last edit, and state plainly what you could not prove.
- 01
Current source
Conclusions about owner, behaviour and consumers come from reading the code now — not from inheriting a summary or trusting a locator.
- 02
Fresh validation
Affected behaviour is re-verified after the final material edit. A later edit makes the earlier result stale, and stale results are not reported as current.
- 03
Truthful limits
Skipped, flaky, unavailable and partial results are reported as they are. Nothing is upgraded into a PASS, and unknown stays unknown.
And three rules that keep the change small
- Read scope widens, write scope does not
- Finding the real owner and affected consumers can take as much reading as it takes. Discovery never expands what may be written, and destructive, production or privileged effects stay with you and the host.
- Structure needs a reason that exists today
- Future reuse, robustness, consistency and safety are not enough on their own to add an abstraction, protocol, validator, factory, adapter or dependency. A current requirement, real variation or an established boundary is.
- Two failures means change the hypothesis
- After the same path fails twice, something material has to change — the hypothesis, the evidence, the gap. Renaming the attempt or repeating the same analysis does not reset the retry.
Risk and hosts
Risk is reachability, not vocabulary.
There is no level ladder to climb. Risk handling turns on five distinctions that are easy to collapse — and on what each host surface can actually do.
- 01
Possibility≠Reachability
Something being conceivable is not the same as a path an actor can actually take.
- 02
Unknown≠Unsafe
A gap in knowledge is a reason to look, not evidence that a risk exists.
- 03
Mutability≠Trust boundary
Code that can change is not automatically code that crosses a privilege line.
- 04
Capability≠Authorization
A host exposing a tool does not authorize destructive, privileged or production effects.
- 05
Risk category≠Material risk
A security-sounding word is not itself a finding. Reachable impact is.
Escalation needs all three
- A less-trusted actor, input or writer
- A privilege or a sensitive asset
- A reachable path to material impact
There is no fixed process hierarchy. Depth is not chosen by a risk score, a severity ladder or a state machine — it comes from the engineering facts of the task in front of you.
One engineering model. Several host surfaces.
rd-skills projects the control model onto what each host actually supports, and says so where a surface falls short.
| Host or surface | Artifact delivery | Live invocation | Full workflow | Limit |
|---|---|---|---|---|
| Codex | Skills + Agent Profiles | $engineering-control-plane | Available | Artifacts checked; live loading not proved |
| Claude Code | Skills + Agent Profiles | /engineering-control-plane | Available | Artifacts checked; live loading not proved |
| Copilot CLI | Skills + Agent Profiles | /engineering-control-plane | Available | Copilot CLI only |
| Cline | Skills only | Not established | Not established | Artifact delivery only |
| OpenAI API | Zip packages | Not applicable | API integration owns orchestration | API integration only |
Codex
- Artifact delivery
- Skills + Agent Profiles
- Live invocation
- $engineering-control-plane
- Full workflow
- Available
- Limit
- Artifacts checked; live loading not proved
Claude Code
- Artifact delivery
- Skills + Agent Profiles
- Live invocation
- /engineering-control-plane
- Full workflow
- Available
- Limit
- Artifacts checked; live loading not proved
Copilot CLI
- Artifact delivery
- Skills + Agent Profiles
- Live invocation
- /engineering-control-plane
- Full workflow
- Available
- Limit
- Copilot CLI only
Cline
- Artifact delivery
- Skills only
- Live invocation
- Not established
- Full workflow
- Not established
- Limit
- Artifact delivery only
OpenAI API
- Artifact delivery
- Zip packages
- Live invocation
- Not applicable
- Full workflow
- API integration owns orchestration
- Limit
- API integration only
Artifact delivery, live invocation and full workflow are separate questions. An invocation rule verified on one surface says nothing about another, and static checks on the installed files do not prove that a running host loaded them.
Quickstart
Two commands, then ask in plain language.
One runtime, no profile flag to choose. These commands come out of the repository at build time, so they cannot drift from what the project actually supports — and the setup page turns them into the exact lines for your agent and scope.
01Build, install and check
python3 -m pip install .
python3 scripts/quickstart.py --agent codex --scope user02Your first task
$engineering-control-plane
Payment callbacks sometimes create the same order twice.
Find the cause and fix it. Add the necessary regression test and verify the change.You do not need to investigate the repository first. Add paths, acceptance criteria or a test command when you already know them; otherwise describe the problem and let the task agent find the owner, the tests and the callers.
Open source
Built in the open.
The registries, the build, the validators and the evaluation harness are all in the repository. So are the governance rules for adding a skill.