feat(product-requirements): introduce PRD and FRD authoring skills

.claude-plugin/marketplace.json

@@ -54,6 +54,12 @@
       "description": "Event-driven architecture skills for designing event names, schemas, contracts, and catalogs following good practices for domain and integration events",
       "source": "./plugins/trogonstack-eda",
       "category": "development"
+    },
+    {
+      "name": "trogonstack-product-requirements",
+      "description": "Skills for writing and reviewing Product Requirements Documents (PRDs) and Feature Requirements Documents (FRDs)",
+      "source": "./plugins/trogonstack-product-requirements",
+      "category": "development"
     }
   ]
 }

.github/release-please-config.json

@@ -47,6 +47,9 @@
     },
     "plugins/trogonstack-eda": {
       "component": "trogonstack-eda"
+    },
+    "plugins/trogonstack-product-requirements": {
+      "component": "trogonstack-product-requirements"
     }
   },
   "plugins": [

.github/release-please-manifest.json

@@ -6,5 +6,6 @@
   "plugins/trogonstack-ask": "0.1.2",
   "plugins/trogonstack-otel": "0.1.1",
   "plugins/trogonstack-eventmodeling": "0.1.1",
-  "plugins/trogonstack-eda": "0.1.1"
+  "plugins/trogonstack-eda": "0.1.1",
+  "plugins/trogonstack-product-requirements": "0.0.1"
 }

plugins/trogonstack-product-requirements/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "trogonstack-product-requirements",
+  "description": "Skills for writing and reviewing Product Requirements Documents (PRDs) and Feature Requirements Documents (FRDs)",
+  "version": "0.0.1",
+  "author": {
+    "name": "TrogonStack",
+    "url": "https://github.com/TrogonStack"
+  }
+}

plugins/trogonstack-product-requirements/README.md

@@ -0,0 +1,76 @@
+# Product Requirements
+
+Skills for writing and reviewing product-level and feature-level requirements. All artifacts live under `.trogonai/project/{projectid}/`.
+
+## Requirements Operating Model
+
+These skills operate on the Requirements side of the product development flow:
+
+- **Requirements** own product-level context, feature requirements, and the feature hierarchy.
+- **Blueprints** own high-level architecture, runtime design, and code links.
+- **Work Orders** own implementable delivery slices and planning phases.
+
+Shared behavior for module boundaries, source-of-truth checks, clarification, feature hierarchy, and downstream impact lives in the `requirements-operating-model` skill. When the TrogonStack `ask-question` skill is available, use it for clarification sessions; these skills keep the Product Requirements-specific judgment about what needs to be clarified.
+
+| Skill | Purpose |
+|-------|---------|
+| `requirements-operating-model` | Shared Requirements-module boundaries, clarification pattern, source-of-truth rules, feature hierarchy, and downstream-impact guidance |
+
+## Product Overview Documents
+
+Product Overview Documents capture the high-level **why** and **what** for the entire product.
+
+- The **why** is the business motivation: the problems being solved, the KPIs not being met, the North Star goals the business is pursuing.
+- The **what** is the product description: what the product is and how its parts fit together.
+
+These documents give anyone (executive, product manager, or engineer) the context they need before looking at specific features.
+
+The six default files live under `.trogonai/project/{projectid}/prd/`:
+
+| Concern | Skill | File |
+|---------|-------|------|
+| Why: problems being solved | `prd-business-problem` | `business-problem.prd.md` |
+| Why: status quo being improved | `prd-current-state` | `current-state.prd.md` |
+| Why: who it serves and what success means for them | `prd-personas` | `personas.prd.md` |
+| What: the product and how its parts fit together | `prd-product-description` | `product-description.prd.md` |
+| Why: the KPIs / North Star being pursued | `prd-success-metrics` | `success-metrics.prd.md` |
+| What: the technical constraints the product must meet | `prd-technical-requirements` | `technical-requirements.prd.md` |
+| Custom: product-level context beyond the defaults | `prd-custom-overview` | `{slug}.prd.md` |
+| Audit of all of the above | `prd-review` | `review.prd.md` |
+
+Each section skill has a focused document owner, but the set is not isolated. Later documents should read the earlier context they depend on, and reviews should flag source-of-truth conflicts across the set.
+
+Additional Product Overview Documents are created with `prd-custom-overview` when the six defaults do not cover a product-specific context area. Custom documents still explain product-level **why** or **what** in plain language; they must name their relationship to the defaults or other custom overviews so they do not become miscellaneous buckets. Feature behavior belongs in FRDs.
+
+## Feature Requirements Documents
+
+Feature Requirements Documents (FRDs) capture the localized **why** and **what** for a single feature: what engineers actually pick up to build.
+
+- The **why** is the user story: *"As a \<role\>, I want to \<action\>, so that I can \<outcome\>."*
+- The **what** is the acceptance criteria: *"When \<condition\>, the system shall/should/may \<behavior\>."*
+
+Each FRD follows the same three-section template (**Overview**, **Terminology**, **Requirements**) with stable IDs so they can be referenced unambiguously from code, commits, tickets, tests, and reviews. Cross-requirement behavior should usually be captured as acceptance criteria; `Child FRDs` is the standard built-in extension for parent documents with nested children.
+
+- **`REQ-`** = **Requirement**: one cohesive, independently testable capability. Format: `REQ-[PREFIX]-NNN`.
+- **`AC-`** = **Acceptance Criterion**: one observable behavior the system must exhibit. Format: `AC-[PREFIX]-NNN.N`, where `NNN` matches the parent requirement.
+
+Large features nest as parent + children, where the parent delivers value on its own and the child is meaningless without the parent.
+
+Files live under `.trogonai/project/{projectid}/frd/`:
+
+- Top-level: `{slug}.frd.md`
+- Parent with children: `{parent-slug}/index.frd.md` + `{parent-slug}/{child-slug}.frd.md`
+
+| Skill | Purpose |
+|-------|---------|
+| `frd-getting-started` | Produce the initial set of FRDs for a new project, calibrated agile vs waterfall |
+| `frd-write` | Author or refine a single FRD |
+| `frd-split` | Split, merge, or nest FRDs using the parent-delivers-value rule |
+| `frd-review` | Audit a single FRD or a tree of FRDs |
+
+## Installation
+
+```bash
+claude plugin marketplace add TrogonStack/agentskills
+claude plugin install trogonstack-product-requirements@TrogonStack
+```

