Gather requirements en

Skill roebi/sw-dev-agent-framework/skills/gather-requirements-en

An agentic framework that does exactly one thing: **software development**. Built with TDD. Every line of production code was preceded by a failing test.

Install

npx -y skills add roebi/sw-dev-agent-framework --skill gather-requirements-en

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Transforms a vague goal or feature request into a structured, testable requirements list. Produces a requirements.md with numbered functional and non-functional requirements. Use when a user or agent starts a new software project and needs to turn an idea into concrete, implementable requirements before any code or design work begins. Activate for trigger phrases like: "gather requirements", "write requirements for", "what are the requirements", "define the requirements", "requirements phase", or "turn this goal into requirements".

The file declares its own license as CC BY-NC-SA 4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.3 KB, as published. Nobody here has run it

Gather Requirements

Converts a goal statement into a structured, numbered list of requirements that are testable, unambiguous, and ready for architecture design and TDD. Output is written to requirements.md in the project root.

Input

A goal statement (one sentence to one paragraph), for example:

"Build a Python CLI tool that converts CSV files to Markdown tables."

Output - requirements.md

# Requirements

## Functional Requirements

FR-01: <verb> <what> <constraint>
FR-02: ...

## Non-Functional Requirements

NFR-01: <quality attribute> - <measurable target>
NFR-02: ...

## Out of Scope

- <explicitly excluded feature>

Step-by-step Instructions

Step 1 - Clarify the goal

Restate the goal in one sentence. Identify:

The primary user or agent (who uses the output?)
The core action (what must the software do?)
The target platform (CLI, library, web service, container?)
Key constraints (language, runtime, existing dependencies?)

Step 2 - Derive functional requirements

Write one requirement per line. Each FR must be:

Testable - you can write a test that passes or fails
Atomic - one behaviour per requirement
Verb-first - starts with an action: "Accept", "Return", "Validate", "Write"

Bad: "Handle files" -> too vague, not testable. Good: "FR-01: Accept a CSV file path as a CLI argument and fail with exit code 1 if the file does not exist."

Step 3 - Add non-functional requirements

Cover at least these where relevant:

Performance (response time, throughput)
Reliability (error handling, exit codes)
Testability (test framework, coverage target)
Portability (Python version, OS)
Security (input validation, no secrets in output)

Step 4 - Define out of scope

Explicitly list at least two things that are NOT in scope. This prevents scope creep in later phases.

Step 5 - Validate requirements

Before writing requirements.md, check each FR:

[ ] Can I write a test for this requirement? (testability gate)
[ ] Does it describe ONE behaviour? (atomicity gate)
[ ] Is it free of implementation detail? (requirements vs design)
[ ] Is it free of ambiguous words like "fast", "easy", "good"? (clarity gate)

Any FR that fails a gate must be rewritten or split.

Step 6 - Write requirements.md

Write the file to the project root. Announce to the orchestrator:

phase: requirements
status: done
output: requirements.md written with <N> functional and <M> non-functional requirements

Handover to Design Phase

Pass requirements.md as the primary input to design-architecture-en. The design phase must not add new requirements - only reference existing ones.