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 agentmods add skills/nazmulnahid-git/ai-stack/prodtestnpx skills add nazmulnahid-git/Ai-Stack --skill prodtestgit clone --depth 1 https://github.com/nazmulnahid-git/Ai-StackWhat 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 | $0.00090 | $0.01323 |
| Opus 5 | $0.00045 | $0.00661 |
| Sonnet 5 | $0.00018 | $0.00265 |
| Haiku 4.5 | $0.00009 | $0.00132 |
Grade A, and why
prodtest scanned grade A with 0 findings 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 2d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 134 lines — stays where its author put it; the contents beside it link to each section on GitHub.
prodtest
Test a feature the way a senior QA engineer would: find out what the feature actually claims to do, then try to break it — at the unit, integration, and browser level.
Step 0 — Ask the fix policy first
Before writing anything, ask once:
Should I fix bugs as I find them, or only report them?
Wait for the answer. It governs the whole run:
- Fix mode — when a test fails because the product is wrong, fix the product, re-run, and note the fix in the report.
- Report-only mode — leave the failing test in place (or document the repro), change no product code, and list every defect at the end.
In both modes, a test that fails because the test is wrong is always yours to fix.
Step 1 — Identify the feature under test
- Use the user's description if given.
- Otherwise diff the branch:
git diff $(git merge-base HEAD origin/main)...HEAD --statplus recent commit messages, and read the changed handlers, components, and models. - Write down, in 3–6 bullets, what the feature is supposed to do — the behaviors you are about to verify. Show these to the user as your test basis; a wrong premise here wastes the whole run.
Step 2 — Learn the real test stack (do not assume)
Read, don't guess:
package.json/pyproject.toml/composer.json/go.mod— which runner exists (vitest, jest, pytest, phpunit, go test) and which scripts run it.- An existing test file near the feature — copy its imports, factories, fixtures, mocking style, DB setup/teardown, and naming. Match the house style exactly.
- CI config — the command that must pass.
- How the app boots locally (dev script, env vars, docker compose, seed/migrate commands) and on which port.
If no test infrastructure exists at all, say so and propose the minimal setup before installing anything.
Step 3 — Unit tests
Cover the pure logic the feature introduced: calculations, validators, reducers, permission predicates, formatters, state machines.
For each unit: the happy path, then the edges that actually bite — empty, null/undefined, zero, negative, very large, unicode, duplicates, boundary values, wrong types at trust boundaries, timezone/DST for dates, rounding for money.
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.
- 2d ago First seen · 134 lines · 90 tokens per session scan A 89597803c52d
prodtest is a skill published in the GitHub repository nazmulnahid-git/Ai-Stack (2 stars, last pushed 24d ago), licensed MIT. It adds 90 tokens to every session and 1,323 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
opencli-sitemap-author
Use when creating or maintaining OpenCLI site sitemaps: agent-facing navigation, page-state, action, workflow, API-reference, pitfall, and fallback knowledge for a website. Use after browser exploration discovers durable site context, when a sitemap is stale, or when promoting local site knowledge into the repo.
golden-rss
Use when testing the rss golden build.
omh-code-review
This is a Hermes-native code-review workflow skill.
redteam-web-detail-pack
Routing and boundary guidance for authorized general web application security testing. Use as a web testing router when the attack surface should be dispatched to more specific web vulnerability skills.
android-pentest
安卓应用渗透测试 — APK分析、Hook、自动化测试、运行态驱动、签名恢复、抓包分析.
studio
Architecture Studio control plane — initialize or inspect a studio workspace, create and register projects, or route an architecture/AEC task to the right agent or skill. Use when the user runs /as:studio, asks to set up or open their studio, manage its projects, or describes a task without naming a skill.