# Prd Technical Requirements

> Draft the Technical Requirements of a PRD by capturing the technical constraints and requirements the product must meet. Drives discovery through performance, scale, reliability, security, privacy, compliance, integrations, platforms, accessibility, and localization. Writes to `.trogonai/project/{projectid}/prd/technical-requirements.prd.md`. Use when the user wants to capture the non-functional…

- **Type:** Skill
- **Install:** `agentstack add skill-trogonstack-agentskills-prd-technical-requirements`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [TrogonStack](https://agentstack.voostack.com/s/trogonstack)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [TrogonStack](https://github.com/TrogonStack)
- **Source:** https://github.com/TrogonStack/agentskills/tree/main/plugins/trogonstack-product-requirements/skills/prd-technical-requirements

## Install

```sh
agentstack add skill-trogonstack-agentskills-prd-technical-requirements
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# PRD: Technical Requirements

## Purpose

Capture the technical constraints and non-functional requirements the product must meet, so engineering can design against concrete targets and the product team can make trade-offs explicit before implementation.

This file is not a technical design or architecture document. It is the contract of constraints the design must satisfy.

## Shared Operating Model

Use `requirements-operating-model` before writing when constraints depend on product shape, metrics, existing context, or Blueprint handoff. Keep architecture decisions in Blueprints.

## When to Use

- A PRD is approaching engineering planning and lacks non-functional targets
- The team is debating "is this fast enough?" / "is this secure enough?" with no shared bar
- Compliance, accessibility, or platform constraints are implicit and need to be made explicit

## Project Identifier

Before writing, determine the `projectid`:

1. If the user has supplied one, use it verbatim.
2. Otherwise, ask for it once. The `projectid` should be a stable, kebab-case identifier for the product/initiative.
3. Confirm the resolved path before writing: `.trogonai/project/{projectid}/prd/technical-requirements.prd.md`.

If the file already exists, read it first and ask whether to **replace** or **refine** before overwriting.

## Read Existing Context

Before discovery, read these files when they exist:

- `.trogonai/project/{projectid}/prd/product-description.prd.md`
- `.trogonai/project/{projectid}/prd/success-metrics.prd.md`
- `.trogonai/project/{projectid}/prd/personas.prd.md`

Use them to ground constraints in user-facing surfaces, measurable goals, and persona contexts. If a technical target becomes an architecture decision, leave the constraint here and identify Blueprints as the owner for the design.

## Discovery

Ask through each category. For every requirement, push for a **number, a threshold, or a named standard**, not adjectives.

1. **Performance**
   - Target latency (p50, p95, p99) for the primary user actions
   - Throughput / requests per second or per minute
   - Cold start, time-to-first-byte, time-to-interactive where relevant
2. **Scale**
   - Expected users / tenants / records / events at launch and at 12 months
   - Peak vs steady-state ratios
   - Growth assumptions and their source
3. **Reliability & availability**
   - SLO (e.g., 99.9% over rolling 30 days)
   - Acceptable error budget burn
   - Recovery objectives: RTO, RPO
   - Graceful degradation expectations
4. **Security**
   - Authentication method(s)
   - Authorization model (roles, scopes, tenancy)
   - Data classification of inputs and outputs
   - Threat model concerns specific to this product
5. **Privacy & compliance**
   - Regulatory regimes that apply (GDPR, HIPAA, SOC 2, PCI, regional data residency)
   - PII / PHI / payment data handling
   - Retention and deletion requirements
   - Audit logging requirements
6. **Integrations**
   - Upstream systems consumed (APIs, events, files)
   - Downstream systems produced for
   - Sync vs async, contract ownership, failure semantics
7. **Platforms & environments**
   - Supported browsers / OS / device classes
   - Minimum hardware / network assumptions
   - Cloud / on-prem / hybrid constraints
   - Offline / intermittent connectivity behavior
8. **Accessibility**
   - WCAG level (typically AA)
   - Keyboard, screen reader, color contrast, motion expectations
9. **Localization & internationalization**
   - Languages at launch and in 12 months
   - Right-to-left support
   - Time zone, currency, date/number formatting
10. **Observability**
    - Logs, metrics, traces required from day one
    - Dashboards and alerts that must exist before GA
11. **Cost constraints**
    - Unit economics targets (cost per user / request / event) if relevant
    - Hard ceilings on infrastructure spend

For each category, the acceptable answer is either:

- A concrete requirement with a target, OR
- An explicit "Not a constraint for this product": which is itself useful information

Push back on:

- "Should be fast" → which action, what percentile, what number, on what hardware/network
- "Secure by default" → which standard, what threat
- "Globally available" → which regions, which latency target per region

## Quality Bar

The file is complete when:

- Every category has either a concrete target or an explicit "not a constraint"
- Performance numbers are tied to specific user actions, not the system as a whole
- Reliability targets are stated as SLOs with measurement windows
- Compliance regimes are named, not implied
- Each requirement is testable: a reviewer could write a verification for it

## Output

Write the complete file to `.trogonai/project/{projectid}/prd/technical-requirements.prd.md` using the template at `assets/technical-requirements-template.md`. Read it, substitute `{projectid}` and the date, and fill in each section from the discovery output. For any category that does not apply, record it under **Explicit non-constraints** rather than dropping the section.

## Writing Guidance

### Writing approach
- **Number, threshold, or named standard per category.** Every line is either a measurable target, a named regulation/standard, or an explicit non-constraint. Adjectives without numbers do not count.
- **Per user action, not per system.** "p95  50% burn.
- RTO 30 min, RPO 5 min for Salesforce Bridge.

## Security
- Authentication: SSO via Okta OIDC; session 12h, refresh 30 days.
- Authorization: role-based: AE (own deals), Manager (team deals), Admin (org).
- Data classification: notes are Restricted (may contain customer PII).

## Privacy & compliance
- Regimes: SOC 2 Type II (annual), GDPR for EU tenants, CCPA for California users.
- Retention: call notes retained 7 years to match Salesforce; deletion request honored within 30 days per GDPR Art. 17.

## Explicit non-constraints
- Localization: English only at launch; not a constraint until EU expansion (Q3 2026).
- Offline behavior: not supported in v1; AE is online by job definition.
```

**Bad**

```md
## Performance
- Should be fast.

## Reliability & availability
- Should be highly available.

## Security
- Should follow best practices.

## Privacy & compliance
- Should be compliant.

## Localization
- Should support multiple languages.
```

The bad version is unfalsifiable: engineering cannot design against any of it, and the team has no shared bar to evaluate the result. Every line is an adjective that means whatever the reader wants.

## Anti-Patterns to Reject

- Adjectives without numbers ("fast", "scalable", "secure").
- One latency number for the whole system rather than per user action.
- SLOs without a measurement window.
- "Follows best practices" instead of naming the standard.
- Silently skipping a category: if it doesn't apply, say so explicitly.

## Allowed Tools

- **AskUserQuestion**: drive discovery and resolve `projectid`
- **Read**: load the existing file if it exists, to decide replace vs refine
- **Write**: write the file

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [TrogonStack](https://github.com/TrogonStack)
- **Source:** [TrogonStack/agentskills](https://github.com/TrogonStack/agentskills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-trogonstack-agentskills-prd-technical-requirements
- Seller: https://agentstack.voostack.com/s/trogonstack
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.