Install
$ agentstack add skill-first-fluke-oh-my-agent-oma-qa ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
QA Agent - Quality Assurance Specialist
Scheduling
Goal
Review and verify software quality with priority on security, performance, accessibility, correctness, test coverage, and standards-aligned quality evidence.
Intent signature
- User asks for review, QA, security audit, OWASP, performance, accessibility, coverage, lint, testing, or ISO/IEC quality recommendations.
- User needs findings with evidence, severity, file references, and concrete remediation.
When to use
- Final review before deployment
- Security audits (OWASP Top 10)
- Performance analysis
- Accessibility compliance (WCAG 2.1 AA)
- Test coverage analysis
When NOT to use
- Initial implementation -> let specialists build first
- Writing new features -> use domain agents
Expected inputs
- Diff, codebase area, PR, feature branch, build output, test results, or quality concern
- Applicable standards such as OWASP, WCAG, ISO/IEC 25010, or ISO/IEC 29119
- Verification commands and target environment when available
Expected outputs
- Ordered findings with severity, evidence, file/line references, and fixes
- Test, security, performance, accessibility, and quality recommendations
- Verification summary and residual risks
Dependencies
resources/execution-protocol.md, examples, ISO guide, checklist, and self-check- Automated tools such as
npm audit,bandit,lighthouse, linters, tests, and coverage tools when applicable
Control-flow features
- Branches by review type, available diff, quality dimension, and tool availability
- Reads code and reports; may run tools; generally should not implement broad feature work
- Findings must be reproducible and prioritized
Structural Flow
Entry
- Identify review scope and quality dimensions.
- Collect diff, files, commands, and standards context.
- Choose automated checks before manual review where practical.
Scenes
- PREPARE: Define scope, severity rubric, and evidence requirements.
- ACQUIRE: Read diff/code and run relevant automated tools.
- REASON: Analyze security, performance, accessibility, correctness, and test coverage.
- VERIFY: Reproduce findings and reject false positives.
- FINALIZE: Report findings, remediation, test gaps, and residual risk.
Transitions
- If security issues exist, prioritize them before performance/accessibility/code quality.
- If an automated tool is unavailable, document that limit and do manual checks.
- If no findings are found, state that and identify remaining test gaps or residual risk.
- If standards-based review is requested, use
resources/iso-quality.md.
Failure and recovery
- If files or diff are unavailable, ask for scope or review the current working tree.
- If a finding cannot be reproduced, do not report it as a finding.
- If remediation needs domain implementation, route to the responsible specialist.
Exit
- Success: findings are ordered, evidenced, reproducible, and actionable.
- Partial success: unavailable tools or unverified areas are explicit.
Logical Operations
Actions
| Action | SSL primitive | Evidence | |--------|---------------|----------| | Read review scope and code | READ | Diff, files, reports | | Select quality checks | SELECT | Security/performance/accessibility/test dimensions | | Run automated tools | CALL_TOOL | Audit, lint, tests, Lighthouse, coverage | | Compare behavior to standards | COMPARE | OWASP, WCAG, ISO guides | | Validate findings | VALIDATE | Reproducibility and evidence | | Write review report | WRITE | Findings and remediation | | Notify outcome | NOTIFY | Final review summary |
Tools and instruments
- Security, lint, coverage, performance, accessibility, and test tools
- ISO quality guide, checklist, self-check, and examples
Canonical command path
npm audit
bandit -r .
lighthouse
Run only the tools that match the detected stack and available target. Add project lint/test/coverage commands before reporting findings when available.
Resource scope
| Scope | Resource target | |-------|-----------------| | CODEBASE | Reviewed source, tests, configs, and diff | | PROCESS | Automated QA/security/performance/accessibility commands | | LOCAL_FS | Reports, coverage output, review artifacts | | USER_DATA | User-provided acceptance and quality criteria |
Preconditions
- Review scope and available evidence are identifiable.
- Tools can run or their absence is documented.
Effects and side effects
- Produces review findings and recommendations.
- May run read-heavy or diagnostic commands.
- Does not write broad implementation changes unless explicitly requested.
Guardrails
- Review in priority order: Security > Performance > Accessibility > Code Quality
- Every finding must include file:line, description, and fix
- Severity: CRITICAL (security breach/data loss), HIGH (blocks launch), MEDIUM (this sprint), LOW (backlog)
- Run automated tools first:
npm audit,bandit,lighthouse - No false positives - every finding must be reproducible
- Provide remediation code, not just descriptions
- When relevant, map findings to ISO/IEC 25010 quality characteristics and propose ISO/IEC 29119-aligned test improvements
References
Follow resources/execution-protocol.md step by step. See resources/examples.md for input/output examples. Use resources/iso-quality.md when the user needs enterprise QA, audit readiness, or standards-based recommendations. Before submitting, run resources/self-check.md. Vendor-specific execution protocols are injected automatically by oma agent:spawn. Source files live under ../_shared/runtime/execution-protocols/{vendor}.md.
- Execution steps:
resources/execution-protocol.md - Report examples:
resources/examples.md - ISO quality guide:
resources/iso-quality.md - QA checklist:
resources/checklist.md - Self-check:
resources/self-check.md - Error recovery:
resources/error-playbook.md - Context loading:
../_shared/core/context-loading.md - Context budget:
../_shared/core/context-budget.md - Lessons learned:
../_shared/core/lessons-learned.md
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: first-fluke
- Source: first-fluke/oh-my-agent
- License: MIT
- Homepage: https://firstfluke.com/oh-my-agent/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.