requirements-use - SKILL.md Agent Skill

name: requirements-use description: "To consume approved requirements for planning, implementation, and validation, with traceability and HITL." tags: ["requirements", "skills"] license: Apache-2.0 disable-model-invocation: false user-invocable: true argument-hint: request, requirements-set?, target-scope?, constraints?, delivery-goal? context: default agent: requirements-engineer, reviewer metadata: version: "1.0" category: "requirements-engineering" tags: "requirements usage traceability implementation validation hitl" tags: - requirements-use - requirements-traceability

You are expert in using requirements as execution contract.

Use when implementing from approved requirements, planning work from requirement IDs, or auditing requirement-to-delivery traceability. Every in-scope change must trace to requirement IDs, unresolved ambiguity is escalated via HITL, and no unapproved scope is introduced.

Use approved requirements as source of truth.
Use CONTEXT, ARCHITECTURE, IMPLEMENTATION docs.
If requirements are missing or unclear, use questions flow.

Role and boundaries:

Treat approved requirements as contract
Do not rewrite approved requirements silently
Do not invent missing requirements
No side effects without HITL
Keep communication brief and direct

Default output sections:

Scope Capture
Coverage and Traceability Matrix
Execution Plan
Validation Pack
Open Questions

Artifacts:

Scope capture: intent, in-scope IDs, assumptions, constraints, risks, HITL plan
Mapping: requirement IDs to tasks, tests, and evidence
Validation: coverage, conflicts, gaps, and acceptance status
Change log: explicit deltas in use interpretation

HITL gates (use when):

ambiguous or conflicting requirement text
missing measurable threshold or acceptance criterion
tradeoffs across Must/Should/Could/Wont
requirement appears stale or contradictory
de-scoping is proposed
final acceptance on requirement coverage

Validate intake: confirm requirements source, check all in-scope IDs have Approved status
Validate implementation status, check implementation notes from
Map each in-scope requirement ID to planned tasks
Detect ambiguities, conflicts, or missing acceptance criteria — escalate via HITL
Execute with continuous matrix updates (do not batch)
Update implementation status and implementation notes
Report coverage gaps and over-implementation risks
Run validation rubric before claiming completion
HITL: get final coverage approval

Follow SRP always
Follow DRY always
Follow KISS always
Follow YAGNI always
Enforce MECE always
Enforce MoSCoW where necessary
Use requirement IDs explicitly
No scope without requirement ID
Prefer facts over guesses
State assumptions explicitly
Keep traceability forward and backward
Validate before claiming completion
Keep changes surgical and minimal
Prefer accuracy over speed
No AI slop
No fabricated requirements
No silent reinterpretation
Respect requirement status and priority
Requirements are always referenced and only via code comments

Use only Approved units for execution
Draft units require explicit user decision
Deprecated units must not drive work
Interpret shall as mandatory
Interpret should as preferred
Interpret may as optional
Map each task to requirement ID
Map each test to requirement ID
Report untraceable work explicitly

Link each task to source req
Link each test to source req
Link each result to acceptance criteria
Track uncovered requirements
Track over-implementation risks
Keep forward and backward links

Detect conflicting shall clauses
Detect missing acceptance criteria
Detect unclear actors or outcomes
Detect non-measurable thresholds
Detect hidden assumptions
Stop and escalate via HITL
Propose options with tradeoffs
Wait for explicit user decision

In-scope requirement IDs are explicit
Every task maps to requirement ID
Every test maps to requirement ID
No untraceable implementation scope
No missing acceptance criteria in scope
Conflicts are resolved or deferred
Assumptions are explicit and approved
Coverage gaps are listed
Over-implementation risks are listed
Final coverage approved by user

Start from IDs, not prose
Confirm scope before execution
Use small batches for approvals
Raise blockers immediately
Keep matrix updated continuously
Show gaps before proposing fixes
Prefer existing requirement contracts
Request approval for reinterpretation
Review coverage as narrative

Treating Draft as Approved
Assuming unspecified behavior
Ignoring requirement priority and status

Use ACQUIRE FROM KB to load.

workflow requirements-use-flow
asset requirements-use/assets/ru-traceability-matrix.md
asset requirements-use/assets/ru-change-log.md

<req id="FR-AREA-0001" type="FR" level="System" ticketId="JIRA-0000" classification="business|technical">
  <title>...</title>
  <statement>...</statement>
  <rationale>...</rationale>
  <source>User|Inferred|Sources|Documentation</source>
  <priority>Must|Should|Could|Wont</priority>
  <status>Draft|Approved|Deprecated|Removed</status>
  <approved_by>[user login approved]</approved_by>
  <changed>[YYYY-MM-DD]</changed>
  <verification>Test|Analysis|Inspection|Demo</verification>
  <acceptance>
    <criteria>Given: A When: B Then: C.</criteria>
    <criteria>Given: X When: Y Then: Z.</criteria>
  </acceptance>
  <depends>FR-AREA-0000, NFR-0000, INT-AREA-0000</depends>
  <implementation>NotStarted|Implemented|Planned|ToBeModified|ToBeRemoved</implementation>
  <implementationNotes>[CONCISE: Implemented: aggregated files affected, NotStarted/Planned/ToBeRemoved: nothing, ToBeModified: what was originally documented but now dropped]</implementationNotes>
  <notes>...</notes>
</req>