ql-verify

Name: ql-verify
Author: andyzengmath

23stars0forks

How to install ql-verify?

andyzengmath/quantum-loop/ql-verify

$npx -y skills add andyzengmath/quantum-loop --skill ql-verify

Installs into the current project.

Summary

Part of the quantum-loop autonomous development pipeline (brainstorm \u2192 spec \u2192 plan \u2192 execute \u2192 review \u2192 verify). Iron Law verification gate. Requires fresh evidence before any completion claim. Use before claiming work is done, before committing, or befor

Files · 1

View on GitHub

SKILL.md

1	# Quantum-Loop: Verify
2
3	## Inline-vs-adversarial review split (P5.A7 / US-007)
4
5	The verify gate distinguishes routine checks (deterministic verdict, exit-code 0/non-0) from adversarial checks (require judgement) and routes them differently:
6
7	\| Check kind \| Examples \| Mode \| Rationale \|
8	\|---\|---\|---\|---\|
9	\| Routine \| typecheck, lint, full test suite, file-org conventions \| inline-only in implementer prompt before STORY_PASSED \| Verdict is deterministic; subagent round-trip adds 25min for zero signal value \|
10	\| Adversarial \| cross-story file conflicts, intent drift vs PRD, security review, architecture / API-shape \| subagent dispatch (spec-reviewer, quality-reviewer, security-reviewer, architect) \| Requires judgement, context, and human-readable explanation that grep cannot provide \|
11
12	Routine checks emit literal tokens the orchestrator greps for evidence:
13	- `[INLINE-REVIEW] typecheck OK`
14	- `[INLINE-REVIEW] lint OK`
15	- `[INLINE-REVIEW] all assigned tests pass`
16	- `[INLINE-REVIEW] file-org follows project conventions`
17
18	If a routine check fails, the implementer marks the story failed and EXITS — does NOT signal STORY_PASSED. Adversarial review is reserved for cases the inline gate cannot adjudicate. Per Superpowers v5.0.6: 25min -> 30s on the routine path; total throughput improves 10-50x at the same quality bar.
19
20	## The Iron Law
21
22	```
23	NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
24	```
25
26	This is not a guideline. This is not a best practice. This is a law. There are zero exceptions.
27
28	## The 5-Step Gate Function
29
30	Every claim that something "works", "passes", or "is done" must pass through these 5 steps:
31
32	### Step 1: IDENTIFY
33	What command or check proves the claim?
34
35	Examples:
36	- "Tests pass" → `npm test` or `pytest`
37	- "Build succeeds" → `npm run build` or `tsc --noEmit`
38	- "Lint clean" → `eslint .` or `ruff check`
39	- "Feature works" → specific test command + manual check
40	- "Bug is fixed" → test that reproduces the original bug
41
42	### Step 2: RUN
43	Execute the complete command. Right now. Fresh. Not from memory or cache.
44
45	Rules:
46	- Run the FULL command, not a subset
47	- Run it in the current state of the code, not from before your changes
48	- Do not use cached results from a previous run
49	- Do not skip the command because "it passed last time"
50
51	### Step 3: READ
52	Read the ENTIRE output. Not just the last line.
53
54	Check:
55	- Exit code (0 = success, non-zero = failure)
56	- Total number of tests (passed, failed, skipped)
57	- Warning messages (warnings can hide real problems)
58	- Specific error messages (not just "X tests passed")
59
60	### Step 4: VERIFY
61	Does the output ACTUALLY confirm the claim?
62
63	Common traps:
64	- "15 tests passed" but 3 were skipped → those 3 might be the important ones
65	- "Build succeeded" but with warnings → warnings might indicate runtime failures
66	- "0 errors" from linter but build still fails → linter ≠ compiler
67	- "Test passed" but the test itself is wrong → test may not test what you think
68
69	### Step 5: CLAIM
70	ONLY NOW may you state that something works, passes, or is done.
71
72	Your claim must include:
73	- The exact command you ran
74	- The key output (pass count, exit code)
75	- Timestamp (when you ran it)
76
77	## Verification Requirements by Claim Type
78
79	\| Claim \| Required Evidence \|
80	\|-------\|-------------------\|
81	\| "Tests pass" \| `0 failures` AND `0 errors` in fresh test run output \|
82	\| "Linter clean" \| `0 errors` AND `0 warnings` in fresh lint output \|
83	\| "Build succeeds" \| Exit code 0 from fresh build command \|
84	\| "Bug is fixed" \| Test reproducing original symptom now passes \|
85	\| "Feature works" \| All acceptance criteria verified with specific evidence \|
86	\| "Story is done" \| ALL of the above that apply + spec compliance review passed \|
87	\| "Typecheck passes" \| Exit code 0 from `tsc --noEmit` or equivalent \|
88
89	## Red Flags -- STOP Immediately
90
91	If you notice ANY of these, you are about to violate the Iron Law:
92
93	### Language Red Flags
94	- Using "should" → "Tests should pass" means you haven't run them
95	- Using "probably" → "This probably works" means you don't know
96	- Using "seems to" → "It seems to be working" means you haven't verified
97	- Using "I believe" → "I believe this is correct" means you're guessing
98	- Using "based on" → "Based on the changes, it should work" means you haven't checked
99
100	### Behavioral Red Flags
101	- Expressing satisfaction before running verification ("Great!", "Perfect!", "Done!")
102	- Trusting a subagent's report without independent verification
103	- Relying on a previous run instead of a fresh one
104	- Checking only part of the test suite
105	- Skipping verification because "the change was small"
106
107	## Anti-Ra

