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/griddynamics/rosetta/qa-structurenpx skills add griddynamics/rosetta --skill qa-structuregit 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/skills/griddynamics/rosetta/qa-structure)<a href="https://agentmods.dev/skills/griddynamics/rosetta/qa-structure"><img src="https://agentmods.dev/badge/skills/griddynamics/rosetta/qa-structure.svg" alt="Measured on agentmods" 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 | $0.00018 | $0.00960 |
| Opus 5 | $0.00009 | $0.00480 |
| Sonnet 5 | $0.00004 | $0.00192 |
| Haiku 4.5 | $0.00002 | $0.00096 |
Grade A, and why
qa-structure 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 2d 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
<qa_structure>
<when_to_use_skill>
Use when you need to create the QA session folder, resolve or name an artifact path, derive the {IDENTIFIER} / <test-name> slug, or seed/read the QA state file. This is the single source for WHERE QA artifacts live -- not for HOW to author or analyze them. Use TMS, Issue Tracker, and Wiki as the roles; TestRail, Jira, and Confluence are canonical examples only.
</when_to_use_skill>
<core_concepts>
- This skill is the SSoT for QA paths, identifiers, and state-file shape; paths here are used verbatim, never reinvented.
- Load only your flow's layout (progressive disclosure): READ SKILL FILE
references/api-aqa-layout.md(backend API) XOR READ SKILL FILEreferences/ui-aqa-layout.md(UI/E2E) -- canonical paths + each flow's slug authority, guards, and state-file fields live there. - Slug format (both flows): lowercase ASCII kebab-case -- letters, digits, hyphens only; no spaces/paths; ≤80 chars; reserved:
state,index, and the flow's own*-statename. - Underivable slug/
{IDENTIFIER}: if unresolvable even after one user attempt, stop, record the gap in the flow's state file, ask once -- never fabricate or guess. - State-file shape (both flows): header +
## Phase Completion Status(8 rows) + per-phase append blocks; each phase appends only its own delta. - Repository-root
gain.json.sdlcis the primary SDLC-provider configuration. Merge it with explicit user input, recognizable provider URLs/handles, and available integrations; ask only when evidence conflicts or remains unresolved. - The API-AQA per-run config-key schema is reference-grade -- READ SKILL FILE
references/config-schema.mdonly when loading/validating that run artifact. - Fill-in skeletons are assets, loaded with READ SKILL FILE at point of use, never resident -- see
<resources>.
</core_concepts>
Router -- READ SKILL FILE for the one your current step needs (point-of-use, never all at once):
| When you need to… | Command |
|---|---|
resolve API-AQA paths, {IDENTIFIER} derivation, or the QA state-file shape |
READ SKILL FILE references/api-aqa-layout.md |
resolve UI-AQA paths, the <test-name> slug rules, the page-sources contract, or the UI-AQA state-file shape |
READ SKILL FILE references/ui-aqa-layout.md |
load or validate the API-AQA per-run config keys (keys + consumer + accepted N/A forms) |
READ SKILL FILE references/config-schema.md |
| write the API-AQA project-config file | READ SKILL FILE assets/api-aqa-project-config-template.md |
| run the user interview when the config is missing | READ SKILL FILE assets/api-aqa-config-interview.md |
| seed the UI-AQA state file | READ SKILL FILE assets/ui-aqa-state-template.md |
The API-AQA state-file seed and the API-AQA per-run initial-data skeleton are tiny + always-needed, so they stay inline in the consuming step rather than as assets -- avoids extra reads on the critical path.
<anti_patterns>
Flag/refuse these before proceeding:
- Fabricating or guessing a
<test-name>/{IDENTIFIER}slug instead of confirming with the user (or stopping when underivable). - Writing the project config or any per-session artifact to a shared
agents/path instead of the per-session feature plan folder (plans/ui-aqa-<test-name>/,plans/api-aqa-{IDENTIFIER}/, orplans/testgen-{TICKET-KEY}/) -- a shared path collides across parallel sessions and commits. - Leaving a required config key absent instead of
N/A -- <reason>-- a later grep silently misses an absent key. - Inventing a non-canonical artifact path instead of binding to the layout reference verbatim.
- Loading both flows' layouts when only one applies (
api-aqa-layoutXORui-aqa-layout).
</anti_patterns>
</qa_structure>
What ships with it
7 files 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.
- 2d ago First seen · 60 lines · 18 tokens per session scan A 25f173211f9d
qa-structure is a skill published in the GitHub repository griddynamics/rosetta (342 stars, last pushed yesterday), licensed Apache-2.0. It adds 18 tokens to every session and 960 once invoked, about $0.0001 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-09-03.
Other skills, from other repositories
azure-devops-rest-api
Guide for working with Azure DevOps REST APIs and OpenAPI specifications. Use this skill when implementing new Azure DevOps API integrations, exploring API capabilities, understanding request/response formats, or referencing the official OpenAPI specifications from the vsts-rest-api-specs repository.
decision-mapping
Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.
memorix-memory
Use when prior workspace context, past decisions, solved bugs, handoff state, or durable project knowledge would help a coding task.
memorix
Use when Claude Code needs Memorix shared memory, reasoning, Git Memory, mini-skills, session handoff, orchestration coordination, or integration troubleshooting.
memorix-git-memory
Use when the task depends on commit history, what changed, when a fix shipped, or linking engineering evidence to reasoning memory.
memorix-mini-skills
Use when durable project knowledge, gotchas, workflows, or repeated fixes should become reusable agent guidance instead of ordinary memory.