# Gsdl Verify Gates

> Run the project's deterministic checks (tests, lint, typecheck, build) and produce a pass/fail gate report before opening a PR or closing out. Use when the user wants to verify a change, run the test suite before wrapping up, check gates, or asks "are we good to close this out?". This is Step 7 (Verify Against Deterministic Gates) of the GSDL pipeline. Runs on the MEDIUM tier.

- Skill: `nsantini/gsdl-verify-gates` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nsantini/gsdl-verify-gates`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nsantini/gsdl-verify-gates/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: nsantini (https://skillmd.com/u/nsantini)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nsantini/gsdl-verify-gates

---


# Verify Against Deterministic Gates

Runs whatever deterministic checks the project actually has, and produces a gate report — the
evidence that Step 8 (Open PR) puts in front of a reviewer and Step 9 (Close Loop) records. This is
**Step 7**:
`Pick up source → Brainstorm → SPEC.md → Slices → Review → Branch → Execute → Verify → PR + bot → Close loop`

**Why this is a standalone skill and not a checkbox inside `gsdl-execute`**: most repos don't yet
have CI that enforces this automatically. Until CI/local parity and unbypassable ratchets exist, this
skill is the manual crutch that makes "verify" a deliberate, evidenced step rather than something
that quietly gets skipped.

## Tier

**MEDIUM.** The gates are deterministic by definition — discover the project's real checks, run them,
capture the output verbatim. There's no judgment to spend a LARGE model on. When the `gsdl`
orchestrator runs Step 7 it spawns a MEDIUM subagent for it.

Running as a subagent means **non-interactive**: don't ask the user anything, and **don't try to fix
failing gates**. Write the report, then return the failures with their verbatim output to the caller.
Triage and remediation happen in the orchestrator context, which can loop back into Step 6.

## Prerequisites

1. **Project exists**: `.planning/[project-name]/`
2. **Implementation complete**: all parent slices in `.planning/[project-name]/tasks.md` are `[x]`
   (run `gsdl-execute` first if not)
3. **`SPEC.md` exists**: read its "Verification Plan" section (Step 3) for what the user already said
   should be checked

## Step 1 — Discover the Gates

Look for deterministic checks in this order, and use **all** that are discoverable — don't stop at
the first one found:

1. **`SPEC.md`'s Verification Plan** — the user may have already named specific commands or manual steps
2. **`package.json` scripts** — `test`, `lint`, `typecheck`/`type-check`, `build`, `format:check`
3. **Other package manifests** — `Makefile` targets (`test`, `lint`, `build`),
   `pyproject.toml`/`tox.ini` (pytest, ruff, mypy), `Cargo.toml` (`cargo test`, `cargo clippy`),
   `go.mod` (`go test ./...`, `go vet`), `*.csproj`/`*.sln` (`dotnet test`, `dotnet build`),
   `Gemfile` (`rspec`, `rubocop`), `pom.xml`/`build.gradle` (`mvn verify`, `gradle check`)
4. **CI config** — `.github/workflows/*.yml`, `.gitlab-ci.yml`, `.circleci/config.yml`,
   `azure-pipelines.yml`. Mirror what CI actually runs; if CI runs something not exposed as a local
   script, note the CI-only gate and try to run its underlying command directly
5. **Pre-commit / lint config** — `.pre-commit-config.yaml`, `.eslintrc*`, `.golangci.yml`, `ruff.toml`

If you find **no discoverable gates at all**: this is itself a finding, not a silent pass. Say so
explicitly — it's a verification-contract gap — and ask what to check manually (e.g., "run the app
and click through X", "check the staging deploy").

## Step 2 — Run Each Gate

Run each discovered command. Capture:
- The exact command run
- Pass/fail
- A trimmed excerpt of the output (full output for failures; just the summary line for passes)

Run gates in a reasonable order: install/build first if needed, then lint/typecheck (fast, cheap),
then tests (slower), matching whatever the repo's CI does if that's discoverable.

Do not skip a gate because it's slow. If a gate is genuinely too expensive to run in full (e.g., a
full e2e suite), say so and ask the user whether to run a subset or skip with their explicit sign-off
— never skip silently.

## Step 3 — Produce the Gate Report

Write to `.planning/[project-name]/verify-report.md`:

````markdown
# [Project Name] — Verify Report

> Generated by gsdl-verify-gates on [YYYY-MM-DD]

## Gates Run

| Gate | Command | Result | Notes |
|------|---------|--------|-------|
| Lint | `npm run lint` | ✅ Pass | |
| Typecheck | `npm run typecheck` | ✅ Pass | |
| Tests | `npm test` | ❌ Fail | 2 failures in `auth.test.ts` — see below |
| Build | `npm run build` | ✅ Pass | |

## Failures

### `auth.test.ts`
```
[trimmed failure output]
```

## Manual Checks (if no automated gate covers them)

- [ ] [Manual check description] — performed by: [user/agent], result: [pass/fail]

## Gaps Identified

- [Any check SPEC.md's Verification Plan called for but no gate exists to run automatically — flag it, don't just note and move on]
````

Omit the "Manual Checks" or "Gaps Identified" sections if empty.

## Step 4 — Gate on the Result

This is a **ratchet, even if a manual one**: do not report Step 7 as complete while any gate is failing.

- **All gates pass**: tell the user verification passed, show the report path, and say the project is
  ready for **Step 8 (`gsdl-open-pr`)** — or Step 9 directly if no forge is configured.
- **Any gate fails**: stop here. Report the failure(s) clearly, and do not proceed to PR creation or
  close-out — a PR is never opened on a red branch. Remediation is the **caller's** call, not yours
  (see Tier above) — return the failures and let it choose between:
  - Fixing the issue and re-running this skill, or
  - Going back to `gsdl-execute` if the fix is substantial enough to need its own sub-task tracking

Never soften a failing gate into "mostly passing" — the report is evidence a human or reviewer may
later rely on.

## Rules

1. **Discover gates from the repo, don't assume a stack** — a Python repo has no `package.json`;
   check what actually exists
2. **No silent gaps** — if something can't be verified automatically, say so in the report, don't omit it
3. **Never mark Step 7 done with a failing gate** — this is the one hard stop in the whole pipeline
4. **Re-run from disk** — if `tasks.md` or `SPEC.md` changed since this skill last ran, re-read them
   before re-verifying