Paperclip is a Node.js server and React application for coordinating AI agents as a business team, with goals, organizational roles, budgets, governance, and work tracking in one interface. It is used by people managing multiple agents or autonomous agent organizations across tools such as OpenClaw, Claude Code, Codex, and Cursor. The catalogue includes skills, agents, an MCP add-on, and an instruction for working with Paperclip.
Borrowing it
Nothing to install: this file belongs to paperclipai/paperclip. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/paperclipai/paperclip/master/.agents/skills/add-product-e2e-eval/SKILL.mdgit clone --depth 1 https://github.com/paperclipai/paperclipWrote 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/paperclipai/paperclip/add-product-e2e-eval)<a href="https://agentmods.dev/skills/paperclipai/paperclip/add-product-e2e-eval"><img src="https://agentmods.dev/badge/skills/paperclipai/paperclip/add-product-e2e-eval/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/paperclipai/paperclip/add-product-e2e-eval"><img src="https://agentmods.dev/badge/skills/paperclipai/paperclip/add-product-e2e-eval.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.00997 |
| Opus 5.5 | $0.00014 | $0.00399 |
| Sonnet 5.5 | $0.00007 | $0.00199 |
| Haiku 4.5 | $0.00004 | $0.00100 |
Grade A, and why
add-product-e2e-eval 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 1mo 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Add a Product E2E Eval
Use this skill for Product E2E Evals: real Chromium, Paperclip server, database, runner, provider, and optionally Daytona. Everyday Workflows are in this family even when their packaged results are imported into Evalbook. Runner protocol cases against the mock control plane belong in add-runner-eval.
Locate the repository using PAPERCLIP_ROOT when supplied, or
git rev-parse --show-toplevel from a checkout. From outside Git, inspect
workspace roots such as ~/paperclipai/paperclip; verify the selected root
contains tests/runner-e2e and packages/paperclip-runner. Run commands from
that repository root. The copied skill may live outside the checkout.
Read doc/evals.md, then the authoritative
tests/runner-e2e/README.md, FIXTURES.md, SECURITY.md, and
EVERYDAY-WORKFLOWS.md for the selected area. Inspect the nearest existing
catalog entry, case, harness flow, matcher, evidence writer, and report test
before changing anything. Keep the user journey on production browser/API
surfaces; do not add private runner hooks or direct fixture database writes.
Define one bounded workflow with a clear user outcome, durable state assertions, and independent evidence. Declare profile, environment, expected provider turns, timeout, cleanup, screenshots, artifact checks, and billing scope. Keep credentials and secrets out of catalog data, screenshots, fixture metadata, logs, and tracked files. Daytona images must be immutable digest references. Use the existing result validator, failure classifier, screenshot policy, and Product E2E report pipeline rather than duplicating them.
Register the workflow in tests/runner-e2e/catalog.ts and the relevant
fixture-registry.ts paths. Everyday cases and actions live in
everyday-cases.ts and everyday-flow.ts; match the existing suite's structure.
Wire its
profile/environment/case IDs through existing selector and matcher tables, and
add report/catalog coverage tests where the surrounding suite does so. Calibrate
new grading assertions with a valid outcome and a plausible wrong outcome;
missing evidence must not produce a pass. Confirm
discovery before running it:
pnpm test:e2e:runner -- --list --suite <suite-name>
pnpm test:e2e:runner -- --list --suite everyday-workflows
--all intentionally excludes the manual everyday-workflows suite and other
explicit-only cells. Use the exact suite or execution ID for those. The Product
E2E generator is pnpm test:e2e:runner:report; an Everyday Workflows result may
also be imported into Evalbook with its canonical importer, but it remains a
Product E2E run and should use its packaged dashboard/report first.
Run credential-free checks first:
pnpm test:e2e:runner:typecheck
pnpm test:e2e:runner:unit
pnpm test:e2e:runner -- --list
For an authorized live check, use the smallest explicit local --id selector.
Select Daytona only with the configured immutable image and credentials. A
full --all campaign is paid and is for the governed workflow. Verify results
from the packaged attempt evidence and dashboard; passing model-authored tests
cannot override the independent oracle.
Classify a completed wrong workflow as product or model/provider behavior as the assertions warrant. Startup, transport, and timeout symptoms require evidence-based attribution: they may indicate a Paperclip/Runner product bug, provider behavior, or infrastructure. Preserve the observed failure and cause separately, keep the existing machine grade/classifier unchanged, and retain partial attempts, retries, source SHA, catalog/definition digest, model/profile, environment, grader version, timing, tokens, runtime estimates, and cost coverage. Do not claim qualification from a partial/manual selection.
Update README.md, FIXTURES.md, SECURITY.md, or
EVERYDAY-WORKFLOWS.md when their authoritative contract changes, and link
from doc/evals.md. Do not recreate Evalbook HTML or publish raw trusted
traces, videos, archives, databases, workspaces, credentials, SVG, provider
session IDs, or hidden reasoning. Public sanitized fixture conversation, marked
screenshots, and allowlisted structured evidence are expected when the existing
publisher permits them.
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.
- 1mo ago First seen · 85 lines · 36 tokens per session scan A 73457e44385a
add-product-e2e-eval is a skill published in the GitHub repository paperclipai/paperclip (107,044 stars, last pushed today), licensed MIT. It adds 36 tokens to every session and 997 once invoked, about $0.0001 per session on Opus 5.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-09-17.
Other skills, from other repositories
agent-production-validator
Agent skill for production-validator - invoke with $agent-production-validator.
agent-tester
Agent skill for tester - invoke with $agent-tester.
test-automation
Execute Vitest and Playwright test suites with result collection and failure analysis.
qa-testing
Generate and execute API and E2E tests with quality gate assessment.
run-dashboard-e2e-local-changes
Run Playwright E2E (tests/e2e/) against the docker/ all-in-one harness so it reflects LOCAL code changes, not a stale cached image.
acceptance-criteria-gwt
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases.