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
Architecture
Six responsibility planes, acting at the same time.
rd-skills is a non-intercepting, host-native control plane — not a hidden agent runtime and not a fixed pipeline. Six responsibility planes combine as a task needs them, and there is no process hierarchy to climb.
Planes
What each plane is responsible for.
Read this as six concerns, not six steps. Nothing here runs in sequence.
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
Boundary
What it has, and what it deliberately has not.
The hookless boundary is the design decision everything else rests on: control rules stay inspectable, host permissions stay explicit, and no internal protocol competes with the engineering task.
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.
Roles
Authority and tool boundaries, not personas.
4 fixed agents cover a large number of engineering domains because professionalism comes from skills rather than from the agent itself.
- 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.
Execution
What actually happens to one request.
An implementation request goes straight to the task agent. Analysis and independent review are branches taken when the facts require them, not stages every task passes through.
- 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.
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.
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
Knowledge
Three layers, one fixed runtime surface.
The repository holds 189 source skills. The host sees 26. The difference is not lost capability — it is deferred loading.
- 1Control
- Runtime top level. Classifies, dispatches, and routes review, repair and closure.
- 25Professional
- Runtime top level. Exactly one primary professional owns each task.
- 141Product Foundation
- Capability modifiers, loaded JIT through the professional selector. Never a host top-level skill.
- 13Domain
- Modifier-only. Adds domain invariants and proof obligations; never owns a primary route.
Fixed request path: user → control → primary professional → selector → the Layer 3 skills this evidence calls for → the references whose conditions fire. Task and review consume that routing decision; they never re-run the global router.
9 further foundation skills are authoring- or dev-only. They take part in source and internal validation, and never reach a runtime.
Routing and JIT
Choosing a skill is not the same as the worker reading it.
The full chain is selection, path delivery, reading the body, and adding knowledge when new evidence appears. What a worker receives is a set of readable paths — not a list of skill names.
- 01
Main picks one primary
From the meaning of the task, not from a keyword match.
- 02
Read that professional's selector
Choose the authorised Foundation and Domain knowledge this evidence needs.
- 03
Decide references separately
The professional and each Layer 3 skill can each have references worth reading.
- 04
Deliver readable paths
The worker gets host-resolved paths to every body it needs — not a list of skill names.
Every selection has to pass three questions
- Is it relevant to this problem?
- Positive evidence and anti-triggers separate a real need from a word that happens to match.
- Is it authorised for this role and primary?
- Professional, profile and domain authorisation are each checked. Several applicable skills is not an owner conflict.
- What judgment will it support?
- Design, implementation or verification now. Knowledge never creates new requirements, abstractions or process by itself.
“Just enough” does not mean “as little as possible”. Knowledge that confirms an approach, checks an invariant or names a concrete failure is worth reading even if it does not change the final decision. Duplicate background and unsupported future risk are not.
Two real tasks, two different loadouts
The same installation composed entirely different knowledge for a small form change and for a cross-system diagnosis.
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
Professional judgment
What a professional actually contributes.
Not a language label or a tool list: a way of seeing where this kind of change fails. Portable enough to hold in any repository that has never heard of rd-skills.
- backend-change-builder
Order decides correctness
Authorisation, write, commit, side effect and retry — their order changes the outcome. A successful response is not enough; check whether an effect happened that should not have.
- frontend-change-builder
The interface is state and recovery
Loading, empty, error, permission, cancel, stale response and retry are all behaviour. A passing snapshot says nothing about focus order, screen readers or narrow-screen overflow.
- integration-change-builder
A timeout is not a non-event
The server may have acted while the client saw nothing. Idempotency, duplicates, unknown outcomes and reconciliation have to be explicit — one component succeeding is not consistency.
- ai-code-review-refactor
A defect needs a reachable mechanism
"This pattern might be wrong" is a lead. A finding names the input, the condition and the failure in the current source.
Evidence
Every claim carries its own limits.
Evidence is a result someone else can re-check: current source, an actual tool result, validation that survived the last edit, and a plain statement of what it does 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.
- 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 authority
No level ladder. Five distinctions instead.
Risk handling turns on real reachability, trust boundaries, authority and material impact — never on a score, a severity ladder or a substitute state machine.
- 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.
Build
Authoring source becomes a host-consumable projection.
Validators and evals produce authoring, regression and release evidence. They are not stages of a user's task.
src/
authoring source — contracts, skills, registries, profiles
build preflight
schema, path, projection and ownership checks
scripts/build.py
compiles Layer 3, selectors and host profiles
dist/
the runtime artifacts a host actually consumes
The professional selector is a build-only artifact. Installing src/ would give an agent the authoring source instead of the compiled projection it is meant to consume.
Hosts
One engineering model. Several host surfaces.
Artifact delivery, live invocation and full workflow are three different questions. The table keeps them apart rather than collapsing them into a single claim of support.
| 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.