From devflow
Use to generate a complete product PRD with phased roadmap — supports new projects and retroactive PRD for existing codebases
npx claudepluginhub nexuz-sys/devflow --plugin devflowThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Generate a complete Product Requirements Document with all phases defined upfront. Supports two modes: new projects (Modo A) and existing codebases (Modo B). The PRD lives above the PREVC cycle — each phase becomes a separate PREVC run.
Language: All templates, interview questions, and announcements below are written in English as structural references. When executing this skill, use the user's configured language (see devflow:language) for ALL output: PRD content, section headers, labels, interview questions, and status announcements. Keep only technical terms (e.g., RICE, MoSCoW, MVP, PREVC) untranslated.
Announce at start: "I'm using the devflow:prd-generation skill to generate the product PRD."
You MUST create a task for each of these items and complete them in order:
devflow:context-awarenessdevflow:feature-breakdown.context/plans/<project>-prd.mdAuto-detect based on project state:
| Condition | Mode |
|---|---|
.context/docs/project-overview.md exists with status: filled | Modo B (existing project) |
docs/superpowers/specs/ has spec files | Modo B (existing project) |
| Otherwise | Modo A (new project) |
Announce the detected mode: "Detected Modo A/B — [new project / existing codebase]."
Invoke devflow:context-awareness to map the project.
context({ action: "buildSemantic" })
context({ action: "getMap" })
context({ action: "detectPatterns" })
Read in order:
.context/docs/project-overview.md.context/docs/codebase-map.json.context/docs/development-workflow.md.context/docs/testing-strategy.mdExplore project files, README.md, package.json/Cargo.toml/go.mod, recent git commits.
Without asking any questions yet, build a "Current State" picture:
.context/plans/ — existing plans and their completion statusdocs/superpowers/specs/ — specs already generatedgit log --oneline -30 — recent features and milestonesOutput internally: a draft "Current State" section for the PRD.
Socratic process — one question at a time. Prefer multiple choice when possible.
Present the "Current State" analysis first, then ask:
Continue with follow-up questions as needed. Stop when you have enough to define all phases.
Apos a entrevista do PRD, coletar informacoes sobre a stack tecnica do projeto.
Perguntas (uma por vez, multipla escolha):
"Quais sao as linguagens principais do projeto?"
"Qual cloud provider?"
"Qual padrao de arquitetura?"
"Usa Infrastructure as Code?"
"Qual CI/CD?"
Salvar as respostas como secao Stack no PRD:
## Stack
| Aspecto | Escolha |
|---------|---------|
| Linguagens | Python, TypeScript |
| Cloud | AWS |
| Arquitetura | Layered |
| IaC | Terraform |
| CI/CD | GitHub Actions |
Cross-reference codebase analysis with interview answers:
Choose the template that matches the project scope, then apply it:
| Template | When to Use | Typical Scope |
|---|---|---|
| Standard PRD | Complex products with multiple phases | 6+ weeks |
| One-Page PRD | Simple features or small products | 2-4 weeks |
| Feature Brief | Exploration / pre-PRD validation | ~1 week |
| Agile Epic | Sprint-based delivery teams | Variable |
Default to Standard PRD unless the user requests otherwise or scope is clearly small.
Apply the Standard PRD template structure adapted for phased delivery:
---
type: plan
name: <project>-prd
description: Product Requirements Document
category: prd
generated: YYYY-MM-DD
status: active
scaffoldVersion: "2.0.0"
---
# PRD: <Project Name>
## Executive Summary
- **Problem:** [2-3 sentences]
- **Solution:** [2-3 sentences]
- **Business Impact:** [3 bullet points]
## Product Vision
[End goal, differentiation, target users]
## Current State
[Modo B: what already exists. Modo A: "Greenfield project."]
## Phased Roadmap
### Phase 1: <name> — MVP
- **Scope:** [what it includes]
- **Depends on:** —
- **RICE Score:** [calculated score]
- **MoSCoW:** Must Have
- **Done Criteria:** [specific, measurable criteria]
- **Spec:** (generated when phase starts)
- **Plan:** (generated when phase starts)
- **Status:** ⬚ Pending
### Phase 2: <name>
- **Scope:** [what it includes]
- **Depends on:** Phase 1
- **RICE Score:** [calculated score]
- **MoSCoW:** [Must/Should/Could]
- **Done Criteria:** [specific, measurable criteria]
- **Status:** ⬚ Pending
### Phase N: <name>
...
## Out of Scope
[Won't Have items — explicitly listed]
## Risks & Mitigations
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|
| ... | ... | ... | ... |
## Success Metrics
| Metric | Target | Measurement |
|--------|--------|-------------|
| ... | ... | ... |
For simple features or small products (2-4 weeks scope):
# One-Page PRD: <Feature Name>
**Problem:** [2-3 sentences — what pain exists today]
**Solution:** [2-3 sentences — what we're building]
**Target User:** [who benefits]
**Success Metrics:** [2-3 measurable outcomes]
## Scope
- **In:** [bullet list of what's included]
- **Out:** [bullet list of what's explicitly excluded]
## Requirements
1. [Requirement with acceptance criteria]
2. [Requirement with acceptance criteria]
3. ...
## Risks
- [Risk → mitigation]
## Timeline
- **Target:** [date or sprint]
- **Dependencies:** [what must exist first]
For exploration / pre-PRD validation (~1 week scope):
# Feature Brief: <Topic>
## Hypothesis
We believe that [building this feature]
for [these users]
will [achieve this outcome].
We'll know we're right when [measurable metric].
## Problem Evidence
- [Data point or user quote supporting the problem]
- [Data point or user quote]
## Proposed Exploration
- [ ] [Investigation or prototype task]
- [ ] [Investigation or prototype task]
## Decision Criteria
After exploration, proceed to full PRD if:
- [Condition 1]
- [Condition 2]
For sprint-based delivery teams:
# Epic: <Name>
**Goal:** [what this epic achieves]
**Owner:** [who drives it]
**Target Sprint(s):** [sprint range]
## User Stories
- As a [user], I want [capability] so that [benefit]
- As a [user], I want [capability] so that [benefit]
## Acceptance Criteria
- [ ] [Testable criterion]
- [ ] [Testable criterion]
## Dependencies
- [Upstream dependency]
## Definition of Done
- [ ] All stories completed
- [ ] Tests passing
- [ ] Documentation updated
Use these frameworks during Steps 4-5 (Interview and Synthesis) to enrich the PRD.
Use when validating whether a phase or feature is worth building:
We believe that [building this feature]
for [these users]
will [achieve this outcome].
We'll know we're right when [measurable metric].
Use when mapping multiple solutions to a desired outcome:
Outcome (North Star goal)
├── Opportunity 1 (user problem)
│ ├── Solution A
│ └── Solution B
└── Opportunity 2 (user problem)
├── Solution C
└── Solution D
Each phase in the PRD roadmap should trace back to an opportunity.
Use when defining Success Metrics in the PRD:
Use when defining Done Criteria and Success Metrics per phase:
| Metric | Definition | How to Measure |
|---|---|---|
| Adoption | % of users using the feature | Usage analytics |
| Frequency | Usage per user per time period | Event tracking |
| Depth | % of feature capability used | Feature coverage |
| Retention | Continued usage over time | Cohort analysis |
| Satisfaction | User perception of value | NPS/CSAT/feedback |
Use alongside RICE when a quick visual prioritization is needed:
Low Effort High Effort
High QUICK WINS BIG BETS
Value [Prioritize] [Strategic]
Low FILL-INS TIME SINKS
Value [Maybe] [Avoid]
For each phase, invoke devflow:feature-breakdown to validate:
Do NOT generate detailed specs or plans for future phases. Only the phase scope, dependencies, and done criteria.
Present the PRD section by section to the user:
Revise sections based on feedback before moving on.
Save the approved PRD to .context/plans/<project>-prd.md.
If .context/plans/ doesn't exist, create it.
Apos salvar o PRD, oferecer adocao de ADRs organizacionais.
"Sua equipe ja possui um repositorio padrao de ADRs (Architecture Decision Records)?"
(A) Sim, tenho um repositorio
→ Solicitar URL do repositorio git (ex: github.com/org/context-adrs-nexuz)
→ Clonar/copiar templates do repositorio para .context/templates/adrs/
→ Usar como fonte de templates
(B) Nao, quero usar os templates padrao do DevFlow
→ Verificar se .context/templates/adrs/ existe
→ Se nao existe, copiar de templates/ do DevFlow (kit inicial)
→ Usar templates locais
(C) Nao, quero criar um repositorio de ADRs para meu time (em breve)
→ Gerar scaffold usando templates/adr-repo-scaffold/ como base
→ Perguntar nome do time para o repo: context-adrs-<team>
→ Perguntar se quer publicar no GitHub (gh repo create)
→ Apos criar, usar o scaffold como fonte
(D) Nao quero usar ADRs neste projeto → Pular para Step 10 (Handoff)
Apos definir a fonte de templates:
.context/templates/adrs/stack do frontmatter corresponde a alguma resposta da stackstack: universal sao sempre recomendadosCom base no seu PRD (Python + AWS + Terraform), recomendo estas ADRs:
✅ SOLID para Python — principios de codigo
✅ Clean Code para Python — legibilidade
✅ TDD para Python — qualidade obrigatoria
✅ OWASP Top 10 — seguranca baseline
✅ Secrets Management — gestao de segredos
✅ IaC com Terraform — infraestrutura
✅ AWS Data Lake — padroes Lakehouse
⬜ Hexagonal Architecture — nao detectado no PRD
Para cada template aceito:
.context/docs/adrs/ com numeracao sequencial (001, 002, ...).context/docs/adrs/README.md com indice:
# ADRs do Projeto
Decisoes arquiteturais ativas neste projeto.
A IA consulta este indice durante o context gathering do PREVC Planning.
## ADRs Ativas
| # | Titulo | Escopo | Status | Guardrails | Stack |
|---|--------|--------|--------|------------|-------|
| 001 | SOLID para Python | Organizacional | Aprovado | 8 regras | Python |
| ... | ... | ... | ... | ... | ... |
## Como a IA usa estas ADRs
1. No inicio do Planning phase, a IA le este README
2. Identifica ADRs relevantes pela stack e categoria
3. Le os guardrails das ADRs aplicaveis
4. Aplica como restricoes durante brainstorming, design e implementacao
5. No Validation phase, verifica compliance com os guardrails
## ADRs Associados
- [001 - SOLID para Python](.context/docs/adrs/001-solid-python.md)
- [002 - TDD para Python](.context/docs/adrs/002-tdd-python.md)
Announce readiness:
"PRD saved to
.context/plans/<project>-prd.md. Phase 1 (<name>) is ready for PREVC. Start planning Phase 1 now?"
If user says yes → invoke devflow:prevc-flow with Phase 1 scope as the task description.
context({ action: "scaffoldPlan", planName: "<project>-prd", title: "PRD: <project>", summary: "<PRD content>", semantic: true, autoFill: true })
Write directly to .context/plans/<project>-prd.md.
Write to .context/plans/<project>-prd.md (create directory if needed).
| Pattern | Problem |
|---|---|
| "Detail all phases now" | Only the current phase gets a detailed spec; future phases stay at macro scope |
| "The PRD is the spec" | PRD is the roadmap; spec is the technical detail of one phase |
| "Skip the interview in Modo B" | Code analysis doesn't capture intent or priority |
| "Phases without done criteria" | Every phase needs a clear, measurable definition of done |
| "One giant phase" | If a phase touches 5+ components, decompose further |
| "Reorder phases ignoring dependencies" | RICE scores guide priority, but dependencies constrain order |