imabusyman/write-a-prd
prompts/squad/skills/write-a-prd/SKILL.md
Generate a Product Requirements Document from a task description, user intent, or PRD outline. Structure the PRD with sections: Overview, Problem Statement, Goals, Scope, Features, Acceptance Criteria, Metrics. Use this when the Planner or Orchestrator needs to formalize requirements before decomposing into implementation steps.
development
Updated Apr 25, 2026
$ install --global
skillsauthnpx skillsauth add imabusyman/CodebrewRouter write-a-prdInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 25, 2026, 7:21 PM126.4s1 file scanned
SKILL.md
- name:
- write-a-prd
- description:
- Generate a Product Requirements Document from a task description, user intent, or PRD outline. Structure the PRD with sections: Overview, Problem Statement, Goals, Scope, Features, Acceptance Criteria, Metrics. Use this when the Planner or Orchestrator needs to formalize requirements before decomposing into implementation steps.
Write a PRD — generate a Product Requirements Document
Formalizes task intent into a structured PRD that serves as input to the Planner or Orchestrator.
When to use
- Planner phase: Before decomposing a task into steps, generate a PRD to align on requirements.
- Orchestrator setup: Before running the autonomous loop, generate/refine a PRD.
- Specification clarity: Task description is vague; PRD forces clarity on scope + acceptance criteria.
Template
A PRD for Blaze.LlmGateway tasks typically has:
# PRD: <Feature Name>
## Overview
<One-paragraph executive summary: what, why, who benefits>
## Problem Statement
<Current state, pain point, why it matters>
## Goals
- <Specific, measurable goal>
- <Specific, measurable goal>
## Scope
### In scope
- <Feature or component>
- <Behavior or interface>
### Out of scope
- <Deliberate exclusion>
## Features
### Feature 1: <Name>
<Description, inputs, outputs, constraints>
### Feature 2: <Name>
<Description, inputs, outputs, constraints>
## Acceptance Criteria
- [ ] Criterion 1 (testable, specific)
- [ ] Criterion 2 (testable, specific)
- [ ] Blaze.LlmGateway-specific: builds with `-warnaserror`, 95% code coverage, ADR-0008 compliant
## Success Metrics
- <Quantifiable outcome: latency, coverage, adoption>
## Dependencies
- <Existing components or external services this relies on>
## Open Questions
- <Ambiguities to resolve before implementation>
Output location
- Primary:
Docs/PRD/<slug>.md(long-lived, blessed version). - Per-run copy (optional):
Docs/squad/runs/<ts>-<slug>/prd.md(working copy for this run).
Examples from Blaze.LlmGateway
See Docs/PRD/blaze-llmgateway-prd.md for a system-level PRD. Task-specific PRDs are smaller and focused on a single feature or component (e.g., "add a circuit breaker to LlmRoutingChatClient").
Quality checks
Before marking the PRD complete:
- Acceptance criteria are testable (not vague).
- Scope is clear (in/out sections are disjoint and complete).
- No missing context (team knows what "done" looks like).
- Blaze.LlmGateway constraints are listed (MEAI usage, quality gate, ADRs).
See also
squad-plancommand — invoked after PRD is approved, decomposes into ordered steps.- Planner agent — reads the PRD and generates spec.md + plan.md.
Related Skills
imabusyman/team-builder
development
VerifiedTrustedCommunity
Compose parallel teams of specialized agents for a multi-faceted task. Map subtasks to agent roles, balance workload, and validate team composition. Use this when breaking a task into parallel streams that require different expertise (Coder, Tester, Infra, etc.).
SKILL.mdUpdated Apr 25, 2026
imabusyman/subagent-driven-development
development
VerifiedTrustedCommunity
Delegate implementation work to specialized subagent instances, each inheriting a task scope and constraints from the parent. Emit structured handoffs, monitor completion signals, aggregate results. Use this in the Orchestrator parallel path when spawning independent Coder/Tester/Infra subagents from a single coordinator.
SKILL.mdUpdated Apr 25, 2026
imabusyman/reasoning
testing
VerifiedTrustedCommunity
Maintain the append-only reasoning log and write handoff envelopes for every squad delegation. Use this when the Conductor delegates to a specialist or when a specialist records a non-trivial decision.
SKILL.mdUpdated Apr 25, 2026
imabusyman/quality-gate
development
VerifiedTrustedCommunity
Enforce the -warnaserror build + 95% coverage test gate on every squad [DONE]. Use this before any specialist (Coder, Tester, Reviewer, Infra) marks a phase complete.
SKILL.mdUpdated Apr 25, 2026