test-author

Derives a test matrix and writes tests from a reviewed spec and architecture.

1|Updated Jul 4, 2026
One-click install
npx skills add https://github.com/happysasha18/live-spec --skill test-author-happysasha18
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-author
Source: https://github.com/happysasha18/live-spec/tree/main/skills/test-author
Command: npx skills add https://github.com/happysasha18/live-spec --skill test-author-happysasha18

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Green test suites can lie: tests pass while users see broken behavior because facts were asserted at the wrong level, such as checking source strings instead of rendered output. This Skill turns a reviewed spec and architecture into a TEST_MATRIX.md grid and a test suite where every fact is pinned to the level that can actually see it fail. ## Core Features & Use Cases - Test matrix derivation: Projects every spec fact into a checkable grid organized by architecture node, with each row stating both the expected behavior and the regression fence it must never violate. - Level ladder pinning: Assigns each fact to string, DOM-text, browser-computed, or pixel level so visibility, layout, color, and interaction facts are asserted in a real browser engine rather than against source text. - Red-first and traceability enforcement: Requires every new test to fail against the pre-change state before implementation, pins the expected skip-set, and keeps a standing traceability test that fails on missing rows, duplicate ids, or uncovered spec facts. - Use Case: A spec says a warning banner turns red when audio clips. Instead of a string check on the template, the fact is pinned at browser-computed level, the test opens a real browser, triggers a clip, and reads the computed color, failing red before the fix ships. ## Quick Start Ask the agent to derive the test matrix and pin test levels from your reviewed spec and architecture documents.

Frequently Asked Questions about test-author

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

FAQPage Schema
How do I write tests that catch bugs users actually see?▼

Pin each fact to the level that can see the failure: visibility, layout, color, and interaction facts need browser-computed tests in a real engine, while content facts need DOM-text assertions. String-level checks on rendered behavior pass while the page shows the wrong thing.

What is a test matrix and how do I derive one from a spec?▼

A test matrix is a grid projecting every spec fact into a checkable row, organized by architecture node. Each row states the expected behavior, the regression fence it must never violate, and a pinned assertion level, with one owning test per row.

Why did my tests pass while the bug still shipped?▼

Passing suites miss visible bugs when facts are asserted at the wrong level, such as checking source strings for facts about rendered output. A test that reads template text proves the code says the right word while the browser shows the wrong one.

When should I not use this test derivation method?▼

Do not use it without a reviewed spec and architecture, since the derivation has nothing sound to build from. It also does not review documents itself; spec review belongs to a separate proving step before matrix derivation begins.

Can browser tests cover touch physics and scroll snapping?▼

No. Touch physics, scroll snapping, and background tab throttling live beyond what a desktop headless browser can reach. Those facts get a real-device row in the matrix that the suite can never turn green, owed to manual verification on a physical device.