datashaman
5 verified skills
skills/implement
--- ## 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
skills/review
--- ## 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
development
skills/ship
--- ## 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
testing
skills/specify
--- ## 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
development
skills/verify
--- ## 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