Rpa Init

---
name: rpa-init
metadata:
  version: 1.0.2
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. **Optional git update** — if the directory is a git repository and the user has not asked to stay on the current commit, run `git pull` to refresh the local copy before analysis.
2. **Scan** repository structure (layout, monorepo packages if any).
3. **Read** user-facing documentation and specs.
4. **Study test code** (naming, fixtures, markers, integration vs unit). This is the BDD-facing view of expected behavior.
5. **Set up dev environment** so tests can run (create venv, install deps, any documented bootstrap). Note blockers if setup cannot be completed.
6. **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).

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

## Report template

Use this structure (adapt if needed):

```markdown
## 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
```

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