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 afaraha8403/balakit --skill generating-app-verifygit clone --depth 1 https://github.com/afaraha8403/balakitWrote 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/afaraha8403/balakit/generating-app-verify)<a href="https://agentmods.dev/skills/afaraha8403/balakit/generating-app-verify"><img src="https://agentmods.dev/badge/skills/afaraha8403/balakit/generating-app-verify/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/afaraha8403/balakit/generating-app-verify"><img src="https://agentmods.dev/badge/skills/afaraha8403/balakit/generating-app-verify.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.00085 | $0.00831 |
| Opus 5.5 | $0.00034 | $0.00332 |
| Sonnet 5.5 | $0.00017 | $0.00166 |
| Haiku 4.5 | $0.00009 | $0.00083 |
Grade A, and why
generating-app-verify scanned grade A 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- **Drive:** existing harness first (Playwright, expect, curl). Then browser/CDP, PTY, or HTTP. How it starts
The opening of the file, as written. The whole thing — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Generate an app verify skill
Leading words: interview the repo, drive like a user, feature map, prove one feature, skills/verify-app.
Every serious project needs a way to launch the app, exercise a feature as a
user would, and keep evidence. This skill writes that as
skills/verify-<app>/ (Agent Skills path — not .cursor/ only).
Copy these steps into the todo list verbatim. Skip with skip: <reason>.
- Interview the repo (surface, run, drive, observe, isolate). Ask the user only what you cannot observe.
- Write
skills/verify-<app>/SKILL.mdwith Launch, Doctor, Drive, Evidence, Cleanup, Helpers. Helpers live underhelpers/(notscripts/). A Launch helper is required even when the app is a one-shot CLI (ready signal = usage line + exit). - Seed a feature map (
features/README.md+ 3–5 user-POV feature files). - Run launch → doctor → drive one mapped feature → evidence still exists after cleanup.
- Point at
/refreshing-app-verify.
If the checkout does not start, fix that first (or report it). A skill written against a broken base teaches the wrong steps.
Interview
- Surface: web UI, CLI/TUI, desktop, API, mobile? Pick the primary.
- Run: the repo's own documented dev command. Ports, env, seed, auth.
- Drive: existing harness first (Playwright, expect, curl). Then browser/CDP, PTY, or HTTP.
- Observe: screenshots, transcripts, bodies, logs, exit codes, DB.
- Isolate: can two instances run? If not, say so — refuse to double-drive a shared session.
Generated skill
Frontmatter: name: verify-<app> and a description that names the app and
surface. Sections with no placeholders:
- Launch — exact command, ready signal, teardown.
- Doctor — read-only "is this instance worth driving?"
- Drive — real selectors/commands from this repo. ARIA, data attributes, prompt strings, routes — not coordinates.
- Evidence — what to capture and where. Real user path, not internal setters. Side effects counted. Mocks only at a production boundary.
- Cleanup — kill what you started. Evidence survives.
- Helpers — executable; invocation shown in the body.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 71 lines · 85 tokens per session scan A c0bf57b15ecb
generating-app-verify is a skill published in the GitHub repository afaraha8403/balakit (1 stars, last pushed 29d ago), licensed MIT. It adds 85 tokens to every session and 831 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-11.
Other skills, from other repositories
enterprise-integration-testing
Use when testing enterprise integrations across SAP, middleware, WMS, or backend systems, validating E2E enterprise flows, testing SAP-specific patterns (RFC, BAPI, IDoc, OData, Fiori), or enforcing cross-system quality gates.
api-testing
API testing patterns for Playwright -- apiRequest fixture usage, Zod response schema creation and validation, test.step wrapping for multi-call tests, per-field negative/validation testing, path parameter fuzzing, and helper fixtures for shared setup/teardown. Use when writing or updating API test specs, adding tests…
debugging
Playwright test debugging conventions for the scaffold — reading failure messages, classifying failure modes (TimeoutError, ZodError, strict-mode violation, locator not found, network errors, schema drift), the playwright.config.ts capture defaults (trace on-first-retry, screenshot only-on-failure, video…
test-standards
Spec file conventions for the Playwright scaffold — imports from test-options.ts, test file structure (describe / beforeEach / test / test.step), single-tag rule, functional vs E2E vs API vs setup test types, data-driven test loops against TS static data, web-first assertions, destructive-test cleanup, and test…
data-strategy
Test data strategy for the Playwright scaffold — Faker + Zod factories for dynamic happy-path data, static TS files (.ts with as const exports — never .json) for domain-specific curated invalid sets, and the universal type-mismatch arrays in test-data/static/util/invalid-values.ts. Use when creating or editing a data…
helpers
Plain utility function conventions for the Playwright scaffold — app-specific helpers in helpers/{area}/ (authentication bootstrap, storage-state creation, data seeding) and generic utilities in helpers/util/ (date formatting, string manipulation, parsing). Use when adding a reusable function that does NOT need the…