Skip to content
rd-skills

Engineering control plane for AI coding agents

Make coding agents work like an engineering system.

rd-skills routes every task to the right professional judgment, loads deep expertise only when needed, separates implementation from review, and requires current evidence before completion.

Get startedView on GitHub
engineering-control-plane

$ Add retry support to payment settlement without changing its public API.

$

Runtime skills
26

Runtime skills

1 control + 25 professional at the host top level

JIT items
154

JIT items

Loaded only behind the selected professional

Layer 3 per task
0–3

Layer 3 per task

Only what the current evidence justifies

Primary professional
1

Primary professional

Per task, always — ownership is never shared

Agent roles
4

Agent roles

Split by authority and tool boundary, not persona

Host adapters
5

Host adapters

Projected onto each host's real capabilities

Derived at build time from the upstream registry — 189 source skills in total, 611 targeted references.

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.

A typical coding agent

  1. Prompt
  2. Search
  3. Edit
  4. Test
  5. Done

What stays undecided

  • Unclear ownership
  • Scope drift
  • Premature abstraction
  • Insufficient validation
  • Self-review bias
  • Stale evidence
  • Unverified completion

rd-skills

  1. Intent
  2. Decision boundary
  3. Professional owner
  4. Targeted expertise
  5. Bounded implementation
  6. Validation
  7. Independent review
  8. Evidence-backed closure

What each step decides

  • Exactly one owner per task
  • Scope fixed by contract
  • Abstraction needs a proven consumer
  • Validation after the final edit
  • Review cannot be self-issued
  • Evidence invalidated by later edits
  • Closure requires covered claims

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

Decision Boundary

What may change?

Compiles user intent into an explicit path, authority, scope, acceptance, task contract and stop conditions.

  • Path
  • Authority
  • Scope
  • Acceptance
  • Task Contract
  • Stop Conditions

02

Expertise Injection

How is it done professionally?

Selects exactly one Primary Professional, then adds only the Layer 3 expertise the current evidence justifies.

  • Primary Professional
  • Foundation
  • Domain
  • Targeted References

03

Assurance Controller

Why should anyone believe it is done?

Sets assurance strength, requires fresh validation, keeps an evidence ledger, and gates closure on independent review.

  • Execution Level
  • Validation
  • Evidence Freshness
  • Review Boundary
  • Closure

All three constrain one engineering task, at the same time.

How it works

One request. A controlled engineering path.

Classification happens once. Everything after it consumes that decision rather than re-deriving it.

  1. 01

    Request

    The user states a goal. Nothing is assumed about scope yet.

  2. 02

    Classify once

    One classification decides the path: Direct Task when the facts and boundary are already established, Analyzed Work when owner, placement, verification or material risk is unknown.

  3. 03

    Authority

    Direct Task produces a Direct Task Contract. Analyzed Work produces an Engineering Brief — the single runtime analysis authority that later artifacts may project but never redefine.

  4. 04

    Professional owner

    Every task gets exactly one Primary Professional. Ownership is by engineering decision, not by language or framework.

  5. 05

    JIT expertise

    A selector adds at most three Layer 3 skills, plus the references whose load conditions actually fire.

  6. 06

    Execute and validate

    The Task Agent changes code inside the contract, then runs targeted validation after the final edit.

  7. 07

    Independent review

    A Review Agent reads the exact change, the changed files and the current validation. It cannot repair what it finds.

  8. 08

    Evidence-backed closure

    Completed is allowed only when current evidence covers the completion claim.

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 Plane

What is allowed to change, and who decided.

  • Core Contract
  • Direct Task Contract
  • Engineering Brief
  • Task Contract
  • Completion

Knowledge Plane

Which expertise is in context, and why it was loaded.

  • Control
  • Professional
  • Foundation
  • Domain
  • Targeted References

Role Plane

Who may read, write, review and close.

  • Main
  • Analysis
  • Task
  • Review

Assurance Plane

How strong the proof must be before a claim stands.

  • Execution Level
  • Validation
  • Evidence Ledger
  • Review Boundary
  • Scoped Freshness

Host Adapter Plane

How the model projects onto each agent host's real capabilities.

  • Codex
  • Claude
  • Copilot
  • Cline
  • OpenAI API

Build / QA Plane

How the runtime is compiled and proven before release.

  • Registry
  • build.py
  • Validation
  • Routing evals
  • Professional evals
  • Release evidence

These are responsibility planes, not six sequential workflow stages.

Read the full architecture →

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.

  1. 01

    Main Control Agent

    Can

    • Classify the request
    • Assign path and profile
    • Compute execution level
    • Route review, repair and closure

    Deliberately cannot

    • Read target source
    • Implement
    • Review
  2. 02

    Analysis Agent

    Can

    • Read source, tests and external evidence
    • Resolve ambiguity
    • Produce the Engineering Brief

    Deliberately cannot

    • Edit code
    • Issue the final review
  3. 03

    Task Agent

    Can

    • Implement or repair one bounded task
    • Run targeted validation after the final edit

    Deliberately cannot

    • Reroute itself
    • Review its own change
  4. 04

    Review Agent

    Can

    • Read the exact diff and changed files
    • Read current validation
    • Report findings

    Deliberately cannot

    • Edit or repair
    • Export the diff on the Task Agent's behalf

