requirements

Original：🇺🇸 English

Translated

Turn a brief or existing feature into testable behavior, quality constraints, and explicit data and permission contracts. Use when stakeholder notes, a brief, or a vibe-coded concept needs FR/NFR requirements before design or implementation.

26installs

Sourcemattjmdesign/dengskills

Added on2026-09-12

NPX Install

npx skill4agent add mattjmdesign/dengskills requirements

SKILL.md Content

View Translation Comparison →

Requirements

Write requirements about outcomes and observable behavior. Keep explicit user choices; do not replace their product with a preferred solution.

Work

Extract the user goal, initiating event, allowed actor, inputs, result, and failure behavior from the brief or running product.
Give requirements stable IDs only when traceability helps. Prefer “An editor can rename a project; a viewer cannot” to legalistic filler.
For each write, identify server authorization, validation, persistence, duplicate submission behavior, and what happens if the result is unknown after a timeout.
Specify applicable quality constraints with conditions: target devices, input methods, content size, latency measurement, supported languages, privacy, and availability. Mark proposed targets as proposals.
Name dependencies, unresolved contract questions, and excluded scope. Do not invent APIs or imply they exist.
When revisiting implementation, report which requirements are met, changed, missing, or unverified, with evidence.

Deliver

Use requirement → acceptance example → dependency/unknown. Add only enough examples to distinguish correct behavior from a plausible implementation.

Write each requirement as:

FR-01: [actor + behavior] — Accept: [observable example] — Depends/unknown: [...] NFR-01: [constraint + condition] — Verify: [scoped check] Close with out-of-scope, assumptions, open questions, and next step.

Example: Given a viewer sends a rename request directly, the server rejects it and the stored name remains unchanged. Hiding the edit button alone does not satisfy this requirement.

Include a failure or boundary case for consequential behavior. “Accessible,” “fast,” and “secure” need scoped verification criteria. Use

$flow

when branch order is the open question;

$component

when a reusable interaction needs a contract.

Worked example

FR-01: The system shows the last 30 days of activity when a user opens the dashboard — Accept: recent work is reviewable without navigation — Depends: activity API exists, rate limits undocumented. FR-02: The system preserves the date-range filter in the URL — Accept: the view can be shared and bookmarked — Depends: none. NFR-01: Dashboard load reaches LCP under 2.5s on 4G mobile — Verify: measure on a mid-tier device; mark the target as a proposal. NFR-02: All dashboard controls are keyboard-reachable with WCAG 2.2 AA contrast — Verify: keyboard pass plus contrast check. Out of scope: custom report builder, CSV scheduling, mobile push notifications. Assumptions: activity data is server-side and queryable by date range. Open questions: past 30 days — paginate or show a summary? Next:

$sitemap

for the app shell and dashboard routes.

Gotchas

Do not treat a hidden button as access control; require server rejection with unchanged data.
Do not invent endpoints or imply they exist; list undocumented contracts as unknowns.
Do not write "fast," "secure," or "accessible" without scoped verification criteria.
Do not specify UI solutions; define observable behavior and defer interaction to flow or component.
Do not present proposed latency or quality targets as committed guarantees.

Boundaries

Do not use when the idea is still vague — run
```
$intent
```
first.
Do not use when requirements exist and the open question is navigation — use
```
$sitemap
```
instead.
Do not specify UI solutions; define comparable behavior and let
```
$component
```
or
```
$flow
```
resolve the interaction.