القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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, 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.
| name | rara-docs-journal |
| description | 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. |
Use this skill when writing or reviewing docs/journal/YYYY-MM-DD-topic.md
files in this repository.
Keep journals as concise implementation records:
Journals are not canonical specs and should not become scratch-note dumps.
docs/journal/.YYYY-MM-DD-topic.md.docs/features/.docs/todo.md.A normal journal should use these sections when they fit:
SummaryBackgroundScopeKey DecisionsValidationFollow-UpsFor small checkpoints, shorter headings are fine if the entry still records the post-change truth and the remaining work.
Do not leave pre-fix wording in place after the same PR already changed the code or docs. If a step landed, mark it as done or remove it from remaining work.
If docs/todo.md references a journal decision, both files must agree on:
List commands or checks that support the entry.
Good examples:
cargo test tui::render::tests::bottom_pane_grows_for_multiline_input -- --nocapture
cargo check
gh pr checks 395 | cat
Avoid vague validation such as tested locally or CI should pass.
Follow-ups should describe remaining work only. If a broad item was partly completed, rewrite the follow-up as the unresolved tail instead of repeating the old broad task.
Check:
docs/features/docs/todo.md