plugins/trogonstack-product-requirements/skills/frd-getting-started/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: frd-getting-started
+description: Produce the initial set of Feature Requirements Documents (FRDs) for a new project. Calibrates between an agile first pass (small set of must-have features only) and a waterfall first pass (comprehensive coverage). Asks how many features to draft, identifies them from the project's product overview, and scaffolds each via the FRD template. Use when the user is starting a project and there are no FRDs yet.
+allowed-tools:
+  - AskUserQuestion
+  - Read
+  - Write
+  - Glob
+  - Grep
+---
+
+# FRD Getting Started: Initial Feature Set
+
+## Purpose
+
+Projects are not seeded with any default FRDs. This skill walks the user through producing the **initial set** of FRDs once, calibrated to how the user wants to work.
+
+## Shared Operating Model
+
+Use `requirements-operating-model` before translating Product Overview Documents into FRDs. Use its clarification pattern for ambiguous feature boundaries, and follow its source-of-truth and downstream-impact rules.
+
+## When to Use
+
+- A project has been created and `.trogonai/project/{projectid}/frd/` is empty
+- The user wants to plan a chunk of features in one pass rather than drafting them ad-hoc
+- The user has just produced the Product Overview Documents (`prd-*` files) and wants to translate them into the first FRDs
+
+## Resolve Project
+
+1. Determine `projectid` (ask if not supplied; offer choices via `Glob`).
+2. `Glob` `.trogonai/project/{projectid}/frd/**/*.frd.md`: if any FRDs already exist, stop and direct the user to `frd-write`. This skill is for getting started only, not for extending an established set.
+3. Read whichever of these files exist for context, in priority order:
+   - `personas.prd.md` (roles for user stories)
+   - `product-description.prd.md` (the surfaces and components to translate into features)
+   - `business-problem.prd.md`, `success-metrics.prd.md` (to prioritize)
+   - `current-state.prd.md`, `technical-requirements.prd.md` (to catch status-quo scope and constraints)
+
+If the Product Overview is missing, surface that as a finding and ask whether to proceed or run the relevant `prd-*` skills first.
+
+## Calibrate the Pass
+
+Ask the user how they want to work this first time. Offer two anchors and let them pick or land somewhere in between:
+
+- **Agile first pass**: draft only the **2–4 must-have features** that prove the product can deliver its primary outcome metric. Other features are deferred to later passes.
+- **Waterfall first pass**: draft **every feature visible in the Product Description** before any one is built, so engineering can plan and estimate the whole scope.
+
+Then ask:
+
+- Approximate number of FRDs for this pass (the calibration sets a default; the user can override).
+- Whether sub-features should be drafted now, or deferred until the parent is built (`frd-split` can do this later).
+
+## Identify the Feature Set
+
+Use the Product Description's components and surfaces as the candidate list. For each candidate, ask:
+
+- Does this pass the **feature unit** definition: one cohesive, independently-buildable capability with a clear user-facing value?
+- Is it top-level, or a child of another candidate? Apply the parent-delivers-value rule: parents must work without the child; children must be meaningless without the parent.
+
+Group candidates into:
+
+- **This pass** (in-scope for getting started)
+- **Later passes** (deferred)
+- **Not a feature** (cross-cutting concerns, non-functional requirements: these belong in `technical-requirements.prd.md`)
+
+Read the grouping back to the user and get explicit confirmation before scaffolding.
+
+## Scaffold the FRDs
+
+For each feature in **this pass**, scaffold a file at:
+
+- Top-level → `.trogonai/project/{projectid}/frd/{slug}.frd.md`
+- Child → if the initial pass includes children, write the parent directly as `{parent}/index.frd.md` and write children as `{parent}/{slug}.frd.md`
+
+Each scaffold is a **stub**, not a finished FRD. It contains:
+
+- Title, project, prefix, parent reference, status `Stub`, last-updated.
+- A placeholder Overview noting what the feature is meant to cover (one sentence, taken from the Product Description).
+- An empty Terminology section.
+- A placeholder requirement `REQ-{PREFIX}-001: <to be authored>` with no acceptance criteria, marked `Status: pending`.
+
+After scaffolding, list the files and recommend the user run `frd-write` per feature to fill in the actual requirements. Do **not** try to fully author every FRD here; that loses the per-feature discovery quality.
+
+### Prefix assignment
+
+For each top-level scaffold, ask the user to confirm a 2–4 letter prefix derived from the feature name. `Grep` existing files in the project to ensure uniqueness. For children, the prefix is `{parent-prefix}-{sub}` per the standard rule.
+
+## Stub Template
+
+```markdown
+# <Feature Name>
+
+- **Project:** {projectid}
+- **Prefix:** {PREFIX}
+- **Parent FRD:** <relative path or "none (top-level)">
+- **Status:** Stub
+- **Last updated:** <YYYY-MM-DD>
+
+## Overview
+
+<One-sentence placeholder taken from the Product Description. Author with `frd-write` to expand into the full 1–2 paragraph overview.>
+
+## Terminology
+
+<To be authored.>
+
+## Requirements
+
+### REQ-{PREFIX}-001: <to be authored>
+
+**Status:** pending
+
+**User Story:** <author with `frd-write`>
+
+**Acceptance Criteria:**
+- <author with `frd-write`>
+
+```
+
+The canonical shape comes from the project's Feature Requirements Template when available. Otherwise, use the bundled default at `../frd-write/assets/frd-template.md`. The stub above is the abbreviated form for scaffolding; `frd-write` expands it into the full template.
+
+## Output Summary
+
+After scaffolding, write `.trogonai/project/{projectid}/frd/_getting-started.md` summarizing the pass:
+
+```markdown
+# Getting Started: Initial FRD Set
+
+- **Project:** {projectid}
+- **Date:** <YYYY-MM-DD>
+- **Pass style:** <Agile / Waterfall / Custom>
+- **Features in this pass:** <N>
+- **Features deferred:** <N>
+
+## This Pass
+- [{slug}](./{slug}.frd.md): <one-line>
+- [{parent-slug}/{child-slug}](./{parent-slug}/{child-slug}.frd.md): <one-line; nested under parent-slug>
+
+## Deferred to Later Passes
+- <feature>: <one-line; why deferred>
+
+## Not a Feature (re-homed elsewhere)
+- <item>: belongs in <prd file or other location>
+
+## Next Steps
+1. Run `frd-write` per stub to author the full FRD.
+2. Run `frd-review` once a meaningful chunk is authored.
+3. Run `frd-split` if a feature grows beyond ~5 requirements.
+```
+
+## Quality Bar
+
+The pass is complete when:
+
+- Every feature in this pass has a stub file with prefix, parent reference, and a placeholder REQ-001.
+- Parents and children follow the parent-delivers-value rule.
+- A summary file enumerates the pass, deferrals, and non-features.
+- The user has explicit next steps (which `frd-write` calls come next).
+
+## Anti-Patterns to Reject
+
+- Trying to fully author every FRD in one pass; that bypasses per-feature discovery.
+- Scaffolding "every component" without applying the feature-unit definition.
+- Scaffolding sub-features whose parents have not been scaffolded.
+- Re-running this skill against a project that already has FRDs; use `frd-write` instead.
+
+## Related Skills
+
+- `frd-write`: author the full content of each scaffolded FRD
+- `frd-split`: decompose a feature that turns out to be an umbrella
+- `frd-review`: audit once a pass of authoring is done
+- `prd-product-description`: re-check if the candidate feature list reveals product-shape gaps
+
+## Allowed Tools
+
+- **AskUserQuestion**: drive calibration and feature grouping
+- **Read**: load Product Overview files for context
+- **Write**: scaffold stub FRDs and the getting-started summary
+- **Glob**: verify the project is empty of FRDs and list candidates