strict-enforcement

Name: strict-enforcement
Author: elb-pr

126stars7forks

How to install strict-enforcement?

elb-pr/claudikins-kernel/strict-enforcement

$npx -y skills add elb-pr/claudikins-kernel --skill strict-enforcement

Installs into the current project.

Summary

Use when running claudikins-kernel:verify, checking implementation quality, deciding pass/fail verdicts, or enforcing cross-command gates — requires actual evidence of code working, not just passing tests

Files · 1

View on GitHub

SKILL.md

1	# Strict Enforcement Verification Methodology
2
3	## When to use this skill
4
5	Use this skill when you need to:
6
7	- Run the `claudikins-kernel:verify` command
8	- Validate implementation before shipping
9	- Decide pass/fail verdicts
10	- Check code integrity after changes
11	- Enforce cross-command gates
12
13	## Core Philosophy
14
15	> "Evidence before assertions. Always." - Verification philosophy
16
17	Never claim code works without seeing it work. Tests passing is not enough. Claude must SEE the output.
18
19	### The Three Laws
20
21	1. See it working - Screenshots, curl responses, CLI output. Actual evidence.
22	2. Human checkpoint - No auto-shipping. Human reviews evidence and decides.
23	3. Exit code 2 gates - Verification failures block claudikins-kernel:ship. No exceptions.
24
25	## Verification Phases
26
27	### Phase 1: Automated Quality Checks
28
29	Run the automated checks first. Fast feedback.
30
31	\| Check \| Command Pattern \| What It Catches \|
32	\| ----- \| ------------------------------------ \| ----------------------------------- \|
33	\| Tests \| `npm test` / `pytest` / `cargo test` \| Logic errors, regressions \|
34	\| Lint \| `npm run lint` / `ruff` / `clippy` \| Style issues, common bugs \|
35	\| Types \| `tsc` / `mypy` / `cargo check` \| Type mismatches, interface drift \|
36	\| Build \| `npm run build` / `cargo build` \| Compilation errors, bundling issues \|
37
38	Flaky Test Detection (C-12):
39
40	```
41	Test fails?
42	├── Re-run failed tests
43	├── Pass 2nd time?
44	│ └── Yes → STOP: [Accept flakiness] [Fix tests] [Abort]
45	└── Fail 2nd time?
46	├── Run isolated
47	└── Still fail? → STOP: [Fix] [Skip] [Abort]
48	```
49
50	### Phase 2: Output Verification (catastrophiser)
51
52	This is the feedback loop that makes Claude's code actually work.
53
54	\| Project Type \| Verification Method \| Evidence \|
55	\| ------------ \| ------------------------------------ \| ------------------------------ \|
56	\| Web app \| Start server, screenshot, test flows \| Screenshots, console logs \|
57	\| API \| Curl endpoints, check responses \| Status codes, response bodies \|
58	\| CLI \| Run commands, capture output \| stdout, stderr, exit codes \|
59	\| Library \| Run examples, check results \| Output values, test coverage \|
60	\| Service \| Check logs, verify health endpoint \| Log patterns, health responses \|
61
62	Fallback Hierarchy (A-3):
63
64	If primary method unavailable, fall back:
65
66	1. Start server + screenshot (preferred for web)
67	2. Curl endpoints (preferred for API)
68	3. Run CLI commands (preferred for CLI)
69	4. Run tests only (fallback)
70	5. Code review only (last resort)
71
72	Timeout: 30 seconds per verification method (CMD-30).
73
74	### Phase 3: Code Simplification (Optional)
75
76	After verification passes, optionally run cynic for polish.
77
78	Prerequisites:
79
80	- Phase 2 (catastrophiser) must PASS
81	- Human approves: "Run cynic for polish pass?"
82
83	cynic Rules:
84
85	- Preserve exact behaviour (tests MUST still pass)
86	- Remove unnecessary abstraction
87	- Improve naming clarity
88	- Delete dead code
89	- Flatten nested conditionals
90
91	If tests fail after simplification:
92
93	- Log failure reasons
94	- Show human
95	- Proceed anyway (A-5) with caveat
96
97	See [cynic-rollback.md](references/cynic-rollback.md) for recovery patterns.
98
99	### Phase 4: Klaus Escalation
100
101	If stuck during verification:
102
103	```
104	Is mcp__claudikins-klaus available? (E-16)
105	├── No →
106	│ Offer: [Manual review] [Ask Claude differently] (E-17)
107	│ Fallback: [Accept with uncertainty] [Max retries, abort] (E-18)
108	└── Yes →
109	Spawn klaus via SubagentStop hook
110	```
111
112	### Phase 5: Human Checkpoint
113
114	The final gate. Present comprehensive evidence.
115
116	```
117	Verification Report
118	-------------------
119	Tests: ✓ 47/47 passed
120	Lint: ✓ 0 issues
121	Types: ✓ 0 errors
122	Build: ✓ success
123
124	Evidence:
125	- Screenshot: .claude/evidence/login-flow.png
126	- API test: POST /api/auth → 200 OK
127	- CLI test: mycli --help → exit 0
128
129	[Ready to Ship] [Needs Work] [Accept with Caveats]
130	```
131
132	Human decides. If approved, set `unlock_ship = true`.
133
134	## Rationalizations to Resist
135
136	Agents under pressure find excuses. These are all violations:
137
138	\| Excuse \| Reality \|
139	\| ------------------------------------------ \| --------------------------------------------------------------------- \|
140	\| "Tests pass, that's good enough" \| Tests aren't enough. SEE it working. Screenshots, curl, outpu

