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 akopichin/afm --skill afm-live-rungit clone --depth 1 https://github.com/akopichin/afmWrote 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/akopichin/afm/afm-live-run)<a href="https://agentmods.dev/skills/akopichin/afm/afm-live-run"><img src="https://agentmods.dev/badge/skills/akopichin/afm/afm-live-run/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/akopichin/afm/afm-live-run"><img src="https://agentmods.dev/badge/skills/akopichin/afm/afm-live-run.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.00036 | $0.01411 |
| Opus 5.5 | $0.00014 | $0.00564 |
| Sonnet 5.5 | $0.00007 | $0.00282 |
| Haiku 4.5 | $0.00004 | $0.00141 |
Grade A, and why
afm-live-run 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 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
until curl -sf "http://127.0.0.1:$AFM_BROWSER_APP_PORT" >/dev/null; do sleep 0.5; done How it starts
The opening of the file, as written. The whole thing — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
afm-live-run — Drive the real app in a managed browser
SCOPE: Run the product for real and confirm a change works end-to-end, using
the managed Chrome DevTools browser exposed as the MCP server afm_chrome. This is
NOT unit testing (that is TDD) — this is launching the actual app and clicking
through it.
This skill assumes the managed browser capability is live. If the afm_chrome MCP
tools are not available, the capability is off for this stage — report that and
treat the live run as not performed (do not claim success).
Environment (set by afm)
$AFM_BROWSER_APP_URL— the URL to open in the browser. ALWAYS use this. Never openlocalhost:<app_port>inside the container, and neverhost.docker.internal— only$AFM_BROWSER_APP_URL.$AFM_BROWSER_APP_PORT— the port the app under test MUST listen on. In Docker, bind the server to0.0.0.0:$AFM_BROWSER_APP_PORTso the host browser can reach the published port; natively127.0.0.1:$AFM_BROWSER_APP_PORTis enough (and avoids exposing the dev app on your LAN). The<browser_tools>block in your prompt states the correct bind for the current mode — follow it.$AFM_STAGE_DIR/artifacts/— write screenshots, console logs and network captures here so they show up in the run.
Step 1: Build the app from the CURRENT sources
Rebuild from the working tree — the pinned image binary does NOT reflect new edits. For afm itself:
make build # rebuilds the frontend bundle before the Go embed, then the binary
For another project, use its real build command (check the repo / dev-plan).
Step 2: Start the app on the managed port
Launch the server in the background (bind address per the mode note above — Docker:
0.0.0.0; native: 127.0.0.1), then wait for it to answer before driving the
browser:
# example — replace with the real start command.
# BIND: Docker → 0.0.0.0, native → 127.0.0.1 (don't expose a native dev server on the LAN)
BIND=0.0.0.0; [ -z "$AFM_IN_DOCKER" ] && BIND=127.0.0.1
# Detach: a plain `&` child dies when your shell tool call ends.
DETACH=nohup; command -v setsid >/dev/null && DETACH="setsid nohup"
$DETACH ./your-app --addr "$BIND:$AFM_BROWSER_APP_PORT" > "$AFM_STAGE_DIR/app.log" 2>&1 < /dev/null &
echo $! > "$AFM_STAGE_DIR/app.pid"
until curl -sf "http://127.0.0.1:$AFM_BROWSER_APP_PORT" >/dev/null; do sleep 0.5; done
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 · 118 lines · 36 tokens per session scan A 0dd3177c3200
afm-live-run is a skill published in the GitHub repository akopichin/afm (25 stars, last pushed today), licensed MIT. It adds 36 tokens to every session and 1,411 once invoked, about $0.0001 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-10-23.
Other skills, from other repositories
browse
Drive a real browser through Aside: open a page, read it, click through a flow, take screenshots, check console errors. (gstack).
cua-driver
Use Cua Driver for desktop or browser tasks that are awkward or unavailable through Bash/APIs, or when the user explicitly wants GUI interaction: app testing, visual bug reproduction, form filling, calendar entry, screenshots, and demo recording. Also covers Cua setup; not OpenAI Codex Computer Use or web research.
create-verification-skill
Create a repo-local verification skill and exhaustive feature map for driving a real app through its UI, CLI, or API. Use for "create a verification skill", "make a verify skill for this repo", or "document how agents can verify this app".
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
browser-qa
A browser-based quality check for deployed web pages and user flows. It uses browser automation to test rendering, navigation, forms, interactions, responsive behaviour, and accessibility-related issues.
test-electron-app
Drive the real running PostHog Electron app (live tRPC, workspace-server, real data) over CDP with agent-browser. Connect to the running app on port 9222, test desktop changes against a local Django stack, snapshot the accessibility tree, inspect network requests, and screenshot only when explicitly asked. Use when…