sig-audit

Measure Fallow maintainability using the repository's SIG system properties and update the evidence-backed audit report.

Quality

66%

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/sig-audit/SKILL.md

Quality

Content

78%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 an exemplar of token efficiency with a clear sequenced workflow and an explicit verification step, but its steps are process-level rather than executable — they point at "the existing audit and measurement scripts" without naming commands or paths. Adding the concrete entry points (script names or example commands) and a recovery loop for failed verification would complete it.

Suggestions

Name the concrete entry points for steps 1-2, e.g., the audit report path and the measurement script invocation (or an example command), so the workflow is executable without discovery.

Add a feedback loop after step 6: what to do when repository verification fails (fix the changed tooling/docs and re-run verification before finishing).

State how to discover "every supported property" (e.g., where the list of supported SIG properties lives) so step 2 is unambiguous.

Dimension	Reasoning	Score
Conciseness	The body is roughly eight lines: a six-step numbered workflow plus one guard sentence ("Do not estimate missing metrics or turn a proxy into a measured result."). Every line instructs; there is no padding or explanation of concepts Claude already knows, matching the lean-and-efficient anchor.	5 / 5
Actionability	Steps name concrete artifacts ("the existing audit and measurement scripts", "commands, raw evidence locations, limitations, and current scores") but provide no executable detail — no script paths, commands, or file names to run, so execution requires inference. It is not a 2 because the guidance is specific about what to do at each step; not a 4 because no concrete command or pointer appears anywhere.	3 / 5
Workflow Clarity	A clear 1-6 sequence exists with an explicit validation step ("Run repository verification for any changed audit tooling or docs") and constraint checkpoints ("Update only claims supported by current measurements"). Not a 5 because there is no error-recovery feedback loop describing what to do when verification fails or a measurement is unsupported.	4 / 5
Progressive Disclosure	The skill is under 50 lines, needs no external references (none are referenced, and no bundle files exist), and the body is well organized as a numbered list plus a guard line — meeting the simple-skill exception for a top score.	5 / 5
	Total	17 / 20 Passed

Description

53%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 states a concrete, distinctive purpose but omits any "Use when..." trigger guidance, which caps both completeness and trigger-term quality. Adding an explicit usage clause with natural trigger phrases (maintainability audit, SIG scores, re-measuring a revision) would lift the weakest dimensions.

Suggestions

Add a trigger clause such as: "Use when asked to run or refresh a SIG maintainability audit, re-score a revision, or update audit claims after changes to Fallow."

Include natural synonyms users would say (e.g., "maintainability rating", "SIG scores", "audit report") next to the project-specific terms so the description matches real user phrasing.

Briefly enumerate the concrete actions covered (run property measurements, record evidence, compare revisions, update the report) to strengthen specificity.

Dimension	Reasoning	Score
Specificity	The description names its domain ("Fallow maintainability", "the repository's SIG system properties") and two concrete actions ("Measure... maintainability", "update the evidence-backed audit report"), matching the 1-2 concrete actions anchor. It is not a 4 because it stops at two actions and does not enumerate what measuring or updating entails.	3 / 5
Completeness	It clearly answers "what" (measure maintainability via SIG properties; update the audit report) but there is no "when should Claude use it" clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. Not a 2 because the "what" half is concrete rather than vague.	3 / 5
Trigger Term Quality	Relevant keywords exist ("maintainability", "SIG", "audit report"), but common variations and synonyms users might say (e.g., "code quality", "audit", "maintainability rating", "SIG 4.0") are missing, and "Fallow" is project-internal jargon. Not a 4 because keyword coverage is not good enough to catch natural phrasings beyond the narrow terms present.	3 / 5
Distinctiveness Conflict Risk	"Measure Fallow maintainability using the repository's SIG system properties" carves a clear niche unlikely to fire for unrelated skills, with only minor overlap risk against generic code-review or audit skills. Not a 5 because the absence of explicit trigger phrasing leaves some ambiguity about when this skill versus a general review skill should engage.	4 / 5
	Total	13 / 20 Passed

Validation

100%

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

Validation for skill structure

No warnings or errors.

Repository: fallow-rs/fallow
Path: .agents/skills/sig-audit/SKILL.md
Commit: 74177e5

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