hf-specify

Generate review-ready requirement specifications with traceability anchors and acceptance criteria.

1|Updated Mar 22, 2026

Search Tags:#specification #requirements #traceability #bdd #ears #invest #deferral

Ready to run

npx skills add https://github.com/hujianbest/garage-agent --skill hf-specify

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: hf-specify
Source: https://github.com/hujianbest/garage-agent/tree/main/packs/coding/skills/hf-specify
Command: npx skills add https://github.com/hujianbest/garage-agent --skill hf-specify

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

hf-specify helps teams avoid rushing into design or implementation by systematically clarifying scope, breaking down oversized requirements, and producing structured requirement rows with traceability anchors.

Core Features & Use Cases

Clarifies scope and boundaries for current work.
Splits oversized requirements into independent, testable FR/NFR items.
Produces requirement rows (FR/NFR/CON/IFR/ASM/EXC) with IDs, acceptance criteria, priority, and sources.
Establishes trace anchors to user requests, spec bridges, review findings, or external constraints.
Supports deferral/backlog planning for non-core capabilities.

Quick Start

Clarify the current scope and boundaries, then draft traceable FR/NFR items with clear sources.

Frequently Asked Questions about hf-specify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I write structured requirement specifications with traceability?▼

Structured requirement specifications are produced by defining items with IDs, Types, Statements, Acceptance criteria, Priorities, and Sources. This establishes traceability anchors linking each requirement to verifiable evidence like user requests or external constraints.

What is the best way to split oversized requirements into testable items?▼

Oversized requirements are split by clarifying scope boundaries and breaking them down into independent FR and NFR items. Each item receives a minimum contract of ID, Type, and Acceptance criteria using EARS or BDD formats to ensure testability.

When do I need to use EARS and BDD formats for requirement acceptance criteria?▼

EARS and BDD formats are needed when drafting acceptance criteria for requirement specifications to ensure they are verifiable. These formats clarify conditions and behaviors, anchoring decisions to testable evidence rather than ambiguous statements.

How do I handle non-functional requirements using ISO 25010 quality attributes?▼

Non-functional requirements are handled by defining them as Quality Attribute Scenarios (QAS) based on ISO 25010. This structures NFRs with clear acceptance criteria and priority, ensuring they are testable and traceable alongside functional requirements.

Can I use requirement deferral for non-core capabilities during scope clarification?▼

Requirement deferral is used during scope clarification to manage non-core capabilities. By establishing boundaries, teams can separate essential FR/NFR items from deferred backlog items, maintaining focus on current work while preserving traceability.

What should I do if my requirement specification is returned for revision?▼

If a requirement specification is returned for revision, you must update the draft using the review findings. The specification process re-applies to refine the FR/NFR rows, ensuring all minimum contract fields and success metrics meet review standards.