Agentic quality skills for TDD, gates, golden benchmarks, and uplift loops

Short answer

What are agentic quality skills?

They are versioned local instructions that an agent can load on demand. Instead of asking the model to “be careful,” the skill gives it a concrete protocol: write or identify the failing test, stop at red flags, preserve evidence, and compare changes against fixed reference cases.

I packaged this in 2026 because the same quality problem kept repeating in real repo work. Agents are excellent at producing plausible diffs. They are less reliable at proving that the diff should exist. That gap needs tooling, vocabulary, and habit.

The first public version is deliberately small. It is easier to trust three clear skills than a giant instruction bundle nobody reads.

Packaging

Why package quality rules as skills instead of prompts?

A prompt lasts one conversation. A skill can be installed, reviewed, versioned, and called by a short natural-language trigger. That matters when the behavior is not stylistic but operational.

GitHub is moving in the same direction: the GitHub CLI gained agent skill management on April 16, 2026, and Copilot announced Agent Skills support on December 18, 2025.²³ The useful lesson is simple: repeatable agent behavior deserves a package boundary.

The repository also includes docs/COMMANDS.md and docs/TRIGGER_DICTIONARY.ru-en.yaml. That dictionary is not cosmetic. It lets a team teach agents how people actually ask for the workflow in English or Russian, then extend the vocabulary without rewriting the core skill.

Public repo

What does the GitHub repo contain?

The public repository ships three installable skills.¹

The install posture should stay conservative: inspect the files before installation. A skill that changes how an agent edits your repo deserves the same review you would give a dependency or git hook.

TDD

How does the TDD skill make red visible before green?

The dangerous agent pattern is familiar: implementation first, test second, everything green. The test often proves that the new code exists, not that the original requirement was correct.

Red/green TDD changes the order. Simon Willison describes the agentic pattern as establishing failure before asking the agent to implement.⁵ Endor Labs frames the same discipline as test-first prompting for AI-generated code.⁶

1. Write or identify the failing test.
2. Run it and prove red.
3. Freeze the test unless the human changes the requirement.
4. Implement the smallest fix.
5. Run the proof again and explain the delta.

This is not ceremony. It keeps the specification outside the implementation long enough to catch the agent when it tries to satisfy itself.

• Confirm the failing test before implementation.
• Keep the test stable after red is proven.
• Implement only the smallest green change.
• Record the proof command and result.

Gates

What should quality gates stop?

A useful gate is allowed to stop the work. The gates skill treats weak evidence as a signal, not as a reason to keep going until the diff looks complete.

Typical red flags include unclear acceptance criteria, code-path changes without matching tests, public API changes without migration notes, secret-like strings, and public docs that no longer match behavior. These are exactly the kinds of problems CI can miss because they depend on scope and intent.

This connects to the broader operating model I use for agents: define human gates in advance, and stop workflows when proof is weak. Those notes are not only for marketing agents; the same rule applies to code agents that are about to publish a change.

Evals

Why do golden benchmarks need an uplift loop?

A golden benchmark is a fixed set of cases that should not move while you test the change. It can include prompts, input files, expected packets, scorer outputs, or before/after workflow traces.

Anthropic’s eval guidance is useful here: measure concrete behavior, start simple, and improve iteratively.⁴ For skills and prompts, that means you need a before score and an after score. A score after the change is not enough.

The uplift-loop skill also guards against same-author grading. If I wrote the skill, saw the expected output, and then grade the result myself, I can accidentally validate my own assumptions. Blind validation is the antidote.

Commands

How do you invoke the skills after installation?

Use the broad command when the task is non-trivial and quality risk spans tests, gates, and benchmarks:

use agentic quality stack

Use targeted commands when the intent is narrower:

• use test driven development
• use agentic quality gates
• use golden benchmark uplift loop

The trigger dictionary is part of the product. A team should extend it with its own phrases: “проверь через quality gates,” “run red first,” “benchmark this prompt,” or whatever language people naturally use during reviews.

Workflow

Where does this sit in an engineering workflow?

Use it before edits when the agent is about to write code. Use it before commit when the diff becomes a public artifact. Use it before changing prompts, scorers, skills, or model routing when behavior can regress without a compiler error.

It does not replace CI, test suites, code review, or security scanners. It sits earlier. The skill’s job is to make the agent expose its proof while the work is still cheap to redirect.

FAQ

FAQ

Related reading

Where to go next