steroid-verify

Files (1)

• SKILL.md

SKILL.md (first lines)

# Steroid Verify (Proof of Work)

This skill runs **after** the engine completes all tasks in `plan.md`. It proves the AI's code actually works before the feature can be archived. Without verification, the pipeline is just a promise — this skill makes it proof.

The governed live outputs for this skill are:

- `.memory/changes/<feature>/review.md`
- `.memory/changes/<feature>/review.json`
- `.memory/changes/<feature>/verify.md`
- `.memory/changes/<feature>/verify.json`
- `.memory/changes/<feature>/completion.json`

The live governed authority chain for this phase is:

- `Steroid runtime contract`
- `Steroid runtime contract`
- `Steroid runtime contract`
- `Steroid runtime contract`

Adapted from:

- **Steroid Verifier** (see `Steroid internal reference`) — Goal-backward verification, 3-level artifact checks, anti-pattern scanning
- **Steroid Spec Compliance Review** (see `Steroid internal reference`) — Independent requirement verification
- **Steroid Code Quality Review** (see `Steroid internal reference`) — Structural quality checks
- **Steroid Verification Before Completion** (see `Steroid internal reference`) — Evidence-before-claims gate

## The Iron Law

```
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
```

Source: `Steroid internal reference` — "Claiming work is complete without verification is dishonesty, not efficiency."

If you haven't run the verification command and seen its output, you cannot claim the feature passes.

## The Circuit Breaker Mandate

All terminal commands executed by this skill MUST be wrapped in the physical Node.js circuit breaker:

```
node steroid-run.cjs '<command>'
```

For file inspection and code searches, prefer shell-free helpers like `node steroid-run.cjs fs-cat ...`, `node steroid-run.cjs fs-find ...`, and `node steroid-run.cjs fs-grep ...`. Avoid `cat`, `type`, `find`, `grep`, pipes, and redirection for routine inspection because they are brittle across hardened and Windows environments.

## Phase Gate (Physical Enforcement)

Before doing anything, run the gate check:

```
node steroid-run.cjs gate verify <feature>
```

If this command fails, STOP. The engine phase is not complete.

Then run the feature verification pre-check:

```
node steroid-run.cjs verify-feature <feature>
```

This is the core verification gate. It confirms review status, task completion, runtime checks, runs the Steroid-owned AccessLint audit when local HTML targets exist, and refreshes `ui-review.md` / `ui-review.json` whenever the latest verification evidence changes the frontend review picture. The receipt records freshness metadata so later handoff surfaces can show who refreshed the frontend verdict and which evidence triggered it.

If you want optional deep scans for runtime UI behavior, code smells, and license auditing, run:

```bash
node steroid-run.cjs verify-feature <feature> --deep
```

If you already have a deployed preview, pass it explicitly:

```bash
node steroid-run.cjs verify-feature <feature> --deep --url https://preview.example.com
```

## Two-Stage Review Gate (v5.0)

Before running the verification process, ensure the two-stage review is complete:

```bash
node steroid-run.cjs review status <feature>
```

If frontend evidence changed and you want to refresh the consolidated UI verdict without rerunning the full verification command, use:

```bash
node steroid-run.cjs review ui <feature>
```

`archive <feature>` and `report generate <feature>` will also auto-refresh stale UI review receipts before they archive or hand off a UI-intensive feature.
If the refreshed `ui-review.json` is `CONDITIONAL`, Steroid now distinguishes cautionary frontend issues from blocking frontend issues. Blocking `CONDITIONAL` cases require an explicit `node steroid-run.cjs archive <feature> --force-ui` override.

If both stages show PASS, proceed to verification. If not:

1. Run `node steroid-run.cjs review spec <feature>` — then complete Stage 1
2. Run `node steroid-run.cjs review quality <feature>` — then complete Stage 2

**The review MUST pass both stages before core verification can pass and before `verify.json` can record a passing result.**

The two-stage review produces the governed review artifacts:

- `.memory/changes/<feature>/review.md` — human-readable review report
- `.memory/changes/<feature>/review.json` — machine-readable review receipt

Source: `Steroid internal reference` — "Spec compliance first, then code quality. Never skip reviews."

## The Verification Process

### Step 1: Load Context

Read these files to understand what was built:

1. `.memory/changes/<feature>/spec.md` — The acceptance criteria (what SHOULD be true)
2. `.memory/changes/<feature>/plan.md` — The task list (what was DONE)
3. `.memory/changes/<feature>/tasks.md` — The durable live task artifact from execution
4. `.memory/changes/<feature>/execution.json` — The durable execution receipt from engine
5. `.memory/changes/<feature>/context.md` — The project context (tech stack, test infra)
6. `.memory/changes/<feature>/prompt.json` — The normalized user intent, if present

From nzkbuild/steroid-workflow, MIT.

More from nzkbuild/steroid-workflow