Agent skill · operations · jeremylongshore
audit-standards
Audits the current project against the development standards defined in ~/.claude/CLAUDE.md. Documents non-compliant findings as GitHub issues and writes a prioritised fix plan to the project CLAUDE.md. Use when the user says audit against settings, audit standards, check standards compliance, or audit this project.
Why this skill is useful
Adds a comprehensive auditing script that checks compliance with specific development standards and generates actionable GitHub issues.
What it needs
Requires gh, markdownlint installed locally. About 4k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Audit Standards Project: !basename $(git rev-parse --show-toplevel 2>/dev/null) 2>/dev/null basename $PWD Branch: !git branch --show-current 2>/dev/null echo "unknown" Audits the current project against the personal development standards loaded from ~/.claude/CLAUDE.md. Generates actionable GitHub issues and a prioritised fix plan. The development standards from the user's global ~/.claude/CLAUDE.md are already loaded into context. The key principles to audit against are: 1. Codify, Don't Document — manual steps should be executable scripts 2. Bash Script UX with pfb — terminal output uses pfb with correct visual hierarchy 3. Markdown Standards — all markdown passes markdownlint with zero warnings 4. Professional Documentation Tone — formal docs are objective, not personal 5. Version Control Everything — correct files committed, secrets excluded 6. Fail Fast, Pivot Early — (process principle, skip for static audit) 7. Behavioral Integrity — (process principle, skip for static audit) Step 0: Pre-flight check Step 1: Inventory the project Also read: README.md — documentation tone and completeness CLAUDE.md — project AI context file exists and is current Any .env, .env.template, .gitignore — secrets handling Any .sh files — bash scripting standards Any .md files — markdown quality Step 2: Audit each principle Principle 1 — Codify, Don't Document Does the README describe manual steps that should instead be scripts? Do bash scripts use #!/usr/bin/env bash shebang? Do scripts have Google-Style header docs (name, description, author, version, usage, dependencies)? Do functions have @param, @return, @example doc comments? Is author attribution derived from git config user.name/git config user.email? Are scripts idempotent (safe to run multiple times)? Run: grep -rn "#!/" --include=".sh" . to find all scripts. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/audit-standards