Unified team skill for quality assurance. Full closed-loop QA combining issue discovery and software testing. Triggers on "team quality-assurance", "team qa".
55
62%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.codex/skills/team-quality-assurance/SKILL.mdQuality
Discovery
40%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description relies heavily on abstract terminology ('closed-loop QA', 'unified team skill') without specifying concrete actions the skill performs. While it includes some trigger terms, they are command-style prefixes rather than natural user language. The description would benefit significantly from listing specific capabilities and adding natural use-case triggers.
Suggestions
Replace vague phrases like 'closed-loop QA' and 'issue discovery' with concrete actions such as 'write unit/integration tests, identify bugs, generate test plans, analyze test coverage, create bug reports'.
Add a 'Use when...' clause with natural trigger scenarios, e.g., 'Use when the user asks to write tests, find bugs, improve test coverage, review code for defects, or set up a testing framework'.
Include natural keyword variations users would actually say: 'tests', 'bugs', 'test coverage', 'regression', 'test suite', 'CI testing', '.test files'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'Full closed-loop QA combining issue discovery and software testing' which names a domain but uses vague, buzzword-heavy language ('closed-loop QA') without listing concrete actions like 'write unit tests', 'run test suites', 'file bug reports', etc. | 1 / 3 |
Completeness | The 'what' is weakly addressed ('issue discovery and software testing') and the 'when' is partially addressed with trigger phrases ('team quality-assurance', 'team qa'), but these are artificial command-style triggers rather than natural use-case descriptions. There is no explicit 'Use when...' clause describing scenarios. | 2 / 3 |
Trigger Term Quality | Includes 'quality assurance', 'qa', and 'software testing' which are relevant keywords, but misses many natural user phrases like 'write tests', 'find bugs', 'test coverage', 'run tests', 'regression testing', or 'bug report'. | 2 / 3 |
Distinctiveness Conflict Risk | The 'team qa' and 'team quality-assurance' triggers are fairly specific command-style phrases that reduce conflict risk, but the underlying description ('issue discovery and software testing') is broad enough to overlap with testing-specific or bug-tracking skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured orchestration skill that clearly defines a multi-agent QA pipeline with concrete templates, explicit tool boundaries, and proper error handling. The delegation lock and role router provide unambiguous decision points. Minor verbosity exists in repeated default values and some structural redundancy between the architecture diagram and role registry, but overall the content is dense with actionable information appropriate for a complex coordination skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly dense and information-rich, but includes some redundancy (e.g., the architecture ASCII diagram partially duplicates the role registry table, and the model selection guide repeats default values). Some sections like the delegation lock table are well-structured but could be tighter. Overall mostly efficient for a complex orchestration skill. | 2 / 3 |
Actionability | Provides concrete spawn_agent templates with exact parameter structures, specific tool call verdicts, explicit message bus API calls, session directory layouts, and copy-paste ready code blocks for completion actions and agent health checks. The delegation lock table gives unambiguous ALLOWED/BLOCKED verdicts for every tool category. | 3 / 3 |
Workflow Clarity | The pipeline is clearly sequenced (scout -> strategist -> generator -> executor -> analyst) with explicit validation checkpoints: agent health checks via list_agents, timeout handling with escalation (STATUS_CHECK -> FINALIZE -> close), GC loops with max 3 rounds for coverage gaps, and error recovery table. The delegation lock provides a clear decision framework before every action. | 3 / 3 |
Progressive Disclosure | The SKILL.md serves as a clear router/overview with well-signaled one-level-deep references to role files (roles/<name>/role.md) and spec files (specs/pipelines.md, specs/team-config.json). The role registry table provides a clean navigation index. Content is appropriately split between the overview (routing, shared constants, spawn templates) and delegated role-specific details. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
5ff5e86
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.