emtcmca/guildproof-skills
A guild of specialist agent prompts, and an inspector that can stop the job. 22 skills covering review and verification, prompt engineering, build work and writing. Each one states its method, its output shape and what it pushes back on. No runtime, no keys, no dependencies.
Review an existing HTTP endpoint or API contract for correctness, contract clarity, and abuse potential: status codes, pagination, versioning, auth, error shapes, and breaking changes. Use when a REST or GraphQL endpoint needs review before it ships, or when deciding whether a change breaks existing clients.
Build an endpoint or backend service to a stated contract: input-validated, authorized, and idempotent. Use when implementing an API route, request handler, webhook receiver, or server-side business logic rather than reviewing it.
Flag where a feature, document, or data flow may trigger a named regulatory regime (GDPR, CCPA/CPRA, HIPAA, PCI-DSS, SOC 2, ADA/WCAG, FTC advertising rules), returning a flag list that names the regime and the element that triggers it rather than legal advice or a legal conclusion. Use when a change touches personal data, health records, card payments, accessibility, or marketing claims and you need to know what to take to counsel.
Rewrite marketing, product, or UI copy to a named tone without inventing facts, claims, or numbers. Use when landing-page copy, an email, or interface microcopy needs a tone change, tightening, or de-hyping, and every claim has to stay exactly as true as it was.
Turn requirements into a sound database schema plus a safe migration path. Use when designing tables, columns, relationships, indexes, and constraints, or when planning a schema change or migration in Postgres, MySQL, or SQLite.
Turn a stack trace, exception, failing test, or bug report into ranked root-cause hypotheses plus the cheapest observation that confirms or kills each one. Use when something is broken, a test started failing, or a regression appeared and the cause is not yet known.
Document code, a feature, or an API so the next person can use it without asking: README, usage guide, or architecture decision record (ADR). Use when shipping something undocumented, when the same onboarding question keeps getting asked, or when a design decision needs recording for future readers.
Grade an artifact against named criteria and return a scored verdict plus the few fixes that raise the score most, deriving a rubric when none is supplied. Use to score and iterate on a doc, plan, spec, design, or piece of copy, or to compare two versions of one. For prompts specifically use prompt-grader; for a pass/fail verdict that can block a merge use verifier.
Turn a rough feature idea into a buildable specification or PRD with scope, requirements, acceptance criteria, and an explicit cut line. Use when an idea, ticket, or vague request has to become something a team can actually build, or when scope keeps growing because nobody wrote the boundary down.
Build UI components that are usable, accessible, and on-brand, covering loading, empty, and error states rather than only the happy path. Use when implementing a page, form, table, or dashboard component in React or any component framework.
Draft HOA and condominium board correspondence that is firm, fair, and compliant: violation notices, assessment and collection letters, and board communications to owners. Use for community-association letters where tone and procedure both matter.
Decide what tool or data access an agent needs and how to wire it through MCP (Model Context Protocol), preferring an existing server over building one, at least privilege, and output a runnable wiring recipe. Use when an agent or workflow needs an external tool, API, or data source.
Turn a goal, ticket, or spec into an ordered task plan with dependencies, acceptance criteria, and a named critical path. Use when a task is too large to start, when work needs breaking down and sequencing before implementation, or when several people or agents need to work in parallel without colliding.
Sharpen a system prompt or agent prompt that already exists into a tighter, more concrete, more testable one, without changing what it is for. Use when an agent ignores its instructions, drifts, or behaves inconsistently and the prompt is the suspect. To write one from scratch use prompt-engineering; to score one use prompt-grader.
Sharpen a vague request into a complete prompt, author a reusable agent or system prompt, or review a draft prompt through expert lenses. Use when a prompt is under-specified, when writing a system prompt for an agent, or when prompt output quality is inconsistent and you need gap-filling and a professional review pass.
Score a system prompt, agent prompt, or task prompt against a stated rubric and return PASS, WEAK, or FAIL with per-dimension marks, quoted evidence, and the two or three fixes that raise the score most. Give it two versions and it reports what improved and what regressed, even when the revision wins overall. Use before shipping a prompt change, or to compare prompt versions.
Turn messy code plus a goal into a staged, commit-by-commit refactor plan where every step leaves the build green and behavior unchanged. Use when a file or module has grown too large, when paying down technical debt, or when extracting and restructuring existing code instead of rewriting it.
Gather across sources and synthesize a cited, honest research brief that keeps uncertainty visible and says plainly when it has no live retrieval. Use for literature reviews, landscape and competitor scans, or comparative research where every claim needs a source.
Security code review of a change, endpoint, or feature: how it gets attacked, abused, or leaked, ranked by real-world impact rather than checklist severity. Use when code touches authentication, authorization, untrusted input, SQL or shell execution, secrets, payments, file uploads, or personal data, or before a risky endpoint ships.
Turn a process into a standard operating procedure someone can follow without the author in the room, including edge cases, ownership, and what to do when a step fails. Use when writing an SOP, runbook, checklist, or onboarding guide for an operational, support, or business process.
Write focused tests that prove behavior through the public interface, naming what each test proves. Use when adding test coverage, writing unit or integration tests, or locking in a bug fix with a regression test.
Independently try to refute that code, a spec, or a prompt meets its contract, and return a blocking verdict: VERIFIED, VERIFIED WITH GAPS, or NOT VERIFIED, with each defect ranked by severity. Use to review another agent's work before it merges or ships, especially when that agent reported success. Run it in a fresh conversation, never the one that wrote the work, and it states whether its check was actually independent.