skill-audit
Skill Audit
Audit a skill before calling it ready. Favor Tessl output, repo conventions, and the skill's actual file shape over taste.
Tessl is the skill-evaluation CLI this repo uses to review skills, score their quality, and suggest improvements. See tessl.io and the CLI docs. If npx tessl ... or tessl ... is unavailable, install or initialize Tessl before running the audit loop.
Principles
- Evidence beats hunches
- Discovery matters: score
nameanddescriptionbefore polishing the body - Keep
SKILL.mdlean; move depth intoreferences/or scripts only when they earn their keep - Prefer the smallest change set that improves activation, clarity, or verification
- Audit only the requested scope; flag adjacent issues separately
Handoffs
- Need to update AGENTS, README, or other repo docs beyond the skill surface -> use
docs - Need to prove a product or code change works on real surfaces -> use
verify - Need to review general code or a PR instead of a skill package -> use
review
Before You Start
- Define scope: one skill folder or the whole skills repo
- Load the target repo's guidance files such as
AGENTS.md,CLAUDE.md, or repo rules, when present - Read the target
SKILL.mdfirst, then nearbyreferences/,scripts/, andagents/openai.yamlonly as needed - Pick the right Tessl loop:
- single skill:
npx tessl skill review --json skills/<name> - full repo batch: use a repo wrapper such as
./scripts/skills/review.shif one exists; otherwise run direct Tessl reviews per skill - optimizer only when explicitly requested:
npx tessl skill review --optimize --yes --max-iterations 1 skills/<name>
- single skill:
Workflow
1. Run Tessl first
Capture the score, summary, and concrete suggestions before proposing edits. Prefer per-skill --json when you need a narrow audit loop or structured output. If Tessl is missing, use npx tessl ... first or follow the official docs before continuing.
2. Audit discovery
Use references/scorecard.md to check:
- whether
nameis specific and memorable - whether
descriptionstates what the skill does, when to use it, and its main boundary - whether likely user phrasing would activate the skill without extra prompting
Quick example:
- weak:
helper— "Helps with skills" - stronger:
skill-audit— "Audits existing skills with Tessl scoring, metadata checks, and repo conventions"
3. Audit workflow shape
Check that the skill tells the agent how to start, what evidence to gather, what not to change, and what "done" looks like.
Concrete failure signs:
- vague verbs like "help" without a workflow
- missing output expectations
- commands or paths that cannot be run as written
- a fragile task described with high-level prose instead of tighter guardrails
4. Audit progressive disclosure
Check whether detail belongs in SKILL.md, references/, or executable scripts:
- keep core workflow in
SKILL.md - move dense doctrine, examples, or score rubrics into
references/ - use scripts for repeated deterministic work instead of asking the model to recreate them
Use references/best-practices.md when the skill feels bloated, under-specified, or hard to trigger.
5. Audit repo fit
Check for repo-relative links, stale paths, duplicated guidance, and conflicts with the source repo's conventions.
6. Synthesize the smallest useful change set
Separate blockers from polish. If edits are requested, fix the highest-leverage issues first, rerun Tessl, and report what improved.
Output
After an audit, report a compact audit footer:
- scope audited
- Tessl command and score
- findings: highest-priority issues only, or
none - changes: files changed or smallest recommended change
- rerun status if edits were made
Keep details compact:
- Do not paste long Tessl output; report the score and only actionable suggestions
- Keep the footer to 5 labeled lines or fewer
- If edits were made, avoid restating every diff hunk; name the behavioral change and verification
References
- references/scorecard.md — audit dimensions, severity, and a compact review template
- references/best-practices.md — distilled skill-authoring guidance from common repo conventions and Claude's skill best-practices guide
More from uinaf/agents
docs-keeper
Maintain project documentation with clear human/agent separation. Use when setting up a new project, auditing docs, creating plans, or managing agent working memory. Triggers include "set up docs", "create a plan", "audit documentation", "init project structure", or any task involving project documentation conventions.
10gh-release-pipeline
Set up or align a GitHub Actions release pipeline for a versioned package, library, CLI, or marketplace action. Use when standardizing repos around the verify-then-release shape: push to main → guardrails → semantic-release tags + publishes → version-bump commit back to main with `[skip ci]`. Pairs with `gh-deploy-pipeline` for running apps; use for publishing versioned artifacts to a registry, not deploying a running service.
10verify
Self-check your own completed change before handing off to `review` — the pre-review sanity pass. Use when you want to check your work, run checks, validate changes, make sure a change is ready, test it end-to-end, run repo guardrails (lint, typecheck, tests, build), exercise the real surface with evidence, and catch obvious self-correctable issues. Produces a `ready for review` / `needs more work` / `blocked` verdict — never a ship decision. If the repo cannot be booted or exercised reliably, hand off to `agent-readiness`. If auditing someone else's diff, branch, or PR, use `review` instead.
9viteplus
Migrate or align frontend repositories to the stock VitePlus workflow. Use when standardizing package or monorepo repos around `vp`, `voidzero-dev/setup-vp`, `vite-plus/test`, and VitePlus-native CI, test, packaging, and hook flows. Default to replacing direct package-manager and Vitest wiring with the VitePlus equivalents unless the repo has a proven exception.
9review
Independently audit existing code, diffs, branches, or pull requests using concern-specific reviewer personas and evidence. Use when triaging risk in a PR, deciding whether a change is safe to ship, or following up on a `verify` pass to make the call the builder cannot make on their own work. Produces a `ship it` / `needs review` / `blocked` verdict. Do not use to self-check a change you just authored; use `verify` for that.
9agent-readiness
Audit and build the infrastructure a repo needs so agents can work autonomously — boot scripts, smoke tests, CI/CD gates, dev environment setup, observability, and isolation. Use when a repo can't boot, tests are broken or missing, there's no dev environment, agents can't verify their work, or agents need human help to get anything done. Do not use for reviewing an existing diff or for documentation-only cleanup.
9