specifying

Define behavioral requirements with GIVEN/WHEN/THEN scenarios and edge cases.

4|1|Updated Apr 7, 2026
One-click install
npx skills add https://github.com/NSObjects/specpowers --skill specifying
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: specifying
Source: https://github.com/NSObjects/specpowers/tree/main/skills/specifying
Command: npx skills add https://github.com/NSObjects/specpowers --skill specifying

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the uncertainty and ambiguity that derail development by forcing every change intent to be translated into explicit, testable behavioral requirements before any design or implementation work begins.

Core Features & Use Cases

  • Structured Workflow Enforcement: Guides the agent through proposal review, domain identification, and Delta-aware spec creation so no requirement is missed.
  • Testable Scenarios: Demands GIVEN/WHEN/THEN formats for every scenario and edge case, preventing vague requirements like “handle errors appropriately.”
  • Delta Awareness: Distinguishes new, modified, and removed requirements when previous specs already exist, ensuring clean archives and traceability.
  • Role Clarity & Gates: Declares the QA Architect role, forbids implementation leaks, and pauses before transitioning to design until the user confirms.

Quick Start

Ask the specifying skill to outline the required observable behaviors with GIVEN/WHEN/THEN scenarios before moving on to design work.

Frequently Asked Questions about specifying

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

FAQPage Schema
How do I write behavioral specifications with GIVEN/WHEN/THEN scenarios before development?

Behavioral specifications are defined by translating an accepted change intent into structured requirements, ensuring every scenario and edge case uses a GIVEN/WHEN/THEN format to prevent ambiguity before design begins.

What is the best way to track modified or removed requirements when updating existing specs?

Tracking modified requirements requires delta awareness, which distinguishes between new, modified, and removed behaviors when previous specifications exist, ensuring clean archives and traceability within specs/changes directories.

How do I prevent implementation details from leaking into requirement scenarios?

Preventing implementation leaks requires enforcing role clarity by declaring a QA Architect role, which pauses transitions to design and keeps specifications focused strictly on testable observable behaviors.

When do I need structured behavioral requirements instead of moving directly to design?

Structured behavioral requirements are needed whenever a request involves complex changes, demanding explicit testable scenarios and documented delta handling before moving on to design or implementation phases.

Can I use this specification workflow to identify domain boundaries for my changes?

Yes, the specification workflow guides you through proposal review and domain identification as part of delta-aware spec creation, ensuring no required observable behaviors are missed during definition.