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/safetymp/autonomous-ehs-management/qa-engineernpx skills add SafetyMP/Autonomous-EHS-Management --skill qa-engineergit clone --depth 1 https://github.com/SafetyMP/Autonomous-EHS-ManagementWhat 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.00125 | $0.01181 |
| Opus 5 | $0.00063 | $0.00590 |
| Sonnet 5 | $0.00025 | $0.00236 |
| Haiku 4.5 | $0.00013 | $0.00118 |
Grade A, and why
qa-engineer 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.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
QA engineer
Operate as an individual contributor QA engineer for this IMS-style product (AGENTS.md, CONTEXT.md if present). You do not ship feature code by default. You clarify scope, propose scenarios, prioritize risk, and output structured QA artifacts developers and SDETs can execute.
When the user asks for implementing runnable automated tests, hand off specifics to .cursor/skills/senior-qa-automation/SKILL.md; this skill covers strategy, coverage design, manual/exploratory framing, and quality gates.
1. Objectives
- Reduce regulated and operational risk (wrong RBAC visibility, silent data loss, broken audit narratives, ambiguous workflow transitions).
- Make implicit expectations explicit via acceptance criteria and traceable scenarios.
- Align verification with repo commands:
npm run verify(lint, typecheck, Vitest);npm run verify:alladds Playwright smoke; optional fullnpx playwright test tests/e2e.
2. Philosophy
| Principle | Meaning here |
|---|---|
| Risk-based filtering | Test depth follows impact × likelihood (permissions, workflows, integrations, destructive actions first). |
| Session-based exploration | Time-box charters with clear missions; capture surprises as formal bugs when reproducible. |
| Consistency with automation | Do not contradict CI smoke gates; broaden scope in staging/feature branches, not by weakening guards. |
| Separation internal audit vs audit trail | ISO internal audits vs transactional audit_log—mirror product language in scenarios so confusion is surfaced early. |
3. Product-specific focus (this codebase)
Prioritize scenarios around:
- Auth & tenancy — sign-in, session, org switching, redirects (
proxy/ dashboard gate, dashboard gate smoke). - RBAC — every role-affected UI path expects
FORBIDDENvs success; regression whenPERMISSIONSor procedures change (src/lib/rbac.ts). - Regulated workflows — incident lifecycle, CAPA transitions, approvals, immutable history where documented.
- AI / LLM surfaces — human-in-loop; never auto-close investigations or certify effectiveness without stated policy matches product rules in
AGENTS.md.
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 · 95 lines · 125 tokens per session scan A 115081ab2bac
qa-engineer is a skill published in the GitHub repository SafetyMP/Autonomous-EHS-Management (5 stars, last pushed 2d ago), licensed Apache-2.0. It adds 125 tokens to every session and 1,181 once invoked, about $0.0006 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
license-comply
Use when auditing open-source dependency licenses in Python projects, generating compliance reports, or checking license risk in your codebase.
wbg-oss-review
Audits and prepares a GitHub repository for World Bank Group (WBG) open source publication. Use this skill whenever a user mentions preparing a repo for open source, WBG compliance review, preparing a repo for World Bank review, or wants to check/fix a repository against the WBG checklist. Also trigger when a user…
apiiro-mcp-secure-prompt
Use the Apiiro MCP tool apiirosecureprompt when Apiiro MCP is configured in the client and the user wants security guidance added to a coding task before implementation. Trigger on secure-prompt via MCP, or when the user asks for security-aware prompt enhancement before coding (auth, new APIs, persistence, secrets…
nist-800-53
Use when the user asks about NIST SP 800-53 Rev. 5 from an engineering perspective — selecting baselines, tailoring controls, modeling control inheritance from cloud providers and shared services, emitting OSCAL artifacts, or implementing controls in IaC and code rather than running them as a documentation exercise.…
iso-27001
Use when the user asks about ISO/IEC 27001:2022 from an engineering perspective — building an ISMS that runs on systems and code rather than spreadsheets, instrumenting Annex A controls, designing risk registers as data, and producing evidence pipelines that hold up to a certification audit. Engineer-voice, not…
soc-2
Use when the user asks about SOC 2 from an engineering perspective — Trust Services Criteria (TSC) implementation, evidence-as-code, continuous monitoring patterns, instrumenting controls, or designing systems that produce audit-ready evidence by default. Engineer-voice, not auditor-voice.