CtrlK
BlogDocsLog inGet started
Tessl Logo

ultraqa

QA cycling workflow - test, verify, fix, repeat until goal met

40

Quality

38%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/ultraqa/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Discovery

14%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This description is too vague and abstract to be useful for skill selection. It describes a generic iterative QA pattern without specifying what domain, technology, or concrete actions are involved. It lacks a 'Use when...' clause and would likely conflict with many other testing or debugging-related skills.

Suggestions

Specify concrete actions and scope, e.g., 'Runs automated test suites, analyzes failures, applies code fixes, and re-runs tests in a loop until all tests pass' instead of the generic 'test, verify, fix, repeat'.

Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks to fix failing tests, debug test failures iteratively, or wants a test-fix cycle until a codebase is green.'

Clarify the domain and technology to improve distinctiveness, e.g., specify whether this is for unit tests, integration tests, specific languages, or particular testing frameworks.

DimensionReasoningScore

Specificity

The description uses vague, abstract language like 'test, verify, fix, repeat' without specifying what is being tested, what kinds of fixes, or what tools/technologies are involved. No concrete actions are listed.

1 / 3

Completeness

The 'what' is extremely vague (cycling through test/verify/fix) and there is no explicit 'when' clause or trigger guidance. The description fails to answer either question clearly.

1 / 3

Trigger Term Quality

Contains some relevant keywords like 'QA', 'test', 'verify', 'fix' that users might naturally say, but lacks common variations like 'quality assurance', 'debugging', 'bug fix', 'test suite', 'regression', or specific testing frameworks.

2 / 3

Distinctiveness Conflict Risk

This description is very generic and could overlap with any testing, debugging, CI/CD, or iterative development skill. 'Test, verify, fix, repeat' describes a fundamental software development pattern rather than a distinct capability.

1 / 3

Total

5

/

12

Passed

Implementation

62%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill defines a clear autonomous QA cycling workflow with well-structured exit conditions and observability. Its main strengths are workflow clarity with explicit cycle limits, failure pattern detection, and state management. Weaknesses include moderate verbosity with some redundancy between sections, and actionability gaps around how to discover project-specific commands and whether the Task() subagent syntax is a real API.

Suggestions

Clarify how to discover project-specific commands (e.g., check package.json scripts, Makefile targets, or common conventions) rather than just saying 'Run the project's test command'

Remove redundancy between the Goal Parsing table and the Cycle Workflow step 1 - consolidate into one location to save tokens

Specify whether Task() with subagent_type is a real API or a conceptual pattern, and if real, link to documentation for the subagent system

DimensionReasoningScore

Conciseness

The skill is moderately efficient but includes some unnecessary elements like the '[ULTRAQA ACTIVATED - AUTONOMOUS QA CYCLING]' banner, redundant explanations of goal types in multiple places, and the overview restating what the cycle workflow already shows. The tables and structured format help, but there's repetition between the goal parsing table and the cycle workflow step 1.

2 / 3

Actionability

The skill provides concrete Task() invocation patterns and example bash commands, but the core workflow relies on project-specific commands ('Run the project's test command') without specifying how to discover or determine those commands. The subagent invocations use a specific syntax but it's unclear if these are real APIs or pseudocode patterns.

2 / 3

Workflow Clarity

The multi-step cycle is clearly sequenced (run → check → diagnose → fix → repeat) with explicit exit conditions including max cycles, repeated failure detection, and environment errors. The exit conditions table serves as validation checkpoints, and the early exit on 3x same failure is a good feedback loop. State tracking and observability sections reinforce the workflow.

3 / 3

Progressive Disclosure

The content is reasonably well-organized with clear sections, but everything is in a single monolithic file with no references to external documentation. The state tracking JSON schema, observability format, and subagent invocation patterns could be split into referenced files. However, no bundle files exist to reference, and the content length is moderate enough that inline presentation is acceptable.

2 / 3

Total

9

/

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.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

10

/

11

Passed

Repository
Yeachan-Heo/oh-my-claudecode
Reviewed

Table of Contents

Is this your skill?

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.