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/griddynamics/rosettaWrote 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/commands/griddynamics/rosetta/ui-aqa-flow-test-correction)<a href="https://agentmods.dev/commands/griddynamics/rosetta/ui-aqa-flow-test-correction"><img src="https://agentmods.dev/badge/commands/griddynamics/rosetta/ui-aqa-flow-test-correction/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/commands/griddynamics/rosetta/ui-aqa-flow-test-correction"><img src="https://agentmods.dev/badge/commands/griddynamics/rosetta/ui-aqa-flow-test-correction.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.00018 | $0.01772 |
| Opus 5.5 | $0.00007 | $0.00709 |
| Sonnet 5.5 | $0.00004 | $0.00354 |
| Haiku 4.5 | $0.00002 | $0.00177 |
Grade A, and why
ui-aqa-flow-test-correction 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<ui_aqa_flow_test_correction>
<description_and_purpose> Fix identified test failures based on the Phase 7 failure analysis. Prepares proposed changes, requires explicit user approval before applying, then applies them incrementally with lint checks and hands re-testing back to the user. </description_and_purpose>
<workflow_context>
- Phase 8 of 8 in
ui-aqa-flow - Input: failure analysis from Phase 7 (
plans/ui-aqa-<test-name>/failure-analysis.md) - Output: corrected test code, ready for re-testing
- Prerequisite: Phase 7 complete
- HITL: explicit user approval required before applying any change (a domain-specific specialization of
hitl) - In-scope file set (single SSoT): test files only (and page-object files if the Phase 7 analysis identifies a selector fix). Writes outside this set are refused and escalated.
- Required skills:
qa-knowledge(correctionmode — proposed-change block + approval gate + correction discipline),qa-structure(run paths + state) - Recommended skills:
coding(authors the proposed/applied edits),debugging(root-cause alignment),hitl(explicit approval) </workflow_context>
<correction_contract>
The phase OWNS the iteration cap and the escalation contract. The proposed-change approval block is qa-knowledge's shared proposed-change template (the skill loads its own asset at step 8.1) — present one block per change BEFORE any write. Flow parameters for the template: change-type enum = selector-update | wait-strategy | assertion-fix | data-setup | other; root-cause reference = Phase 7 failure-analysis entry id (e.g. F3); state file = agents/TEMP/<FEATURE>/ui-aqa-state.md; on retry-cap, loop back to Phase 7. Verified by <validation_checklist> independent of skill internals.
</correction_contract>
<phase_steps>
- Prepare proposed corrections (step 8.1 — preparation-only)
- Present changes for approval (step 8.2)
- Apply approved changes (step 8.3)
- Update state (step 8.4) </phase_steps>
<execute_corrections step="8.1" subagent="engineer" role="Test correction engineer"> Guardrail: all of step 8.1 is preparation-only; file writes are forbidden until step 8.3. "Preparation-only" means proposed edits paired with before/after evidence — no writes to test, page-object, or product source files.
- USE SKILL
qa-structureto resolve run paths/state. USE SKILLdebuggingto align each proposed edit with a confirmed Phase 7 root cause (no symptom-only fixes). - USE SKILL
qa-knowledge(correctionmode) and USE SKILLcodingto author each proposed edit (preparation-only — before/after evidence, no writes). The present → approve → apply discipline is owned by this phase:<present_for_approval>(8.2) +<apply_changes>(8.3). Bindings: proposed-change source =plans/ui-aqa-<test-name>/failure-analysis.md; proposed-change template =<correction_contract>; in-scope file set =<workflow_context>; approval-token set = step 8.2; state file =agents/TEMP/<FEATURE>/ui-aqa-state.md; iteration cap =<correction_contract>; loop target = Phase 7. - Produce one Proposed Change record per fix per the
<correction_contract>template. Do NOT apply anything yet. </execute_corrections>
<present_for_approval step="8.2">
- Present all proposed changes with before/after code per the template.
- Approval gate: USE SKILL
qa-knowledgeto run its shared approval gate; USE SKILLhitl. Approval = an exact token from the closed listapproved/approve/yes(case-insensitive), scoped to the named changes — no"or equivalent"/"or similar"phrasing extends it. Comments, questions, suggestions, edits, and partial review are REVIEW, not approval. Partial approval applies only to named changes/hunks; re-present changed proposals; full rejection returns to Phase 7. </present_for_approval>
<apply_changes step="8.3">
- Apply approved changes one at a time (or in named approved batches).
- Validate linting/format after each change. On lint failure: revert that change (never leave the file broken), re-prepare, and re-present that single change via
<present_for_approval>. - Verify each applied change addresses its Phase 7 root cause (cite the analysis entry id). On root-cause mismatch: return to step 8.1 with a note in
agents/TEMP/<FEATURE>/ui-aqa-state.md; do not leave unmapped changes applied. - Max retries: apply the
<correction_contract>iteration cap — on the 3rd failed cycle for the same change, stop, recordPhase 8 blocked: in-phase apply retry cap reachedinui-aqa-state.md, loop back to Phase 7 (do not auto-start a 4th cycle). </apply_changes>
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 · 88 lines · 18 tokens per session scan A 9141ac53bf20
ui-aqa-flow-test-correction is a command published in the GitHub repository griddynamics/rosetta (360 stars, last pushed today), licensed Apache-2.0. It adds 18 tokens to every session and 1,772 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-03.
Other commands, from other repositories
analyze-failures
Triage Katalon True Platform/TestOps test failures and file defects. Use when you need to investigate failed test results, classify each failure as product defect vs automation defect vs environment/data issue, cluster failures by common signature, find likely root cause from execution data, and optionally create…
self-healing
Automatically detect and recover from errors without interrupting your flow.
fire-test
Run Dominion Flow plugin integration tests to verify all commands and integrations work correctly.
e2e-dashboard
Read .cursor/playwright-skills/e2e-dashboard/SKILL.md and follow its instructions exactly. Treat that file's body as your operating instructions for this task. Template files to install live in .cursor/playwright-skills/e2e-dashboard/templates/.
flutter-test
Run Flutter/Dart tests, report failures, and incrementally fix test issues. Covers unit, widget, golden, and integration tests.
resume-ai-validator
A command-line tool for checking a résumé application through its API and user interface. End-to-end testing means checking a complete user flow from start to finish.