datashaman/skills/implement
skills/implement/SKILL.md
--- ## 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
development
Updated Apr 20, 2026
$ install --global
skillsauthnpx skillsauth add datashaman/agentfiles skills/implementInstall 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 PM14.2s1 file scanned
SKILL.md
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.jsoninto a pull request reviewers can land (code + tests + PR description), not just a private branch.
Preconditions
spec.jsonexists and acceptance criteria are testable.- You know where feature code and tests live (mirror existing folders and naming).
Steps
- Map AC → work items — List each
acceptance_criteriaID and the files you expect to touch. - Discover conventions (15-minute pass)
- Routing/DI patterns (e.g. Laravel routes/controllers, Next.js app router, Express routers).
- How validation is done (Zod, Pydantic, Form Request).
- How errors are returned (problem+json shape, exception handlers).
- Tests: existing runner (
npm test,php artisan test,pytest); colocation vstests/tree.
- Contract-first at boundaries — Implement handlers/UI against the spec’s request/response and status codes; keep internals private.
- Tests — At least one automated test per new or changed acceptance path (unit or integration as the repo already does). Name or comment tests with
AC-*IDs where helpful. - Spec drift — If the spec was wrong, update spec + get agreement in the ticket; do not silently change behavior without recording rationale in
build_report.jsonknown_risksor a linked commit message. - Refactors — Only refactor when it clears the path for the feature; same PR should still be reviewable (avoid drive-by renames unrelated to ACs).
- Pull request (required handoff) — Push your branch and open a PR against the team’s default integration branch. The PR is the deliverable: include a short summary, link to the issue/spec, note how ACs are covered (tests or manual checks), and ensure CI can run on it. Do not stop at “commits on a branch” with no PR.
Output
- Open pull request (URL)—review-ready, with description and linked
spec.json/ issue as appropriate. build_report.json:source_ref,spec_ref,**pull_request** (url,base_branch,head_branch; optionalnumber,title,draft,ci_status),changes,tests.added_or_updated,known_risks,metadata(seeschemas/build-report.schema.json).
Concrete checks before handoff
- Run the project’s usual lint/format (fix what you touched).
- Run relevant tests (full suite if fast enough; otherwise smallest set that proves ACs).
- PR exists, targets the right base branch, and is in a state maintainers can review (not only local or unpushed work).
Related Skills
datashaman/skills/verify
testing
VerifiedTrustedCommunity
--- ## 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):
SKILL.mdUpdated Apr 20, 2026
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