aif-qa-check

Executes QA test cases created by /aif-qa in human-guided or automated-agent mode, including reusable browser replay scripts. Use when you need to walk through QA one case at a time, record pass/fail results, or have an agent verify and rerun cases through browser, CLI, API, automated tests, or file/document checks.

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/aif-qa-check/SKILL.md

Quality

Content

62%Weight 40%Scale 1-5

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

The body provides a well-sequenced, highly actionable QA workflow with strong validation and feedback loops, but it is let down by significant redundancy (a 25-rule restatement of the steps) and a lack of progressive disclosure for a skill this large. Splitting reference material and de-duplicating the rules would materially improve it.

Suggestions

Move the digest-canonicalization, worktree-digest, and branch-slug algorithms into a references/ file and link to them, reducing the main body and improving progressive disclosure.

Remove the standalone Critical Rules section or collapse it to a short pointer, since it duplicates the Step 1-3 guidance; keep the rules inline where they are enforced.

De-duplicate the redaction and agent-context/history policy so each is stated once authoritatively and referenced elsewhere.

Dimension	Reasoning	Score
Conciseness	The ~370-line body is noticeably verbose: the 25-item Critical Rules section restates the workflow steps, and redaction plus agent-context/history policy each recur 2-3 times across Steps 0.1, 1.1, 3, and Artifact Ownership, which is padded redundancy rather than novel content.	2 / 5
Actionability	Concrete executable commands are given throughout (`git branch --show-current`, `git hash-object --stdin`, `git status --porcelain=v1 --untracked-files=all`, `git diff --binary HEAD --`) plus a spelled-out branch-slug algorithm, but no complete runnable browser-replay script example is shown, leaving minor gaps at anchor 4.	4 / 5
Workflow Clarity	The Step 0 through Step 4 sequence is clearly ordered with explicit validation checkpoints (source/case/worktree digests, staleness gates, replay proof runs, per-case authorization) and feedback loops (stale -> retest, repair -> recompute digest -> proof run), matching anchor 5; the destructive-op validation cap does not apply because validation is extensive.	5 / 5
Progressive Disclosure	The skill is a single ~370-line monolith with clear section headers but no reference/scripts/assets bundle to offload detail; the digest-canonicalization, branch-slug, and Critical Rules material is inlined content that could live in separate reference files, placing it at anchor 3.	3 / 5
	Total	14 / 20 Passed

Description

78%Weight 40%Scale 1-5

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 clearly states both what the skill does and when to use it, with strong trigger-term coverage and a distinct QA-execution niche. Its main weakness is the second-person 'Use when you need to' phrasing, which violates the third-person voice guideline and caps specificity.

Suggestions

Rewrite the trigger clause in third person to avoid the voice penalty, e.g. 'Use when walking through QA one case at a time, recording pass/fail results, or having an agent verify and rerun cases ...'.

Add 1-2 common synonyms such as 'retest' or 'regression' to broaden natural trigger-term coverage.

Sharpen the 'what' clause with one more distinct concrete action so specificity reaches anchor 4 even before the voice adjustment.

Dimension	Reasoning	Score
Specificity	The 'what' clause names the domain and only 1-2 concrete actions ('Executes QA test cases ... including reusable browser replay scripts'), and the second-person 'Use when you need to' phrasing triggers the voice penalty, capping it at anchor 3 rather than 4.	3 / 5
Completeness	Both 'what' (executes /aif-qa test cases in human or agent mode with replay scripts) and 'when' ('Use when you need to walk through QA one case at a time, record pass/fail results, or have an agent verify and rerun cases ...') are explicit with concrete trigger phrases, matching anchor 5.	5 / 5
Trigger Term Quality	Good natural-keyword coverage ('QA', 'test cases', 'pass/fail results', 'browser', 'CLI', 'API', 'automated tests', 'file/document checks', 'rerun cases'), but a few common synonyms like 'regression' or 'retest' are missing, so it sits at anchor 4 rather than 5.	4 / 5
Distinctiveness Conflict Risk	The /aif-qa binding and QA-execution niche make it mostly distinct with minimal conflict risk, but it sits adjacent to the /aif-qa creator skill, so anchor 4 (minor overlap with a closely related skill) fits better than 5.	4 / 5
	Total	16 / 20 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
allowed_tools_field	'allowed-tools' contains unusual tool name(s)	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	14 / 16 Passed

Repository: lee-to/ai-factory
Path: skills/aif-qa-check/SKILL.md
Commit: ac92beb

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

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.