People who liked this also viewed

6 picks

Type

strict-enforcement

126stars7forks

View on GitHub

How to install strict-enforcement?

elb-pr/claudikins-kernel/strict-enforcement

$npx -y skills add elb-pr/claudikins-kernel --skill strict-enforcement

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Strict Enforcement Verification Methodology
2
3	## When to use this skill
4
5	Use this skill when you need to:
6
7	- Run the `claudikins-kernel:verify` command
8	- Validate implementation before shipping
9	- Decide pass/fail verdicts
10	- Check code integrity after changes
11	- Enforce cross-command gates
12
13	## Core Philosophy
14
15	> "Evidence before assertions. Always." - Verification philosophy
16
17	Never claim code works without seeing it work. Tests passing is not enough. Claude must SEE the output.
18
19	### The Three Laws
20
21	1. See it working - Screenshots, curl responses, CLI output. Actual evidence.
22	2. Human checkpoint - No auto-shipping. Human reviews evidence and decides.
23	3. Exit code 2 gates - Verification failures block claudikins-kernel:ship. No exceptions.
24
25	## Verification Phases
26
27	### Phase 1: Automated Quality Checks
28
29	Run the automated checks first. Fast feedback.
30
31	\| Check \| Command Pattern \| What It Catches \|
32	\| ----- \| ------------------------------------ \| ----------------------------------- \|
33	\| Tests \| `npm test` / `pytest` / `cargo test` \| Logic errors, regressions \|
34	\| Lint \| `npm run lint` / `ruff` / `clippy` \| Style issues, common bugs \|
35	\| Types \| `tsc` / `mypy` / `cargo check` \| Type mismatches, interface drift \|
36	\| Build \| `npm run build` / `cargo build` \| Compilation errors, bundling issues \|
37
38	Flaky Test Detection (C-12):
39
40	```
41	Test fails?
42	├── Re-run failed tests
43	├── Pass 2nd time?
44	│ └── Yes → STOP: [Accept flakiness] [Fix tests] [Abort]
45	└── Fail 2nd time?
46	├── Run isolated
47	└── Still fail? → STOP: [Fix] [Skip] [Abort]
48	```
49
50	### Phase 2: Output Verification (catastrophiser)
51
52	This is the feedback loop that makes Claude's code actually work.
53
54	\| Project Type \| Verification Method \| Evidence \|
55	\| ------------ \| ------------------------------------ \| ------------------------------ \|
56	\| Web app \| Start server, screenshot, test flows \| Screenshots, console logs \|
57	\| API \| Curl endpoints, check responses \| Status codes, response bodies \|
58	\| CLI \| Run commands, capture output \| stdout, stderr, exit codes \|
59	\| Library \| Run examples, check results \| Output values, test coverage \|
60	\| Service \| Check logs, verify health endpoint \| Log patterns, health responses \|
61
62	Fallback Hierarchy (A-3):
63
64	If primary method unavailable, fall back:
65
66	1. Start server + screenshot (preferred for web)
67	2. Curl endpoints (preferred for API)
68	3. Run CLI commands (preferred for CLI)
69	4. Run tests only (fallback)
70	5. Code review only (last resort)
71
72	Timeout: 30 seconds per verification method (CMD-30).
73
74	### Phase 3: Code Simplification (Optional)
75
76	After verification passes, optionally run cynic for polish.
77
78	Prerequisites:
79
80	- Phase 2 (catastrophiser) must PASS
81	- Human approves: "Run cynic for polish pass?"
82
83	cynic Rules:
84
85	- Preserve exact behaviour (tests MUST still pass)
86	- Remove unnecessary abstraction
87	- Improve naming clarity
88	- Delete dead code
89	- Flatten nested conditionals
90
91	If tests fail after simplification:
92
93	- Log failure reasons
94	- Show human
95	- Proceed anyway (A-5) with caveat
96
97	See [cynic-rollback.md](references/cynic-rollback.md) for recovery patterns.
98
99	### Phase 4: Klaus Escalation
100
101	If stuck during verification:
102
103	```
104	Is mcp__claudikins-klaus available? (E-16)
105	├── No →
106	│ Offer: [Manual review] [Ask Claude differently] (E-17)
107	│ Fallback: [Accept with uncertainty] [Max retries, abort] (E-18)
108	└── Yes →
109	Spawn klaus via SubagentStop hook
110	```
111
112	### Phase 5: Human Checkpoint
113
114	The final gate. Present comprehensive evidence.
115
116	```
117	Verification Report
118	-------------------
119	Tests: ✓ 47/47 passed
120	Lint: ✓ 0 issues
121	Types: ✓ 0 errors
122	Build: ✓ success
123
124	Evidence:
125	- Screenshot: .claude/evidence/login-flow.png
126	- API test: POST /api/auth → 200 OK
127	- CLI test: mycli --help → exit 0
128
129	[Ready to Ship] [Needs Work] [Accept with Caveats]
130	```
131
132	Human decides. If approved, set `unlock_ship = true`.
133
134	## Rationalizations to Resist
135
136	Agents under pressure find excuses. These are all violations:
137
138	\| Excuse \| Reality \|
139	\| ------------------------------------------ \| --------------------------------------------------------------------- \|
140	\| "Tests pass, that's good enough" \| Tests aren't enough. SEE it working. Screenshots, curl, outpu

People who liked this also viewed

6 picks

Type