AI SKILLs for Better Requirements

It takes only two steps to improve an AI-generated spec.

Step 1: Fix what AI knows about your product.
Step 2: Fix the language and the format.

The setup takes about 20 minutes. Once you have it, you can reuse the same context across your specs.

Two project skills that chain: the first establishes product context, the second consumes it to write requirements.

Works with any LLMs - simply copy the file contents and ask it to install itself a skill.

I explain how I use them in this free Lightning Lesson

Interviews you to pin down the foundations of a product so later work stops inventing
assumptions. Trigger phrases include "grill me", "set up context", "extract context".

Flow — three blocks in sequence, each feeding the next, max 3 back-and-forths per
block, confirmation required before moving on:

1. Product description — what it does, problems solved, domain, regulations, scale.

2. Users — the skill proposes likely roles from block 1; you cut and add.

3. Domain entities — proposed candidates get tested against five criteria (many

   instances, has attributes, has lifecycle, has relationships, queryable). Actions,
   attributes, incidental nouns and UI state are excluded. No data model is produced.

Output — files under context/, one per user type and one per entity:

• context/product/product-description.md — description, problems, domain, regulations

• context/users/[User-Type].md — user type plus jobs-to-be-done lines

• context/entities/[Entity-Name].md — entity name plus an attribute/example table

It closes by reporting what it wrote and any call it made that you did not explicitly
confirm.

Rewrites loose requirement text — a ticket or a feature blurb — into EARS
(Easy Approach to Requirements Syntax): one atomic, testable shall statement per line.

Flow:

1. Read context first — README.md/CLAUDE.md, then docs/, specs/,

   context/, then existing requirement files, to fix the system name, actors and
   entity vocabulary. This is where context-extractor's output gets used.

2. Decide whether to ask — only if a missing answer would change the requirements;

   one message, not a half-grounded list as a hedge.

3. Convert — classify against the six patterns (ubiquitous, event-driven,

   unwanted behaviour, state-driven, optional feature, complex), split compound
   statements, replace unverifiable words like "fast" or "seamless" with a measured
   value or flag them as gaps. Nothing the input does not imply gets added.

Output — one file per invocation at outputs/<slug>.md (numeric suffix rather than
overwrite), with four sections:

• Source — the original text, verbatim, as the traceability link

• EARS-compliant list — plain 1. 2. 3. numbering, ordered ubiquitous → state-driven
  → event-driven → unwanted behaviour → optional

• Assumptions — what was inferred and from where

• Gaps and open questions — what the author still has to decide

Headline assumptions and gaps are repeated in the chat reply so you see them without
opening the file.