SKILL

PRD Authoring

Use this skill to create structured Product Requirements Documents that include threat modeling, architecture decisions, and security considerations as first-class sections.

When to Use

• Defining a new feature or service before implementation
• Creating a formal specification for board/stakeholder review
• Documenting architecture decisions alongside requirements
• Any initiative that touches user data, external APIs, or security boundaries

Prerequisites

• Clear understanding of the feature/initiative scope
• Access to existing architecture docs and ADRs
• Knowledge of the target deployment environment
• Stakeholder input on business requirements

PRD Template

Use this structure for all PRDs. Store as a markdown file in /workspace/.ai/projects/cascadeguard/prds/<name>.md, commit via PR, and link from the Paperclip issue comment.

# PRD: {Feature/Initiative Title}
 
**Author:** {agent or person}
**Status:** Draft | In Review | Approved | Superseded
**Date:** {YYYY-MM-DD}
**Related:** {links to Paperclip issues, ADRs, prior PRDs}
 
## 1. Problem Statement
 
{What problem does this solve? Who is affected? What is the current state?
Keep to 2-3 paragraphs maximum.}
 
## 2. Goals and Non-Goals
 
### Goals
- {Specific, measurable outcomes this initiative delivers}
 
### Non-Goals
- {Explicitly out of scope — prevents scope creep}
 
## 3. User Stories
 
| # | As a... | I want to... | So that... | Priority |
|---|---------|-------------|-----------|----------|
| 1 | {role} | {action} | {benefit} | P0/P1/P2 |
 
## 4. Architecture
 
### System Context
 
{How this feature fits into the overall system. Include a diagram if helpful
(Mermaid preferred for version control).}
 
### Component Design
 
{Key components, their responsibilities, and interactions.
Include API contracts, data models, or sequence diagrams as needed.}
 
### Technology Choices
 
| Decision | Choice | Rationale |
|----------|--------|-----------|
| {e.g. Database} | {e.g. PostgreSQL} | {Why this over alternatives} |
 
### ADR References
 
{Link to any Architecture Decision Records created for this initiative.}
 
## 5. Threat Model
 
### Assets
 
{What data or capabilities are we protecting?}
 
| Asset | Classification | Storage |
|-------|---------------|---------|
| {e.g. User credentials} | {Confidential} | {Encrypted at rest in PostgreSQL} |
 
### Threat Actors
 
{Who might attack this? What are their capabilities and motivations?}
 
### Attack Surface
 
{Entry points, trust boundaries, data flows that cross boundaries.}
 
### Threats (STRIDE)
 
| # | Category | Threat | Mitigation | Status |
|---|----------|--------|-----------|--------|
| T1 | Spoofing | {description} | {mitigation} | Mitigated/Accepted/Open |
| T2 | Tampering | {description} | {mitigation} | ... |
| T3 | Repudiation | {description} | {mitigation} | ... |
| T4 | Info Disclosure | {description} | {mitigation} | ... |
| T5 | Denial of Service | {description} | {mitigation} | ... |
| T6 | Elevation of Privilege | {description} | {mitigation} | ... |
 
### Risk Acceptance
 
{Any threats explicitly accepted, with rationale and owner.}
 
## 6. Security Requirements
 
- [ ] Authentication: {method and standard}
- [ ] Authorization: {RBAC/ABAC model}
- [ ] Data encryption: {at rest and in transit}
- [ ] Input validation: {approach}
- [ ] Audit logging: {what events are logged}
- [ ] Rate limiting: {thresholds}
- [ ] Secrets management: {how secrets are stored and rotated}
- [ ] Dependency scanning: {Dependabot, Trivy, etc.}
- [ ] Container security: {base image policy, scanning}
 
## 7. Implementation Plan
 
### Phases
 
| Phase | Scope | Target |
|-------|-------|--------|
| 1 | {MVP scope} | {date or sprint} |
| 2 | {Enhancement scope} | {date or sprint} |
 
### Dependencies
 
{External dependencies, blocking work, or prerequisites.}
 
### Paperclip Task Breakdown
 
{Link to or list the Paperclip subtasks that implement this PRD.}
 
## 8. Success Metrics
 
| Metric | Target | Measurement |
|--------|--------|-------------|
| {e.g. Scan latency} | {< 5s p95} | {Grafana dashboard} |
 
## 9. Open Questions
 
- [ ] {Question needing resolution before implementation}

Authoring Guidelines

Threat Model Depth

Scale the threat model to the risk:

• Low risk (internal tool, no PII): abbreviated STRIDE table, focus on access control and audit logging
• Medium risk (external API, limited PII): full STRIDE table, explicit mitigations, security requirements checklist
• High risk (payment processing, credentials, public-facing auth): full threat model with attack trees, formal risk acceptance sign-off

Architecture Section

• Use Mermaid diagrams for version-controlled visuals
• Reference existing ADRs rather than duplicating decisions
• Include API contracts (OpenAPI references or inline schemas) for any new endpoints
• Call out integration points with existing systems

Security Requirements

• Every PRD must have the security requirements checklist, even if some items are marked N/A with rationale
• Container-based services must reference the base image policy and scanning requirements
• Any new external dependency must be noted in the dependency scanning section

Review Process

1. Draft — author creates PRD with all sections filled
2. CTO Review — technical accuracy, architecture alignment, threat model completeness
3. Board Review — business alignment, priority, resource allocation
4. Approved — implementation can begin, Paperclip tasks created

Storing PRDs

PRDs live on the filesystem, not in Paperclip issue documents or descriptions.

Store in /workspace/.ai/projects/cascadeguard/prds/<name>.md, commit via PR, and link from the Paperclip issue comment. See the IC SDLC workflow for the canonical artifact locations.

Notes

• This pattern was extracted from CAS-25 (try-me flow PRD) and standardized
• The threat model section uses STRIDE as the default framework
• PRDs are living documents — update them as requirements evolve during implementation
• Link PRDs bidirectionally with their implementation tasks in Paperclip