Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add arcasilesgroup/ai-engineering --skill verify-featuregit clone --depth 1 https://github.com/arcasilesgroup/ai-engineeringWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/arcasilesgroup/ai-engineering/verify-feature)<a href="https://agentmods.dev/skills/arcasilesgroup/ai-engineering/verify-feature"><img src="https://agentmods.dev/badge/skills/arcasilesgroup/ai-engineering/verify-feature/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/arcasilesgroup/ai-engineering/verify-feature"><img src="https://agentmods.dev/badge/skills/arcasilesgroup/ai-engineering/verify-feature.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00167 | $0.02787 |
| Opus 5.5 | $0.00067 | $0.01115 |
| Sonnet 5.5 | $0.00033 | $0.00557 |
| Haiku 4.5 | $0.00017 | $0.00279 |
Grade C, and why
verify-feature scanned grade C with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Tells the agent never to refusehighAnti-refusal
Suppressing the ability to decline removes a core safety control; a later harmful request then succeeds.
Don't refuse to work — reconstruct from the conversation per §1 and proceed. But if the How it starts
The opening of the file, as written. The whole thing — 208 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify feature against requirements
Code review asks "is this code correct and safe?" This asks a different question that review reliably misses: is this the thing we agreed to build? A dropped requirement compiles. A near-miss substitution passes lint. An unasked-for feature has no failing test. Nothing in the normal toolchain notices, which is why drift is usually found by a human weeks later.
Your output is a verdict per requirement, backed by evidence, plus a list of gaps. You do not fix anything until the user picks what to fix.
1. Establish the contract, and write it down before reading the code
First settle which feature you're verifying, since the answer scopes everything else.
Usually it's obvious from the conversation. When invoked cold, infer it from the branch
name and the diff against the base branch — a branch called feat/mobile-channel-ui
touching the channel views names its own subject. If the diff spans two unrelated
features, say so and ask which one rather than blending them into one confusing report.
You cannot measure drift without a fixed thing to measure against. Find the contract in this order:
- A written spec this project already keeps. Look for the project's own
convention before assuming there isn't one: a PRD or spec directory
(
docs/features/,docs/specs/,docs/rfcs/,adr/), adesign.md, or a location named inREADME.md,CONTRIBUTING.md,CLAUDE.md, orAGENTS.md. If a document exists for this feature, it is the contract. Prefer it over conversation memory even when the two disagree — disagreement is itself a finding, handled in §5. - A file or ticket the user points you at — a spec, an issue body
(
gh issue view,glab issue view), a linked design doc. - The conversation — the user's own earlier messages. The most common case, since most branches have no written spec.
If the contract comes from the conversation rather than a file, write the requirement
list out and show it to the user before you look at a single line of the
implementation. This ordering is the most important step in the skill, and it is worth
the extra round trip. Read the code first and you will unconsciously reconstruct
requirements that the code happens to satisfy — you will look at a channels filter and
remember the ask as "filter posts", when it was "filter posts and persist the choice
per user". Freezing the list first makes that failure impossible instead of merely
discouraged. It also gives the user a cheap chance to say "no, that's not what I meant"
before you spend effort verifying the wrong contract.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 208 lines · 167 tokens per session scan C ddd7e5ca0c86
verify-feature is a skill published in the GitHub repository arcasilesgroup/ai-engineering (61 stars, last pushed 2d ago), licensed Apache-2.0. It adds 167 tokens to every session and 2,787 once invoked, about $0.0007 per session on Opus 5.5. A static security scan graded it C with 1 finding (tells the agent never to refuse). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-12.
Other skills, from other repositories
702-technologies-wiremock
Use when you need framework-agnostic WireMock guidance — stub design, JSON or programmatic mappings, precise request matching, response bodies and faults, classpath fixtures, isolation and reset between tests, verification of calls, dynamic ports and base URLs, and avoiding flaky stubs — without choosing Spring Boot…
054-design-tdd
Use when Java implementation work should be guided by Test-Driven Development, including maintaining a test list, choosing the next behavior, writing a failing test first, implementing only enough production code to pass, and refactoring while keeping tests green. This should trigger for requests such as Apply TDD…
generate-microcks-openapi-samples
Use when creating OpenAPI mock examples for Microcks, setting up request/response routing with dispatchers, or mapping request fields to mock responses.
131-java-testing-unit-testing
Use when you need to review, improve, or write Java unit tests — including migrating from JUnit 4 to JUnit 5, adopting AssertJ for fluent assertions, structuring tests with Given-When-Then, ensuring test independence, applying parameterized tests, mocking dependencies with Mockito, verifying boundary conditions…
132-java-testing-integration-testing
Use when you need to set up, review, or improve Java integration tests — including generating a BaseIntegrationTest.java with WireMock for HTTP stubs, detecting HTTP client infrastructure from import signals, injecting service coordinates dynamically via System.setProperty(), creating WireMock JSON mapping files with…
321-frameworks-spring-boot-testing-unit-tests
Use when you need to write unit tests for Spring Boot applications — including pure unit tests with @ExtendWith(MockitoExtension.class) for @Service/@Component, slice tests with @WebMvcTest and @MockitoBean for controllers, @JsonTest for JSON serialization, parameterized tests with @CsvSource/@MethodSource, test…