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/ricneves-ai/flowgrammers-skillsWrote 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/ricneves-ai/flowgrammers-skills/prd)<a href="https://agentmods.dev/commands/ricneves-ai/flowgrammers-skills/prd"><img src="https://agentmods.dev/badge/commands/ricneves-ai/flowgrammers-skills/prd/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/ricneves-ai/flowgrammers-skills/prd"><img src="https://agentmods.dev/badge/commands/ricneves-ai/flowgrammers-skills/prd.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.00000 | $0.03151 |
| Opus 5 | $0.00000 | $0.01576 |
| Sonnet 5 | $0.00000 | $0.00630 |
| Haiku 4.5 | $0.00000 | $0.00315 |
Grade A, and why
prd 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 7d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- prd — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 427 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/prd
O que essa skill faz
Gera PRD (Product Requirements Document) completo em 8 seções: problema, usuários, solução, métricas, critérios de sucesso, riscos, dependências, roadmap.
Saída: PRD formatado pronto para design, eng e stakeholder review.
Quando usar
- Descoberta validou uma hipótese — hora de especificar
- Tem ideia e precisa estruturar antes de começar
- Vai rodar com múltiplos times e precisa alinhamento escrito
Input esperado
Mínimo:
- Problema: Qual problema resolve (de descoberta ou entrevistas)
- Audiência: Quem usa (personas ou segmentos)
- Ideia de solução: O que você vai construir
- Por quê agora: Por que esse problema é prioritário
Opcional:
- Dados de discovery (trechos de entrevistas, experimentos)
- Métricas hoje (baseline)
- Constraints (timeline, tech, budget)
- Competitors ou benchmark
Processo
- Contexto — Resume problema + audiência + oportunidade
- Goals e success metrics — Que sucesso parece? Como medir?
- User stories — 5-7 stories que cobrem solução
- Design constraints — Restrições técnicas, budget, timeline
- Risks e dependencies — O que pode dar errado?
- Roadmap — Phases de execução
- Success criteria — Como vai saber se funcionou?
- Approval — Quem precisa assinar
Output
# PRD: [Nome da Feature]
## 1. Problema e Oportunidade
### Problema
**1 frase clara do problema:**
Usuários de [segmento] gastam [X tempo] em [atividade], quando poderiam gastar [Y tempo].
### Contexto
- **Usuários afetados**: [Segmento], [Volume]
- **Severidade**: [Alto/Médio/Baixo]
- **Evidência**:
- [X% de usuários mencionaram em entrevista]
- [Y churn ligado a esse problema]
- [Z usuários solicitaram no feedback]
### Oportunidade de negócio
- **Mercado**: [Tamanho, crescimento]
- **Segmento**: [Quem mais sofre com isso]
- **Impacto estimado**: [X% churn reduction, Y% revenue uplift]
---
## 2. Audiência
### Persona primária
**[Nome]** — [Role], [Company size]
- Problema: Gasta [X] em [atividade]
- Alternativa atual: [Usa competitors ou workaround]
- Valor que recebe: [Y% melhoria em métrica]
### Persona secundária
**[Nome]** — [Role], [Company size]
- Problema: [...]
- Alternativa atual: [...]
- Valor que recebe: [...]
### Não-audiência
Deliberadamente NÃO building para:
- [Segmento A] porque [razão]
- [Segmento B] porque [razão]
---
## 3. Solução
### Visão (1 parágrafo)
[Descrição da solução em linguagem de usuário, não técnica]
### Features principais
#### Feature 1: [Nome]
- **O que faz**: [Descrição clara]
- **Por quê importa**: Resolve [Parte do problema]
- **Sucesso parece**: User consegue [X] em [Y tempo] vs [Z tempo] hoje
- **MVP**: [Escopo mínimo para essa feature]
#### Feature 2: [Nome]
- [...]
#### Feature 3: [Nome]
- [...]
### Escopo de exclusão (não vamos fazer)
- [Feature mencionada que NÃO vai entrar]
- Razão: [Timeline, tech debt, lower priority]
### Design principles
- [Princípio 1 que guia design decisions]
- [Princípio 2]
- [Princípio 3]
---
## 4. Métricas e Success Criteria
### Metrics de negócio
| Métrica | Baseline | Target | Timeline |
|---------|----------|--------|----------|
| [Métrica 1] | [X] | [Y] | [Timeline] |
| [Métrica 2] | [X] | [Y] | [Timeline] |
| [Métrica 3] | [X] | [Y] | [Timeline] |
### Health metrics (não queremos piorar)
- [Métrica que monitora saúde geral do produto]
- Temos [baseline] hoje, vai manter > [threshold]
### User satisfaction
- **NPS**: [Target]
- **Feature adoption**: [X% de relevant users usando em 30 dias]
- **Feature love**: [X% dizendo "love it" vs "okay" ou "hate it"]
### Go-live criteria
Produto saindo quando:
- ✅ Todas as features principais QA'd
- ✅ Performance metrics atingidos
- ✅ Docs e support materiais prontos
- ✅ Rollout plan executado (beta → general)
---
## 5. Constraints e Dependências
### Constraints técnicas
- **Stack**: [Linguagem, arquitetura afetada]
- **Performance**: [API deve responder em < Xms]
- **Integrations**: [Sistemas que precisa se integrar]
- **Scale**: [Precisa suportar X usuários simultâneos]
### Constraints de negócio
- **Timeline**: Deve sair em [data] por causa de [razão]
- **Budget**: [$X] para feature
- **Team**: [Eng alocação, design, PM]
### Dependências
1. **[Equipe/Sistema]** — Precisa de [O quê] até [Data]
- Blocker se não: [Impact]
- Plano B: [Se não conseguir, fazer isso]
2. **[Equipe/Sistema]** — Precisa de [...]
- [...]
### Risks e mitigações
| Risk | Probabilidade | Impacto | Mitigação |
|------|-----------|--------|----------|
| [Risk 1] | Alta | Alto | [Mitigação] |
| [Risk 2] | Média | Médio | [Mitigação] |
| [Risk 3] | Baixa | Alto | [Mitigação] |
---
## 6. Roadmap
### Phase 1: MVP (Semana 1-3)
Features:
- Feature 1 (core)
- Feature 2 (parte A)
Métricas críticas:
- [Métrica que define sucesso de MVP]
Go-live: [Data aproximada]
### Phase 2: Robustez (Semana 4-6)
Features:
- Feature 2 (parte B)
- Feature 3
Refinamentos:
- Performance optimization
- Bug fixes
### Phase 3: Expand (Semana 7+)
- Feature 4 (se MVP sucesso)
- Suporte para novo segmento
---
## 7. Casos de uso e User Stories
### Caso de uso 1: [Descrição]
Dado que [contexto], Quando [ação], Então [resultado esperado].
### Caso de uso 2: [...]
[...]
---
## 8. Perguntas abertas
- [ ] [Pergunta para clarificar com stakeholder]
- [ ] [...]
---
## Aprovação
| Role | Responsável | Aprovado? | Data |
|------|-----------|-----------|------|
| Product | [Name] | ☐ | |
| Engineering Lead | [Name] | ☐ | |
| Design | [Name] | ☐ | |
| [Stakeholder] | [Name] | ☐ | |
**Versão**: 1.0
**Última atualização**: [Data]
**Próxima review**: [Data + 1 mês]
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.
- 7d ago First seen · 427 lines · 0 tokens per session scan A a811e87286f1
prd is a command published in the GitHub repository ricneves-ai/flowgrammers-skills (111 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 3,151 tokens. 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-09-03.
Other commands, from other repositories
template
Manage issue templates for streamlined issue creation.
sync-linear
Sync current work with Linear ticket status.
add-note
Add an internal or external note to a ConnectWise PSA ticket.
fest-show
Show festival progression (in-progress tasks, roadmap, and dependency view).
dispatcher
Pick the next-best repo to work on across the portfolio — rank free repos, recommend one, claim its lease atomically, and route to the entry command.
workpm
A project-management workflow for coordinating multiple AI workers through five stages. It includes task assignment, shared activity logs, worker replacement, and final checks.