Borrowing it
Nothing to install: this file belongs to Kandil7/prprompts-flutter-generator. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/Kandil7/prprompts-flutter-generator/master/.claude/commands/planning/stakeholder-review.mdgit clone --depth 1 https://github.com/Kandil7/prprompts-flutter-generatorWrote 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/kandil7/prprompts-flutter-generator/stakeholder-review)<a href="https://agentmods.dev/commands/kandil7/prprompts-flutter-generator/stakeholder-review"><img src="https://agentmods.dev/badge/commands/kandil7/prprompts-flutter-generator/stakeholder-review/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/kandil7/prprompts-flutter-generator/stakeholder-review"><img src="https://agentmods.dev/badge/commands/kandil7/prprompts-flutter-generator/stakeholder-review.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.00017 | $0.02855 |
| Opus 5 | $0.00009 | $0.01427 |
| Sonnet 5 | $0.00003 | $0.00571 |
| Haiku 4.5 | $0.00002 | $0.00285 |
Grade A, and why
Generate Stakeholder Review Checklist 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 10d 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 — 437 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Stakeholder Review Checklist Generator
Overview
Generate customized review checklists for business, technical, and compliance stakeholders to systematically review and approve the PRD.
Instructions
Step 1: Read PRD
# Expected location
docs/PRD.md
Extract key metadata from YAML frontmatter:
project_type(healthcare, fintech, education, etc.)compliancearray (HIPAA, PCI-DSS, GDPR, etc.)platforms(iOS, Android, Web)team_compositionbusiness_context.timelinefeaturesarray
Step 2: Identify Stakeholder Types
Based on project metadata, determine which stakeholders need to review:
Always Required:
- Executive/Business Stakeholder
- Technical Lead
- Product Manager
Conditionally Required:
- Compliance Officer (if compliance requirements present)
- Security Lead (if sensitive_data present)
- Legal (if compliance includes GDPR, HIPAA, PCI-DSS)
- Finance (for budget approval)
- Design Lead (if design team specified)
Step 3: Generate Stakeholder-Specific Checklists
Create docs/STAKEHOLDER_REVIEW.md with role-specific sections:
# Stakeholder Review Checklist: [Project Name]
**PRD Source:** docs/PRD.md
**Generated:** [Date]
**Status:** ⏳ Pending Review
---
## Review Sign-off Tracker
| Stakeholder | Role | Status | Date | Comments |
|-------------|------|--------|------|----------|
| [Name] | Executive Sponsor | ⏳ Pending | - | - |
| [Name] | Product Manager | ⏳ Pending | - | - |
| [Name] | Technical Lead | ⏳ Pending | - | - |
| [Name] | Compliance Officer | ⏳ Pending | - | - |
| [Name] | Security Lead | ⏳ Pending | - | - |
| [Name] | Legal | ⏳ Pending | - | - |
**Approval Threshold:** All stakeholders must approve before development begins.
---
## 📊 Executive/Business Review
**Reviewer:** [Name/Title]
**Focus:** Business value, ROI, strategic alignment
### Business Case
- [ ] Problem statement is clear and compelling
- [ ] Target market/users are well-defined (XX,XXX users)
- [ ] Success metrics are measurable (revenue, engagement, retention)
- [ ] Competitive advantage is articulated
- [ ] Timeline ([Timeline]) is realistic for business goals
### Financial Review
- [ ] Budget estimate provided (run `claude estimate-cost`)
- [ ] ROI projection included
- [ ] Revenue model is clear (if applicable)
- [ ] Ongoing costs estimated (hosting, support)
- [ ] Funding source identified
### Strategic Alignment
- [ ] Aligns with company OKRs/goals
- [ ] Fits product roadmap
- [ ] Market timing is appropriate
- [ ] Resource allocation justified
**Questions to Resolve:**
1. What is the expected ROI in year 1?
2. How does this compare to alternative investments?
3. What are the risks if we delay 6 months?
**Approval:** [ ] Approved [ ] Needs Changes [ ] Rejected
**Comments:**
_______________________________________________
---
## 💻 Technical Review
**Reviewer:** [Name/Title]
**Focus:** Feasibility, architecture, technical risks
### Architecture Review
- [ ] Technology stack is appropriate ([Platforms])
- [ ] Architecture style ([Style]) fits requirements
- [ ] Scalability to [Target Users] users is feasible
- [ ] Offline support ([Yes/No]) is correctly scoped
- [ ] Real-time requirements ([Yes/No]) are achievable
### Technical Feasibility
- [ ] All features are technically possible
- [ ] Critical complexity features have spike plans
- [ ] Third-party integrations are viable ([List])
- [ ] Platform compatibility verified
- [ ] Performance targets ([API Response Time]) are realistic
### Team & Timeline
- [ ] Team composition matches complexity
- [ ] Timeline ([Timeline]) allows for quality development
- [ ] Junior developer count ([Count]) is manageable
- [ ] CI/CD pipeline requirements defined
- [ ] Testing strategy is comprehensive
### Technical Risks
- [ ] All high-risk technical areas identified
- [ ] Mitigation strategies defined
- [ ] Backup plans for critical dependencies
- [ ] Technical debt considerations addressed
**Questions to Resolve:**
1. Do we have expertise in [Critical Technology]?
2. What happens if [Third-Party Service] is unavailable?
3. How will we handle [Performance] at 10x scale?
**Approval:** [ ] Approved [ ] Needs Changes [ ] Rejected
**Comments:**
_______________________________________________
---
## 🎨 Product Manager Review
**Reviewer:** [Name/Title]
**Focus:** User experience, feature completeness, priorities
### Feature Completeness
- [ ] All user personas are documented
- [ ] User journeys are mapped for core flows
- [ ] Features cover MVP requirements
- [ ] Priority levels (P0/P1/P2) are correct
- [ ] Feature dependencies identified (run `claude analyze-dependencies`)
### User Experience
- [ ] User stories are complete and testable
- [ ] Acceptance criteria are clear
- [ ] Edge cases considered
- [ ] Error handling defined
- [ ] Accessibility requirements included
### Prioritization
- [ ] P0 features are truly essential for launch
- [ ] P1 features can be deferred if needed
- [ ] Feature scope is realistic for timeline
- [ ] MVP is clearly defined
**Questions to Resolve:**
1. Can we launch without [Feature]?
2. What user segments are we NOT serving?
3. How will we gather user feedback post-launch?
**Approval:** [ ] Approved [ ] Needs Changes [ ] Rejected
**Comments:**
_______________________________________________
---
## 🔒 Compliance Officer Review
**Reviewer:** [Name/Title]
**Focus:** [Compliance Requirements] compliance
### [Compliance Standard 1] Compliance (if HIPAA/PCI-DSS/etc.)
**HIPAA Requirements:** (if applicable)
- [ ] PHI is clearly identified
- [ ] Encryption at rest (AES-256-GCM) specified
- [ ] Encryption in transit (TLS 1.3) required
- [ ] Audit logging for PHI access defined
- [ ] Access controls implemented (RBAC)
- [ ] BAA requirements with vendors documented
- [ ] Data retention (6 years) specified
- [ ] Breach notification process defined
**PCI-DSS Requirements:** (if applicable)
- [ ] Payment data handling uses tokenization
- [ ] NO credit card storage in app/database
- [ ] Stripe/payment provider is PCI-compliant
- [ ] SAQ-A level compliance achieved
- [ ] Annual security audit planned
- [ ] Penetration testing scheduled
**GDPR Requirements:** (if applicable)
- [ ] User consent flows defined
- [ ] Right to erasure implemented
- [ ] Data portability supported
- [ ] Privacy policy drafted
- [ ] DPA with vendors in place
- [ ] EU data residency addressed
**COPPA Requirements:** (if applicable)
- [ ] Age gate at registration
- [ ] Parental consent flow for <13
- [ ] No behavioral advertising for children
- [ ] Data deletion within 30 days
### Compliance Gaps
- [ ] All compliance requirements from PRD are addressed
- [ ] Vendor compliance verified
- [ ] Audit schedule defined
- [ ] Compliance training for team planned
**Questions to Resolve:**
1. Do all third-party vendors have required certifications?
2. Who is the compliance officer during development?
3. When is the first compliance audit?
**Approval:** [ ] Approved [ ] Needs Changes [ ] Rejected
**Comments:**
_______________________________________________
---
## 🛡️ Security Lead Review
**Reviewer:** [Name/Title]
**Focus:** Security architecture, threat modeling
### Authentication & Authorization
- [ ] Auth method ([Method]) is secure
- [ ] MFA/2FA required for sensitive operations
- [ ] Session management defined
- [ ] Password policy meets standards
- [ ] JWT verification (NOT signing) in Flutter
- [ ] Token refresh flow secure
### Data Protection
- [ ] Sensitive data ([Types]) identified
- [ ] Encryption keys managed securely
- [ ] Secure storage for credentials (Keychain/Keystore)
- [ ] API keys NOT in source code
- [ ] PII handling complies with [Compliance]
### Threat Mitigation
- [ ] SQL injection prevention
- [ ] XSS protection
- [ ] CSRF tokens where needed
- [ ] Rate limiting on API
- [ ] Input validation everywhere
### Security Testing
- [ ] Penetration testing planned
- [ ] Security code review process
- [ ] Vulnerability scanning in CI/CD
- [ ] Incident response plan exists
**Questions to Resolve:**
1. Who conducts penetration testing?
2. What is our bug bounty policy?
3. How do we handle zero-day vulnerabilities?
**Approval:** [ ] Approved [ ] Needs Changes [ ] Rejected
**Comments:**
_______________________________________________
---
## ⚖️ Legal Review
**Reviewer:** [Name/Title]
**Focus:** Legal compliance, contracts, IP
### Legal Documents
- [ ] Terms of Service drafted
- [ ] Privacy Policy covers all data collection
- [ ] Cookie Policy (if Web platform)
- [ ] EULA (if applicable)
- [ ] BAA drafted (if HIPAA)
- [ ] DPA drafted (if GDPR)
### Intellectual Property
- [ ] All code will be company-owned
- [ ] Third-party licenses reviewed
- [ ] Open source compliance checked
- [ ] Trademark search completed
### Contracts & Vendors
- [ ] Vendor contracts reviewed
- [ ] SLAs defined
- [ ] Liability clauses acceptable
- [ ] Termination clauses clear
**Questions to Resolve:**
1. Are we using any GPL-licensed code?
2. Do vendors meet our liability requirements?
3. Is our data handling GDPR-compliant?
**Approval:** [ ] Approved [ ] Needs Changes [ ] Rejected
**Comments:**
_______________________________________________
---
## 💰 Finance Review (Optional)
**Reviewer:** [Name/Title]
**Focus:** Budget, cost management
### Budget Approval
- [ ] Cost estimate reviewed (run `claude estimate-cost`)
- [ ] Total cost: $XXX,XXX is within budget
- [ ] Funding source approved
- [ ] Contingency (20%) included
- [ ] Payment schedule defined
### Cost Management
- [ ] Monthly burn rate acceptable
- [ ] Infrastructure costs sustainable
- [ ] Third-party service costs reviewed
- [ ] Post-launch maintenance budgeted
**Approval:** [ ] Approved [ ] Needs Changes [ ] Rejected
**Comments:**
_______________________________________________
---
## Final Approval
**All stakeholders must sign off before proceeding to PRPROMPTS generation.**
### Pre-Development Checklist
- [ ] All stakeholder reviews complete
- [ ] All "Needs Changes" addressed
- [ ] PRD quality score ≥ B (run `claude analyze-prd`)
- [ ] Cost estimate approved
- [ ] Feature dependencies mapped (run `claude analyze-dependencies`)
- [ ] Team allocated
- [ ] Kickoff meeting scheduled
### Next Steps After Approval
1. **Generate PRPROMPTS:**
```bash
claude gen-prprompts
-
Set up project infrastructure:
claude bootstrap-from-prprompts -
Begin Sprint 1:
- Focus on critical path features
- See dependency analysis for order
Approval Date: _______________ Approved By: _______________ Next Review Date: _______________ (quarterly)
Generated by Stakeholder Review Generator v1.0.0
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.
- 10d ago First seen · 437 lines · 17 tokens per session scan A ac3c781899b1
Generate Stakeholder Review Checklist is a command published in the GitHub repository Kandil7/prprompts-flutter-generator (11 stars, last pushed 9mo ago), licensed MIT. It adds 17 tokens to every session and 2,855 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-30.
Other commands, from other repositories
speckit.gh-triage.triage
Fetch open GitHub issues, classify each as bug, feature, or chore, then DELEGATE to the correct extension: bugs → bug.fetch (saved under .specify/bugs/), chores → chore.fetch (saved under .specify/chores/), features → speckit.specify (saved under specs/). Never save bugs or chores as specs.
speckit.chore.fetch
Load an existing GitHub issue into the chore workflow and seed a triage draft.
speckit.chore.implement
Implement the scoped chore (the actual maintenance work) and record what changed.
speckit.bug.issue
File a GitHub issue from a bug assessment (the 'report' phase) and record the issue link.
speckit.chore.issue
File a GitHub issue from a chore assessment (the 'report' phase) and record the issue link.
speckit.gh-triage.feature
Create a GitHub issue describing a new feature, label it with the configured feature label, and optionally auto-run speckit.specify to turn it into a spec.