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 skills add Team-Deepiri/deepiri-axiom --skill deepiri-qa-workflowgit clone --depth 1 https://github.com/Team-Deepiri/deepiri-axiomWrote 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/team-deepiri/deepiri-axiom/deepiri-qa-workflow)<a href="https://agentmods.dev/skills/team-deepiri/deepiri-axiom/deepiri-qa-workflow"><img src="https://agentmods.dev/badge/skills/team-deepiri/deepiri-axiom/deepiri-qa-workflow/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/skills/team-deepiri/deepiri-axiom/deepiri-qa-workflow"><img src="https://agentmods.dev/badge/skills/team-deepiri/deepiri-axiom/deepiri-qa-workflow.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.00038 | $0.00971 |
| Opus 5 | $0.00019 | $0.00485 |
| Sonnet 5 | $0.00008 | $0.00194 |
| Haiku 4.5 | $0.00004 | $0.00097 |
Grade A, and why
deepiri-qa-workflow 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 6d 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deepiri Qa Workflow
Use when the task involves reviewing/approving a Deepiri PR as QA, standing up a QA test
environment via team_dev_environments/qa-team/, or onboarding a new QA engineer.
1. Task identification
- Plaky board: check for assigned PR tasks.
- GitHub review inbox: check
https://github.com/pulls/inboxfor PRs where you've been requested as a reviewer — this is often how an assignment actually surfaces, in addition to Discord/Plaky. - Scope definition: read the PR description and diff to determine which repo(s) or submodule(s) are affected before touching a local environment. If a PR is connected to other open PRs (shared branch, dependent submodule bump), identify those first — testing one in isolation when it depends on another will produce false failures.
- Status: once assigned, update your status in the availability channel to "Busy," and keep it current in general — it's how leads know who's free to pick up new work.
2. Local environment setup
- Repository access: locate the relevant repo(s)/submodule(s) on GitHub.
- Branch checkout: in the local directory of each affected submodule, checkout the branch the
PR is built from — not
main, and not a stale local branch with the same name. - Environment initialization: use the Docker scripts in
your deepiri-control-plane clone; use ./setup-deepiri-dev.sh start qa-team:start.sh— bring the environment up.build.sh— rebuild containers when the PR changes dependencies (lockfiles, Dockerfiles, base images) — a plainstart.shwill silently run against stale images otherwise.stop.sh— tear the environment down once testing is complete. Don't leave stacks running between PRs; the next reviewer (or your next task) may need the ports/resources clean.
3. Verification and testing
- Health check: after
start.sh, confirm every container reports healthy before testing functionality on top of it. A "healthy enough" container that's actually still initializing produces test results that look like the PR's fault when they're the environment's. - Sorge bot pass: comment
/sorgeon the PR to get an automated code review flagging things worth looking into. Treat this as a first pass that informs your manual review — it does not replace the code review or testing steps below; run both. - Code review: read the source for logic and consistency, not just "does it run."
- Frontend PRs: verify UI/UX against the design spec, not just "the page loads."
- Backend PRs: verify functional requirements and data integrity — check what the change actually persists or returns, not only that the endpoint responds.
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.
- 6d ago Changed 4e4c14152dd7
- 10d ago First seen · 76 lines · 38 tokens per session scan A 6e9be1e89888
deepiri-qa-workflow is a skill published in the GitHub repository Team-Deepiri/deepiri-axiom (2 stars, last pushed 2d ago), licensed Apache-2.0. It adds 38 tokens to every session and 971 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-31.
Other skills, from other repositories
regression-consistency-checker
Checks whether a new version of a repository preserves the behavior observed by tests on the old version. Use this skill when comparing two versions of code to detect regressions, verify refactoring safety, validate bug fixes don't break existing functionality, or ensure backward compatibility. Detects differences in…
merge-ready
Run all quality gates before merge — git hygiene, documentation completeness, code review, security audit, build, E2E, goal-backward verification, doc accuracy and UI/UX — then write the changelog entry.
release
Release preparation workflow - security audit → E2E tests → review → changelog → docs.
contribution-pipeline
Full issue-to-PR lifecycle with 5-phase gated pipeline. Produces contributions maintainers look forward to — project-aware, thoroughly tested, security-gated, well-documented. Skill bundle with sub-skills for security, test quality, documentation, clean-room verification, and vault integration.
dev-ship
Fechamento de feature — verificação goal-backward antes de declarar pronto. Roda Must-Haves do PLAN.md, executa o demo script, revisa o diff completo procurando bugs e restos (debug logs, TODOs, código morto), passa lente de segurança nos arquivos tocados, escreve SUMMARY.md e arquiva o plano. Use quando o usuário…
pr-qa
Persistent-session, per-sweep QA runbook for {{targetrepo}}. Discovers PRs since the last check, then for each one checks out the branch, runs the full verification suite, deploys the change to the test environment, exercises it through the edge, and posts a pass/fail result as a GitHub check and comment. Test…