gspec

Advanced tools

Install Socket

Detect and block malicious and high-risk dependencies

Install

gspec - npm Package Compare versions

Comparing version

2.3.0

2.5.0

+5

-2

dist/antigravity/skills/gspec-qa/SKILL.md

		@@ -23,2 +23,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -33,3 +34,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -43,2 +44,4 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.

+5

-2

dist/antigravity/workflows/gspec-architect.md

		@@ -178,2 +178,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -188,3 +189,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -198,5 +199,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -203,0 +206,0 @@

+5

-2

dist/antigravity/workflows/gspec-distill.md

		@@ -75,2 +75,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -85,3 +86,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -95,5 +96,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -100,0 +103,0 @@

+5

-2

dist/antigravity/workflows/gspec-feature.md

		@@ -191,2 +191,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -201,3 +202,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -211,5 +212,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -216,0 +219,0 @@

+5

-2

dist/antigravity/workflows/gspec-implement.md

		@@ -182,2 +182,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -192,3 +193,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -202,5 +203,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-orchestrator
		@@ -207,0 +210,0 @@

+5

-2

dist/antigravity/workflows/gspec-plan.md

		@@ -125,2 +125,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -135,3 +136,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -145,5 +146,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -150,0 +153,0 @@

+5

-2

dist/antigravity/workflows/gspec-practices.md

		@@ -195,2 +195,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -205,3 +206,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -215,5 +216,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -220,0 +223,0 @@

+5

-2

dist/antigravity/workflows/gspec-profile.md

		@@ -141,2 +141,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -151,3 +152,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -161,5 +162,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -166,0 +169,0 @@

+5

-2

dist/antigravity/workflows/gspec-qa.md

		@@ -49,2 +49,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -59,3 +60,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -69,2 +70,4 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.

+5

-2

dist/antigravity/workflows/gspec-stack.md

		@@ -216,2 +216,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -226,3 +227,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -236,5 +237,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -241,0 +244,0 @@

+5

-2

dist/antigravity/workflows/gspec-style.md

		@@ -180,2 +180,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -190,3 +191,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -200,5 +201,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -205,0 +208,0 @@

+2

-2

dist/claude/commands/gspec-build.md

		@@ -41,6 +41,6 @@ ---
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)
		$ARGUMENTS

+5

-2

dist/claude/gspec-qa/SKILL.md

		@@ -23,2 +23,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -33,3 +34,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -43,2 +44,4 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.

+5

-2

dist/codex/agents/architecture-validator.toml

		@@ -26,2 +26,3 @@ name = "architecture-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -51,0 +54,0 @@

+5

-2

dist/codex/agents/distiller.toml

		@@ -54,2 +54,3 @@ name = "distiller"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -64,3 +65,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -74,5 +75,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -79,0 +82,0 @@

+5

-2

dist/codex/agents/feature-validator.toml

		@@ -26,2 +26,3 @@ name = "feature-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -51,0 +54,0 @@

+5

-2

dist/codex/agents/implementation-validator.toml

		@@ -26,2 +26,3 @@ name = "implementation-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -51,0 +54,0 @@

+5

-2

dist/codex/agents/plan-validator.toml

		@@ -26,2 +26,3 @@ name = "plan-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -51,0 +54,0 @@

+5

-2

dist/codex/agents/practices-validator.toml

		@@ -26,2 +26,3 @@ name = "practices-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-practices
		@@ -51,0 +54,0 @@

+5

-2

dist/codex/agents/profile-validator.toml

		@@ -26,2 +26,3 @@ name = "profile-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -51,0 +54,0 @@

+5

-2

dist/codex/agents/stack-validator.toml

		@@ -26,2 +26,3 @@ name = "stack-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -51,0 +54,0 @@

+5

-2

dist/codex/agents/style-validator.toml

		@@ -26,2 +26,3 @@ name = "style-validator"
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -36,3 +37,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -46,5 +47,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-designer
		@@ -51,0 +54,0 @@

+2

-2

dist/codex/skills/gspec-build/SKILL.md

		@@ -42,5 +42,5 @@ ---
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)

+5

-2

dist/cursor/agents/architecture-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -54,0 +57,0 @@

+5

-2

dist/cursor/agents/distiller.md

		@@ -57,2 +57,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -67,3 +68,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -77,5 +78,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -82,0 +85,0 @@

+5

-2

dist/cursor/agents/feature-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -54,0 +57,0 @@

+5

-2

dist/cursor/agents/implementation-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -54,0 +57,0 @@

+5

-2

dist/cursor/agents/plan-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -54,0 +57,0 @@

+5

-2

dist/cursor/agents/practices-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-practices
		@@ -54,0 +57,0 @@

+5