MainAnalysisTaskReviewClosure— but this is not always a fixed linear pipeline.

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 · selector-authorised Layer 3 · 4 candidates, at most 3 loaded per task

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. Load the smallest set of expertise that can materially change the current engineering decision.

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: implementation-preparation for source-backed changes, diagnosis-only for causes, or source-backed-answer for repo questions; skip source-free, implementation-ready, and accepted-artifact work.

Intake, analysis and planning37 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

Use analysis-agent to analyze permissions, secrets, sensitive data, trust boundaries, and injection; task-agent to implement controls; and review-agent to assess evidence. Skip self-review and no-trust-impact work.

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 governance24 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

Browse all 25 professional skills →

Evidence

Completion is a claim. Evidence makes it believable.

A green test suite is not automatically proof of correctness. Evidence has to cover the actual claim being made, and it has to have survived the last edit.

  1. Unverified

    A change exists. Nothing yet proves it behaves as claimed.

  2. Validated

    Targeted validation ran after the final edit, with a recorded scope.

  3. Reviewed

    An independent agent read the actual diff and the current evidence.

  4. Completed

    Current evidence covers the completion claim, with proof limits stated.

Scope
What this evidence actually covers — and what it never touched.
Freshness
Whether it was produced after the final edit. A later edit invalidates it.
Proof limit
What this evidence cannot establish, stated rather than implied.
Residual risk
What remains reachable after the controls that are in place.

Assurance and hosts

Assurance strength, then honest host capability.

Execution level says how much proof a task needs — it is not a phase of the workflow. Host support says what each agent host can actually do, including where it cannot.

  1. L1Strict minimalMust satisfy both L1 and L2 eligibility. Non-bypassable controls still apply.
  2. L2Bounded and reversibleOne bounded owner, local scope, reversible forward fix, known non-production verification, no material unknown.
  3. L3Default executable taskdefaultThe standard source-backed executable task. This is the default, not an escalation.
  4. L4Reachable residual riskMaterial residual impact remains reachable after existing controls, or an explicit policy floor applies.
  5. L5Extra assuranceConfirmed critical L4 where additional assurance materially reduces uncertainty.

Level changes the depth and independence of validation, review and evidence. It never re-selects the primary professional, the implementation Layer 3, the domain, or the required review skills.

One engineering model. Multiple agent hosts.

rd-skills projects the control model into each host's available capabilities. It does not claim they are equivalent.

  • Codex

    Strongest native diff and read-only validation path. Fine-grained tool allowlists are still prompt-enforced.

    Profile
    Native
    Skill loading
    Prompt-enforced
    Subagent
    Native
    Review diff
    Native
    Validation
    Native

  • Claude

    Skill loading and subagents are native. Review consumes a supplied diff because there is no verified read-only shell for it.

    Profile
    Native
    Skill loading
    Native
    Subagent
    Native
    Review diff
    Supplied artifact
    Validation
    Supplied artifact

  • GitHub Copilot

    Review has read and search but no execute, so exact supplied diff delivery matters most here.

    Profile
    Native
    Skill loading
    Prompt-enforced
    Subagent
    Native
    Review diff
    Supplied artifact
    Validation
    Supplied artifact

  • Cline

    The control model is projected through prompts only; none of these capabilities are host-native.

    Profile
    Not supported
    Skill loading
    Not supported
    Subagent
    Not supported
    Review diff
    Not supported
    Validation
    Not supported

  • OpenAI API

    Ships as generated top-level skill bundles; the harness around them is yours to build.

    Profile
    Not supported
    Skill loading
    Not supported
    Subagent
    Not supported
    Review diff
    Not supported
    Validation
    Not supported

Quickstart

Install it, then submit one bounded task.

One runtime, no profile flag to choose. These commands are extracted from 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.

01Install
python3 --version
python3 -m pip install .
02Preview the installation
python3 scripts/quickstart.py --agent codex --scope user --dry-run
03Install and check
python3 scripts/quickstart.py --agent codex --scope user
python3 installers/doctor.py --agent codex --scope user
04Submit your first task
/engineering-control-plane

Goal: Add an empty-string check to src/example.py without changing its public API.
Acceptance: Empty input returns the existing validation error; valid input is unchanged.
Allowed scope: src/example.py and its existing test file only.
Verify: Run python3 -m unittest tests.test_example.
Stop if: Ownership, the public contract, or the verification command differs.

A bounded implementation should produce one primary professional skill, an implementation by a task agent, validation after the final edit, an independent review, and a handoff listing changed files, results, unverified scope and residual risk.

Set it up for your agent

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.