Skills and managed work

RSP 4.0 defines seven host-neutral core Skills installed together and loaded on demand. Each Skill has a narrow authority boundary; routine session work does not require inventing a Change. Behavioral evidence remains specific to its tested source and scenarios.

Skill	Responsibility
rsp	Select the current branch; continue ordinary authorized work through checks and necessary writeback, or coordinate only when qualified.
rsp-shape	Answer a bounded read-only design question or, with planning authority, shape one executable Change or justified shallow Group.
rsp-implement	Diagnose read-only when requested; implement authorized fixes, use test-first work when warranted, and correct accepted fixed findings with fresh checks.
rsp-doc	Write repository documents, Skills and release communication for a defined reader and result.
rsp-verify	Run one bounded read-only verification pass against a selected WorkOwner's declared evidence boundary.
rsp-review	Review a fixed code, document, or mixed comparison, including release communication, without mutation.
rsp-commit	Inspect delivery readiness read-only or create one authorized exact-scope local commit.

Structural discovery is a conditional method of rsp-review. It examines an explicit repository/subtree boundary without requiring a diff; ordinary review does not expand into an audit. Findings grant no implementation or design authority.

rsp-doc is installed with the complete suite and may be invoked directly. Use artifact lenses for README, CONTEXT, Spec, Change and guides; use the Skill branch for package creation or revision, and release communication for changelogs, release notes, migration or authorized document reconciliation. Review loads release checks only for reviewed release documents. Neither method controls publication or establishes release readiness. Local wording fixes and mechanical status/evidence updates remain direct when they need no whole-record reconciliation. Whole-Change convergence uses the artifact method when Doc is available, even when few lines change; already-converged text needs no rewrite. The maintainer-only author-rsp-skills adds local Change, provenance and evaluation requirements.

Pinned Skills-only migration

For consumer projects, RSP 4.0 records an exact CLI in .rsp/version. Init creates project files and installs the complete suite. Ordinary commands keep that selection; only an authorized update deliberately selects another exact target. Source identity includes more than version metadata, and older CLIs have no retrofitted guard.

Before upgrading from 3.3, preserve managed customizations and replace the entire legacy manage mapping with an explicitly chosen workflow policy. Validate it with the target's config --json before update; update does not convert configuration. See workflow policy and the ordered 4.0 migration guide for commands, removed interfaces, success checks and recovery boundaries.

The RSP development repository explicitly selects its own source with .rsp/source containing ., instead of a version pin. Build with mise exec -- pnpm run build, then use mise exec -- node dist/cli.mjs <command> from that checkout. Another checkout or registry CLI is not a substitute, even with the same version metadata. Init/update preserve this selection without creating .rsp/version; doctor reports source mode. Conflicting, malformed or symlinked markers fail closed. This mode is not inferred for consumer projects. Candidate identity includes the commit, dirty diff and build inputs; source mode alone does not establish build freshness.

Preserve needed local modifications in managed assets, then run the target CLI's update. It reconciles the complete suite, refreshes managed project files and removes retired Rules and known obsolete Skills. Optional update --dry-run previews without writes. No separate adoption, deletion, force or Skill installation steps are required. Keep ongoing customizations in project-owned instructions or separately named Skills; unknown names, configuration values and project knowledge remain intact.

Doctor and skills list are read-only. Doctor reports actual pin/suite drift and retired names; only doctor --check-updates queries stable metadata, with a two-second timeout. Notices grant no upgrade authority. Missing required Skills stop dependent work without fallback reading or implicit installation.

Migrating the earlier Skill names

Known retired identities are removed during update: rsp-address-review, rsp-codebase-audit, rsp-structural-audit, rsp-design, rsp-diagnose, rsp-manage, rsp-release-docs, rsp-resolve-findings and rsp-tdd. Route design to Shape, diagnosis/test-first/correction to Implement, coordination to Core, writing to Doc and review to Review. These mappings grant no authority over unknown custom Skills.

Update leaves the retired Rules directory and unknown contents in place. An empty directory is harmless. If Doctor reports unsupported .rsp/rules/ entries, review and migrate their instructions, then rerun Doctor. Remove the directory with rmdir .rsp/rules only when it is empty.

Update replaces only package-owned assets. User config and knowledge/work directories are not rewritten or repaired; missing settings use read-time defaults. AGENTS changes are confined to its managed block, and the version is written last. Canonical maintainer links to package sources are preserved; unexpected managed symlinks are rejected.

Failure stops without whole-update rollback or recovery copies. Completed replacements and deletions remain applied. Fix the cause and rerun the same exact target CLI. Incomplete fresh initialization can likewise retry init without overwriting user files. There is no recovery command, arbitrary downgrade or crash-recovery guarantee; avoid concurrent edits during setup. Repeated init does not adopt another pinned version.

Installation, runtime role, and invocation are separate:

Skills	Distribution	Runtime role	Invocation
rsp	default	Core	direct project entry
rsp-shape	default	Shape	Core-routed or explicit shaping
Implementation, verification, and review	default	Discipline	Core-routed specialist or explicit bounded request
rsp-commit	default	local-delivery Discipline	explicitly authorized exact boundary; closure policy never grants Git authority
Conditional coordination in rsp	within Core	coordination branch	selected under effective project policy only for an actual obligation
rsp-doc	default	writing Discipline	repository-document, Skill or release writing

default means included in the 4.0 suite; it does not mean automatically invoked. A Skill boundary is not a worker boundary. Core's qualified coordination branch can compose bounded worker lanes, but selection alone does not imply delegation. Install/update the seven core Skills together from one package version. Direct invocation does not require executing Core: when tracked work identities are needed, each consumer reads Core references/work-model.md unless already in its context. Independent workers supply their own context. Missing shared resources indicate an incomplete installation; do not invent definitions.