People who liked this also viewed

6 picks

Type

ql-verify

23stars0forks

View on GitHub

How to install ql-verify?

andyzengmath/quantum-loop/ql-verify

$npx -y skills add andyzengmath/quantum-loop --skill ql-verify

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Quantum-Loop: Verify
2
3	## Inline-vs-adversarial review split (P5.A7 / US-007)
4
5	The verify gate distinguishes routine checks (deterministic verdict, exit-code 0/non-0) from adversarial checks (require judgement) and routes them differently:
6
7	\| Check kind \| Examples \| Mode \| Rationale \|
8	\|---\|---\|---\|---\|
9	\| Routine \| typecheck, lint, full test suite, file-org conventions \| inline-only in implementer prompt before STORY_PASSED \| Verdict is deterministic; subagent round-trip adds 25min for zero signal value \|
10	\| Adversarial \| cross-story file conflicts, intent drift vs PRD, security review, architecture / API-shape \| subagent dispatch (spec-reviewer, quality-reviewer, security-reviewer, architect) \| Requires judgement, context, and human-readable explanation that grep cannot provide \|
11
12	Routine checks emit literal tokens the orchestrator greps for evidence:
13	- `[INLINE-REVIEW] typecheck OK`
14	- `[INLINE-REVIEW] lint OK`
15	- `[INLINE-REVIEW] all assigned tests pass`
16	- `[INLINE-REVIEW] file-org follows project conventions`
17
18	If a routine check fails, the implementer marks the story failed and EXITS — does NOT signal STORY_PASSED. Adversarial review is reserved for cases the inline gate cannot adjudicate. Per Superpowers v5.0.6: 25min -> 30s on the routine path; total throughput improves 10-50x at the same quality bar.
19
20	## The Iron Law
21
22	```
23	NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
24	```
25
26	This is not a guideline. This is not a best practice. This is a law. There are zero exceptions.
27
28	## The 5-Step Gate Function
29
30	Every claim that something "works", "passes", or "is done" must pass through these 5 steps:
31
32	### Step 1: IDENTIFY
33	What command or check proves the claim?
34
35	Examples:
36	- "Tests pass" → `npm test` or `pytest`
37	- "Build succeeds" → `npm run build` or `tsc --noEmit`
38	- "Lint clean" → `eslint .` or `ruff check`
39	- "Feature works" → specific test command + manual check
40	- "Bug is fixed" → test that reproduces the original bug
41
42	### Step 2: RUN
43	Execute the complete command. Right now. Fresh. Not from memory or cache.
44
45	Rules:
46	- Run the FULL command, not a subset
47	- Run it in the current state of the code, not from before your changes
48	- Do not use cached results from a previous run
49	- Do not skip the command because "it passed last time"
50
51	### Step 3: READ
52	Read the ENTIRE output. Not just the last line.
53
54	Check:
55	- Exit code (0 = success, non-zero = failure)
56	- Total number of tests (passed, failed, skipped)
57	- Warning messages (warnings can hide real problems)
58	- Specific error messages (not just "X tests passed")
59
60	### Step 4: VERIFY
61	Does the output ACTUALLY confirm the claim?
62
63	Common traps:
64	- "15 tests passed" but 3 were skipped → those 3 might be the important ones
65	- "Build succeeded" but with warnings → warnings might indicate runtime failures
66	- "0 errors" from linter but build still fails → linter ≠ compiler
67	- "Test passed" but the test itself is wrong → test may not test what you think
68
69	### Step 5: CLAIM
70	ONLY NOW may you state that something works, passes, or is done.
71
72	Your claim must include:
73	- The exact command you ran
74	- The key output (pass count, exit code)
75	- Timestamp (when you ran it)
76
77	## Verification Requirements by Claim Type
78
79	\| Claim \| Required Evidence \|
80	\|-------\|-------------------\|
81	\| "Tests pass" \| `0 failures` AND `0 errors` in fresh test run output \|
82	\| "Linter clean" \| `0 errors` AND `0 warnings` in fresh lint output \|
83	\| "Build succeeds" \| Exit code 0 from fresh build command \|
84	\| "Bug is fixed" \| Test reproducing original symptom now passes \|
85	\| "Feature works" \| All acceptance criteria verified with specific evidence \|
86	\| "Story is done" \| ALL of the above that apply + spec compliance review passed \|
87	\| "Typecheck passes" \| Exit code 0 from `tsc --noEmit` or equivalent \|
88
89	## Red Flags -- STOP Immediately
90
91	If you notice ANY of these, you are about to violate the Iron Law:
92
93	### Language Red Flags
94	- Using "should" → "Tests should pass" means you haven't run them
95	- Using "probably" → "This probably works" means you don't know
96	- Using "seems to" → "It seems to be working" means you haven't verified
97	- Using "I believe" → "I believe this is correct" means you're guessing
98	- Using "based on" → "Based on the changes, it should work" means you haven't checked
99
100	### Behavioral Red Flags
101	- Expressing satisfaction before running verification ("Great!", "Perfect!", "Done!")
102	- Trusting a subagent's report without independent verification
103	- Relying on a previous run instead of a fresh one
104	- Checking only part of the test suite
105	- Skipping verification because "the change was small"
106
107	## Anti-Ra

People who liked this also viewed

6 picks

Type