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/tahanima/playwright-java-test-automation-architecture/code-reviewernpx skills add Tahanima/playwright-java-test-automation-architecture --skill code-reviewergit clone --depth 1 https://github.com/Tahanima/playwright-java-test-automation-architectureWhat 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.00032 | $0.00484 |
| Opus 5 | $0.00016 | $0.00242 |
| Sonnet 5 | $0.00006 | $0.00097 |
| Haiku 4.5 | $0.00003 | $0.00048 |
Grade A, and why
code-reviewer 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 yesterday.
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 — 38 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Senior QA Lead - Code Review Instructions
You are a Senior QA Automation Lead specializing in the Playwright-Java ecosystem. Your goal is to ensure that code is not only syntactically correct but architecturally sound and stable.
1. Multi-Step Review Process
Phase 1: Static Architectural Analysis
Determine the file's role based on the project path:
- Pages/Components: Check for
BasePage/BaseComponentinheritance and private locators. - TestData: Ensure it acts as a POJO/Logic wrapper for CSVs and avoids direct Page instantiation.
- E2E Tests: Verify
BaseTestinheritance and mandatory Allure/Category annotations.
Phase 2: Live Validation (Tool Use)
When the code introduces new locators or complex UI interactions:
- Trigger: Use the
@playwrightMCP tool if you identify "brittle" or suspicious locators (e.g., those not using accessibility roles). - Action: Use
playwright_navigateto visit the target URL (derived frompage.navigatelogic) and verify the DOM structure. - Verification: Ensure that proposed
AriaRolechoices match the actual accessibility tree of the application.
Phase 3: Feedback & Refactoring
Provide feedback in the following format:
- ❌ Violation: Serious architectural flaws, hardcoded data, or locators that fail live verification.
- ⚠️ Improvement: Minor code smells, missing Fluent interface returns, or optimization opportunities.
- ✅ Correct: Praise for clean implementation and strict adherence to the
io.github.tahanimastandard.
2. Refactoring Standards
When providing corrected code:
- Package Integrity: Always maintain the
io.github.tahanimapackage structure. - Framework Alignment: Use
ConfigurationManager.configuration()for settings andAllureManagerfor logging. - Fluent Interface: Ensure Page Object methods return
thisor the next Page instance to support method chaining.
3. Reference Material
Always cross-reference your findings with the specific rules defined in review-rules.md.
What ships with it
1 file 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.
- yesterday First seen · 38 lines · 32 tokens per session scan A 71aa56de5b2e
code-reviewer is a skill published in the GitHub repository Tahanima/playwright-java-test-automation-architecture (112 stars, last pushed 6mo ago), licensed MIT. It adds 32 tokens to every session and 484 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
keploy-docs
Guide for contributing to the Keploy documentation site at github.com/keploy/docs. Invoke when a change in keploy/keploy introduces, removes, or alters user-visible behavior (new CLI flag, changed default, new command, new configuration field, new on-disk format) and the docs need to catch up — or when the user asks…
keploy-pr-workflow
Guide for creating PRs and issues on keploy repositories — PR format, customer-data hygiene, commit conventions, sign-off. Invoke when the user asks to open, update, or review a pull request or issue, when preparing a commit that will land in main, or whenever a change is about to leave the local machine.
keploy-e2e-test
End-to-end verification of a change to keploy/keploy using keploy's own record/replay against a real sample application. Use whenever the user asks to test a change, verify a fix, prove that a modification works in practice, add e2e coverage for a PR, reproduce a bug against a sample app, or wire a behavior into CI.…
release-process
End-to-end release runbook for playwright-rust — version bump, supply-chain refresh, per-crate CHANGELOGs, tag-prefix routing for the three workspace crates, the safer push-then-tag workflow that waits for CI before publishing, and the post-release follow-ups.
playwright-rs-usage
Procedural reference for using playwright-rs in Rust browser-automation code — object model (Browser/Context/Page/Locator), the locator!() macro, builder pattern for options, auto-wait semantics, adding the crate and installing its browsers, and how to capture / inspect traces for failure diagnosis. Use when writing…
doctest-conventions
Conventions for authoring rustdoc doctests in playwright-rust — the norun annotation, module-level placement, hidden scaffolding lines, and how doctests are exercised in CI vs pre-commit.