agentleFS
broneqbroneq/bdk/.claude/skills/skill-lint/SKILL.md

skill-lint

Skill1 starsChanged 51 days agoMITView on GitHub

Lint a BDK skill or agent file for best practices and portability. Use when reviewing, creating, or editing a skill (skills/*.md) or agent (agents/*.md) to verify it meets BDK conventions. Trigger on phrases like "check this skill", "verify agent", "does this follow best practices", "lint skill", or when about to commit a new skill/agent.

9 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 0 are common, 6 are distinctive, and 13 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 13

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify BDK skill or agent file meets portability and quality conventions.

    line 12
  2. Distinctive:

    No arguments: ask user which file, or infer from recent context.

    line 17
  3. Very specific:

    Must contain name: field

    line 32
  4. Very specific:

    Test runners: pytest, go test, npm test, yarn test, cargo test, rspec, jest, mocha

    line 56
  5. Distinctive:

    Use generic phrasing: "run the project's test suite", "run the linter".

    line 60
  6. Very specific:

    If name: present: must match ^[a-z0-9-]{1,64}$.

    line 75
  7. Very specific:

    If description: present: WARN if >250 chars (truncated in skill listing).

    line 79
  8. Very specific:

    If effort: present: must be one of low, medium, high, xhigh, max.

    line 87
  9. Very specific:

    If agent: present but context: fork missing: WARN — agent: only applies with context: fork.

    line 91
  10. Very specific:

    If both disable-model-invocation: true AND user-invocable: false: FAIL — skill inaccessible.

    line 94
  11. Very specific:

    If body uses $ARGUMENT (no S): FAIL — correct variable is $ARGUMENTS or $ARGUMENTS[N].

    line 97
  12. Very specific:

    Check if agents/<name>.md exists in BDK repo.

    line 108
  13. Very specific:

    If exists → WARN: bare name found, use /bdk:<name> prefix.

    line 109
  14. Distinctive:

    If not exists → WARN: unknown agent dependency, not shipped with BDK.

    line 110
  15. Very specific:

    Check: list dir contents, scan SKILL.md body for each filename.

    line 128
  16. Very specific:

    All files pass → end with: All checks passed.

    line 219
  17. Distinctive:

    No fixes beyond check results unless user asks.

    line 221
  18. Very specific:

    Verify ALL 21 checks were executed for SKILL.md (not just the ones that seemed relevant):

    line 225
  19. Distinctive:

    Do not output the checklist.

    line 249

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “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
SKILL.md

Relies on BDK foundation (STARTUP_INSTRUCTIONS.md). Assumes environment discovery has already run (language, test runner, build tool are known).

Skill Lint

Verify BDK skill or agent file meets portability and quality conventions.

Determine target

  • $ARGUMENTS may be one or more space-separated paths.
  • No arguments: ask user which file, or infer from recent context.

Per path:

  1. Read file.
  2. List all files in skill directory (recursively). Every file other than SKILL.md is supporting file.
  3. Each supporting file: lint too (checks 3–6 only — portability checks), regardless of whether referenced in SKILL.md.

Print separate report block per file linted.

Run checks

Report each check as PASS, FAIL, or WARN with one-line reason.

1. Frontmatter present

  • File must start with ---
  • Must contain name: field
  • Must contain description: field

2. Model field

  • Agent files (agents/): model: required — FAIL if missing
  • Skill files (skills/): model: recommended — WARN if missing (some skills intentionally inherit)

3. No absolute paths

Fail if file contains:

  • /Users/, /home/, /root/, /opt/, /var/, C:\
  • Any hardcoded filesystem path

4. No project-specific file references

Warn if file refs files only in one project:

  • Patterns: specific filenames like src/foo.py, app/models/user.rb, internal/auth/handler.go
  • Exception: generic illustrative examples (e.g. <your-file>, path/to/file)

5. No project-specific instructions

Warn if file contains phrases tied to specific project:

  • "in this project", "this repo", "our codebase", specific org/team names
  • Hardcoded branch names, database names, service names

6. No language-specific commands

Fail if file hardcodes language/framework tooling:

  • Test runners: pytest, go test, npm test, yarn test, cargo test, rspec, jest, mocha
  • Build tools: mvn, gradle, cargo build, make (as build command)
  • Linters: ruff, eslint, golangci-lint, rubocop, flake8

Use generic phrasing: "run the project's test suite", "run the linter".

7. BDK foundation header (skills only)

Skills must start body (after frontmatter) with:

> Relies on BDK foundation (STARTUP_INSTRUCTIONS.md)...

FAIL if missing.

8. Skill cross-references use full namespace

Refs to other BDK skills must use /bdk: prefix.

  • FAIL on: /commit, /debug, /create-plan (bare names)
  • PASS on: /bdk:commit, /bdk:debug

9. name format valid

If name: present: must match ^[a-z0-9-]{1,64}$.

  • FAIL on uppercase, underscores, spaces, or >64 chars.

10. description length

If description: present: WARN if >250 chars (truncated in skill listing).

11. Invalid frontmatter fields

FAIL if file uses unsupported/obsolete frontmatter fields:

  • arguments: (list of objects) — replaced by argument-hint:
  • Any field not in: name, description, argument-hint, disable-model-invocation, user-invocable, allowed-tools, disallowed-tools, model, effort, context, agent, background, hooks, paths, shell

12. effort valid value

If effort: present: must be one of low, medium, high, xhigh, max.

  • FAIL on any other value.

13. context + agent combo

If agent: present but context: fork missing: WARN — agent: only applies with context: fork.

14. Dead skill combo

If both disable-model-invocation: true AND user-invocable: false: FAIL — skill inaccessible.

15. $ARGUMENT typo

If body uses $ARGUMENT (no S): FAIL — correct variable is $ARGUMENTS or $ARGUMENTS[N].

16. External skill/agent references

BDK skills depend only on BDK-owned skills. Flag /slash-command and agent name invocations NOT prefixed /bdk:.

Slash command refs (/name in body):

  • WARN on bare /name refs (e.g. /commit, /debug) — ambiguous, may resolve to wrong skill
  • WARN on /other-plugin:name — hard dep on external plugin not guaranteed present
  • PASS on /bdk:name — BDK namespace, expected

Agent refs (backtick or plain agent-name in body, e.g. `test-runner`):

  1. Check if agents/<name>.md exists in BDK repo.
  2. If exists → WARN: bare name found, use /bdk:<name> prefix.
  3. If not exists → WARN: unknown agent dependency, not shipped with BDK.

17. Skill directory format

Per Claude Code skills spec, each skill must live at <skill-name>/SKILL.md.

  • FAIL if filename not exactly SKILL.md (case-sensitive)
  • WARN if parent dir name doesn't match name field in frontmatter (causes confusing dual identities)

18. Artifacts go to .bdk/

Skills producing file output must write to .bdk/ in project root, not arbitrary dirs.

  • FAIL if skill body instructs writing to docs/, output/, tmp/, reports/, or other non-.bdk paths
  • PASS if output path is .bdk/... or no file output produced
  • Exception: skills writing code/config into project structure as part of code-gen task (not report/artifact output)

19. No unused files in skill directory

List all files in skill directory (recursively). Every file other than SKILL.md must be referenced in skill body (markdown link, inline code mention, or explicit filename reference).

  • WARN for each file present but not referenced anywhere in SKILL.md
  • Exception: SKILL.md itself always exempt

Check: list dir contents, scan SKILL.md body for each filename. Not found → WARN.

20. Valid skill directory structure

Allowed layout:

<skill-name>/
├── SKILL.md            ← required, exactly this name
├── references/
│   └── *.md            ← templates and reference docs
├── examples/
│   └── *.md            ← example output files only
├── scripts/
│   └── *               ← executable scripts only (*.sh, *.py, etc.)
└── fragments/
    └── *.md            ← conditional injection targets

Rules:

  • FAIL if any subdirectory other than examples/, references/, scripts/, or fragments/ exists
  • WARN if fragments/ contains non-.md files
  • WARN if *.md template/reference files sit at root level instead of references/ — suggest moving
  • WARN if examples/ contains non-.md files
  • WARN if references/ contains non-.md files
  • WARN if scripts/ contains non-script files (non-executable or non-.sh/.py/.js/.rb extensions)
  • WARN if any file at root level that is not SKILL.md (e.g. .sh scripts at root → scripts/, .md files → references/)
  • PASS if only SKILL.md present (minimal valid structure)

21. Inject conditions use a recognised form

For every !...inject.py ...`` call in the body, check each --if / --prefer condition against the three forms scripts/inject.py actually parses:

FormMeaning
features.<key>settings.features.<key> is true
tool.<binary><binary> is on PATH
<field>[<value>]<value> is in the settings.<field> list
  • FAIL on anything else (e.g. languages.react, feature.react, tool[lavish-axi]) — name the line and the correct spelling.
  • The two near-misses matter most because they fail silently: languages.react matches no regex and raises, while tool[lavish-axi] is happily parsed by the array rule as a lookup in a nonexistent tool list and evaluates false forever. Neither looks broken in the rendered skill.
  • Also FAIL a --then path that does not exist, for the same reason: a missing fragment renders as an absent one.

22. Stated tool invariants are enforced

allowed-tools is pre-approval, not a whitelist: listing tools there restricts nothing. When a skill's body states that it must never call a tool, the restriction belongs in disallowed-tools, which removes the tool from the pool.

WARN when the body asserts such an invariant and the frontmatter does not back it:

Body says something likeExpected frontmatter
"autonomous", "no human-in-loop", "never ask the user mid-flow"disallowed-tools: AskUserQuestion
"read-only", "MUST NOT modify source files", "never edit"disallowed-tools: Edit NotebookEdit (plus Write when the skill writes nothing at all)

Name the body line and the missing field. Do not FAIL: a skill may legitimately need the tool on some path, and the field cannot express "only for X". PASS when the invariant is absent or already backed.

Output format

One report block per file. Supporting files get abbreviated reports (checks 3–6 only).

SKILL LINT: skills/brainstorming/SKILL.md
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PASS  Frontmatter present (name, description)
FAIL  No model defined — agent files require model:
PASS  No absolute paths
WARN  Project-specific reference: src/auth/middleware.py (line 14)
PASS  No project-specific instructions
FAIL  Language-specific command: pytest (line 22) — use "run the project's test suite"
PASS  BDK foundation header present
PASS  Skill references use /bdk: namespace
PASS  name format valid
PASS  description length OK
PASS  No invalid frontmatter fields
PASS  Directory format correct (SKILL.md, dir matches name)
WARN  External skill reference: /deploy (line 44) — use /bdk: prefix or remove dependency
FAIL  Artifact path: docs/designs/ (line 88) — skills must write artifacts to .bdk/
WARN  Unused file: examples/old-sample.md — not referenced in SKILL.md
PASS  Directory structure valid (SKILL.md, examples/, scripts/)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2 failures, 2 warnings

SKILL LINT: skills/brainstorming/reference.md  [supporting file — portability checks only]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PASS  No absolute paths
PASS  No project-specific file references
PASS  No project-specific instructions
PASS  No language-specific commands
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
All checks passed.

All files pass → end with: All checks passed.

No fixes beyond check results unless user asks.

Checklist before responding

Verify ALL 21 checks were executed for SKILL.md (not just the ones that seemed relevant):

  • 1. Frontmatter present
  • 2. Model field
  • 3. No absolute paths
  • 4. No project-specific file references
  • 5. No project-specific instructions
  • 6. No language-specific commands
  • 7. BDK foundation header
  • 8. Skill cross-references use full namespace
  • 9. name format valid
  • 10. description length
  • 11. Invalid frontmatter fields
  • 12. effort valid value
  • 13. context + agent combo
  • 14. Dead skill combo
  • 15. $ARGUMENT typo
  • 16. External skill/agent references
  • 17. Skill directory format
  • 18. Artifacts go to .bdk/
  • 19. No unused files in skill directory
  • 20. Valid skill directory structure
  • 21. Inject conditions use a recognised form

Do not output the checklist. Use it internally to confirm no check was skipped.

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.