requirements-engineering_skill

This skill converts vague feature ideas into clear, testable requirements using the EARS format, capturing user stories, criteria, and edge cases for
  • TypeScript

492

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill jasonkneen/kiro --skill requirements-engineering

  • SKILL.md8.4 KB

Overview

This skill transforms vague feature ideas into clear, testable requirements using the EARS (Easy Approach to Requirements Syntax) format. It captures user stories, generates precise acceptance criteria, surfaces edge cases, and validates completeness before design. The result is a consistent, unambiguous requirements set ready for implementation and testing.

How this skill works

Start by converting stakeholder input into concise user stories (As a [role], I want [feature], so that [benefit]). For each story, the skill produces acceptance criteria written in EARS patterns (WHEN/IF ... THEN system SHALL ...) and enumerates edge cases like errors, boundaries, concurrency, and empty states. It runs a checklist-based validation for completeness, clarity, consistency, and testability so requirements are ready to hand off to design and QA.

When to use it

  • At the start of any new feature or project
  • When stakeholder requests are ambiguous or high-level
  • To define acceptance criteria for user stories and sprint tickets
  • When documenting system behavior for QA and testing
  • Before moving from requirements to design or implementation

Best practices

  • Always write a one-line user story before acceptance criteria
  • Use EARS patterns consistently (WHEN/IF ... THEN system SHALL ...) for testability
  • List edge cases explicitly: empty inputs, boundaries, errors, concurrency
  • Avoid implementation detail; state observable system behavior and measurable metrics
  • Validate with checklist: roles, normal flows, edge cases, error handling, and measurable performance

Example use cases

  • Convert a product idea into a requirements document with EARS-formatted acceptance criteria
  • Create detailed acceptance criteria for payment, upload, or search features
  • Identify and document edge cases and error-handling requirements before development
  • Produce a validated requirements template to share with stakeholders and QA
  • Turn stakeholder emails or meeting notes into testable user stories and acceptance criteria

FAQ

EARS (Easy Approach to Requirements Syntax) gives repeatable patterns (WHEN/IF ... THEN system SHALL ...) that make requirements specific, unambiguous, and testable.

How does this skill handle non-functional requirements?

It captures measurable non-functional requirements (performance, security, accessibility) as EARS-style statements or explicit metrics in the non-functional section of the document.

Can it find missing edge cases automatically?

It suggests common edge-case categories (errors, boundaries, concurrency, empty states) and prompts you to confirm or add cases relevant to the feature.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational