Install
$ agentstack add skill-trogonstack-agentskills-frd-getting-started ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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
- Determine
projectid(ask if not supplied; offer choices viaGlob). Glob.trogonai/project/{projectid}/frd/**/*.frd.md: if any FRDs already exist, stop and direct the user tofrd-write. This skill is for getting started only, not for extending an established set.- 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-splitcan 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.mdand 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:with no acceptance criteria, markedStatus: 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
#
- **Project:** {projectid}
- **Prefix:** {PREFIX}
- **Parent FRD:**
- **Status:** Stub
- **Last updated:**
## Overview
## Terminology
## Requirements
### REQ-{PREFIX}-001:
**Status:** pending
**User Story:**
**Acceptance Criteria:**
-
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:
# Getting Started: Initial FRD Set
- **Project:** {projectid}
- **Date:**
- **Pass style:**
- **Features in this pass:**
- **Features deferred:**
## This Pass
- [{slug}](./{slug}.frd.md):
- [{parent-slug}/{child-slug}](./{parent-slug}/{child-slug}.frd.md):
## Deferred to Later Passes
- :
## Not a Feature (re-homed elsewhere)
- : belongs in
## 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-writecalls 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-writeinstead.
Related Skills
frd-write: author the full content of each scaffolded FRDfrd-split: decompose a feature that turns out to be an umbrellafrd-review: audit once a pass of authoring is doneprd-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
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: TrogonStack
- Source: TrogonStack/agentskills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.