fla-correctness-coverage

Guidelines for kernel correctness testing and coverage in fla/ops/** and related modules, including common Triton grid/addressing pitfalls. Helps decide what tests to add or run before an MR.

Quality

68%

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 ./.agents/skills/fla-correctness-coverage/SKILL.md

Quality

Content

75%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 is well-structured, lean, and highly actionable with concrete commands, paths, and named helpers, supported by clearly signaled one-level-deep reference files.

Suggestions

Add a short copy-paste example of a parameterized kernel correctness test (covering e.g. varlen + backward) to close the actionability gap for authoring new tests.

Make the workflow's feedback loop explicit (e.g., 'If tests fail, fix the kernel or test and re-run until all dependent tests pass') to push workflow clarity toward 5.

Consider moving the 'What NOT to put in this skill' meta-guidance into a maintainer note or the description so the user-facing body stays purely operational.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence (no explaining what kernels, coverage, or Triton are); every section adds project-specific knowledge, with only minor trailing explanatory clauses that could be trimmed, matching the 'efficient, minor instances of over-explanation' anchor.	4 / 5
Actionability	It provides concrete executable pytest commands, specific test paths, named helpers (IS_NVIDIA, fla.utils.device, TensorDescriptor), and a runnable script; the gap is the absence of any example test code for authoring new kernel tests, matching the 'mostly executable guidance, minor gaps' anchor.	4 / 5
Workflow Clarity	A clear 4-step numbered workflow with an explicit verification step ('Run the relevant tests and make sure they pass') plus multi-backend verification guidance in the safety-checks section; it lacks an explicit fix-and-re-run feedback loop, matching the 'clear sequence, most checkpoints present, minor validation gaps' anchor.	4 / 5
Progressive Disclosure	Well-structured with clear section headers, and the four reference files are one-level-deep and clearly signaled with per-file descriptions plus 'do not load every reference by default' guidance; minor organization gaps (e.g., the meta 'What NOT to put' section) keep it just under the ideal anchor.	4 / 5
	Total	16 / 20 Passed

Description

61%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 is specific to a clear niche and uses natural domain keywords, but its trigger guidance is soft rather than an explicit 'Use when...' directive and the 'Guidelines for...' framing is slightly abstract.

Suggestions

Add an explicit 'Use when adding or modifying a kernel in fla/ops and you need to verify correctness or close a coverage gap before an MR.' trigger clause to lift completeness.

Reframe the opening from 'Guidelines for...' to concrete verbs (e.g., 'Verifies kernel correctness and closes coverage gaps in fla/ops/**') to strengthen specificity.

Include the full phrase 'merge request' alongside 'MR' and add synonyms like 'regression test' / 'unit test' to broaden trigger term coverage.

Dimension	Reasoning	Score
Specificity	Names the domain ('kernel correctness testing and coverage in fla/ops') and several concrete areas (Triton grid/addressing pitfalls, deciding tests before an MR), but the 'Guidelines for...' framing is more abstract than crisp action verbs, so it sits at the anchor naming domain plus a few concrete actions rather than a comprehensive action list.	3 / 5
Completeness	The 'what' is clear, but the 'when' is only soft trigger guidance ('Helps decide what tests to add or run before an MR') rather than an explicit 'Use when...' clause, which the guidelines cap at 3.	3 / 5
Trigger Term Quality	Natural domain keywords are well covered ('kernel', 'correctness', 'testing', 'coverage', 'Triton', 'tests', 'MR'), matching the 'good keyword coverage, a few natural terms missing' anchor; full forms like 'merge request' and synonyms like 'unit/regression test' are absent.	4 / 5
Distinctiveness Conflict Risk	It carves a clear niche (fla/ops kernel correctness/coverage) with distinct triggers and minimal conflict risk, but the 'before an MR' phrasing creates minor overlap with a sibling MR-readiness skill, matching the 'mostly distinct, minor overlap' anchor.	4 / 5
	Total	14 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 1 missing	Warning

	Total	15 / 16 Passed

Repository: fla-org/flash-linear-attention
Path: .agents/skills/fla-correctness-coverage/SKILL.md
Commit: 27967b9

Reviewed: 3 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.