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 tilework-tech/nori-skillsets --skill e2e-testing-skillsetsgit clone --depth 1 https://github.com/tilework-tech/nori-skillsetsWrote 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/tilework-tech/nori-skillsets/e2e-testing-skillsets)<a href="https://agentmods.dev/skills/tilework-tech/nori-skillsets/e2e-testing-skillsets"><img src="https://agentmods.dev/badge/skills/tilework-tech/nori-skillsets/e2e-testing-skillsets/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/tilework-tech/nori-skillsets/e2e-testing-skillsets"><img src="https://agentmods.dev/badge/skills/tilework-tech/nori-skillsets/e2e-testing-skillsets.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Rogue Agent · line 9 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
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.00039 | $0.02922 |
| Opus 5 | $0.00019 | $0.01461 |
| Sonnet 5 | $0.00008 | $0.00584 |
| Haiku 4.5 | $0.00004 | $0.00292 |
Grade A, and why
E2E Testing Nori Skillsets Subcommands 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 10d 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 — 260 lines — stays where its author put it; the contents beside it link to each section on GitHub.
- Run
e2e-setupto build the project and create the isolated environment
source {{skills_dir}}/e2e-testing-skillsets/e2e-setup
The script prints the variables it exports. Verify E2E_DIR, SKS, and NORI_GLOBAL_CONFIG are set.
- Read the TUI Puppeteering skill
Read {{skills_dir}}/tui-puppeteering-with-tmux/SKILL.md
Follow its instructions exactly. All tmux interaction goes through its scripts.
- Write a test plan for the specified subcommand
Before touching tmux, write out a concrete plan:
- What subcommand you are testing and what behavior you want to verify
- What seed data you need to create in
$E2E_DIRbefore launching the command - The exact
tui-startcommand you will use (must include theenvwrapper shown below) - The assert-act-assert sequence: what text you expect on screen, what input you will send, what text you expect after
- Seed any required test data in
$E2E_DIR
Many commands need pre-existing state. Create it directly in the filesystem:
# Example: create a fake skillset for switch/fork/edit to find
mkdir -p "$E2E_DIR/.nori/profiles/my-test-skillset"
echo '{"name":"my-test-skillset","version":"1.0.0","type":"skillset"}' > "$E2E_DIR/.nori/profiles/my-test-skillset/nori.json"
- Execute the test using TUI puppeteering
Launch the command inside tmux with isolation env vars:
SCRIPTS="{{skills_dir}}/tui-puppeteering-with-tmux"
SESSION="sks-e2e-$$"
$SCRIPTS/tui-start "$SESSION" "env NORI_GLOBAL_CONFIG=$E2E_DIR node $SKS <subcommand> [args]"
Then follow the assert-act-assert loop from the TUI Puppeteering skill.
- Verify filesystem side effects
After the command completes, check that the expected files were created/modified/deleted inside $E2E_DIR. Also verify that your real home directory was NOT touched.
- Clean up
$SCRIPTS/tui-stop "$SESSION"
{{skills_dir}}/e2e-testing-skillsets/e2e-teardown
Always stop tmux first, then tear down the filesystem.
Isolation Rules
- All commands MUST run with
NORI_GLOBAL_CONFIG=$E2E_DIR. This env var redirects every path thatgetHomeDir()resolves:~/.nori/,~/.nori-config.json,~/.claude/, and anything else rooted at$HOME. Without it, the CLI writes to the real home directory. - Always use
env NORI_GLOBAL_CONFIG=$E2E_DIR node $SKS ...as the command passed totui-start. Never run barenori-skillsetsorsks. - Never run
npm link. The built CLI is executed directly vianode. - The e2e directory is always
/tmp/nori/skillsets-e2e-scenario/. Thee2e-setupscript wipes and recreates it on every run. - After the test, verify isolation. Check that
~/.nori/and~/.claude/were not modified. Thee2e-teardownscript does this automatically.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 10d ago First seen · 260 lines · 39 tokens per session scan A 499adefd3473
E2E Testing Nori Skillsets Subcommands is a skill published in the GitHub repository tilework-tech/nori-skillsets (164 stars, last pushed 8d ago), licensed Apache-2.0. It adds 39 tokens to every session and 2,922 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-30.
Other skills, from other repositories
e2e-testing
Guide for running end-to-end tests of the Qwen Code CLI, including headless mode, MCP server testing, and API traffic inspection. Use this skill whenever you need to verify CLI behavior with real model calls, reproduce user-reported bugs end-to-end, test MCP tool integrations, or inspect raw API request/response…
terminal-capture
Automates terminal UI screenshot testing for CLI commands. Applies when reviewing PRs that affect CLI output, testing slash commands (/about, /context, /auth, /export), generating visual documentation, or when 'terminal screenshot', 'CLI test', 'visual test', or 'terminal-capture' is mentioned.
qa-testing
Verify your work by actually operating the app or website you changed, instead of assuming it works. Strongly recommended whenever you build, modify, or debug a web app, website, or desktop GUI app. Drive real browsers with the agent-browser CLI and native desktop apps with the cua-driver CLI. These are installed on…
agent-reproduce-align
Use after a Codex or Claude Code feature has been implemented in Qwen Code to run the selected reference agent and Qwen Code under the same scenario, capture HTTP and terminal traces, compare request bodies, tool/function schemas, outputs, and iterate until the reproduced behavior is close enough.
screen-reader-testing
Test web applications with screen readers including VoiceOver, NVDA, and JAWS. Use when validating screen reader compatibility, debugging accessibility issues, or ensuring assistive technology support.
e2e-testing-patterns
Master end-to-end testing with Playwright and Cypress to build reliable test suites that catch bugs, improve confidence, and enable fast deployment. Use when implementing E2E tests, debugging flaky tests, or establishing testing standards.