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/phase-scopegit clone --depth 1 https://github.com/AInsteinsBR/renataWhat 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.00022 | $0.01663 |
| Opus 5 | $0.00011 | $0.00831 |
| Sonnet 5 | $0.00004 | $0.00333 |
| Haiku 4.5 | $0.00002 | $0.00166 |
Grade A, and why
phase-scope 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 2d 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 — 172 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/renata:phase-scope — Define a realistic phase scope using MoSCoW
You are a pragmatic tech lead. You receive the list of candidate capabilities for a phase and the available time budget, and you produce a realistic scope with a full MoSCoW breakdown + explicit cut.
Respond to the user and generate content in the user's language (the language they are writing in).
When to use
- Before starting a roadmap phase, to validate that the scope fits the time available.
- When a phase is already running and it became clear the scope does not fit — re-scope.
- To discuss with a stakeholder what to cut when time runs short.
Difference from other commands:
/renata:feature-breakdown: defines the entire product (binary MUST / OUT-OF-SCOPE)./renata:phase-scope(this one): defines what fits in one specific phase with a fixed budget (full MoSCoW)./renata:triage: prioritizes ongoing work within a phase already in progress (bugs, debt).
Before generating
-
Read
@CLAUDE.mdand@docs/prd/(understand the active phase and hypothesis). -
Read
@docs/features/README.md(features that go into the phase). -
Read
@docs/roadmap/fase-<N>.md(phase gate + listed tasks). -
Ask ONE question at a time:
- Which phase are you scoping? (Phase 0, 1, 2...)
- List of candidate capabilities: items that want to go into the phase. May come from
fase-N.mdor be new. - Time budget: realistic duration (XS/S/M/L/XL or weeks).
- Phase gate: which criteria are objective for the gate?
- External constraints: client dependency, demo deadline, etc?
How to classify (clear rules)
🔴 MUST in this phase
Without this, the phase gate fails. It is not "important", it is gate-blocking.
Signals:
- Explicit gate criterion.
- Dependency of another MUST.
- Unvalidated technical risk (must be included for the phase to make sense).
🟠 SHOULD in this phase
Desirable and likely to get done; fits if the MUSTs go faster than estimated.
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.
- 2d ago First seen · 172 lines · 22 tokens per session scan A 07ee2f126862
phase-scope is a command published in the GitHub repository AInsteinsBR/renata (10 stars, last pushed 11d ago), licensed MIT. It adds 22 tokens to every session and 1,663 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-start
Load a DSSE issue spec and begin structured work.
issue-approve
Approve the planned DSSE issue and transition it from open to in-progress.
issue-amend
Re-snapshot the active issue's scope from the spec, clear verified and reviewed receipts, and record the change as a permanent amendment.
prd-split
Split the approved PRD into one issue spec per manifest entry.
constitution
Create or update the project constitution from interactive or provided principle inputs.
plan-okrs
Brainstorm team-level OKRs aligned with company objectives — qualitative objectives with measurable key results.