agentleFS
fmindfmind/dot/.agents/skills/dot-verify/SKILL.md

dot-verify

Skill13 starsChanged 4 days agoMITView on GitHub

Qualify the fmind/dot working tree before a release: review changes, sync docs, run every gate, and smoke-test the dot CLI.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    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:

    Synchronize docs: check README.md, AGENTS.md, dot_agents/AGENTS.md, .github/*.md, .agents/skills/, and skills/ against the code: removed or …

    line 21
  2. Very specific:

    Check the workstation: when tools or dotfiles changed: mise run diff preview, dot orphan for retired targets (report, never delete), and …

    line 24

≈ “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

Verify Dot

Prove that the current checkout (committed and uncommitted work) is correct, documented, and releasable. This skill sequences the owners; full-review, repository-docs, dot-development, and dot-skills own the details. Verification fixes findings in place but never commits, pushes, or releases; dot-release owns that.

Workflow

  1. Record the baseline: record git status --short, staged and unstaged diffs, untracked files, and git fetch state against origin/main. Commits already on main since the last tag are part of the candidate; preserve unrelated work.
  2. Review the change set: list what changed since the last tag (git diff <tag>) plus uncommitted work, excluding generated locks. For large sets, fan out read-only reviews by area (dot Python, chezmoi and host config, docs and skills) and verify each finding against code or real local data before fixing. Behavior fixes need regression tests per dot-development.
  3. Synchronize docs: check README.md, AGENTS.md, dot_agents/AGENTS.md, .github/*.md, .agents/skills/, and skills/ against the code: removed or renamed files, commands and flags (uv run --frozen --project dot dot <command> --help), tasks (mise tasks), and JSON fields. Bump updated: on changed skills; run mise run format:skills for guide indexes; follow dot-skills for catalog changes.
  4. Run the gates: mise run format (isolated when unrelated edits are present), mise run all, then the host checks it omits: mise run check:completions and mise run test:starters. Rerun only what a later fix invalidates.
  5. Smoke-test the CLI from the repository root with uv run --frozen --project dot dot (--directory dot would resolve . to dot/): --help for every top-level command, then read-only commands: doctor, agent doctor, agent context --check, config show, status, orphan, cache, prune --dry-run, prune --aggressive --dry-run, pull --dry-run, trust --dry-run ., and agent stats --no-sync. Every exit code must be 0 or explained.
  6. Check the workstation when tools or dotfiles changed: mise run diff preview, dot orphan for retired targets (report, never delete), and mise run doctor. STALE for the installed dot is expected until release or mise run deploy.
  7. Report: fixed findings, deliberately left items with reasons, each check and its result, and confirm the tested snapshot equals the candidate (the working tree after the last fix).

Gotchas

  • Suppress lock false positives narrowly: universal uv locks list versions for old Python markers. Confirm the installed environment's resolved version; record a false positive as a path-scoped .trivyignore.yaml entry with a statement, never by lowering severity.
  • Fix upstream breaks at the source: an upgraded tool can drop its completion generator or tighten a pinned dependency; fix the source configuration and its skill, not the deployed copy.

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.