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 makifbaysal/tasktrooper --skill e2e-automation-projectgit clone --depth 1 https://github.com/makifbaysal/tasktrooperWrote 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/makifbaysal/tasktrooper/e2e-automation-project)<a href="https://agentmods.dev/skills/makifbaysal/tasktrooper/e2e-automation-project"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/e2e-automation-project/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/makifbaysal/tasktrooper/e2e-automation-project"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/e2e-automation-project.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.00035 | $0.00971 |
| Opus 5.5 | $0.00014 | $0.00388 |
| Sonnet 5.5 | $0.00007 | $0.00194 |
| Haiku 4.5 | $0.00003 | $0.00097 |
Grade A, and why
e2e-automation-project 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 8d 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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
E2E Automation Project
Overview
Every repository worth testing gets a dedicated automation test project: a separate project that exercises the real product through its public surface and can be re-run on every change. It is not the product's unit-test folder and never mixes into it — it has its own dependencies, its own entrypoint, and runs in the repository's own pipeline (automation-pipeline-integration).
Core principle: scenarios before code (scenario-plan-first). A suite written without a scenario list tests whatever was easy, not what matters. And automation follows the manual pass: you automate the scenarios you have already executed and understood by hand.
Structure
One automation project per repository, following the project's convention — default qa-automation/ at the repo root (a sibling repo also works):
qa-automation/
scenarios/ # the human-readable scenario lists, one file per feature
api/ # backend API suite: HTTP client + assertions
worker/ # async job suite: trigger → poll → assert side effects
ui/ # frontend suite: Playwright against the built app
fixtures/ # seed data
support/ # helpers, page objects, request builders, stub mappings
scripts/e2e.sh # single entrypoint: provision, run all suites, teardown
| Surface | Tool (follow the project's existing choice) |
|---|---|
| REST API | the language's HTTP test client + assertions (Playwright APIRequest, RestAssured, supertest, Go net/http + testify) |
| Worker / async jobs | same test runner; triggers through the product path, polls for side effects (worker-job-testing) |
| Web UI | Playwright (preferred) / Cypress — headless Chromium via executablePath: process.env.CHROME_BIN, no browser download |
Mobile automation is out of scope for now — do not scaffold a mobile suite.
Determinism
- The app under test boots from the current branch build; the suite never targets stage, prod, or any shared environment.
- Database and infra are disposable containers seeded per run (test-database-seeding, Testcontainers or the project's equivalent).
- External services are stubbed and asserted on (test-doubles-wiremock).
- Each test seeds and cleans its own data; no ordering dependencies; re-running gives the same result.
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.
- 8d ago First seen · 74 lines · 35 tokens per session scan A 7d1191c2d95c
e2e-automation-project is a skill published in the GitHub repository makifbaysal/tasktrooper (113 stars, last pushed yesterday), licensed Apache-2.0. It adds 35 tokens to every session and 971 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-10-05.
Other skills, from other repositories
jetson-video-pipeline
Use when planning, executing, and independently validating Jetson Video Codec SDK or PyNvVideoCodec encode/decode, transcode, segmentation, container decode, AV1, or concise acceptance workflows.
chaos-experiment
Design and document chaos engineering experiments. Guide steady state baseline, hypothesis formation, failure injection plans, and results analysis. Use when you say "design a chaos experiment", "plan a game day", "failure injection", "test resilience", or "chaos engineering". Do NOT use for security threat analysis…
webapp-testing
Verify a local web app in a real browser with page, element, click, form, console and screenshot evidence. Use after a build or UI change; do not implement features or publish deployments with this skill.
C31-review
Reviews code changes using dynamically selected reviewer personas, then runs a verify-work pass: UAT walkthrough, verifier validation, and decision coverage logging. Writes memory/.planning/phases/XX-VERIFICATION.md.
textual-ui-developer
Develop and debug the MassGen Textual TUI with deterministic replay, snapshot regression tests, and targeted runtime checks.
production-verifier
Post-deployment smoke tests, synthetic user checks, and "Canary" validation in Prod.