rpa-init

Install

/plugin marketplace add EvilFreelancer/rpa-skills
/plugin install rpa-init@rpa-skills

This is third-party code. Review the repository files before installing.

What it does

On /rpa-init the agent studies the project layout, documentation and test code, which the skill treats as the behavior specification. It then installs dependencies as the project documents, runs the tests and records failures without fixing them. It finishes with a templated report: purpose, environment, test commands, covered scenarios, gaps, risks and next steps.

Who it is for. For developers starting on an unfamiliar repository who want to load context into the agent quickly.

Example request

/rpa-init

Limitations

The default flow targets Python and pytest; for other stacks the agent follows their standard commands. Report quality depends on the project's docs and tests.

How to disable. Uninstall the rpa-init plugin via /plugin or remove the rpa-init folder from the skills directory.

Security check

• The agent installs dependencies and runs the project's tests

README in short

rpa-init is part of Pavel Rykov's rpa-skills catalog and is packaged from the cursor-vibe-prompts collection. The README covers its purpose, the agent's steps and installation as a Claude Code plugin or a skill folder for Cursor, Codex and Kimi Code CLI. It can be invoked by slash command, @ context or automatically by description. MIT licensed.

SKILL.md

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

# RPA project initialization (context warm-up)

## Intent

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.

## Preconditions you must verify yourself

1. Read **application source**, **docs**, and **tests** (test code is part of the specification).
2. **Dev environment** - install dependencies and prepare the environment the repo documents (for example `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.
3. Locate how tests are run. Default for Python: `pytest` via `.venv` when present. Respect `pytest.ini`, `pyproject.toml`, or `tox` / `nox` if present.
4. Identify entrypoints: `README`, `docs/`, package layout, `main` modules, CLI.

## Workflow

1. **Scan** repository structure (layout, monorepo packages if any).
2. **Read** user-facing documentation and specs.
3. **Study test code** (naming, fixtures, markers, integration vs unit). This is the BDD-facing view of expected behavior.
4. **Set up dev environment** so tests can run (create venv, install deps, any documented bootstrap). Note blockers if setup cannot be completed.
5. **Run the test suite**, for example:

   ```bash
   .venv/bin/pytest -q
   ```

   If tests fail, record where and why (do not fix unless the user asked).

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

## Constraints

- Comments in any new code: English only.
- Do not add secrets or keys.
- If the repository is not Python, still follow the same pattern: official install and test commands, then report.

Related