At task transitions, Core selects from the current requested result and authority, not the last-used Skill or edit size, and loads only the applicable entrypoint and method not already in context. Shape owns decision clarification and planning artifacts, not approval of material choices or new public requirements; Doc writes settled facts and converges final work records. Changing responsibility grants no new authority and requires no extra worker, repeated checks or user continuation.

Compose the suite from evidence

• Shape can answer one bounded design question read-only without inventing a WorkRef or plan. Authorized planning may create or refine a Change or justified shallow Group; advice within tracked work retains its existing owner without editing it unless authorized.
• Implement investigates unexplained failures before correction. Diagnosis-only remains read-only without creating an owner. An authorized fix proceeds within the same scope after confirming cause; use pre-mutation RED only when explicitly required or justified by concrete risk.
• Implement disposes each fixed finding as accepted, rejected, or needing clarification, corrects accepted findings within authority and runs affected checks. When review is requested or required, Core coordinates the separate read-only judgment; a repair-only request returns the correction without inventing review or self-certifying review-clean.
• Verify executes a declared read-only evidence boundary when required; ordinary Implement checks need no Verify handoff. A Change uses its WorkRef and Verify boundary; a Group uses a named Integration: condition from its Brief. A request-only boundary must be written back before Group closeout. Required independent acceptance needs host-observed distinct workers.
• Release writing uses Doc; release-document review uses Review. Both load only their applicable method, preserve evidence and migration boundaries, and confer no publication authority.
• Release checks without a selected WorkOwner stay with Core and the project's declared checks, not an invented Change or ownerless Verify request. Require an exact candidate, any range the checks need, and authority for their actual effects; missing prerequisites stop dependent checks. Preserve required independent acceptance and separate Git/publication authority.
• Doc and Review apply the adopted writing-quality contract: grounded facts, useful structure, concise result steps, stable notation and preserved meaning. Skill tables are sparse fixed mappings; human documents use tables for reader-relevant comparison. Agreed expression rules are reviewable contracts, not personal preference.
• Doc owns writing/self-checks; formal Review stays read-only. Review selects Code for behavior/tool semantics and Document for explanation/usage within fixed content. Complete Skill instructions normally need both; comments and embedded examples receive proportionate applicable checks, not classification by extension. Authority-only reads do not enlarge the target. Review grants no repair authority; originally authorized corrections may continue. Static checks do not prove live behavior or independent acceptance.
• The host, user, and Git own execution-location selection and cross-branch integration. Core's coordination branch operates only in the checkout or environment it actually observes; no canonical Skill selects or lands an execution environment.
• Commit owns one exact local commit in the current checkout and never absorbs cherry-pick, cleanup, or cross-branch integration.
• No Skill infers commit, push, publication, deployment, approval, or human-acceptance authority.

Control outcomes

Core selects from intent, authority, available ownership, and checkout evidence, then loads only the chosen branch's detailed guidance. Within one authorized request, ordinary single-owner work continues through required and proportionate checks and necessary writeback without another continue. It needs no invented Change for a trivial session task and gains no archive or commit authority.

The owning capability chooses permitted methods under the same goal, scope, authority, authoritative baseline and evidence requirements. CLI and scripts provide deterministic diagnostics and observations, not semantic approval. A method change cannot waive a named mandatory command, required independent worker or protected RSP operation. For effect-aware recovery and stops, follow Verify and review. Return to Core for completed responsibility, a changed boundary, required cross-capability independent acceptance, or a real unresolved blocker; that return does not itself require another user turn. No route, controller state, or second ledger is persisted.

Work ownership, decision ownership, transient handoff, execution uncertainty, and acceptance are separate concepts. WorkOwner means the selected Change or shallow Group, DecisionOwner means the human or authority source required for a material decision, and NextOwner means the next control or execution capability. A stop must say who acts next, what input is required, and whether work returns through Shape or Core, or waits for fresh evidence, environment, verification, or capability. Missing required worker creation, a worker-authored result, or required host attribution is unavailable evidence, never successful completion.

Three review-related gates remain distinct:

• Implementation verification establishes applicable evidence for the current outcome. Reuse still-applicable passing results; run only missing, failed or invalidated checks. Explicit reruns and required independent execution remain binding.
• Fixed-scope change review is the report-only Review comparison. It is required when explicitly requested, required by project authority or risk, or needed by selected acceptance; it is not automatically required for every tiny direct action.
• The durable writeback decision is required before archive and independently decides whether stable current facts or lasting rationale must update a Spec, scoped instruction, or Decision Record. It never substitutes for fixed-scope change review.

These outcomes exist only in the current response and host execution context. Changes and Groups remain the durable owners, and their lifecycle remains open or archived.

Managed automation

Core selects capabilities directly. Direct is bounded work without durable tracking; Change retains one recoverable acceptance/delivery boundary; Group coordinates independently acceptable children with dependencies or integration. Complexity or worker count alone does not justify Group.

Automatic delegation is off by default. Explicit worker requirements remain binding; when auto is enabled, the user or main agent decides worker count within host resources. Main owns dependency/resource decisions and result acceptance; workers do not recursively delegate by default. Separate Review/Verify is selected for an actual obligation, not for each task or worker.

Ordinary completion and checkpoint commits leave work open. Established final delivery selects ask/auto/manual closure independently of Git authority. Necessary stable knowledge is updated before final Change reconciliation, which may be one operation. Reuse applicable tests and reviews; supplement only missing or invalidated evidence. Independent review does not itself require independently executing every test.

See workflow configuration and explicit legacy migration. No configuration grants commit, push or publication authority. Core prepares the exact boundary; Commit owns authorized staging and one local commit. Archive/commit failure is reported from actual effects, without automatic reopen or history rewrite.