# Create Requirements

> Draft a requirements document with functional and non-functional requirements from a feature brief or issue.

- **Type:** Skill
- **Install:** `agentstack add skill-tomzx-agents-create-requirements`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [tomzx](https://agentstack.voostack.com/s/tomzx)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [tomzx](https://github.com/tomzx)
- **Source:** https://github.com/tomzx/agents/tree/main/skills/create-requirements

## Install

```sh
agentstack add skill-tomzx-agents-create-requirements
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Create Requirements

Drafts a structured requirements document from a feature brief, user story, or GitHub issue, capturing functional requirements, non-functional requirements, constraints, and acceptance criteria.

## Prerequisites

- Apply the shared SDLC conventions in `skills/sdlc/references/shared.md`.
- If no argument is provided, use `$ISSUE_TITLE` and `$ISSUE_BODY` as the feature brief (and `$ISSUE_NUMBER` to link the feature).
- A feature brief, user story, or issue description provided in context or as `$1`
- Stakeholder goals and constraints, if known

## Steps

1. Read and understand the input (feature brief, issue, or user story).
2. Identify the goal: what problem is being solved and for whom.
3. List functional requirements: behaviors the system must exhibit.
4. List non-functional requirements: quality attributes (performance, security, availability, etc.).
5. Identify constraints: technology choices, regulatory requirements, compatibility needs.
6. Write acceptance criteria: testable conditions that confirm each requirement is met.
7. Flag any open questions where requirements are unclear or missing.
8. Derive the feature directory name `N-` following the Feature Directory Naming convention in `skills/sdlc/references/shared.md`: use the issue number as `N` when one is available, otherwise a `p`-prefixed sequence number (`p1`, `p2`, ...) marking the feature as pending a placeholder issue. Record the related issue number in the frontmatter `issue` field only when an issue exists.
9. Write the output to `.sdlc/features/N-/requirements.md`, creating the directory if it does not exist.

## Output Format

Use the template at `skills/sdlc/templates/features/requirements.md` (copied to `.sdlc/templates/features/requirements.md` by `/initialize-sdlc-directory`; use the project's customized copy if present). Write the result to the artifact path named in the steps above.

Use MoSCoW priority for functional requirements: **Must** (essential), **Should** (important), **May** (nice-to-have).

Functional requirements state *what* the system shall do; acceptance criteria state *how you verify* it is done.
Do not restate an FR as its acceptance criterion.
Write concrete, scenario-based criteria (happy path, edge cases, error states), usually several per requirement, each independently checkable and translatable into a test case.

## Outcome

If `$OUTCOME_YAML` is set, emit your verdict there per `skills/sdlc/references/shared.md`:

| Verdict | When |
|---|---|
| `approved` | Requirements drafted (artifact written with `status: draft`, ready for `/review-requirements`) |
| `needs-info` | Issue lacks the detail needed to derive requirements |

## Example Usage

**Scenario 1: Feature brief in context**
User describes "we need users to reset their passwords via email."
Draft FR for the email flow, NFR for token expiry and security, and acceptance criteria for each step.

**Scenario 2: GitHub issue as input**
```
/create-requirements https://github.com/owner/repo/issues/42
```
Fetch the issue, extract the described behavior, and produce a requirements document.

**Scenario 3: Incomplete brief**
User gives a vague description.
List open questions and draft requirements for the parts that are clear.

## Completion Checklist

Before handing off to review, confirm:

- [ ] Each functional requirement has testable, scenario-based acceptance criteria that do not just restate the FR

Self-check the draft against the [`review-requirements` checklist](../review-requirements/SKILL.md) and fix what you can, so review finds less to flag.

## Next Step

Run `/review-requirements` to audit the document for clarity, completeness, testability, and conflicts before moving on.
Once approved, continue with `/create-existing-solutions` to survey prior art.

## Useful Commands Reference

For document-only input, no CLI commands are required.
If given an issue URL, fetch it with:

| Command | Description |
|---|---|
| `ghx issue view  --comments` | Fetch issue details and comments (cached) |

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [tomzx](https://github.com/tomzx)
- **Source:** [tomzx/agents](https://github.com/tomzx/agents)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-tomzx-agents-create-requirements
- Seller: https://agentstack.voostack.com/s/tomzx
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.