agentleFS
Sign inStart free
jara-r-kjara-r-k/claude-code-skills/.github/workflows/AGENTS.md

claude-code-skills / workflows

AGENTS.md1 starsChanged 46 days agoMITView on GitHub

CI for the repo: one GitHub Actions workflow that structurally validates every skill, example, and agent file. It is the only automated gate — a single inline Bash step on ubuntu-latest after actions/checkout@v4, with no external tooling. - Run the step locally from the repo root before pushing: awk '/^ run: \|/{f=1;next} f' .github/workflows/validate-skills.yml | sed 's/^ //' | bash The extraction assumes run: | at 8-space and the script body at 10-space indentation — adjust it if the YAML…

The file

We split this AGENTS.md into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Only agents/*.md can match a non-agent file.

    line 25
  2. Very specific:

    Run the step locally from the repo root before pushing: awk '/^ run: \|/{f=1;next} f' .github/workflows/validate-skills.yml | sed 's/^ //' …

    line 30
  3. Distinctive:

    After changing a check, prove it fails a deliberately bad file in a scratch copy before relying on it.

    line 33
  4. Distinctive:

    Add new rules inside the existing loops rather than new jobs — the whole check is one shell step.

    line 38

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md
<!-- Parent: ../AGENTS.md --><!-- Generated: 2026-09-27 | Updated: 2026-09-27 -->

.github/workflows/

Purpose

CI for the repo: one GitHub Actions workflow that structurally validates every skill, example, and agent file. It is the only automated gate — a single inline Bash step on ubuntu-latest after actions/checkout@v4, with no external tooling.

Key Files

FileDescription
validate-skills.yml"Validate Skills" — on push/pull_request touching skills/**, agents/**, examples/**, or .github/workflows/**, checks skills/*/SKILL.md, examples/*/SKILL.md, and agents/*.md (minus AGENTS.md); exits 1 on any hard failure

For AI Agents

Working In This Directory

  • Hard checks (increment errors, exit 1): line 1 exactly ---; name: present with no uppercase, _, or spaces (a trailing space counts); description: present, ≤ 1024 chars, no </>; wc -w of the whole file ≤ 5,000. Agents get only the --- check and a non-empty name:.
  • Warnings only: no ## error/## troubleshoot heading, no ## example heading (case-insensitive substring match).
  • Parsing is line-based grep, not YAML: name:/description: are the first matching lines anywhere in the file, and only the description's first line is read — description: > fails the angle-bracket check, description: | escapes the length check.
  • Globs are one level deep: references/** and nested files are never validated, and changes to root files, scripts/, or README.md do not trigger the workflow.
  • The per-file log prints OK (N words) even after that file's FAIL lines — trust the final summary line and exit code.
  • Only agents/*.md can match a non-agent file; the AGENTS.md basename skip (commit f0911af) exists for the deepinit map there. Any other non-agent .md in agents/ will fail.
  • GitHub Actions loads only .yml/.yaml files here, so this AGENTS.md is inert — but editing it still triggers a run via the path filter.

Testing Requirements

  • Run the step locally from the repo root before pushing: awk '/^ run: \|/{f=1;next} f' .github/workflows/validate-skills.yml | sed 's/^ //' | bash The extraction assumes run: | at 8-space and the script body at 10-space indentation — adjust it if the YAML is reindented.
  • After changing a check, prove it fails a deliberately bad file in a scratch copy before relying on it.

Common Patterns

  • Errors print FAIL: … and increment errors; warnings print WARN: … and never affect the exit code.
  • Add new rules inside the existing loops rather than new jobs — the whole check is one shell step.

Dependencies

External

  • GitHub-hosted ubuntu-latest runner, actions/checkout@v4, POSIX tools (grep, sed, wc, head)
<!-- MANUAL: -->

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free