-2

dist/cursor/agents/profile-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -54,0 +57,0 @@

+5

-2

dist/cursor/agents/stack-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -54,0 +57,0 @@

+5

-2

dist/cursor/agents/style-validator.md

		@@ -29,2 +29,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -39,3 +40,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -49,5 +50,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-designer
		@@ -54,0 +57,0 @@

+2

-2

dist/cursor/commands/gspec-build.md

		@@ -37,5 +37,5 @@ Run the autonomous "idea → built" gspec build: hold the one-time intake interview here, then hand off to the headless `gspec build` runtime, which drives every stage (profile → competitive research (opt-in, `--research`) → stack → practices → style → features → architecture → plans → spec review → implement → reconcile) unattended — pausing once at the spec-review gate, after every spec is written and before any code is generated, so the user can review the specs (skippable with `--no-review`) — self-healing each writer/validator and build/test gate.
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)

+5

-2

dist/cursor/skills/gspec-qa/SKILL.md

		@@ -23,2 +23,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -33,3 +34,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -43,2 +44,4 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.

+5

-2

dist/opencode/agent/architecture-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -58,0 +61,0 @@

+5

-2

dist/opencode/agent/distiller.md

		@@ -61,2 +61,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -71,3 +72,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -81,5 +82,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -86,0 +89,0 @@

+5

-2

dist/opencode/agent/feature-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -58,0 +61,0 @@

+5

-2

dist/opencode/agent/implementation-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -58,0 +61,0 @@

+5

-2

dist/opencode/agent/plan-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -58,0 +61,0 @@

+5

-2

dist/opencode/agent/practices-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-practices
		@@ -58,0 +61,0 @@

+5

-2

dist/opencode/agent/profile-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -58,0 +61,0 @@

+5

-2

dist/opencode/agent/stack-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -58,0 +61,0 @@

+5

-2

dist/opencode/agent/style-validator.md

		@@ -33,2 +33,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -43,3 +44,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -53,5 +54,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-designer
		@@ -58,0 +61,0 @@

+2

-2

dist/opencode/command/gspec-build.md

		@@ -41,6 +41,6 @@ ---
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)
		$ARGUMENTS

+5

-2

dist/opencode/skills/gspec-qa/SKILL.md

		@@ -23,2 +23,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -33,3 +34,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -43,2 +44,4 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.

+5

-2

dist/pi/agents/architecture-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -53,0 +56,0 @@

+5

-2

dist/pi/agents/distiller.md

		@@ -56,2 +56,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -66,3 +67,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -76,5 +77,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		---
		@@ -81,0 +84,0 @@

+5

-2

dist/pi/agents/feature-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -53,0 +56,0 @@

+5

-2

dist/pi/agents/implementation-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -53,0 +56,0 @@

+5

-2

dist/pi/agents/plan-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-engineer
		@@ -53,0 +56,0 @@

+5

-2

dist/pi/agents/practices-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-practices
		@@ -53,0 +56,0 @@

+5

-2

dist/pi/agents/profile-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-product
		@@ -53,0 +56,0 @@

+5

-2

dist/pi/agents/stack-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-architect
		@@ -53,0 +56,0 @@

+5

-2

dist/pi/agents/style-validator.md

		@@ -28,2 +28,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -38,3 +39,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -48,5 +49,7 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.


		## gspec-designer
		@@ -53,0 +56,0 @@

+2

-2

dist/pi/prompts/gspec-build.md

		@@ -41,6 +41,6 @@ ---
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)
		$ARGUMENTS

+5

-2

dist/pi/skills/gspec-qa/SKILL.md

		@@ -23,2 +23,3 @@ ---
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -33,3 +34,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -43,2 +44,4 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.

+1

-1

package.json

		{
		"name": "gspec",
		"version": "2.3.0",
		"version": "2.5.0",
		"description": "Install gspec specification commands for Claude Code, Cursor, and other AI tools",
		@@ -5,0 +5,0 @@ "main": "bin/gspec.js",

+2

-2

plugin/commands/gspec-build.md

		@@ -37,6 +37,6 @@ Run the autonomous "idea → built" gspec build: hold the one-time intake interview here, then hand off to the headless `gspec build` runtime, which drives every stage (profile → competitive research (opt-in, `--research`) → stack → practices → style → features → architecture → plans → spec review → implement → reconcile) unattended — pausing once at the spec-review gate, after every spec is written and before any code is generated, so the user can review the specs (skippable with `--no-review`) — self-healing each writer/validator and build/test gate.
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)
		<<<BUILD_IDEA>>>

+5

-2

