// Run when the user invokes /rpa-init or asks to onboard or warm up context on a repository. The agent studies code, reads documentation and test code, sets up the dev environment as the project expects, runs tests, and writes a short project report. No extra user brief is required.
Run when the user invokes /rpa-bugfix together with a clear bug description (expected vs actual, reproduction). Reproduction test first, then fix, full test suite, short report. Will not work correctly without the bug details.
Run when the user invokes /rpa-feat together with a clear feature description (for example issue text). BDD workflow: plan, failing tests, implementation, green tests, full suite, docs and examples, linter at the end. Will not work correctly without the user supplying what to build.
Run when the user invokes /rpa-gen-rules or asks to create or refresh agent project rules (Cursor .mdc, Claude Code CLAUDE.md and .claude/rules). Infers from specs, docs, and code. Rules use a layered-cake model (implement inner layers with no dependencies first, then the next layer) and BDD-style delivery. No separate user brief required.
Use when the user needs logical analysis, reasoning chains, or critical thinking grounded in classical formal logic (concepts, judgments, syllogisms, induction, fallacies). Triggers: analyzing arguments, checking validity of inferences, classifying concepts or judgments, building syllogisms, identifying logical errors, solving logic textbook problems, constructing proofs, or evaluating hypotheses and analogies.
| name | rpa-init |
| version | 1.0.0 |
| description | Run when the user invokes /rpa-init or asks to onboard or warm up context on a repository. The agent studies code, reads documentation and test code, sets up the dev environment as the project expects, runs tests, and writes a short project report. No extra user brief is required. |
Treat automated tests as the project long-term memory. Initialization maps documented intent, behavior encoded in tests, and implementation. Prefer learning from tests and docs before inferring only from production code.
python -m venv .venv, pip install -e ., uv sync, npm ci, or commands from README / CI). If the stack is not Python, follow that ecosystem's norms.pytest via .venv when present. Respect pytest.ini, pyproject.toml, or tox / nox if present.README, docs/, package layout, main modules, CLI.Scan repository structure (layout, monorepo packages if any).
Read user-facing documentation and specs.
Study test code (naming, fixtures, markers, integration vs unit). This is the BDD-facing view of expected behavior.
Set up dev environment so tests can run (create venv, install deps, any documented bootstrap). Note blockers if setup cannot be completed.
Run the test suite, for example:
.venv/bin/pytest -q
If tests fail, record where and why (do not fix unless the user asked).
Summarize in a concise report (see template). Use English for code-related terms if the codebase uses English; respond in the user's language for narrative.
Use this structure (adapt if needed):
## Project snapshot
- Purpose (one paragraph)
- Main packages and boundaries
## Dev environment
- What was installed or configured (venv, package manager, key commands)
## How to run tests
- Commands actually used
## Behavior from tests
- Scenarios covered by tests (bullets)
- Gaps (important paths with weak or missing tests)
## Risks and notes
- Flaky tests, secrets, external services
## Suggested next steps
- 1 to 3 follow-ups