agentleFS
jmolzjmolz/m0lz.01/.agents/skills/source-command-validate/SKILL.md

source-command-validate

Skill0 starsChanged 6 months agoMITView on GitHub

Run comprehensive validation across the entire codebase

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

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

    Use this skill when the user asks to run the migrated source command validate.

    line 8
  2. Distinctive:

    Run every available validation tool to ensure the codebase is healthy.

    line 15
  3. Distinctive:

    Check what validation tools exist in this project:

    line 21
  4. Distinctive:

    Run the project's linter (eslint, ruff, clippy, etc.)

    line 43
  5. Distinctive:

    Run the type checker if available:

    line 52
  6. Distinctive:

    Run the test suite:

    line 70
  7. Distinctive:

    Verify the project builds:

    line 79
  8. Distinctive:

    Run any integration or end-to-end tests:

    line 88
  9. Distinctive:

    Don't run tools that aren't configured (no phantom validation)

    line 119
  10. Distinctive:

    If a check doesn't exist yet, note it as a gap

    line 120

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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
SKILL.md

source-command-validate

Use this skill when the user asks to run the migrated source command validate.

Command Template

Validate: Full Codebase Check

Run every available validation tool to ensure the codebase is healthy.

Process

1. Discover Available Tools

Check what validation tools exist in this project:

# Check for package.json scripts
cat package.json 2>/dev/null | grep -A 50 '"scripts"' | head -60

# Check for Python project tools
cat pyproject.toml 2>/dev/null | head -40

# Check for Makefile
cat Makefile 2>/dev/null | grep '^[a-z]' | head -20

# Check for CI config
ls .github/workflows/ 2>/dev/null
cat .github/workflows/*.yml 2>/dev/null | head -80

2. Run Validation Pyramid

Execute each level in order. Fix failures before proceeding.

Level 1: Linting

Run the project's linter (eslint, ruff, clippy, etc.)

# Examples — use whatever this project has:
# npm run lint
# ruff check .
# cargo clippy

Level 2: Type Checking

Run the type checker if available:

# Examples:
# npx tsc --noEmit
# mypy .
# cargo check

Level 3: Formatting

Check code formatting:

# Examples:
# npx prettier --check .
# ruff format --check .
# cargo fmt --check

Level 4: Unit Tests

Run the test suite:

# Examples:
# npm test
# pytest
# cargo test

Level 5: Build Check

Verify the project builds:

# Examples:
# npm run build
# uv run python -m py_compile main.py
# cargo build

Level 6: Integration / E2E (if available)

Run any integration or end-to-end tests:

# Examples:
# npm run test:e2e
# pytest tests/integration/

3. Report Results

## Validation Report

| Check | Status | Details |
|-------|--------|---------|
| Lint | ✅/❌ | {error count or "clean"} |
| Types | ✅/❌ | {error count or "clean"} |
| Format | ✅/❌ | {files needing format or "clean"} |
| Tests | ✅/❌ | {passed/failed/skipped counts} |
| Build | ✅/❌ | {success or error summary} |
| E2E | ✅/❌/⏭️ | {results or "not configured"} |

### Issues Found
{List any failures with file paths and brief descriptions}

### Recommended Fixes
{For each issue: what to change and where}

Notes

  • Adapt to whatever tools this project actually uses
  • Don't run tools that aren't configured (no phantom validation)
  • If a check doesn't exist yet, note it as a gap
  • Fix issues in order: lint → types → format → tests → build

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.