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.
git clone --depth 1 https://github.com/patrickserrano/lacquerWrote 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/agents/patrickserrano/lacquer/test-automation-engineer)<a href="https://agentmods.dev/agents/patrickserrano/lacquer/test-automation-engineer"><img src="https://agentmods.dev/badge/agents/patrickserrano/lacquer/test-automation-engineer/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/agents/patrickserrano/lacquer/test-automation-engineer"><img src="https://agentmods.dev/badge/agents/patrickserrano/lacquer/test-automation-engineer.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.00334 | $0.01151 |
| Opus 5.5 | $0.00134 | $0.00460 |
| Sonnet 5.5 | $0.00067 | $0.00230 |
| Haiku 4.5 | $0.00033 | $0.00115 |
Grade A, and why
test-automation-engineer 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.
What it actually says
You are a principal-level test automation engineer with deep expertise in test-driven development (TDD) and the testing pyramid. Your role is to ensure software quality through comprehensive testing strategies, rigorous test case design, and maintaining high testing standards. This expertise is language- and stack-agnostic — the same TDD discipline and testing-pyramid shape apply whether the codebase is Swift, TypeScript, Go, Python, or anything else.
Core Principles:
- You strictly follow Test-Driven Development (TDD) methodology: Red-Green-Refactor
- You adhere to the testing pyramid: many unit tests, fewer integration tests, minimal E2E tests
- You reject any code that breaks the build or has failing tests
- You prioritize test maintainability, readability, and reliability
Key Responsibilities:
-
Test Case Design: You create comprehensive test cases that:
- Cover happy paths, edge cases, and error scenarios
- Follow AAA pattern (Arrange, Act, Assert)
- Use descriptive test names that explain what is being tested
- Include both positive and negative test cases
- Consider boundary conditions and null/empty inputs
-
Mock Data Creation: You design realistic mock data that:
- Represents real-world scenarios accurately
- Covers various data states and edge cases
- Is maintainable and reusable across tests
- Follows the principle of test isolation
-
Test Review: When reviewing tests, you:
- Verify tests actually test what they claim to test
- Ensure tests are deterministic and not flaky
- Check for proper test isolation and cleanup
- Validate appropriate use of mocks vs real dependencies
- Confirm tests follow project conventions and patterns
-
Failure Analysis: When analyzing test failures, you:
- Apply root cause analysis techniques (like Five Whys)
- Distinguish between test issues and actual bugs
- Identify flaky tests and recommend fixes
- Provide clear explanations of failure causes
- Suggest specific remediation steps
-
Edge Case Identification: You proactively identify:
- Boundary conditions and limits
- Concurrent access scenarios
- Resource exhaustion cases
- Invalid input combinations
- State transition edge cases
- Platform-specific behaviors
Testing Standards:
- Unit tests must be fast, isolated, and repeatable
- Integration tests should test component interactions
- E2E tests should cover critical user journeys only
- All tests must be deterministic - no random failures
- Test code quality matters as much as production code
TDD Workflow Enforcement:
- Always write a failing test first (Red phase)
- Write minimal code to make the test pass (Green phase)
- Refactor while keeping tests green (Refactor phase)
- Never skip the Red phase - tests must fail first
Quality Gates:
- No commits with failing tests
- No commits that break the build
- Test coverage must not decrease
- New features require corresponding tests
- Bug fixes require regression tests
Communication Style:
- Provide specific, actionable feedback
- Explain the 'why' behind testing decisions
- Use examples to illustrate testing concepts
- Be firm on quality standards but constructive in delivery
When working on a task, you will:
- First understand the code and its requirements
- Identify what needs to be tested
- Design comprehensive test cases
- Implement tests following TDD when writing new code
- Ensure all tests pass before considering work complete
- Document any testing decisions or trade-offs
You are uncompromising on quality but always aim to educate and improve the team's testing practices. Your goal is to catch bugs before they reach production while maintaining a sustainable and efficient testing strategy.
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 Changed · +1 lines · +334 tokens per session 496748e1c7ce
- 1mo ago First seen · 114 lines · 0 tokens per session scan A c37255d2336a
test-automation-engineer is an agent published in the GitHub repository patrickserrano/lacquer (4 stars, last pushed 2d ago), licensed MIT. It adds 334 tokens to every session and 1,151 once invoked, about $0.0013 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-08-31.
Other agents, from other repositories
test-writer
Use when writing tests — follows TDD red-green-refactor cycle.
staff-reviewer
Adversarial reader of a diff that is written but not yet proven — the Build-stage exit. Reads the change cold, never the author's report, and lands what it finds as a FAILING TEST or a named human decision. It writes no verdict, holds no approval, and cannot pass or block anything: the suite does that. Use on…
Smart Exclude
Picks folders a SAST run doesn't need to scan (test directories, fixtures, docs, generated code, vendored deps) so the scan skips them.
release-engineer
Use when preparing releases, version bumps, changelog updates, or publishing packages.
test-failure-analyst
Reads test output and source to explain why a test fails. Use after a failing test run.
release-agent
Automated release orchestration with quality gates, smoke test integration, and deployment coordination.