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/api-aqa-flow)<a href="https://agentmods.dev/commands/griddynamics/rosetta/api-aqa-flow"><img src="https://agentmods.dev/badge/commands/griddynamics/rosetta/api-aqa-flow/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/api-aqa-flow"><img src="https://agentmods.dev/badge/commands/griddynamics/rosetta/api-aqa-flow.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.00029 | $0.03336 |
| Opus 5.5 | $0.00012 | $0.01334 |
| Sonnet 5.5 | $0.00006 | $0.00667 |
| Haiku 4.5 | $0.00003 | $0.00334 |
Grade A, and why
api-aqa-flow 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 3d 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 — 158 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<api_aqa_flow>
<description_and_purpose>
End-to-end backend API test automation from test case input to working automated tests.
Prerequisite: Rosetta Prep Steps.
Terminology. External systems are named by role throughout this workflow and its phases: Test Management System (TMS), Issue Tracker, and Wiki. TestRail, Jira, and Confluence are canonical examples only — adapt identifiers, URLs, requests, calls, and query syntax to the systems resolved for the current project (from repository-root gain.json, explicit user input, recognizable URLs/handles, and available integrations).
At completion the user has: corrected, passing API test files in the repository; the per-session artifacts under plans/api-aqa-{IDENTIFIER}/ (raw-data.md, api-analysis.md, analysis.md, test-specs.md, execution-report.md); and agents/TEMP/<FEATURE>/api-aqa-state.md recording phase completion, metrics, and HITL approvals.
</description_and_purpose>
<workflow_phases>
- Phases 0→7 MUST run in order; sanctioned skips per
<skip_rules>only. - All Rosetta prep steps MUST be FULLY completed, SKILL
load-project-contextloaded and fully executed. - NO ASSUMPTIONS: never assume endpoints, payloads, auth mechanisms, or response schemas — ask the user when missing.
- MUST ALWAYS use todo tasks ledger, ASAP. Prioritize ACCURACY over SPEED. Proactively use available tools/MCPs, if question can be answered from code or MCP call - do that first.
- Drive loop (owned by this workflow): execute phases in order — for each: APPLY PHASE its phase file → update
agents/TEMP/<FEATURE>/api-aqa-state.md→ verify the phase-output gate → next; keep todos matched to the active phase; never batch-load future phases; never skip without approval (<skip_rules>). When a phase delegates work to subagents, dispatch per USE SKILLorchestration. - Phase-output gate (verify before advancing): each phase's mandatory artifact must exist and pass its phase-file completion gate before the next phase starts — notably Phase 4: every
ATC-NNNintest-specs.mdtraces to a Phase 3 source (araw-data.mdtest case and/or ananalysis.mdG[N]/C[N]/A[N]finding); also Phase 1raw-data.md, Phase 2api-analysis.md, and Phase 6execution-report.mdpresent and non-placeholder.
<skip_rules>
This block owns ONLY the api-aqa-flow-specific skip rules below: a set of always-in-force carve-outs plus a single verification-failure unilateral-start override (the only no-ask deviation; its preconditions are in the table further down). The carve-outs bind unconditionally; the override is subordinate to them. Gate-execution mechanics (how to run an approval gate, token handling) are owned by USE SKILL hitl — defer to it; not restated here.
-
Always-in-force carve-outs (the override never suppresses these):
- Per-phase HITL gates (Phases 3-7 marked
type="HITL") — explicit user approval per thehitlskill. - NO ASSUMPTIONS rule (above) — every non-skip-gate decision.
- Safety / destructive confirmations — file deletion, edits outside
plans/api-aqa-{IDENTIFIER}/, comparable irreversible actions.
- Per-phase HITL gates (Phases 3-7 marked
-
Verification-failure unilateral-start override — subordinate to the
hitlskill + the carve-outs above; the only no-ask deviation, applies only at this skip-verification gate.Precondition (ALL true, independently verified) Action (a) user asserts Phases 0-2 complete this turn AND (b) agents/TEMP/<FEATURE>/api-aqa-state.mdmarks them complete AND (c)raw-data.md+api-analysis.mdexist underplans/api-aqa-{IDENTIFIER}/Print (a)/(b)/(c) each with its concrete evidence (user-assertion quote · the api-aqa-state rows · the two artifact paths), then skip Phases 0-2 and resume at Phase 3. Any precondition not showable with concrete evidence → treat as uncertain (last row). Any of (a)/(b)/(c) false AND user instruction unambiguous Print failing conditions; begin Phase 0 same turn. Any precondition uncertain Fall back to normal HITL ask. Ambiguity defaults to ASK.
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.
- 3d ago Changed 54af6b351439
- 4d ago Changed 39032331afa7
- 1mo ago First seen · 158 lines · 29 tokens per session scan A 2d03eaa8ec26
api-aqa-flow is a command published in the GitHub repository griddynamics/rosetta (360 stars, last pushed 3d ago), licensed Apache-2.0. It adds 29 tokens to every session and 3,336 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
execute-task
Execute a specific task and its sub-tasks systematically following a Test-Driven Development (TDD) workflow. This command reads task specifications from .code-captain/specs/ directories and implements features with comprehensive testing, following established code standards and best practices.
spec-impl
Execute spec tasks using TDD methodology.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first.
implement-approved-slice
Implement only the approved slice with minimal changes, then persist execution evidence in slice notes and TASKSTATE.md. The official execution path. Opt-in test-first mode via --tdd. Use when the plan and slice are approved, ambiguity is resolved and files in scope are known. Do not use during discovery or planning…
tdd
Canon TDD (specify, encode, fulfill) with one test at a time, approval gates, and kitchen-cleaning refactor when needed.
tdd
TDD workflow - red-green-refactor per docs/methodology/tdd.md. Use when asked to '/tdd', 'TDD workflow', 'red-green-refactor', 'test-first development', 'write the failing test first'.