Files
holocron/plugins/kyberforge/.apm/skills/skill-audit/SKILL.md
Defame1297 60be7b3232 refactor(skills): mandate metadata.version on every skill's frontmatter
Only 12 of 39 skills carried metadata.version, and adoption tracked
which plugin a skill lived in rather than any stated rule: core,
gitea and lint were consistent adopters, bin and kyberforge were
consistent non-adopters, git was split with one outlier. There was
no documented convention, and skill-author's own bump logic was
already written as if presence were conditional.

metadata.version is now required on every skill. The 19 skills here
that never carried one (bin, kyberforge, gitea-files) are seeded at
1.0.0, not 0.1.0 -- that value stays reserved for a skill's actual
creation point under skill-author's existing convention. The
skill-frontmatter pre-commit hook now fails a SKILL.md missing the
field, the same class of failure as a missing name/description.

Full rationale in the new ADR. The git-plugin skills that also need
this field follow in the next commit, bundled with issue #113's rtk
normalization since both touch the same files.

Refs: #127
ADR: 0022
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
2026-09-07 20:36:24 +00:00

5.3 KiB

name, description, allowed-tools, metadata
name description allowed-tools metadata
skill-audit Use when the user wants a skill directory audited against the agentskills.io spec — "audit this skill", "review my SKILL.md", "is this ready to ship" — or after hand-editing a skill outside skill-author. Not applying fixes -> skill-author. Bash Read
version category source_keys
1.0.0 factory
agentskills-home
agentskills-spec
agentskills-best-practices
agentskills-optimizing-descriptions
agentskills-using-scripts

Gotchas

  • Do not narrate PASS/FAIL per check while auditing. Gather findings internally and surface them only in the Step 4 report. Narrating each check as you go is the default failure mode here.
  • A skill carrying disable-model-invocation: true is hand-invoked — its description is never routed against, so the trigger, capability and boundary rules do not apply. Audit it as one plain human-facing sentence instead.
  • validate.sh reports two independent length families: the 500-line / 2,770-word pair counts the whole file for spec conformance, while the 250/400-character and 600/900-word pair is the house context budget and its word half counts the body only. A skill can sit inside one and fail the other — report them separately.
  • Vale reporting 0 files scanned means NOT RUN, not clean. Fall back to full Step 3 judgment for every dimension it would have covered.

Step 1 — Deterministic checks

Resolve all three paths against this skill's own directory so they work from a repo checkout and an installed plugin cache alike. Run exactly:

bash scripts/validate.sh <skill-dir>
bash scripts/validate-provenance.sh <skill-dir>
bash scripts/vale-wrap.sh <skill-dir>/SKILL.md

validate.sh findings become the ### Structure dimension — its FAILs and its SUGGESTIONs both, at the tier the script assigned. Report each once; never re-grade one under another dimension. Unresolved boundary targets are where this bites, because their tier turns on notation.

If any of the three cannot run, or exits non-zero for a reason other than findings, read references/validation-scripts.md — it carries the manual fallback and the misleading exit codes. Ordinary content FAILs are the expected outcome here and need no fallback.

validate-provenance.sh prints nothing on success, so read its exit code before you read its silence. 0 is a genuine pass. 1 means real findings: its FAILs and INFOs become a separate ### Provenance dimension, and it emits Why and Fix itself — surface those verbatim. 2 means the check never ran — a usage or environment error, reason on stderr, no findings and often no stdout at all. On a 2, report ### Provenance as unverified and quote the stderr reason. Never grade an exit 2 as a clean pass: empty stdout there means nothing was checked, not that nothing was wrong.

vale-wrap.sh applies the bundled Kyberforge style as a prefilter. Pass no --config; the wrapper locates its own. Every rule is graded error, so every alert is a FAIL. Report each one citing its rule ID, filed under the dimension it belongs to, and do not re-derive it by judgment:

Rule Dimension
Kyberforge.DescriptionOpener, Kyberforge.CompositionNote, Kyberforge.VagueWording description
Kyberforge.SentenceOpenerThereIs body-discipline
Kyberforge.PaddingPhrase patterns

Step 2 — Read the whole skill

Read SKILL.md, README.md, and every text file under scripts/, references/, assets/ and tests/. Skip binaries only — internal-consistency findings need the full picture.

Step 3 — Qualitative audit

Read references/finding-criteria.md first — every dimension's FAIL and SUGGESTION criteria. Load the rubric below only for a dimension the criteria put in play: one carrying a candidate finding, or one where the criterion alone does not settle the call.

Dimension Rubric
description references/description-quality.md
body-discipline references/body-discipline.md
patterns references/patterns.md
file-structure, internal-consistency references/file-structure.md
formatting, scripts references/formatting-and-scripts.md

Each rubric is self-contained and grounded in the agentskills.io specification plus the house context budget (ADR-0020). Cite file and line number for every finding.

Step 4 — Report

Open with a coverage line naming every dimension checked:

Checked: structure · description · body-discipline · patterns · file-structure · formatting · scripts · internal-consistency · provenance

Then output only the dimensions that have findings, grouped under H3 headings, FAILs before SUGGESTIONs within each. Omit clean dimensions — their absence is what confirms they passed.

Each finding:

FAIL/SUGGESTION  <finding> — file:line
                 Why: <why this is a problem>
                 Fix: <exact change — quote before/after where applicable>

Close with a ## Result block holding one line: PASS, PASS (N suggestions), or FAIL (N fails · M suggestions), each optionally followed by · P info. INFO findings are observational and never change PASS/FAIL; omit · P info when there are none. Add a second line, Run skill-author to address findings., whenever there is at least one finding. Do not apply fixes — report and propose only.