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.
npx agentmods add commands/ainsteinsbr/renata/screensgit 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/screens)<a href="https://agentmods.dev/commands/ainsteinsbr/renata/screens"><img src="https://agentmods.dev/badge/commands/ainsteinsbr/renata/screens.svg" alt="Measured on agentmods" 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 | $0.00027 | $0.02420 |
| Opus 5 | $0.00014 | $0.01210 |
| Sonnet 5 | $0.00005 | $0.00484 |
| Haiku 4.5 | $0.00003 | $0.00242 |
Grade A, and why
screens 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 5d 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 — 269 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/renata:screens — Screen inventory, flow, and briefs (UX design)
You are a Product Designer + PM. You receive context in $ARGUMENTS (optional) and structure the product's screen design: inventory, flow between screens, states, and structured briefs for external tools (Claude Design, Lovable, v0.dev, Figma).
Core philosophy: this command does NOT generate pixels or UI code. It structures the decisions about screens (what exists, how it connects, why) and generates reusable briefs that you paste into external tools.
Respond to the user and generate content in the user's language (the language they are writing in).
⚠️ The output of external tools (Lovable, v0, Claude Design) is a PROTOTYPE, not final code. The technical-architecture step and the execution-plan step decide how much to reuse vs rewrite according to the project's ADRs.
When to use
- After
/renata:feature-specfor the anchor feature is ready. - When the product has a significant UX component (anything with a screen for a human user).
- Before the roadmap step — because the roadmap needs to estimate with a visual sense.
When NOT to use
- ❌ Product without UI (CLI tool, API, library, internal microservice).
- ❌ Product with 1 trivial screen (e.g. a Phase 0 technical spike with 1 button).
- ❌ To generate pixels — that is the external tool's job.
Before generating
- Read
@CLAUDE.md(product context). - Read
@docs/prd/(understand scope IN/OUT — screens only exist for IN capabilities). - Read
@docs/business-context/personas.mdandjornada.md— screens serve personas and journey moments. - Read
@docs/features/README.mdand the anchor feature-spec — screens implement features. - Detect whether
docs/decisions/ADR-*-frontend*.mdexists (a standard frontend / starter-kit ADR):- If YES: read the ADR and extract the starter's constraints (components, palette, stack). The briefs will be generated already including those constraints, and the expected output is "implement in the existing starter", not "generate from scratch".
- If NO: briefs will be generic, and the expected output is "generate the screen in the external tool".
- Read other ADRs in
@docs/decisions/— any decision about UX, mobile-first, etc. - Ask ONE question at a time:
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.
- 5d ago First seen · 269 lines · 27 tokens per session scan A c7a44f6ccaf6
screens is a command published in the GitHub repository AInsteinsBR/renata (10 stars, last pushed 14d ago), licensed MIT. It adds 27 tokens to every session and 2,420 once invoked, about $0.0001 per session on Opus 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
issue-closeout
Triage Codex findings via per-finding dispositions, mark findingstriaged, close the active issue.
issue-review
Run Codex native + adversarial review against the active issue, scoped to allowedfiles, capped per kind.
prd-review
Review the active PRD with Codex and stream normalized findings to JSONL.
prd-triage
Triage pending findings on the active PRD.
prd-archive
Archive the active PRD (terminal state).
issue-start
Load a DSSE issue spec and begin structured work.