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-test-implementation)<a href="https://agentmods.dev/commands/griddynamics/rosetta/api-aqa-flow-test-implementation"><img src="https://agentmods.dev/badge/commands/griddynamics/rosetta/api-aqa-flow-test-implementation/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-test-implementation"><img src="https://agentmods.dev/badge/commands/griddynamics/rosetta/api-aqa-flow-test-implementation.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.00026 | $0.01946 |
| Opus 5.5 | $0.00010 | $0.00778 |
| Sonnet 5.5 | $0.00005 | $0.00389 |
| Haiku 4.5 | $0.00003 | $0.00195 |
Grade A, and why
api-aqa-flow-test-implementation 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 — 100 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<api_aqa_flow_test_implementation>
<description_and_purpose> Implement all approved API test specifications as executable automated tests with shared utilities (auth, data factories, response validation), validate locally (lint-clean), then hand execution off to the user. The phase implements → validates → hands off → updates state without closing the workflow. </description_and_purpose>
<workflow_context>
- Phase 5 of 8 in
api-aqa-flow - Input: approved test specs
plans/api-aqa-{IDENTIFIER}/test-specs.md+ existing patterns + API analysis (api-analysis.md); resolve{IDENTIFIER}fromagents/TEMP/<FEATURE>/api-aqa-state.md - Output: implemented test files + shared utilities, lint-clean; state updated; user given an execution command
- Prerequisite: Phase 4 complete with recorded user approval of the specs
- HITL: must stop and wait for the user to execute the tests (this phase does not run them)
- Write boundary (single SSoT — referenced by other sections): writes test files + shared test-utility files only; synthetic data only — no hardcoded credentials, URLs, or production data.
- Required skills:
qa-knowledge(implementation_modes— API impl + hand-off record fields),qa-structure({IDENTIFIER}+ artifact path) - Recommended skills:
testing(test quality discipline),coding(repo conventions) </workflow_context>
<implementation_handoff_contract>
This phase OWNS the implement → validate-locally → hand-off-execution → update-state-without-closing contract. Verified by <validation_checklist> independent of skill internals.
- Implement — author tests + shared utilities via
qa-knowledgeimplementation_modes(API impl) against the approved specs; USE SKILLtestingfor general test quality; usecodingfor repo conventions (read repo standards as authority; repo docs win). - Validate locally — lint/format clean on touched files; every ATC implemented OR surfaced as a Gap (no silent ATC drop); tests isolated + idempotent; test-data lifecycle (create + cleanup) verified.
- Hand off execution — provide the exact project test-execution command; STOP and WAIT for the user to run it (
<stop_for_execution>). The phase never executes the tests itself. - Update state without closing — record outcome in
agents/TEMP/<FEATURE>/api-aqa-state.md, mark Phase 5 complete, set Phase 6 current; do NOT mark the overall AQA workflow COMPLETE.
Hand-off summary fields (returned by the implementing skill, verified by this phase) → qa-knowledge's test-implementation record (the skill loads its own asset) — the ordered field list (framework, file counts, ### Files, ### ATC → test mapping, ### Assumptions made, ### Gaps surfaced, ### Lint / format status, ### Validation scope & waivers, ### Ready for re-test).
</implementation_handoff_contract>
<phase_steps>
- Implement and validate the tests locally (step 5.1)
- Validate against requirements (step 5.2)
- Stop for user test execution (step 5.3)
- Update state (step 5.4) </phase_steps>
<execute_implementation step="5.1" subagent="engineer" role="Test automation engineer">
- USE SKILL
qa-structureto resolve{IDENTIFIER}/run paths. GATE: confirmplans/api-aqa-{IDENTIFIER}/test-specs.mdexists, is non-empty, andUser Approvalis set inagents/TEMP/<FEATURE>/api-aqa-state.md; confirmapi-analysis.mdand discoverable existing patterns are present. On any failure apply<failure_handling>— never author from unapproved or incomplete inputs. - USE SKILL
codingto read the repository standards as authority before authoring; repo docs beat model defaults. - USE SKILL
qa-knowledge(implementation_modes— API impl) and USE SKILLtestingwith the parent-supplied bindings: approved-specs path + the recorded approval signal; API-contract path; existing-patterns source; write boundary = test + shared-utility files only (<workflow_context>); output = the hand-off summary fields per<implementation_handoff_contract>. - Implement shared utilities (auth helper, data factory, response validator) — prefer EXTENDING existing helpers over parallel ones; record any extension. Every test name/docstring carries its ATC-NNN id.
- Record assumptions as
[ASSUMED: <field>=<value>](code + summary) and surface any unimplementable ATC as a Gap — no silent ATC drop. - Validate locally: run the project lint/format command on touched files and resolve issues; emit the hand-off summary. </execute_implementation>
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 · 100 lines · 26 tokens per session scan A 00b4ebf7e0d9
api-aqa-flow-test-implementation is a command published in the GitHub repository griddynamics/rosetta (360 stars, last pushed 3d ago), licensed Apache-2.0. It adds 26 tokens to every session and 1,946 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
fix-tests
Focus on all unit + command tests (pytest --exclude tests/integration). Make sure they pass and fix errors. If you run into anything very odd: stop, and let me know. Mutate test code first and let me know if you think you should update application code.
run_tests
Use the text the user typed after the command name as the request for this command.
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.
implement_tests
Use the text the user typed after the command name as the request for this command.
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.