liuqi1024liuqi1024/matrix-boot/skills/implementation-verification/SKILL.md

implementation-verification

Skill1 starsChanged 5 months agoMITView on GitHub

Verify generated or modified application code with reproducible build, test, runtime, browser, API, console, and network checks. Use after code generation or bug fixes, especially for web UI login flows, forms, dashboards, frontend/backend integration, local dev servers, and claims that implementation is complete or tested.

1 other project uses a version of this.

Adopted by

Most recently taken up by

ufukyuksel-dev/SUPER_COMPUTER_AItheir own version, first seen Nov 1, 2026

Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
ufukyuksel-dev/SUPER_COMPUTER_AI★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- api-db-designSkill
- architecture-designSkill
- frontend-design-guideSkill
- integration-test-guideSkill
- project-guideSkill
- requirements-designSkill
- tech-stack-designSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. About 0 are common, 11 are distinctive, and 6 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Use this skill after code generation or code modification to verify that the implementation actually works.
line 12
Very specific:
Before code verification, check that upstream implementation-driving artifacts were approved by the user.
line 14
Very specific:
If any check is not run, say not verified for that check and explain why.
line 33
Distinctive:
Ensure corresponding unit test code exists or is updated.
line 40
Very specific:
Run compile/build/typecheck/lint/unit tests where available.
line 41
Distinctive:
Start required services or dev servers.
line 42
Distinctive:
Check browser console errors.
line 45
Distinctive:
Check failed network requests and API response status.
line 46
Distinctive:
Do not require unit tests for pure configuration, generated DTOs without logic, trivial constants, or visual-only markup unless behavior is …
line 70
Very specific:
If unit tests cannot be added or run, mark the unit test gate as not verified and explain the blocker.
line 72
Distinctive:
No blocking console errors exist.
line 82
Distinctive:
If login is involved, do not mark the feature complete until login succeeds in the browser or the exact blocker is documented.
line 87
Distinctive:
Use the best available browser verification tool:
line 91
Very specific:
If no browser tool exists, generate a Playwright smoke test and instruct the user to run it.
line 95
Distinctive:
Do not hide failures behind optimistic wording.
line 123
Distinctive:
After producing the implementation verification report, stop and request explicit user review.
line 125
Very specific:
Use references/web-verification-checklist.md for the default browser and API smoke checklist.
line 129

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Implementation Verification

Purpose

Use this skill after code generation or code modification to verify that the implementation actually works. Do not accept visual inspection, static reasoning, or "should work" statements as proof.

Before code verification, check that upstream implementation-driving artifacts were approved by the user. If API/database/design artifacts are still drafts, report that implementation should not have started and ask whether to review the drafts first.

Verification Standard

The agent may say "verified" only after it has recorded reproducible evidence:

Exact commands executed.
Build/test/lint results.
Unit test files created or updated for new/changed logic.
Unit test command results.
Runtime startup result and URL.
Browser or API smoke test result for critical flows.
Console errors checked.
Network/API failures checked.
Screenshots or trace artifacts when available.
Remaining gaps or skipped checks.

If any check is not run, say not verified for that check and explain why.

Required Workflow

Inspect project structure and package/build files.
Identify how to start backend and frontend.
Identify new or changed implementation logic.
Ensure corresponding unit test code exists or is updated.
Run compile/build/typecheck/lint/unit tests where available.
Start required services or dev servers.
For web UI, open the app with a browser automation tool.
Exercise the critical user journey, not only the homepage.
Check browser console errors.
Check failed network requests and API response status.
Fix blocking issues and repeat failed checks.
Report evidence and unresolved risks.
Store raw verification output under the approved reports path, defaulting to reports/verification/, not under scripts/ or the repository root.

Unit Test Requirements

For generated or modified code, require unit tests for:

Backend service/business logic.
Validation and error handling logic.
Permission/security decision logic.
Data mapping or conversion logic.
Frontend composables/hooks/state utilities.
Non-trivial frontend form validation or data transformation.
Reusable utility functions.

Default test choices:

Java/Spring: JUnit 5, AssertJ, Mockito, Spring Boot Test only when Spring context is actually needed.
Frontend: Vitest/Jest plus Testing Library where applicable.

Do not require unit tests for pure configuration, generated DTOs without logic, trivial constants, or visual-only markup unless behavior is involved.

If unit tests cannot be added or run, mark the unit test gate as not verified and explain the blocker. Do not mark implementation complete.

Web UI Smoke Checks

For any web page or frontend feature, verify:

Page loads without blank screen.
Main route renders expected content.
Login or primary form can be completed with known test credentials or seed data.
Backend API calls return expected status.
No blocking console errors exist.
Navigation after the action works.
Auth/session state is persisted as expected.
Refresh does not break the route.

If login is involved, do not mark the feature complete until login succeeds in the browser or the exact blocker is documented.

Browser Tool Policy

Use the best available browser verification tool:

In Codex, prefer the Browser plugin or available browser automation tool for localhost/file targets.
In Claude Code, prefer Playwright MCP, Chrome DevTools MCP, or the browser automation tool configured in that environment.
If no browser tool exists, generate a Playwright smoke test and instruct the user to run it; mark browser verification as not verified.

API Verification

For backend/API work, verify:

Application starts with the selected profile.
Health endpoint or base API route responds.
Auth endpoints work with test credentials or seeded users.
CRUD happy path works for at least one core entity.
Validation failure returns the expected error shape.
Unauthorized access is rejected.

Evidence Report

Always end with:

Verified: checks that passed with command/tool evidence.
Failed: checks that failed and the exact error.
Not verified: checks that could not be run.
Unit tests: files added/updated and command results.
Fixes applied: changes made after failures.
Next action: the smallest remaining action.

Record the report in docs/06-verification/implementation-verification.md or the approved equivalent path.

Store screenshots, browser traces, console/network exports, server logs, and other raw evidence under reports/verification/ or the approved equivalent path. Do not leave transient logs in the repository root.

Do not hide failures behind optimistic wording.

After producing the implementation verification report, stop and request explicit user review. Do not proceed to integration testing, performance testing, or release readiness until the user approves the verification artifact or asks for fixes.

References

Use references/web-verification-checklist.md for the default browser and API smoke checklist.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free