test

Name: test
Author: avibebuilder

109stars17forks

How to install test?

avibebuilder/claude-prime/test

$npx -y skills add avibebuilder/claude-prime --skill test

Installs into the current project.

Summary

Use when the user wants to know if something works — the answer requires running code, not analyzing it. Output is a verdict backed by evidence: passed, failed, or broken. Primary triggers: 'run the tests', 'does X still work after my change?', 'did the merge break anything?', 'v

Files · 1

View on GitHub

SKILL.md

1	## Route fast
2
3	\| Situation \| Steps \|
4	\| --- \| --- \|
5	\| `run tests` or a specific test path \| 3 → 5 → 6 \|
6	\| The verification claim is already clear from the request or recent context \| 4 → 5 → 6 \|
7	\| Behavioral claim but no tests exist \| 1 → 4 manual path → 5 → 6 \|
8	\| Vague claim or broad change \| Full flow \|
9
10	Skip steps whose answers are already known from the conversation.
11
12	## Flow
13
14	### 1. Define the claim
15
16	Figure out what must be true before running anything.
17
18	Possible sources:
19	- explicit argument
20	- stated request or acceptance criteria
21	- recent conversation
22	- recent diff or git status as fallback
23
24	Good claim: `expired tokens return 401`.
25	Bad claim: `the app works`.
26
27	If the claim is mushy, sharpen it before you touch the tools. Weak claims create noisy verification.
28
29	### 2. Scope only when needed
30
31	Skip if the claim is already scoped.
32
33	Use the change set to identify:
34	- deliverables — what must hold true
35	- coverage — what existing tests or manual checks could prove each deliverable
36	- blast radius — what nearby behavior could regress
37
38	For shared code, config, auth, schema, or similar cross-cutting changes, read `references/regression-strategy.md` before deciding how wide to test.
39
40	### 3. Find the project's real test entrypoints
41
42	Check in this order:
43	1. `CLAUDE.md`
44	2. `package.json`, `Makefile`, `justfile`, `Taskfile`
45	3. CI config
46	4. test framework config
47	5. existing test layout
48
49	Prefer project-defined commands over raw framework commands.
50
51	### 4. Choose the proof lane
52
53	Match the claim to the execution lane.
54
55	\| Claim type \| Lane \|
56	\| --- \| --- \|
57	\| logic, transforms, business rules \| direct tests \|
58	\| API behavior or contracts \| backend verification \|
59	\| UI behavior or rendering \| frontend verification \|
60	\| visual UI criteria \| frontend visual verification \|
61	\| DB persistence \| backend verification \|
62	\| CLI behavior \| direct command verification \|
63	\| type or schema correctness \| direct static verification \|
64	\| compile/build correctness \| direct static/build verification \|
65
66	Once you've picked a lane, read the relevant reference before executing. Let the reference own the execution details.
67
68	## Reference map
69
70	- `references/backend-verification.md` — API, DB, services, and background jobs
71	- `references/frontend-verification.md` — browser, component, and visual verification
72	- `references/regression-strategy.md` — how wide to test once the main claim is proven
73
74	The right method is the one that can disprove the claim fastest without pretending to offer more confidence than it really does.
75
76	If no relevant tests exist, use a manual path instead of calling the result inconclusive. Follow the selected lane's reference rather than rebuilding the checklist inline.
77
78	For command-line claims, run the command and inspect output directly.
79
80	Keep these guardrails in mind:
81	- once a lane is chosen, follow its reference instead of rebuilding the same checklist inline
82	- keep verification outcome-first: prove the user-visible or system-visible result, not just an intermediate action
83	- when regression is warranted, widen in rings: direct dependents → feature area → full suite
84
85	Only use INCONCLUSIVE when neither an automated path nor a manual path is feasible.
86
87	### 5. Pre-flight and execute
88
89	Before running verification, confirm required infra is already available. If a server, DB, queue worker, mock service, or migration is needed and not running, stop and tell the user the exact command to start it. Do not start it yourself.
90
91	When you run verification, capture evidence:
92	- exact command
93	- exit code
94	- relevant output
95	- non-zero test count when a suite was run
96	- warnings, skipped tests, and flaky behavior that matter to the claim
97
98	Start with the most direct proof. Expand into broader regression only when the blast radius justifies it.
99
100	### 6. Report
101
102	Use this structure:
103
104	```md
105	## Verification Report
106
107	Claim: {what was tested}
108	Verdict: CONFIRMED \| REFUTED \| PARTIAL \| INCONCLUSIVE
109
110	### Evidence
111	- {command}: exit {code} — proves or refutes {deliverable}
112
113	### Failures
114	- {test

People who liked this also viewed

6 picks

Type

test

109stars17forks

View on GitHub

How to install test?

avibebuilder/claude-prime/test

$npx -y skills add avibebuilder/claude-prime --skill test

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Route fast
2
3	\| Situation \| Steps \|
4	\| --- \| --- \|
5	\| `run tests` or a specific test path \| 3 → 5 → 6 \|
6	\| The verification claim is already clear from the request or recent context \| 4 → 5 → 6 \|
7	\| Behavioral claim but no tests exist \| 1 → 4 manual path → 5 → 6 \|
8	\| Vague claim or broad change \| Full flow \|
9
10	Skip steps whose answers are already known from the conversation.
11
12	## Flow
13
14	### 1. Define the claim
15
16	Figure out what must be true before running anything.
17
18	Possible sources:
19	- explicit argument
20	- stated request or acceptance criteria
21	- recent conversation
22	- recent diff or git status as fallback
23
24	Good claim: `expired tokens return 401`.
25	Bad claim: `the app works`.
26
27	If the claim is mushy, sharpen it before you touch the tools. Weak claims create noisy verification.
28
29	### 2. Scope only when needed
30
31	Skip if the claim is already scoped.
32
33	Use the change set to identify:
34	- deliverables — what must hold true
35	- coverage — what existing tests or manual checks could prove each deliverable
36	- blast radius — what nearby behavior could regress
37
38	For shared code, config, auth, schema, or similar cross-cutting changes, read `references/regression-strategy.md` before deciding how wide to test.
39
40	### 3. Find the project's real test entrypoints
41
42	Check in this order:
43	1. `CLAUDE.md`
44	2. `package.json`, `Makefile`, `justfile`, `Taskfile`
45	3. CI config
46	4. test framework config
47	5. existing test layout
48
49	Prefer project-defined commands over raw framework commands.
50
51	### 4. Choose the proof lane
52
53	Match the claim to the execution lane.
54
55	\| Claim type \| Lane \|
56	\| --- \| --- \|
57	\| logic, transforms, business rules \| direct tests \|
58	\| API behavior or contracts \| backend verification \|
59	\| UI behavior or rendering \| frontend verification \|
60	\| visual UI criteria \| frontend visual verification \|
61	\| DB persistence \| backend verification \|
62	\| CLI behavior \| direct command verification \|
63	\| type or schema correctness \| direct static verification \|
64	\| compile/build correctness \| direct static/build verification \|
65
66	Once you've picked a lane, read the relevant reference before executing. Let the reference own the execution details.
67
68	## Reference map
69
70	- `references/backend-verification.md` — API, DB, services, and background jobs
71	- `references/frontend-verification.md` — browser, component, and visual verification
72	- `references/regression-strategy.md` — how wide to test once the main claim is proven
73
74	The right method is the one that can disprove the claim fastest without pretending to offer more confidence than it really does.
75
76	If no relevant tests exist, use a manual path instead of calling the result inconclusive. Follow the selected lane's reference rather than rebuilding the checklist inline.
77
78	For command-line claims, run the command and inspect output directly.
79
80	Keep these guardrails in mind:
81	- once a lane is chosen, follow its reference instead of rebuilding the same checklist inline
82	- keep verification outcome-first: prove the user-visible or system-visible result, not just an intermediate action
83	- when regression is warranted, widen in rings: direct dependents → feature area → full suite
84
85	Only use INCONCLUSIVE when neither an automated path nor a manual path is feasible.
86
87	### 5. Pre-flight and execute
88
89	Before running verification, confirm required infra is already available. If a server, DB, queue worker, mock service, or migration is needed and not running, stop and tell the user the exact command to start it. Do not start it yourself.
90
91	When you run verification, capture evidence:
92	- exact command
93	- exit code
94	- relevant output
95	- non-zero test count when a suite was run
96	- warnings, skipped tests, and flaky behavior that matter to the claim
97
98	Start with the most direct proof. Expand into broader regression only when the blast radius justifies it.
99
100	### 6. Report
101
102	Use this structure:
103
104	```md
105	## Verification Report
106
107	Claim: {what was tested}
108	Verdict: CONFIRMED \| REFUTED \| PARTIAL \| INCONCLUSIVE
109
110	### Evidence
111	- {command}: exit {code} — proves or refutes {deliverable}
112
113	### Failures
114	- {test

People who liked this also viewed

6 picks

Type