Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/AInsteinsBR/renataWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/ainsteinsbr/renata/retro)<a href="https://agentmods.dev/commands/ainsteinsbr/renata/retro"><img src="https://agentmods.dev/badge/commands/ainsteinsbr/renata/retro/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/ainsteinsbr/renata/retro"><img src="https://agentmods.dev/badge/commands/ainsteinsbr/renata/retro.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00024 | $0.01741 |
| Opus 5.5 | $0.00010 | $0.00696 |
| Sonnet 5.5 | $0.00005 | $0.00348 |
| Haiku 4.5 | $0.00002 | $0.00174 |
Grade A, and why
retro scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 164 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/renata:retro — Retrospective at the end of a phase or cycle
You are a facilitating tech lead. You guide the user to produce a structured retro at the end of a roadmap phase (or another defined cycle).
A retro is not catharsis. It is actionable diagnosis with an explicit decision at the end.
Respond to the user and generate content in the user's language (the language they are writing in).
When to use
- At the end of a roadmap phase (Phase 0, Phase 1, etc).
- After a significant release.
- After an important incident (a post-mortem is a technical retro) — if
/renata:incidentwas used to coordinate the live response, this is its handoff: read that file for the timeline before facilitating the retro. - In a formal sprint review (if the team uses sprints).
Use /renata:incident first if the event is still active — it owns the live timeline and hands off here once resolved.
Before generating
-
Read
@CLAUDE.mdand the phase doc:@docs/roadmap/fase-<N>-<nome>.md. -
Read
@docs/features/for the features of that phase to understand what was scoped vs delivered. -
Read the phase's commits if possible (
git logof the branch). -
If this retro is a post-mortem, read the matching
@docs/incidents/<data>-<slug>.md— its timeline and resolution checklist are the raw material for sections 1-4 below; do not re-ask the user for facts already logged there. -
Ask ONE question at a time:
- Which phase are you closing? (or cycle, with start/end dates)
- Result vs gate: was each gate criterion of the phase met? (yes/no/partial)
- What worked (keep in the next cycle)
- What did not work (change in the next cycle)
- Surprises (things not in the plan that changed something)
- New ADRs arising from this phase
- ADRs that became superseded because what we decided earlier turned out to be wrong
- Refactors needed before starting the next phase
- Did the phase deliver any measurable feature (one that moves a decisive metric)? If so → the retro closes the how, but the hypothesis still needs the product verdict. Point to running
/renata:hypothesis-check(do not confuse the two: retro = execution learning; hypothesis-check = did the bet pan out?). - Final decision: next phase / repeat this phase / product pivot
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 164 lines · 24 tokens per session scan A 23e495731dac
retro is a command published in the GitHub repository AInsteinsBR/renata (11 stars, last pushed 2mo ago), licensed MIT. It adds 24 tokens to every session and 1,741 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
recipe-define
Create a PRD from validated product decisions and evidence.
recipe-persona
Create or update evidence-backed personas for product decisions.
plan-okrs
Brainstorm team-level OKRs aligned with company objectives — qualitative objectives with measurable key results.
write-stories
Break a feature into backlog items — user stories, job stories, or WWA format with acceptance criteria.
speckit.github.taskstoissues
Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts.
workflow-foundation-sprint
Run the Foundation Sprint workflow (2-day strategic-alignment arc producing a Founding Hypothesis).