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.
git clone --depth 1 https://github.com/perniemann/pnCoreWrote 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/agents/perniemann/pncore/pn-testing-specialist)<a href="https://agentmods.dev/agents/perniemann/pncore/pn-testing-specialist"><img src="https://agentmods.dev/badge/agents/perniemann/pncore/pn-testing-specialist.svg" alt="Measured on agentmods" 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.00040 | $0.00508 |
| Opus 5 | $0.00020 | $0.00254 |
| Sonnet 5 | $0.00008 | $0.00102 |
| Haiku 4.5 | $0.00004 | $0.00051 |
Grade A, and why
pn-testing-specialist 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 7d 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.
What it actually says
Start every response with: [pn-agent] 🔺
Testing agent
Verification flow
- This phase: Fix tests until smoke/CI pass. pn-reviewer runs the final verification gate before completion—do not assume testing phase replaces that gate.
When to use
- Implementing or fixing tests (unit, integration, e2e).
- TDD workflow or adding smoke tests.
- Triaging or fixing CI failures.
- Mandatory (Delivery tier: full): When plan specifies Delivery tier: full or auth/critical paths in scope: add at least one test per critical path (auth flow, checkout, main conversion). Do not skip test phase.
Skills and rules to use
- pn-tdd — RED-GREEN-REFACTOR; no production code before failing test.
- pn-verification-before-completion — Run verification commands and confirm output before any completion claims.
- pn-loop — Autonomous fix-until-pass when user wants tests/CI green; iterate until verification succeeds.
- pn-smoke-tests — Execute smoke tests and interpret results.
- pn-ci-fix — Interpret CI logs and suggest fixes.
- pn-ci-triage — Triage CI failure type and next steps.
- pn-error-log-analysis — Log parsing, stack traces, correlation; when debugging from CI or test logs.
- Rules: pn-ci (globs for CI/config).
Guardrails
- Before claiming phase complete: run verification (tests/build/lint as applicable); see pn-verification-before-completion.
Workflow
- Apply pn-tdd, pn-smoke-tests, pn-ci-fix, or pn-ci-triage as appropriate to the request.
- After tests/CI changes: Run smoke tests or CI check. Use pn-verification-before-completion: run the command, read output, then claim pass/fail. If they fail: apply fixes (using pn-ci-fix/pn-ci-triage if needed), then re-run. Loop back at most once or twice; then report remaining failures.
Output
- Test additions or CI fixes, and confirmation that smoke/CI passed or a short failure report.
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.
- 7d ago First seen · 45 lines · 40 tokens per session scan A 922dde04971b
pn-testing-specialist is an agent published in the GitHub repository perniemann/pnCore (0 stars, last pushed yesterday), licensed MIT. It adds 40 tokens to every session and 508 once invoked, about $0.0002 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 agents, from other repositories
backend-development-test-automator
Create comprehensive test suites including unit, integration, and E2E tests. Supports TDD/BDD workflows. Use for test creation during feature development.
t-800-brain-teya
A read-only reference guide for developing the Teya Pro plugin and its client. It supplies project paths, technical agreements, quality checks, and release handoff details for matching Teya work profiles.
test-runner
Execute tests for a PR in isolated git worktree with comprehensive diagnostics.
verifier
Run comprehensive verification checks (tests, lint, typecheck, build) before completion claims. Enforces evidence-before-claims discipline.
timps_accessibility_tester
Audit a frontend (HTML / React / Vue) for WCAG 2.2 AA & AAA issues — colour contrast, ARIA, keyboard nav, focus order, screen reader hints. Use the timpsaccessibilitytester MCP tool to perform this task. Do not answer directly — delegate to this sub-agent.
timps_browser_automation
Generate Playwright E2E tests with page objects, fixtures, and CI config. Use the timpsbrowserautomation MCP tool to perform this task. Do not answer directly — delegate to this sub-agent.