English | 简体中文
A repository-native engineering workflow for humans and AI agents.
RSP turns unclear intent into shaped, implemented, reviewed, and verified software changes while keeping project knowledge durable and work recoverable. It uses ordinary repository files—Skills, Specs, and Plans—rather than hidden workflow state.
- Shape ambiguous work into an executable Change.
- Resolve design questions from repository evidence before implementation.
- Route diagnosis, implementation, risk-selected test-first work, review, and release work to explicit capabilities.
- Preserve current facts, lasting rationale, scoped instructions, and completed history in the right owners.
- Keep authority visible: RSP never infers permission to commit, publish, deploy, or approve work.
RSP selects the next responsibility from the task and evidence, not a fixed stage pipeline. A settled authorized task can proceed directly to implementation and its own checks; design, review, coordination and lifecycle closeout apply only when needed and permitted.
RSP requires Node.js 22 (>=22). Run setup from the target project root. For a new project, resolve a stable version once and keep that exact selection. Existing projects use the version in .rsp/version and the generated AGENTS entry, not a fresh latest resolution. Later rsp examples denote that exact invocation or a verified matching executable:
npm view @oevery/rsp dist-tags.latest
# Replace <version> with the inspected exact version.
RSP_VERSION='<version>'
npx -y @oevery/rsp@"$RSP_VERSION" init --with-project-setup
# fill .rsp/changes/project-setup.md
# fill .rsp/specs/design.md
npx -y @oevery/rsp@"$RSP_VERSION" statusThen create and focus one tracked change:
rsp create improve-login "Make login failures actionable"
rsp focus improve-login
rsp show improve-loginFocus is a set: the setup Change may still be focused alongside improve-login. Use the explicit name to inspect it; show --focused requires exactly one marker.
Confirm that status shows the expected work; use read-only doctor when diagnosing setup. These are deterministic observations, not semantic acceptance. Follow the nearest AGENTS.md, keep the selected Change current and establish applicable required verification, reusing traceable passing evidence when its tested boundary and relevant inputs still apply. Before authorized archive, decide necessary knowledge updates, converge the whole Change and check current readiness.
Read the full getting-started guide.
.rsp/
├── version # exact CLI package selection
├── specs/ # current contracts, boundaries, and constraints
├── changes/ # open work
├── focus.d/ # markers selecting work; optional short recovery capsules
└── archives/ # completed history
A Change is one Markdown file with canonical Proposal, Spec, Design, Tasks, Verify, and Blockers sections. Stable facts belong in Specs, lasting rationale in Decision Records, and scoped operating instructions in the nearest project-owned AGENTS.md.
- Getting started
- Core concepts and artifact ownership
- Daily workflow
- Skills and managed work
- Configuration reference
- CLI reference
- 3.0 migration guide and 3.1 migration guide
- 4.0 migration guide
- Changelog
- Maintainer tests and Skill validation
- Maintainer workflows, publication and documentation recovery
- Repository context and contract navigation
- Authoritative architecture and Specs and maintainer research
Run the documentation locally:
pnpm docs:dev
pnpm docs:check
pnpm docs:buildThe site is only a presentation layer over the Markdown in this repository. It adds bilingual navigation, local search, and page outlines without introducing a content database or runtime service.
RSP is a tool-agnostic file convention and works with any assistant or editor that can read project files. Humans start here; agents follow the nearest AGENTS.md, load the required project Core through host Skill discovery or .agents/skills/rsp/SKILL.md. Missing required Skills stop dependent work; there is no Rules fallback. Root skills/ contains authored sources in the RSP repository, not the consumer installation entry.
RSP 4.0 uses init for a complete setup and the selected target CLI's update for the complete environment. It pins exact versions and retires Rules and separate Skill installation; existing projects must follow the 4.0 migration guide. The seven core Skills remain independently invocable; see Skill ownership.
RSP is licensed under the MIT License.