oztenozten/skills/tpm-spec-verify/SKILL.md

tpm-spec-verify

Skill7 starsChanged 9 months agoMITView on GitHub

Enrich a Phase Sepc/PRD with Quality Requirements (Q-nnn) and Acceptance Criteria (AC-nnnn). Use when user wants to add QA perspective, define test criteria, identify non-functional requirements, add verification steps, or prepare a Phase PRD for test planning.

In this repository15 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- creative-directionSkill
- find-bugsSkill
- five-whysSkill
- idea-to-icpSkill
- nano-banana-image-genSkill
- self-improvementSkill
- simplifySkill
- tpm-roadmap-sliceSkill
- tpm-spec-trace-idsSkill
- ui-design-iterationSkill
- webdev-combobox-autocompleteSkill
- webdev-filter-query-builderSkill
- webdev-token-inputSkill
- youtube-transcriptSkill

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Add Quality Requirements and Acceptance Criteria to a Phase PRD, preparing it for test planning.
line 8
Distinctive:
If a requirement needs >10 ACs, recommend splitting the requirement.
line 89
Distinctive:
After adding ACs, update the Traceability Matrix:
line 93

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

PRD QA Enricher

Add Quality Requirements and Acceptance Criteria to a Phase PRD, preparing it for test planning.

Inputs Required

Phase PRD — With R-nnnn requirements (use prd-phase-generator first if missing)

Workflow

Audit for Quality Requirements — Identify missing non-functional concerns
Add Q-nnn entries — Security, performance, accessibility, etc.
Write Acceptance Criteria — Happy path, edge cases, error conditions for each R-nnnn
Update traceability — Link ACs to requirements

Step 1: Quality Requirements Audit

Review the Phase PRD and ask: what cross-cutting concerns are missing?

Quality Categories Checklist

Tag	Category	Questions to Ask
`[PERF]`	Performance	Response times? Throughput? Caching?
`[SEC]`	Security	Auth? Input validation? Data protection?
`[AVAIL]`	Availability	Uptime requirements? Failover? Recovery?
`[SCALE]`	Scalability	Concurrent users? Data volume limits?
`[ACCESS]`	Accessibility	WCAG level? Keyboard nav? Screen readers?
`[COMPAT]`	Compatibility	Browsers? Devices? Integrations?
`[I18N]`	Internationalization	Languages? Locales? RTL support?
`[API]`	API Standards	Versioning? Rate limits? Error formats?

Writing Quality Requirements

Q-007 [COMPAT]: The system shall support Chrome, Firefox, Safari, and Edge (latest 2 versions)

**Applies to:** F-001, F-002, F-003
**Priority:** Must

Each Q-nnn should:

Have a category tag in brackets
List which features it applies to
Be testable and specific

Step 2: Acceptance Criteria

For each R-nnnn, write AC-nnnn entries covering:

Coverage Categories

Happy path — Normal successful flow
Edge cases — Boundary conditions, limits, empty states
Error handling — Invalid input, failures, recovery
State transitions — Before/after, concurrent access

AC Format

**Acceptance Criteria:**
- AC-R0142-01: Form accepts valid email formats (user@domain.tld)
- AC-R0142-02: Form rejects invalid emails with inline error message
- AC-R0142-03: Form requires non-empty name field
- AC-R0142-04: Form preserves input on validation failure
- AC-R0142-05: Submit button disabled until required fields populated

AC Writing Guidelines

Do	Don't
Specific, testable conditions	Vague ("works correctly")
One behavior per AC	Multiple behaviors combined
Observable outcomes	Implementation details
Include error states	Only happy path

Typical AC Count

Simple requirement: 2-3 ACs
Standard requirement: 3-5 ACs
Complex requirement: 5-8 ACs

If a requirement needs >10 ACs, recommend splitting the requirement.

Step 3: Update Traceability

After adding ACs, update the Traceability Matrix:

Requirement	Feature	Priority	Status	AC Count
R-0142	F-014	Must	Draft	5

Quality Requirements Numbering

Q-nnn is sequential across the entire product (like R-nnnn). Check previous Phase PRDs for last used Q-nnn.

Reference

See references/naming-conventions.md for ID format details and category tags.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free