Menú
Use when creating, revising, or reviewing RARA canonical feature specs under docs/features/. Applies to stable runtime, TUI, protocol, memory, provider, skill, plugin, and tool contracts, including scope boundaries and validation matrices.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Use when you need to understand the RARA codebase structure — what each file does, where subsystems live, and how they connect. The index maps every source file to its role.
Use when preparing, validating, tagging, or troubleshooting a RARA release. Enforces the release order that prevents tag versions from diverging from the Cargo package version.
Handle unused code warnings by investigating purpose via journals, then choose the right fix: suppress, wire-up, or remove.
Add or update tests for the RARA codebase. Use when implementing non-trivial behavior changes, fixing regressions, tightening TUI rendering, or adding repo-specific test coverage in Rust. Especially relevant for focused unit tests, TUI snapshot tests, agent/runtime regressions, and behavior-driven test updates in this repository.
Use when preparing commit messages, pull request titles, or first-line summaries for the RARA repository. Enforces the repo's short conventional title subset using feat, fix, chore, or test.
Use when creating, updating, or reviewing RARA implementation journals under docs/journal/. Applies to dated rollout notes, implementation checkpoints, validation evidence, and deciding what belongs in a journal versus a feature spec or docs/todo.md.
| name | rara-docs-spec |
| description | Use when creating, revising, or reviewing RARA canonical feature specs under docs/features/. Applies to stable runtime, TUI, protocol, memory, provider, skill, plugin, and tool contracts, including scope boundaries and validation matrices. |
Use this skill when writing or reviewing docs/features/*.md files in this
repository.
Keep feature specs as the stable source of truth for:
Feature specs are not date-stamped rollout notes and should not read like a PR-by-PR changelog.
docs/features/.docs/features/.docs/journal/.docs/todo.md.Prefer these sections for active specs:
ProblemScopeNon-GoalsArchitectureContractsValidation MatrixOperational NotesOpen RisksSource JournalsIf a section is intentionally short, keep it short, but do not silently drop scope, non-goals, contracts, or validation.
A spec should answer what behavior is intended, what boundary is canonical, and what downstream consumers can rely on.
Avoid:
Do not let a spec silently expand into adjacent surfaces. If a capability is
deferred, put it in Non-Goals or Open Risks instead of implying it is
already part of the contract.
When a transition exists, identify the canonical path and the compatibility path separately. Do not describe both as equally primary unless they truly are.
The validation matrix should name focused checks that prove the contract:
When multiple journals describe the same area:
docs/todo.md follow-ups at the canonical spec.Check: