self-test

Name: self-test
Author: minghinmatthewlam

34stars4forks

How to install self-test?

minghinmatthewlam/agent-guards/self-test

$npx -y skills add minghinmatthewlam/agent-guards --skill self-test

Installs into the current project.

Summary

Prove the requested goal works on the highest-signal affected surface before closing. Default closing behavior for every implementation task — not just when explicitly asked. Also triggers on: 'make sure it works', 'test it yourself', 'don't just tell me it's done', 'I don't want

Files · 1

View on GitHub

SKILL.md

1	# Self-Test
2
3	You own verification of the delivered goal. If you can't prove the requested behavior works, it's not done.
4
5	Consider `$ARGUMENTS` if provided.
6
7	## Discover Verification Tools
8
9	Before planning, find what's available to prove the goal on the highest-signal affected surface. Search for test configs, test helpers, build scripts, app launch paths, browser/Electron harnesses, Computer Use skills, and existing specs. If you're missing a tool to reach the surface that matters, tell the user what you need and why — don't silently downgrade to lower-signal proof.
10
11	Missing test structure is usually implementation work, not an excuse to skip verification. When a feature, bug fix, or product change lacks a useful proof lane, add the smallest appropriate test harness, script, fixture, browser check, app smoke path, or artifact capture while you implement. Prefer repo-local repeatable entrypoints such as `scripts/self-test.sh`, existing package scripts, focused tests, or documented Computer Use/browser steps so the next agent can rerun the proof.
12
13	## Before You Code
14
15	- Define concrete, testable success criteria. If ambiguous or below 85% confidence, clarify first.
16	- Name the exact goal surface you'll verify on. The surface is where the requested behavior is consumed, not where the code runs internally. Examples: for desktop/web UI changes -> "the running app with real user interactions through browser automation or Computer Use." For API changes -> "the HTTP endpoint hit by a real client." For CLI changes -> "the command run in a real terminal." For library changes -> "a calling program that exercises the public API."
17	- Name the exact proof path you'll use. This may be commands, test files, browser/Electron automation, Computer Use steps, or a combination. If an existing repeatable test covers the goal surface, name it. If not, plan the smallest proof that can demonstrate the delivered behavior. If you can't reach the surface at all, surface that as a blocker.
18	- Name any missing proof structure you'll add. For new features, this can be a focused unit/contract test, an integration or E2E spec, a local app launch script, a browser/Computer Use smoke, a fixture, or artifact capture. Keep it proportional to the change, but do not leave the repo unable to prove the behavior if you can reasonably add the lane yourself.
19	- Name the proof artifacts you'll create when the surface is visual or interactive. Screenshots prove final visible state; short screen recordings prove multi-step flows, focus behavior, animation, scrolling, or timing. Store them under a durable path such as `/Users/matthewlam/.codex/proofs/<thread-or-task>/<slug>/`.
20	- For new user-facing features, bias toward a real-surface smoke test of the completed workflow using Computer Use, browser automation, or the most product-like harness available. If a human could manually test the workflow on this machine, Computer Use or browser tooling should usually be able to test it too. Use command-line checks as supporting repeatable proof unless the command/API/library is itself the user-facing surface.
21	- Name exact verification blockers early: missing credentials, env vars, test data, local run path, preview/staging access, prod access, hardware, or anything else that prevents real verification.
22
23	## While You Code
24
25	- Use whatever fast tests and checks you need while coding. The skill does not need to prescribe the inner loop.
26	- Build or update the verification lane as part of the implementation when the existing repo cannot prove the new behavior. Examples: add the focused test you need, expose a local script, add fixture data, make the UI flow reachable in a dev build, or save Computer Use/browser artifacts from the real workflow.
27	- If you discover you can't verify the final goal, surface the blocker immediately — what you tried, why it blocks, and the smallest user action that would unblock you.
28
29	## Before You Say Done
30
31	- Run verification that proves the requested goal works on the highest-signal affected surface. Mock-heavy or deterministic suites are not enough for new user-facing behavior unless they exercise that surface.
32	- For user-visible changes, report proof as user action -> visible result. Example: "user types @ in textarea -> popup appears with file list." If your proof doesn't simulate the relevant user action (click, type, keyboard shortcut, paste, HTTP request) and assert or observe the user-visible result (element appears, text changes, response body matches), it's testing plumbing, not product.
33	- Show the exact commands, tool steps, environment, and evidence you used as proof. For Computer Us

People who liked this also viewed

6 picks

Type

self-test

34stars4forks

View on GitHub

How to install self-test?

minghinmatthewlam/agent-guards/self-test

$npx -y skills add minghinmatthewlam/agent-guards --skill self-test

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Self-Test
2
3	You own verification of the delivered goal. If you can't prove the requested behavior works, it's not done.
4
5	Consider `$ARGUMENTS` if provided.
6
7	## Discover Verification Tools
8
9	Before planning, find what's available to prove the goal on the highest-signal affected surface. Search for test configs, test helpers, build scripts, app launch paths, browser/Electron harnesses, Computer Use skills, and existing specs. If you're missing a tool to reach the surface that matters, tell the user what you need and why — don't silently downgrade to lower-signal proof.
10
11	Missing test structure is usually implementation work, not an excuse to skip verification. When a feature, bug fix, or product change lacks a useful proof lane, add the smallest appropriate test harness, script, fixture, browser check, app smoke path, or artifact capture while you implement. Prefer repo-local repeatable entrypoints such as `scripts/self-test.sh`, existing package scripts, focused tests, or documented Computer Use/browser steps so the next agent can rerun the proof.
12
13	## Before You Code
14
15	- Define concrete, testable success criteria. If ambiguous or below 85% confidence, clarify first.
16	- Name the exact goal surface you'll verify on. The surface is where the requested behavior is consumed, not where the code runs internally. Examples: for desktop/web UI changes -> "the running app with real user interactions through browser automation or Computer Use." For API changes -> "the HTTP endpoint hit by a real client." For CLI changes -> "the command run in a real terminal." For library changes -> "a calling program that exercises the public API."
17	- Name the exact proof path you'll use. This may be commands, test files, browser/Electron automation, Computer Use steps, or a combination. If an existing repeatable test covers the goal surface, name it. If not, plan the smallest proof that can demonstrate the delivered behavior. If you can't reach the surface at all, surface that as a blocker.
18	- Name any missing proof structure you'll add. For new features, this can be a focused unit/contract test, an integration or E2E spec, a local app launch script, a browser/Computer Use smoke, a fixture, or artifact capture. Keep it proportional to the change, but do not leave the repo unable to prove the behavior if you can reasonably add the lane yourself.
19	- Name the proof artifacts you'll create when the surface is visual or interactive. Screenshots prove final visible state; short screen recordings prove multi-step flows, focus behavior, animation, scrolling, or timing. Store them under a durable path such as `/Users/matthewlam/.codex/proofs/<thread-or-task>/<slug>/`.
20	- For new user-facing features, bias toward a real-surface smoke test of the completed workflow using Computer Use, browser automation, or the most product-like harness available. If a human could manually test the workflow on this machine, Computer Use or browser tooling should usually be able to test it too. Use command-line checks as supporting repeatable proof unless the command/API/library is itself the user-facing surface.
21	- Name exact verification blockers early: missing credentials, env vars, test data, local run path, preview/staging access, prod access, hardware, or anything else that prevents real verification.
22
23	## While You Code
24
25	- Use whatever fast tests and checks you need while coding. The skill does not need to prescribe the inner loop.
26	- Build or update the verification lane as part of the implementation when the existing repo cannot prove the new behavior. Examples: add the focused test you need, expose a local script, add fixture data, make the UI flow reachable in a dev build, or save Computer Use/browser artifacts from the real workflow.
27	- If you discover you can't verify the final goal, surface the blocker immediately — what you tried, why it blocks, and the smallest user action that would unblock you.
28
29	## Before You Say Done
30
31	- Run verification that proves the requested goal works on the highest-signal affected surface. Mock-heavy or deterministic suites are not enough for new user-facing behavior unless they exercise that surface.
32	- For user-visible changes, report proof as user action -> visible result. Example: "user types @ in textarea -> popup appears with file list." If your proof doesn't simulate the relevant user action (click, type, keyboard shortcut, paste, HTTP request) and assert or observe the user-visible result (element appears, text changes, response body matches), it's testing plumbing, not product.
33	- Show the exact commands, tool steps, environment, and evidence you used as proof. For Computer Us

People who liked this also viewed

6 picks

Type