Files
holocron/plugins/kyberforge/skills/agent-audit/scripts
Defame1297 1164f3abad fix(lint): make Vale prefilter portable via the plugin
skill-audit/agent-audit's Step 1 resolved vale-wrap.sh/.vale.ini via
`git rev-parse --show-toplevel`, which returns whichever repo the skill
happens to run in. Inside ai-development that works; in any external repo
that installs kyberforge@holocron as a plugin, it resolves to that repo's
own root, which has no .vale.ini — the prefilter silently fell back to
full LLM judgment. ADR-0013 named this as a deliberately deferred gap.

Vale's config/styles/wrapper now ship inside the plugin itself: a
canonical copy in agent-audit/assets/vale/ (Kyberforge + KyberforgeCopilot,
the superset agent-audit needs) and a smaller duplicate in
skill-audit/assets/vale/ (Kyberforge only) — per the no-cross-skill-path
rule already established for plugin cache-installs. Both skills resolve
these relative to their own directory, same as scripts/validate.sh
already does.

A new root .pre-commit-hooks.yaml exposes both copies plus
skill-size-check so any external repo can enforce the same rules via
`repo: <this-repo-url>, rev: <tag>` in its own pre-commit config,
independent of Claude Code entirely — the same mechanism covers CI. This
repo's own pre-commit hook now consumes the identical plugin-bundled
copies via repo: local (not a third root copy, and not a pinned
self-reference, which would lint working-tree edits against the last
tagged release instead of the change being made). Split into
vale-audit-prefilter-skill/-agent hooks after confirming, by diffing the
full corpus against both old and new config before deleting the old
files, that one combined hook pointed at only one copy silently 0-file-
skips the other file type.

scripts/check-vale-style-sync.sh guards the two copies against drift,
wired at pre-push alongside check-manifests.

ADR: 0014
2026-08-09 10:04:19 +00:00
..

scripts/

Executable code bundled with this skill. Agents run scripts in this directory to perform repeatable operations rather than reinventing the logic each run.

When to add a script

Add a script when agents independently reinvent the same logic across runs — building the same parser, chart, or validation routine from scratch each time. Bundle it here once, tested and reliable.

Script requirements (agentskills.io)

Scripts must be designed for non-interactive, agentic execution:

  • No interactive prompts — agents run in non-interactive shells. Accept all input via flags, env vars, or stdin. A script that blocks on TTY input hangs indefinitely.
  • Expose --help — this is how agents learn your script's interface. Keep the output concise; it enters the agent's context window.
  • Structured output — write data (JSON, CSV, TSV) to stdout. Write progress, warnings, and diagnostics to stderr.
  • Idempotent — prefer "create if not exists" over "create and fail on duplicate". Agents may retry on failure.
  • Meaningful exit codes — 0 for success, non-zero for failure. Use distinct codes for different failure types; document them in --help.
  • Dry-run support — add --dry-run for destructive operations.

Self-contained scripts

Bundle dependencies inline so the agent can run the script with a single command.

Python (PEP 723 + uv):

# /// script
# dependencies = ["requests>=2.31,<3"]
# requires-python = ">=3.11"
# ///
import requests
uv run scripts/my-script.py

If no scripts are needed

Delete this README and the scripts/ directory entirely.