Agent-first repository control-plane suite
Project description
Repo Control Suite Kit
A control plane for repositories that take AI-assisted change seriously.
Most AI coding setups optimize for generation speed: drop a guidance file in your repo, point an agent at it, ship. That works fine — until someone asks "what changed, why, and can we roll it back?"
rctl is a small CLI that installs a durable control plane into any repository. It gives agents and humans a shared place to find plans, evidence, validation results, and rollback notes — so the next session doesn't start from zero.
The idea
AI agents are good at writing code. They're terrible at remembering what they did, why they did it, and whether it actually worked. Your chat history shouldn't be the source of truth for that — your repository should.
rctl treats the repo as the single source of truth for the entire change lifecycle:
Plan → Implement → Verify → Score → Archive
One canonical set of skills and guidance lives under rctl/. It gets projected into whatever agent surfaces you use — Claude Code, Cursor, Windsurf, Codex — without duplication, without drift.
Features
- 8 CLI commands covering the full lifecycle: init, update, validate, score, enforce, status, next, gc
- 17 reusable skills — structured agent workflows with defined triggers, steps, success criteria, and failure patterns (not prompt snippets)
- 4 agent adapters — one canonical source, projected to Codex, Claude Code, Cursor, and Windsurf native surfaces
- 5-layer validation — structure, discovery, operational, freshness, and enforcement checks
- Honest readiness scoring — because "files exist" and "repo is actually ready" are different things
- Durable change records — plans, execution status, evidence, and rollback notes that survive across sessions
- Conservative updates — hash-tracked manifests, explicit conflict files, no silent overwrites
- Profile-based governance — scale controls from minimal to full without rewriting anything
Installation
Prerequisites
- Python 3.10 or later
Install
pip install repo-control-suite-kit
For development:
git clone https://github.com/liqiongyu/repo-control-suite-kit.git
cd repo-control-suite-kit
pip install -e .
Quick start
Three commands to go from nothing to a validated control plane:
# Install the control plane with your preferred agents
rctl init . --agents claude,cursor --profile core
# Verify that everything is wired correctly
rctl validate . --smoke
# See how ready the repo actually is (not just "did files get created")
rctl score .
Your repo now has a rctl/ directory with skills, schemas, zone configs, and a command registry — all projected into the agent surfaces you selected.
After onboarding
You don't need to learn rctl commands to use it day-to-day. Once the control plane is installed, just tell your agent what you want in natural language — it reads the routing files and follows the rctl workflow automatically.
# Agent fills in zone metadata by reading your project structure
"Help me complete rctl/control-plane/zones/root.zone.yaml based on the actual project layout."
# Agent creates a change plan, implements, verifies, and archives — all on its own
"Add a caching layer to the API client."
# Agent reads the score output and fixes each warning
"Fix all the warnings from rctl score."
The slash commands (/rctl-plan, /rctl-verify, etc.) exist for when you want to trigger a specific step manually — but for most work, natural language is all you need.
See Post-onboard runbook for the full guide.
To refresh after changing skills, profiles, or adapter mappings:
rctl update .
Commands
| Command | What it does |
|---|---|
rctl init <repo> |
Install or refresh the control plane |
rctl update <repo> |
Refresh managed files without silent clobbering |
rctl validate <repo> |
Run 5-layer structure, discovery, and enforcement checks |
rctl score <repo> |
Compute readiness with honest gating notes |
rctl enforce <repo> |
Run zone-level enforceable constraints |
rctl status <repo> |
Show active change lifecycle or list all active changes |
rctl next <repo> <id> |
Suggest — and optionally apply — the next lifecycle step |
rctl gc <repo> |
Detect and fix repository entropy: stale changes, orphaned artifacts |
All commands support --format json|text. score also accepts markdown. validate, score, enforce, and gc support --write-artifact for CI integration.
Profiles
Not every repo needs full governance on day one. Pick a profile that matches where you are:
| Profile | Skills | When to use |
|---|---|---|
| minimal | 6 | Routing, active-change flow, and verification. Nothing more. |
| core | 13 | The everyday profile. Adds context mapping, evaluation, drift scanning, permission review, archival, scoring. |
| full | 17 | The works. Adds grading, governance hardening, cleanup, and incident-to-learning loops. |
| custom | — | Pick exactly which skills to install via --skills. |
# Start small
rctl init . --profile minimal --agents claude
# Graduate later
rctl init . --profile full --agents claude,cursor,windsurf,codex --force
Skills
Skills are the core of rctl. Each one is a structured agent workflow — not a prompt snippet. They define when to trigger, what steps to follow, what success looks like, and where things commonly go wrong.
Minimal profile — 6 skills
| Skill | Purpose |
|---|---|
rctl-onboard-repo |
Bootstrap or refresh the control plane |
rctl-plan-change |
Create a durable change plan with risks and rollback notes |
rctl-implement-change |
Execute a change while keeping status and evidence current |
rctl-verify-change |
Validate against zone commands and acceptance criteria |
rctl-sync-memory |
Update durable repo knowledge after meaningful work |
rctl-validate-repo |
Check that rctl structure and discovery wiring are intact |
Core profile adds 7 more
| Skill | Purpose |
|---|---|
rctl-map-context |
Map zones, owners, and source-of-truth links |
rctl-evaluate-change |
Adversarial evaluation beyond command-based checks |
rctl-archive-change |
Archive completed changes without losing lessons |
rctl-permission-review |
Review trust boundaries before risky actions |
rctl-scan-drift |
Detect divergence between code, docs, and plans |
rctl-create-skill |
Create or improve reusable skills |
rctl-score-repo |
Score readiness honestly using structure + evidence |
Full profile adds 4 more
| Skill | Purpose |
|---|---|
rctl-cleanup-pr |
Prune stale residue after review cycles |
rctl-grade-trace |
Grade a workflow trace for compliance and usefulness |
rctl-govern-zone |
Tighten zone invariants, owners, and permissions |
rctl-incident-to-learning |
Convert failures into durable repo lessons |
How it works
graph TB
subgraph "Canonical source — rctl/"
CP["control-plane/"]
SK["skills-src/"]
REG["registry/"]
SCH["schemas/"]
end
SK -->|"project"| CODEX[".agents/skills/\n(Codex)"]
SK -->|"project"| CLAUDE[".claude/skills/ + commands/\n(Claude Code)"]
SK -->|"project"| CURSOR[".cursor/skills/ + rules/\n(Cursor)"]
SK -->|"project"| WIND[".windsurf/skills/ + workflows/\n(Windsurf)"]
subgraph "Change lifecycle"
direction LR
PLAN["Plan"] --> IMPL["Implement"]
IMPL --> VERIFY["Verify"]
VERIFY --> SCORE["Score"]
SCORE --> ARCHIVE["Archive"]
end
One truth. Projected everywhere agents look. No drift.
Generated layout
After rctl init, your repo gets this structure:
repo/
AGENTS.md # Root discovery — agents start here
CLAUDE.md # Claude Code routing (when selected)
rctl/
control-plane/ # Machine-readable manifests
changes/
active/ # Live change plans, status, evidence
archive/ # Completed change records
docs/ # Decisions, runbooks, quality artifacts
registry/ # Command, skill, profile, agent mappings
skills-src/ # Canonical skill definitions
schemas/ # JSON Schemas for validation
bridges/ # Integration protocols (e.g., OpenSpec)
.agents/skills/ # → Codex
.claude/skills/ # → Claude Code
.claude/commands/ # → Claude Code slash commands
.cursor/rules/ # → Cursor
.cursor/skills/ # → Cursor
.windsurf/rules/ # → Windsurf
.windsurf/skills/ # → Windsurf
.windsurf/workflows/ # → Windsurf
Design principles
These are opinions, not accidents:
- Keep operating truth under
rctl/. Business code and control-plane metadata don't belong in the same directories. - Root files are discovery layers, not documentation.
AGENTS.mdandCLAUDE.mdpoint agents inward — the detail lives underrctl/. - Structural completeness ≠ operational readiness. Generating files is easy. Having plans, evidence, and passing checks is hard.
rctlmeasures both, separately. - Conservative updates, explicit conflicts.
rctl updatetracks file hashes. If you edited a managed file, it writes a.rctl.newconflict file instead of overwriting your work. - One canonical source, many projections. Skills and commands are authored once under
rctl/skills-src/and projected to each agent's native surface.
Development
# Compile check
python3 -m compileall src
# Run tests
PYTHONPATH=src python3 -m unittest discover -s tests -v
# Smoke-check the control plane
PYTHONPATH=src python3 -m rctl validate . --smoke --format text
# Score this repo's own readiness
PYTHONPATH=src python3 -m rctl score . --format markdown
CI runs these across Python 3.10–3.13 on every push and PR.
When making non-trivial changes, create an active change record under rctl/changes/active/<change-id>/.
Working with OpenSpec
rctl and OpenSpec can coexist in the same repository. OpenSpec handles proposals, specs, and design intent; rctl handles execution plans, evidence, validation, and governance. The two coordinate through cross-links rather than shared directories — a formal bridge protocol defines the responsibility boundary, linking rules, and conflict resolution.
[!TIP] If your repo already uses OpenSpec, just run
rctl initas usual. Validation will detect theopenspec/directory and verify the bridge protocol is in place.
Status
Alpha (v0.5.0). Actively evolving. The CLI installs, validates, scores, enforces, and projects assets to all four agent surfaces. Change lifecycle tracking, garbage collection, and zone enforcement are functional. Areas with room to grow: merge behavior, benchmark loops, deeper discovery checks.
Community
License
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file repo_control_suite_kit-0.6.0.tar.gz.
File metadata
- Download URL: repo_control_suite_kit-0.6.0.tar.gz
- Upload date:
- Size: 109.4 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.14.3
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
6ac50a8f2283900b1de10b93f5115e303977f67ca4a710800ae7133f43c705ed
|
|
| MD5 |
92dec09c46db5eb5a42036df0dfe63b3
|
|
| BLAKE2b-256 |
e3fe594e3ee9e35c8a43a41dd6bb18b50288a4227da5338f77fe43819612405b
|
File details
Details for the file repo_control_suite_kit-0.6.0-py3-none-any.whl.
File metadata
- Download URL: repo_control_suite_kit-0.6.0-py3-none-any.whl
- Upload date:
- Size: 114.9 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.14.3
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
f44fd7914adaf8abeb7bf0c4cdb5bbdc82897d785a71a2f384291c1fc0015088
|
|
| MD5 |
14ba871ad305e1b11e1c6c7542d670cc
|
|
| BLAKE2b-256 |
4fe77db41111c3a1fb7c68579c58eb1f2ae3b2724d66ea7a698625cd89c0e4cb
|