RPent: Skill for Claude Code

Review an RPent change

Use AGENTS.md and CONTRIBUTING.md as repository guidance. Prioritize correctness and real maintenance costs. Adapt the review to the change; the guidance below is not an exhaustive checklist or a quota of findings.

1. Establish scope and versions

• For a PR, use available GitHub tools or Git to read its description, live base repository/branch/SHA, exact head SHA, diff, checks, and review threads. Fetch those refs and the latest RLinf/RPent main. Verify remote URLs; origin may be a contributor's fork.
• Use the verified base/head merge base to identify the PR's changes. Read full files and consumers at the head, then compare affected interfaces with current upstream main. Keep PR scope separate from later main refactors.
• Do not use an unrelated checkout or uncommitted work as upstream evidence. Use git show <ref>:<path>, git diff, and git log, or equivalent GitHub reads. If a ref is inaccessible, state the missing evidence.
• For local review, establish the requested staged, unstaged, or branch diff and its baseline. Identify that snapshot explicitly in the report.

2. Understand the change

Identify the problem, previous behavior, proposed behavior, main implementation choices, and affected entry points. Trace configuration and registration through the actual callers; verify the PR description against the code.

For RPent, inspect relevant paths across planner/session, prompt/tool schema, toolkit, Env/VLA RPC, and CLI/Dashboard runtime. Identify the affected callers and the prompts, tool results, and observations the model receives.

3. Review correctness and project fit

Choose the depth of review from the affected contracts and plausible failure modes. Follow relevant callers beyond the diff where needed. Keep findings attributable to the change; identify pre-existing problems separately when they materially affect the review.

• Correctness and lifecycle: verify intended behavior, defaults, state transitions, and error handling through the affected entry points. For concurrent or resource-owning code, inspect cancellation, partial startup, cleanup, and ownership of services and artifacts. Check that constraints hold at the operation that executes them, including alternate callers.
• Design and current-main integration: compare with the nearest current implementation and shared helpers, registration, configuration, and optional imports. Assess abstractions, compatibility paths, and validation against actual consumers and supported data. Propose simplifications with concrete evidence while preserving required behavior. Explain any mismatch with a main refactor; being behind main or mergeable alone is not evidence of one.
• Module boundaries: check new files and changes to existing classes, methods, and helpers. Trace callers and imports to identify the module that owns the behavior. A placement finding needs a project convention or a comparable implementation, the coupling or maintenance cost, and a suggested location.
• Shared classes and interfaces: identify the shared behavior being added and its callers. Check the effect on other subclasses and backends, including those that do not use the feature. Look for backend-specific policy, imports from higher layers, or unrelated state added to common components. Consider existing extension points and direct calls before adding another abstraction. A small feature can require a shared change. Recommend a split only when it clarifies responsibility or reduces coupling.
• Contract changes: check whether existing flags, parameters, or methods gain new guarantees or restrictions. Trace their callers even when names, types, and defaults are unchanged. If one flag controls multiple behaviors, verify that each caller satisfies all of them, and check the matching tests and documentation.
• Documentation and model inputs: when public behavior or prose changes, use docs-check to verify accuracy, useful explanation, and natural, consistent language. For prompt or tool changes, inspect the rendered instructions, schemas, results, and affected planner modes; judge omissions, conflicts, and repetition by their effect on the model's task.
• Tests and evidence: check that coverage exercises the changed contract and would detect the intended regression through the relevant entry path. Assess whether added cases provide useful coverage and whether existing tests can be extended. Follow AGENTS.md for test design and style; avoid speculative nits or issues already resolved by passing gates.