datashaman/skills/verify
skills/verify/SKILL.md
--- ## name: verify description: Run the project’s quality gates, map results to spec acceptance criteria, and produce verification_report.json with evidence and severities. # Verify ### When to use - Verifier Agent after a change is claimed ready for review. - You need a **pass/fail** tied to evidence, not gut feel. ### Part A — Automated gates (use the repo’s real commands) Run what this repository already defines (examples—substitute from `package.json` scripts, `Makefile`, CI config):
testing
Updated Apr 20, 2026
$ install --global
skillsauthnpx skillsauth add datashaman/agentfiles skills/verifyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 20, 2026, 3:00 PM11.9s1 file scanned
SKILL.md
name: verify
description: Run the project’s quality gates, map results to spec acceptance criteria, and produce verification_report.json with evidence and severities.
Verify
When to use
- Verifier Agent after a change is claimed ready for review.
- You need a pass/fail tied to evidence, not gut feel.
Part A — Automated gates (use the repo’s real commands)
Run what this repository already defines (examples—substitute from package.json scripts, Makefile, CI config):
| Layer | Typical commands (pick what exists) |
| ----- | ---------------------------------------------------------------------------------------------------------------- |
| Lint | npm run lint, ruff check, php -d detect_unicode=0 $(which php-cs-fixer) fix --dry-run, golangci-lint run |
| Types | npm run typecheck, tsc --noEmit, phpstan, mypy |
| Tests | npm test, php artisan test, pytest -q, go test ./... |
Record in verification_report.json → checks: pass | fail | not_run (only use not_run if the project truly has no check; say why in a finding).
Part B — Spec coverage matrix
- Open
spec.json→acceptance_criteria. - For each AC id, list evidence:
- test name + file, or
- manual repro steps + screenshot/log (if no test yet—flag as risk).
- Any AC with no evidence → finding (usually high until tests exist for must-have behavior).
Part C — Severity rubric (use in every finding)
| Level | Meaning | Example | | ------------ | ---------------------------------------------------- | ------------------------------------- | | critical | Security hole, data loss, auth bypass, payment wrong | Missing auth check on mutating route | | high | Wrong behavior vs spec, crash on main path, CI red | AC fails, 500 on happy path | | medium | Edge case, flaky test, incomplete error handling | Wrong message body, race in rare case | | low | Polish, copy, minor a11y | Typo in validation message |
Every finding needs **owner** (team or role), **impact**, **evidence**, **remediation**.
Output
verification_report.json:status,build_ref,checks,findings,metadata(see schema).
Anti-patterns
- “Looks fine” without AC → evidence mapping.
- Downgrading high to please schedule—severity describes user/system risk, not comfort.
Related Skills
datashaman/skills/specify
development
VerifiedTrustedCommunity
--- ## name: specify description: Turn a GitHub issue, ticket, or chat into scope, testable acceptance criteria, and concrete API/data/UI contracts for spec.json. Stop and consult the human stakeholder whenever anything is ambiguous or the source material is broken—never guess. Use before any implementation. # Specify ### When to use - Spec Agent (or anyone) must produce `spec.json` from messy input. - You need a **single source of truth** for what “done” means before code changes. ### Con
SKILL.mdUpdated Apr 20, 2026
datashaman/skills/ship
testing
VerifiedTrustedCommunity
--- ## name: ship description: Cut a versioned release, run CI/deploy with health verification, and document rollback—output release_report.json aligned to your platform (Fly, Vercel, k8s, etc.). # Ship ### When to use - Release Agent after `review_decision.json` is **approve** and CI is green on the merging branch. ### Preconditions - You know **where** production runs and how deploys are triggered (GitHub Action, Git push tag, `fly deploy`, `vercel --prod`, etc.). - **Health check** URL
SKILL.mdUpdated Apr 20, 2026
datashaman/skills/review
development
VerifiedTrustedCommunity
--- ## name: review description: Produce an approve or block decision with reviewer-grade checks—maintainability, team policy, and OWASP-style web review—captured in review_decision.json. # Review ### When to use - Reviewer Agent (or human) after `verification_report.json` is **pass** for merge-worthy work—or **fail** with documented risk acceptance (rare; usually fix first). ### Inputs - `verification_report.json`, diff, team standards (CONTRIBUTING, security doc, ADRs). ### Review seque
SKILL.mdUpdated Apr 20, 2026
datashaman/skills/implement
development
VerifiedTrustedCommunity
--- ## name: implement description: Implement features with minimal surface area—match repo conventions, honor spec contracts, add focused tests, open a reviewable pull request, and record deviations in build_report.json. The finished artifact is a PR, not merely a local branch. # Implement ### When to use - Builder Agent (or developer) is turning an approved `spec.json` into a **pull request** reviewers can land (code + tests + PR description), not just a private branch. ### Preconditions
SKILL.mdUpdated Apr 20, 2026