Empirical Validation

Validates completed work with empirical evidence before marking tasks done.

Updated Mar 11, 2026
One-click install
npx skills add https://github.com/apsulli/gsd-extended --skill empirical-validation-apsulli
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: Empirical Validation
Source: https://github.com/apsulli/gsd-extended/tree/main/.agent/skills/empirical-validation
Command: npx skills add https://github.com/apsulli/gsd-extended --skill empirical-validation-apsulli

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI-assisted development often ends with unverified claims like "the code looks correct," leading to broken builds, failed endpoints, and UI regressions discovered only later. This Skill enforces proof-based completion so no task is marked done without observable evidence. ## Core Features & Use Cases - Validation Methods by Change Type: Maps each change type (UI, API, build/config, data, file operations) to a required verification tool such as browser screenshots or command output. - Four-Step Validation Protocol: Identify verification criteria, execute verification, document evidence in .gsd/JOURNAL.md, and confirm results against expectations. - Failure Handling Workflow: Failed verifications block task completion, get documented in .gsd/STATE.md, generate fix tasks, and trigger the Context Health Monitor after 3+ failures. - Use Case: After modifying a login API endpoint, run a curl request against it, capture the actual JSON response showing a success token, and record that output in the journal before closing the task. ## Quick Start Ask the AI to verify the most recent change using the empirical validation protocol and record the evidence in the GSD journal.

Frequently Asked Questions about Empirical Validation

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

FAQPage Schema
How do I verify code changes actually work before marking tasks done?▼

Run the verification method matching your change type: curl commands for API endpoints, build output for config changes, or browser screenshots for UI work. Capture the actual output and document it in the journal as evidence before closing the task.

What counts as valid validation evidence for UI changes?▼

UI changes require a screenshot captured with a browser tool showing the expected visual state, such as a visible header, loaded data, and correct layout. Statements like "the component should render correctly" are explicitly rejected as validation.

What happens when task verification fails?▼

The task is not marked complete, the failure is documented in `.gsd/STATE.md`, and a fix task is created if the cause is known. After three or more failures, the Context Health Monitor is triggered to address diminishing returns.

Which phrases are forbidden when justifying task completion?▼

Forbidden justifications include "this should work," "the code looks correct," "I've made similar changes before," "based on my understanding," and "it follows the pattern." Only captured empirical evidence counts as proof of completion.

Does empirical validation integrate with other GSD workflows?▼

Yes, it integrates with the `/verify` command as its primary workflow and with `/execute`, which must validate before marking tasks complete. It also enforces Rule 4 (Empirical Validation) defined in `GEMINI.md`.