Skip to content
rd-skills

Architecture

Six responsibility planes, acting at the same time.

rd-skills is not a hidden agent runtime and not a fixed pipeline. It is a set of planes that constrain the same task concurrently — when the Task Agent edits a file, its skills, execution level, evidence obligations and authority all apply at once.

Planes

What each plane is responsible for.

Read this as six concerns, not six steps. Nothing here runs in sequence.

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

Authority

Two chains, one classification.

The path is chosen once. A Direct Task never creates an Engineering Brief; in Analyzed Work the Engineering Brief is the only runtime analysis authority, and later artifacts may project it but never redefine its protected decisions.

Direct Task

The user supplied the facts and the boundary is explicit.

  1. 1

    User facts + explicit boundary

    nothing material is unknown

  2. 2

    Direct Task Contract

    the authority for this task

  3. 3

    Task / execution delta

    implementation inside the boundary

  4. 4

    Review artifact

    latest change plus current evidence

  5. 5

    Closure

    conditions met

Analyzed Work

Owner, placement, verification or material risk is still unknown.

  1. 1

    User request + source evidence

    start from the repository, not the prompt

  2. 2

    Engineering Brief

    the single runtime analysis authority

  3. 3

    First executable slice

    the first fully executable task

  4. 4

    Task / execution delta

    implementation and evidence increment

  5. 5

    Review artifact

    independent review input

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.

  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.

Execution

What actually happens to one request.

Classification happens once, and everything downstream consumes that decision instead of 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.

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 → 0..3 Layer 3 → required references. 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.

Explore all 189 skills →

Evidence

Every claim carries its own limits.

Evidence is not a test result. It is a test result with a scope, a timestamp relative to the final edit, a statement of what it cannot prove, and the risk that remains.

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

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.

  1. src/

    authoring source — contracts, skills, registries, profiles

  2. build preflight

    schema, path, projection and ownership checks

  3. scripts/build.py

    compiles Layer 3, selectors and host profiles

  4. 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. Multiple agent hosts.

rd-skills projects the control model into each host's available capabilities. Where a capability is absent, the matrix says so.

  • 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