verification

Name: verification
Author: fusengine

21stars3forks

How to install verification?

fusengine/agents/verification

$npx -y skills add fusengine/agents --skill verification

Installs into the current project.

Summary

Use when marking a task as complete, finishing a feature, or claiming a bug is fixed. Ensures functional resolution is verified with evidence before closing. Do NOT use for: lint/type/code-quality validation (use code-quality / sniper AFTER functional verification passes).

Files · 1

View on GitHub

SKILL.md

1	# Verification Before Completion
2
3	## Overview
4
5	Sniper validates CODE QUALITY. Verification validates FUNCTIONAL RESOLUTION. Both are needed before closing any task.
6
7	Sniper catches linter errors, SOLID violations, and code style issues. Verification ensures the original request is actually fulfilled -- the right behavior, the right output, the right fix. A task can pass sniper with zero errors and still be functionally wrong.
8
9	\| Aspect \| Sniper \| Verification \|
10	\|--------\|--------\|-------------\|
11	\| Focus \| Code quality \| Functional correctness \|
12	\| Checks \| Linting, SOLID, style \| Acceptance criteria, regressions, side effects \|
13	\| Runs \| After any code change \| Before marking task as complete \|
14	\| Result \| Clean code \| Solved problem \|
15
16	---
17
18	## Agent Workflow
19
20	When invoked, follow the 6-step verification process below before marking any task as completed.
21
22	### 6-Step Verification Process
23
24	Step 1: Re-read the original request
25	Go back to the original issue, task description, or user message. Read it word by word. Do not rely on memory or assumptions.
26
27	Step 2: List ALL acceptance criteria
28	Extract every explicit and implicit requirement from the original request. Number them. If the request is vague, list what a reasonable user would expect.
29
30	Step 3: Verify each criterion with evidence
31	For each criterion, provide concrete evidence of resolution:
32	- Test output showing the expected behavior
33	- Log output confirming the fix
34	- Screenshot of the UI change
35	- Code diff showing the implementation
36
37	Step 4: Check for regressions
38	Run the full test suite. Compare results before and after. No new failures, no new warnings.
39
40	Step 5: Check for side effects
41	Review every modified file. Confirm no accidental changes to unrelated code. Verify dependencies and configuration are unchanged unless required.
42
43	Step 6: Confirm functional resolution -- challenge, then write the artifact
44	Before writing "Original problem is FUNCTIONALLY resolved," ALWAYS route the claim through the `challenger` agent (or `challenge` skill), fresh-context: claim = "functionally resolved" + evidence from Steps 3-5, NEVER the investigation reasoning. This is systematic -- every Verify gate, no exception, exactly like sniper runs at every eXamine. Only write the "FUNCTIONALLY resolved" verdict after a `CONFIRMED` result (or an `UNCERTAIN` explicitly accepted by the owner). A `REFUTED` verdict must be resolved (fix and re-verify) before the claim reaches the owner -- soft-gate, not a hard veto.
45
46	Write `.claude/apex/docs/verify-{task-slug}.md` (template: `references/verify-template.md`): every verification step checked, one evidence item per criterion (command output, log excerpt, screenshot path, or diff), plus the challenge verdict from this step. A context-only "it works" declaration does not survive a session boundary; the written artifact is the guardrail gates (sniper, later elicitation passes) actually check. Then state explicitly in your response: "Original problem is FUNCTIONALLY resolved" with a summary of evidence, or list what remains unresolved.
47
48	`{task-slug}`: derive per `apex-methodology/references/init-tracking.md` (git branch slug or active `TaskCreate` id) -- same pattern used by the `elicitation` skill's artifact.
49
50	---
51
52	## Reference Guide
53
54	\| Resource \| Path \| Content \|
55	\|----------\|------\|---------\|
56	\| Checklist \| `references/checklist.md` \| Full verification checklist with all categories \|
57	\| Common Misses \| `references/common-misses.md` \| Frequently forgotten verification items \|
58	\| Artifact Template \| `references/verify-template.md` \| `verify-{task-slug}.md` template + task-slug derivation \|
59
60	---
61
62	## Integration with APEX
63
64	Verification runs between eLicit and eXamine in the APEX workflow:
65
66	```
67	Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)
68	```
69
70	This ensures functional correctness is confirmed before code quality validation. A task is only complete when both verification and sniper pass.
71
72	---
73
74	## Critical Rules
75
76	\| Rule \| Reason \|
77	\|------\|--------\|
78	\| Never skip re-reading the original request \| Prevents solving the wrong problem \|
79	\| Evidence required for every criterion \| "It works" is not evidence \|
80	\| Full test suite, not just new tests \| Catches regressions \|
81	\| Review ALL modified files \| Catches accidental side effects \|
82	\| Both verification AND sniper must pass \| Quality without correctness is useless \|
83	\| Step 6 writes `verify-{task-slug}.md` to disk \| In-context self-review without persisted state regresses across sessions \|

