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/os-factory/har/new-pluginnpx skills add os-factory/har --skill new-plugingit clone --depth 1 https://github.com/os-factory/harWrote 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/os-factory/har/new-plugin)<a href="https://agentmods.dev/skills/os-factory/har/new-plugin"><img src="https://agentmods.dev/badge/skills/os-factory/har/new-plugin.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 | $0.00089 | $0.02325 |
| Opus 5 | $0.00044 | $0.01162 |
| Sonnet 5 | $0.00018 | $0.00465 |
| Haiku 4.5 | $0.00009 | $0.00232 |
Grade A, and why
new-plugin 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 5d 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 — 166 lines — stays where its author put it; the contents beside it link to each section on GitHub.
New HAR plugin factory line
Instance of the factory-line template. Program data:
new-plugin.line.json. Stations here are sequential phases, not GitHub issues. The product is a plugin, not a runtime migration — that is why this line exists as a second instance.
Ship a new verification plugin <id> for framework <framework> end-to-end:
research → template → registration → local validation → real-repo validation → PR.
A plugin is an installable bundle under src/templates/plugins/<id>/ applied by
har env add-plugin <id>. It registers generic stage kinds (test, verify,
custom, …) in the target repo's .har/stages.json. Philosophy (AGENTS.md):
plugins install stages; agents only talk to the stage registry. Never add
stack-specific MCP tools or core stages.
Reference implementations: src/templates/plugins/playwright/ (web e2e, package.json
merge, CI workflow) and src/templates/plugins/rocketsim/ (external-tool flows,
no package merge). Pick whichever is closer to <framework> as your baseline.
Phase 0 — Inputs
Establish before doing anything (ask the user only if not inferable):
- Plugin id — short lowercase slug (
cypress,maestro,k6). - Framework — what it tests and on which stack (web, iOS, API, load…).
- Stage id — what the stage does, not the brand (
browser-e2e,mobile-flows,load-test). Brand goes in the description and docs filename. - Validation repo — a real repository that uses
<framework>to prove the plugin works (Phase 5). An existing example/OSS repo, or a minimal app you scaffold.
Phase 1 — Research the framework
Do this before writing any template file. Use WebSearch/WebFetch on the framework's official docs and answer:
- Headless CLI invocation — exact command to run tests non-interactively in CI
(e.g.
npx cypress run,maestro test flows/). Flags for reporter/output dir. - Config file — name, format, and the minimal config needed; how to inject
BASE_URL/ports via env vars (HAR slots compute ports per agent id). - Artifacts — where reports/screenshots/videos land and how to redirect them
into
.har/artifacts/<stage-id>/. - Install — npm devDependencies (+ current stable version) or external binary (then document a doctor/preflight check instead of a package merge).
- CI recipe — official GitHub Actions setup, for the optional workflow file.
- Exit codes — how failure is signaled so the stage script can pass it through.
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.
- 5d ago First seen · 166 lines · 89 tokens per session scan A e8925adcde5e
new-plugin is a skill published in the GitHub repository os-factory/har (83 stars, last pushed 5d ago), licensed Apache-2.0. It adds 89 tokens to every session and 2,325 once invoked, about $0.0004 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-30.
Other skills, from other repositories
ctx
Codebase intelligence and evidence-driven governance with the indexed ctx CLI. Use when exploring an unfamiliar repository, locating symbols or callers, checking for existing implementations, estimating change impact, enforcing architecture rules, scoring a branch, finding hotspots or duplication, or analyzing…
ctx
Codebase intelligence and evidence-driven governance with the indexed ctx CLI. Use when exploring an unfamiliar repository, locating symbols or callers, checking for existing implementations, estimating change impact, enforcing architecture rules, scoring a branch, finding hotspots or duplication, or analyzing…
alego-pre-push-checks
Use before pushing, force-pushing, marking ready for review, or claiming checks pass on an alego branch, and immediately after gh stack sync publishes rewritten branches, to select the smallest tests and checks that cover the outgoing or just-published diff without reflexively running the full repository suite.
alego-doc-site-sync
Use when publishing, updating, moving, or removing Alego documentation website pages; editing website/docs.ts mappings or navigation; diagnosing a page missing from the VitePress site; fixing projected documentation links; or running the docs:dev, docs:check, and doc-sync workflow after website-content changes.
editing-cordis-compositions
Use when creating, changing, or validating a Cordis composition for this harness — writing or editing an agent preset, adding or removing a plugin row, deciding whether something belongs to the host composition or to one session, checking whether a preset you authored actually mounts, or diagnosing a row that mounted…
alego-code-review
Use when reviewing a pull request in the alego repo — orients the reviewer to this codebase's standards (AGENTS.md conventions, defensive patterns, ADRs, quality gates) and the review-specific checks that code alone can't show.