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/shabaraba/vibing.nvim/self-testingnpx skills add shabaraba/vibing.nvim --skill self-testinggit clone --depth 1 https://github.com/shabaraba/vibing.nvimWrote 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/shabaraba/vibing.nvim/self-testing)<a href="https://agentmods.dev/skills/shabaraba/vibing.nvim/self-testing"><img src="https://agentmods.dev/badge/skills/shabaraba/vibing.nvim/self-testing.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.00098 | $0.01995 |
| Opus 5 | $0.00049 | $0.00997 |
| Sonnet 5 | $0.00020 | $0.00399 |
| Haiku 4.5 | $0.00010 | $0.00199 |
Grade A, and why
self-testing 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 3d 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 — 196 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Self-Testing for vibing.nvim
vibing.nvim can test itself by driving a separate, child Neovim instance over RPC. This enables automatic QA and self-correction after implementing a feature, without manual testing.
Architecture
Test Runner (Current Nvim)
├─ lua/vibing/testing/e2e_helper.lua
│ ├─ spawn_nvim_instance() - Launch child Nvim via jobstart(rpc=true)
│ ├─ send_keys() - Send key input via rpcrequest
│ ├─ wait_for_buffer_content() - Poll buffer TEXT until pattern matches
│ ├─ wait_for_buffer_name() - Poll buffer NAME (use this for a filename)
│ └─ cleanup_instance() - Stop job
│
└─ tests/e2e/*.spec.lua - plenary.nvim test specs
└─ Test Neovim Instance (Child Process)
└─ vibing.nvim running with test configuration
Communication: Parent Nvim ←RPC→ Child Nvim (jobstart with rpc=true). Child instances get a
unique RPC port in the 9876-9925 range.
Running Tests
npm run test:e2e # all E2E tests (sets VIBING_E2E=1; spends real tokens)
npm test # unit only (test:lua + test:node) — E2E is deliberately not included
# Specific file. VIBING_E2E=1 is required: without it every spec self-skips, and the run reports
# "0 tests" as a pass rather than telling you nothing ran.
VIBING_E2E=1 nvim --headless -u tests/minimal_init.lua \
-c "PlenaryBustedFile tests/e2e/chat_jump_user_spec.lua"
Writing a Test
Place files in tests/e2e/ with a _spec.lua suffix:
local helper = require("vibing.testing.e2e_helper")
describe("E2E: Chat basic flow", function()
local nvim_instance
before_each(function()
nvim_instance = helper.spawn_nvim_instance({
headless = true,
init_script = "tests/e2e_init.lua",
})
end)
after_each(function()
helper.cleanup_instance(nvim_instance) -- always cleanup, prevents zombie processes
end)
it("should create chat buffer and display initial state", function()
helper.send_keys(nvim_instance, ":VibingChat<CR>")
vim.wait(2000)
local ok = helper.wait_for_buffer_name(nvim_instance, "%.md$", 5000)
assert.is_true(ok, "Chat buffer should be created with .md extension")
ok = helper.wait_for_buffer_content(nvim_instance, "created_at:", 2000)
assert.is_true(ok, "Frontmatter should contain created_at field")
end)
end)
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.
- 3d ago First seen · 196 lines · 98 tokens per session scan A f59e7af411de
self-testing is a skill published in the GitHub repository shabaraba/vibing.nvim (13 stars, last pushed 3d ago), licensed MIT. It adds 98 tokens to every session and 1,995 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-30.
Other skills, from other repositories
add-sponsor
Add, move or remove a sponsor logo in the README and on the install page. Use when a GitHub sponsor reaches the Team or Company tier, when a sponsorship lapses, or when a sponsor sends a new logo asset.
codex-app-parity
Use only when the user explicitly mentions Codex parity, codex-app-parity, Codex.app parity, or asks to compare against the installed Codex desktop app.
tlamatini-daily-chat-test
Run the daily automated Tlamatini chat regression — drive a visible Chrome via Playwright, log into agentpage.html, ask up to 1000 curated safe questions one-by-one (Multi-Turn ON, ACPX/Ask-Execs/Exec-Report/Internet OFF), wait for and qualify each answer (heuristic + LLM judge on failures), then write a dated report…
implement
Generate Playwright TypeScript test code from a test-plan.md (and discovery.md/audit.md if present). Use when the user wants to turn an approved test plan into runnable Playwright tests, or continue the Verefi pipeline after /verefi:testplan, /verefi:audit, or /verefi:discover.
discover
Explore a running app with agent-browser and record verified selectors (test-id attribute, role, text) into discovery.md — including identifying which test-id attribute the app actually uses. Use when the user wants to verify a test plan's assumed selectors actually exist before writing test code, or continue the…
execute
Run the generated Playwright tests and summarize pass/fail results. Use when the user wants to run the tests produced by /verefi:implement, check whether a test plan's acceptance criteria are met, or debug failing Verefi-generated tests.