People who liked this also viewed

6 picks

Type

verification

21stars3forks

View on GitHub

How to install verification?

fusengine/agents/verification

$npx -y skills add fusengine/agents --skill verification

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Verification Before Completion
2
3	## Overview
4
5	Sniper validates CODE QUALITY. Verification validates FUNCTIONAL RESOLUTION. Both are needed before closing any task.
6
7	Sniper catches linter errors, SOLID violations, and code style issues. Verification ensures the original request is actually fulfilled -- the right behavior, the right output, the right fix. A task can pass sniper with zero errors and still be functionally wrong.
8
9	\| Aspect \| Sniper \| Verification \|
10	\|--------\|--------\|-------------\|
11	\| Focus \| Code quality \| Functional correctness \|
12	\| Checks \| Linting, SOLID, style \| Acceptance criteria, regressions, side effects \|
13	\| Runs \| After any code change \| Before marking task as complete \|
14	\| Result \| Clean code \| Solved problem \|
15
16	---
17
18	## Agent Workflow
19
20	When invoked, follow the 6-step verification process below before marking any task as completed.
21
22	### 6-Step Verification Process
23
24	Step 1: Re-read the original request
25	Go back to the original issue, task description, or user message. Read it word by word. Do not rely on memory or assumptions.
26
27	Step 2: List ALL acceptance criteria
28	Extract every explicit and implicit requirement from the original request. Number them. If the request is vague, list what a reasonable user would expect.
29
30	Step 3: Verify each criterion with evidence
31	For each criterion, provide concrete evidence of resolution:
32	- Test output showing the expected behavior
33	- Log output confirming the fix
34	- Screenshot of the UI change
35	- Code diff showing the implementation
36
37	Step 4: Check for regressions
38	Run the full test suite. Compare results before and after. No new failures, no new warnings.
39
40	Step 5: Check for side effects
41	Review every modified file. Confirm no accidental changes to unrelated code. Verify dependencies and configuration are unchanged unless required.
42
43	Step 6: Confirm functional resolution -- challenge, then write the artifact
44	Before writing "Original problem is FUNCTIONALLY resolved," ALWAYS route the claim through the `challenger` agent (or `challenge` skill), fresh-context: claim = "functionally resolved" + evidence from Steps 3-5, NEVER the investigation reasoning. This is systematic -- every Verify gate, no exception, exactly like sniper runs at every eXamine. Only write the "FUNCTIONALLY resolved" verdict after a `CONFIRMED` result (or an `UNCERTAIN` explicitly accepted by the owner). A `REFUTED` verdict must be resolved (fix and re-verify) before the claim reaches the owner -- soft-gate, not a hard veto.
45
46	Write `.claude/apex/docs/verify-{task-slug}.md` (template: `references/verify-template.md`): every verification step checked, one evidence item per criterion (command output, log excerpt, screenshot path, or diff), plus the challenge verdict from this step. A context-only "it works" declaration does not survive a session boundary; the written artifact is the guardrail gates (sniper, later elicitation passes) actually check. Then state explicitly in your response: "Original problem is FUNCTIONALLY resolved" with a summary of evidence, or list what remains unresolved.
47
48	`{task-slug}`: derive per `apex-methodology/references/init-tracking.md` (git branch slug or active `TaskCreate` id) -- same pattern used by the `elicitation` skill's artifact.
49
50	---
51
52	## Reference Guide
53
54	\| Resource \| Path \| Content \|
55	\|----------\|------\|---------\|
56	\| Checklist \| `references/checklist.md` \| Full verification checklist with all categories \|
57	\| Common Misses \| `references/common-misses.md` \| Frequently forgotten verification items \|
58	\| Artifact Template \| `references/verify-template.md` \| `verify-{task-slug}.md` template + task-slug derivation \|
59
60	---
61
62	## Integration with APEX
63
64	Verification runs between eLicit and eXamine in the APEX workflow:
65
66	```
67	Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)
68	```
69
70	This ensures functional correctness is confirmed before code quality validation. A task is only complete when both verification and sniper pass.
71
72	---
73
74	## Critical Rules
75
76	\| Rule \| Reason \|
77	\|------\|--------\|
78	\| Never skip re-reading the original request \| Prevents solving the wrong problem \|
79	\| Evidence required for every criterion \| "It works" is not evidence \|
80	\| Full test suite, not just new tests \| Catches regressions \|
81	\| Review ALL modified files \| Catches accidental side effects \|
82	\| Both verification AND sniper must pass \| Quality without correctness is useless \|
83	\| Step 6 writes `verify-{task-slug}.md` to disk \| In-context self-review without persisted state regresses across sessions \|

People who liked this also viewed

6 picks

Type