guildproof-skills
A guild of specialist agents, and an inspector that can stop the job. Twenty-two of them, as
plain SKILL.md files.
npx skills add emtcmca/guildproof-skills
Works in any agent that reads SKILL.md. No runtime, no dependencies, no API keys, no
host-specific syntax. Each skill is one file with a stated contract: a role, a method, an output
shape, and the conditions under which it pushes back instead of producing something plausible.
The engine turning a one-line request into a full prompt. A terminal-styled animation drawn frame by frame from the text of a real run, not a screen recording.
That run is a slash command in guildproof, the Claude Code plugin these are generated from. Installed as skills there is no slash command: you ask for the thing and your agent picks the skill up. Same prompt underneath.
What's measured
verifier is the one to look at first. It reviews another agent's work, returns a blocking
verdict, and states whether its own check was actually independent of whoever wrote the work.
Upstream ran it against twelve models from three vendors, twice bare and twice with the verifier
prompt in front of it, scored by two blinded judges against a fixed checklist. Bare, not one run
stated whether the work was blocked, and not one stated whether the review was independent of
whoever wrote the code. With the prompt, every run did. The gap does not close as models get newer.
The unprompted scores scatter with no trend across four Gemini generations, three OpenAI
generations, and three Claude tiers.
What it does not claim: every run found the defect, in both arms, on every model, so this changes what a model does with a defect rather than whether it finds one. One defect type, one artifact.
Counts, raw outputs, judge scorecards, and the four bugs found in the measuring instrument itself:
evals/runs/2026-09-20-crossmodel-verifier.md.
Four specialists have a bare-versus-prompted benchmark on file: verifier, debugger,
security-review, and api-reviewer. api-reviewer came back mixed, and it publishes with the
rest. Everything else ships because it is a complete prompt, not because a number says it helps.
Try it before you install
A skill is one file, so you can run one by hand in whatever chat you already have open and decide from the output.
1. Open skills/debugger/SKILL.md and copy the whole file. About 60 lines, and it is the entire skill.
2. Paste it as the first message in a new conversation with any capable model.
3. Send your actual problem as the second message. If you don't have one handy, use this:
Here is the failure:
TypeError: Cannot read properties of undefined (reading 'map')
at renderInvoiceLines (invoice-table.tsx:88)
at InvoiceTable (invoice-table.tsx:41)
It hits about 3% of invoice page loads. I think it started last Thursday, around when we
moved the invoice fetch into a server component. I don't have a reproduction.
Five things a good run does:
- Labels your claims as yours. "Last Thursday," the refactor, and the 3% come back as unverified input, not as fact.
- Refuses to invent a reproduction and names that as a gap.
- Ranks hypotheses, each with the cheapest probe that kills it. A specific observation and a rough cost, not a list of five things to try.
- Separates trigger from root cause. The refactor is the trigger. The root cause is code treating an optional field as guaranteed.
- Withholds the one-line patch.
?? []stops the crash and tells you nothing about whether those invoices are supposed to have line items. If they are, the guard turns a loud crash into silent under-billing.
How often those five actually happen is measured on this exact input at two model tiers: small tier · frontier tier. At the small tier the claim-labelling bullet did not happen in either arm, so on a small model expect to ask for that yourself.
Any of the twenty specialists works this way, one file and one paste. Two skills want a real
install: the engine (prompt-engineering) loads twelve lens files and three templates from its own
directory, and prompt-grader carries one template.
What's in here
| Skill | When to reach for it |
|---|---|
prompt-engineering | 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. |
debugger | Use when something is broken, a test started failing, or a regression appeared and the cause is not yet known. |
test-author | Use when adding test coverage, writing unit or integration tests, or locking in a bug fix with a regression test. |
security-review | 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. |
data-modeler | Use when designing tables, columns, relationships, indexes, and constraints, or when planning a schema change or migration in Postgres, MySQL, or SQLite. |
planner | 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. |
refactor-planner | 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. |
feature-spec | 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. |
docs-writer | Use when shipping something undocumented, when the same onboarding question keeps getting asked, or when a design decision needs recording for future readers. |
api-reviewer | Use when a REST or GraphQL endpoint needs review before it ships, or when deciding whether a change breaks existing clients. |
backend-builder | Use when implementing an API route, request handler, webhook receiver, or server-side business logic rather than reviewing it. |
frontend-builder | Use when implementing a page, form, table, or dashboard component in React or any component framework. |
evaluator | 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. |
prompt-grader | Use before shipping a prompt change, or to compare prompt versions. |
verifier | 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. |
compliance-reviewer | 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. |
prompt-engineer | 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. |
research-synthesizer | Use for literature reviews, landscape and competitor scans, or comparative research where every claim needs a source. |
mcp-integrator | Use when an agent or workflow needs an external tool, API, or data source. |
copy-rewrite | 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. |
sop-writer | Use when writing an SOP, runbook, checklist, or onboarding guide for an operational, support, or business process. |
governance-letter | Use for community-association letters where tone and procedure both matter. |
All 22 rows are generated from the same descriptions the skills ship with, so this table cannot drift from what your agent actually reads.
Install one instead of all twenty-two, or list them without installing:
npx skills add emtcmca/guildproof-skills --skill debugger
npx skills add emtcmca/guildproof-skills --list
Honest limits
- 13 of the 22 were run once each, not all 22. The write-up in
docs/test-runs/dates from 2026-07-26 and covers the 13 skills that existed then, at 13 of 13 PASS. The nine added since,verifierandprompt-graderamong them, have not been exercised as installed skills. Upstream's plugin benchmarks test those prompts inside the plugin, which is not the same as testing this conversion of them. One run per skill is a sample and not a pass rate either way. That write-up also lists what the exercise could not test, notably the prompt-injection guardrails, which no input exercised. Three of the runs found real defects in this repo. (Corrected 2026-09-20. This read "Every skill was executed against one realistic input", which stretched a 13-skill report to cover 22. Found by an adversarial review from a different model family.) - Eval coverage is partial. Upstream's eval corpus is counted and linked in the mirror stamp
below, pinned to the commit this was built from, and not all of it covers what ships here. Four
specialists have no dedicated case:
docs-writer,frontend-builder,prompt-engineer, andrefactor-planner. The engine andprompt-graderare covered instead by the command-route cases they were extracted from. - Host support is one report, not a compatibility matrix. A single verification install reported writing to Claude Code, Codex, GitHub Copilot, Hermes Agent, and Qwen Code. That is what one install observed, and not a claim that each of them selects and runs a skill well. If you install these into any agent, tell us what happened. A failure report is worth more than a success report.
- No slash commands, no
/orchestrate. guildproof's commands are Claude Code features, and its coordinator dispatches subagents from a plugin-bundled gallery, so neither can run from a plain skills install. Both stay in the plugin. No specialist is left out. - No API keys, no dependencies, no network calls. These are prompts. They run wherever your agent runs.
Generated mirror
guildproof is the source of truth and ships as a Claude
Code plugin with slash commands (/sharpen, /forge-agent, /lens, /orchestrate) and a
20-agent gallery.
This repo is a generated distribution mirror. It exists because skills.sh indexes
skills/<name>/SKILL.md, and adding those directories to the plugin's own skills/ folder would
change what the plugin loads for existing users. Nothing under skills/ is hand-edited.
Versioning
This mirror carries the plugin's version number. These skills are not independently authored, so a separate number would mean nothing on its own: you would have to decode a commit hash to answer "are my skills current." The cost is a mirror release with no content change when a plugin release touches nothing this mirror reads, and that is the cheaper problem. The commit stamp below is the precise signal, and the one to trust if the two ever disagree.
Generated from guildproof at commit 6ec7fdc, committed 2026-09-20. At that commit upstream carries 38 eval cases and 6 known-bad regression fixtures — both links are pinned to that exact commit, so the counts are checkable rather than claimed. That commit is the most recent one to touch anything this mirror reads or cites; guildproof's own main may be further ahead on changes that cannot affect these files.
Every generated skill carries that same stamp in its own footer, so the provenance travels with the file after install rather than living only here.
To regenerate after guildproof changes:
git clone https://github.com/emtcmca/guildproof.git ../guildproof
node scripts/build-skills.mjs
The generator fails loudly if an upstream reword breaks one of its path rewrites, or if any generated file still points at a plugin-only path, so a silent drift cannot ship.
If you use Claude Code, install the plugin instead. You get these prompts plus the commands, the full gallery, and the orchestrator.
Contributing
Prompt fixes go upstream; packaging, install, and generator fixes go here. Host compatibility reports are welcome and there is a template for them. See CONTRIBUTING.md.
License
Apache-2.0. Same as guildproof.