plugin/skills/personas/gspec-qa.md

		@@ -18,2 +18,3 @@ You are a QA reviewer for specifications — a rigorous, fair, evidence-driven critic. Your job is to judge whether a spec meets its quality bar and to say precisely what's wrong and how to fix it. You never rewrite the spec and you never edit files; you return a verdict.
		## Severity
		Every finding MUST carry exactly one severity tag — it is load-bearing, not decoration: the verdict is decided by severity, and the autonomous build reads the tags to decide whether a FAIL actually blocks.
		- blocker — unsafe to build on until fixed.
		@@ -28,3 +29,3 @@ - major — a real defect that will cause rework.
		```
		VERDICT: PASS \| FAIL # FAIL if any blocker or major finding
		VERDICT: PASS \| FAIL # FAIL only if a blocker or major finding stands; minor/nit NEVER cause FAIL
		SPEC: <path>
		@@ -38,2 +39,4 @@ SUMMARY: <2-3 sentences>

		A PASS may still carry minor/nit findings — list them, don't fail the spec for them. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.
		PASS is a reachable state — reach it. A spec with only minor/nit findings PASSes; list those findings as advisory, don't fail the spec for them. Reserve `blocker`/`major` for defects that genuinely make the spec unsafe or wrong to build on — do not inflate a polish preference to major to force another revision. A large document will always have another precision nit; "zero findings" is not the bar, "no standing blocker/major" is. Judge strictly against the paired domain skill's quality bar; cite evidence for every finding; propose the smallest fix that resolves it.

		Re-validating a revised spec. When you are re-checking a spec after a revision (you're shown the prior verdict), first state for each prior finding whether it is resolved; only then raise anything new. Hold the bar steady — judge against the same bar, and grade a concern you notice only in text just added to address a prior finding no higher than `minor` unless it is a genuine blocker/major. This is how the loop converges instead of chasing fresh nits into an ever-growing document.

lib/build.js

Sorry, the diff of this file is too big to display

		@@ -41,6 +41,6 @@ ---
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)
		$ARGUMENTS

		@@ -42,5 +42,5 @@ ---
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)

		@@ -37,5 +37,5 @@ Run the autonomous "idea → built" gspec build: hold the one-time intake interview here, then hand off to the headless `gspec build` runtime, which drives every stage (profile → competitive research (opt-in, `--research`) → stack → practices → style → features → architecture → plans → spec review → implement → reconcile) unattended — pausing once at the spec-review gate, after every spec is written and before any code is generated, so the user can review the specs (skippable with `--no-review`) — self-healing each writer/validator and build/test gate.
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)

		@@ -41,6 +41,6 @@ ---
		- Paused for spec review (exit 0; log says "Paused for spec review"; manifest `review` stage is `paused`). This is the expected second human gate: every spec is written, no code exists yet. Summarize the specs for the user (`gspec/profile.md`, `research.md` if `--research` ran, `stack.md`, `practices.md`, `style.`, `architecture.md` + any `architecture/` sub-files, `features/`, `tasks/`), help them review and edit anything they want changed — on a `--research` run, remind them the research findings were auto-accepted* by the build, so this pause is where to prune any they disagree with, and on their go-ahead relaunch with `gspec build --resume` (background/detached, as in step 4) — that resume is the approval and continues into implementation. Do not treat this pause as an error.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`.
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user.
		- Paused on a failure (exit 1). Surface the failing stage and why: the runtime prints the failing verdict/output and keeps it in full in `.gspec/build/last-failure.md` and in the failed stage's `detail` field in the manifest — relay those findings verbatim (not just the one-line reason), and tell the user they can fix the issue and re-run this command to resume from exactly there. A gate fails only on a `blocker`/`major` finding, so a pause is a real defect, not polish. The user may hand-edit the flagged spec to unblock: on resume, a stage left `failed` re-validates the current on-disk deliverable (their edit is honored, not overwritten), so a hand-fix that resolves the finding lets the run continue. If the failure was a QA gate that just needs more attempts, resume with `--qa-retries <n>`. For tuning the build loop, every QA failure this run — including ones a self-heal already recovered from — is also kept in full in the cumulative `.gspec/build/qa-failures.md` (never auto-removed).
		- Build complete (exit 0; log says "Build complete"). Report that specs + code are in place and point at the run record. Either way, the runtime finishes by printing a "Learnings recorded this run" report — the lessons agents captured to memory during the build (promotable via `/gspec-distill`) and the QA feedback events that drove a self-heal; relay it, and surface any captured lessons to the user. The full verdict behind each feedback event (even recovered ones) is in `.gspec/build/qa-failures.md`.

		## Input Idea (and any flags: --engine, --no-qa, --qa-retries, --no-review, --research, --dry-run, --resume, --pi-permission-level)
		$ARGUMENTS

gspec - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics