agentleFS
MrHashMeMrHashMe/efficiency-playbook/skills/verify/SKILL.md

verify

Skill0 starsChanged 44 days agoMITView on GitHub

Check the efficiency setup for drift, duplicate or oversized instructions, missing tools and unreadable managed settings, and explain each finding with its fix. Changes no configuration. Run only when the user types /efficiency-playbook:verify.

188 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use instinct-export, instinct-import and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-import

    Import instincts from file or URL into project/global scope

    Also in 3 projects that use this

  • AviadPSkill

    risk-assess

    Assess the risk and blast radius of a proposed code change before implementing it. Evaluates CI impact, framework-wide vs localized scope, rollback path, and identifies blindspots. Use when user says "what's the risk", "is this safe", "assess the impact", "risk assess", "blast radius", or before applying framework-wide or CI-affecting changes. Do NOT use for code quality review (use code-quality) or plan validation (use design-validator).

    Also in 3 projects that use this

  • diego-tobalinaSkill

    build-fix

    Fix build and compilation errors systematically. Run when build fails.

    Also in 6 projects that use this

  • AaravChadhaSkill

    secure

    Security review with a confidence gate - a finding exists only with a concrete exploit scenario and a high/medium/low confidence rating; everything else goes to a worth-hardening list, never inflated. Sweeps five surfaces: auth gates, secrets hygiene, injection and unsafe sinks, unsafe deserialization/crypto/transport, and LLM tool-use trust boundaries. Reports only, never fixes. Use when the user asks for a security review or to check vulnerabilities, secrets, or auth.

    Also in 3 projects that use this

  • ArvorCoSkill

    specify

    Create feature specification from natural language description. Use when starting a new feature or creating a spec. Triggers on: create spec, specify feature, new feature spec.

    Also in 10 projects that use this

  • +1 more from TheKREATORS

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 167 edited versions we read keep these.

  • 0

    Distinctive

    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:

    If the user asks what is installed, run show --scope <scope> --json.

    line 20

“Common” is measured: kept by at least 6 in 10 of the 167 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

Arguments: $ARGUMENTS

Run node "${CLAUDE_PLUGIN_ROOT}/engine/ep.mjs" verify --deep --scope <scope> --json for the scope in the arguments. With none, run it for user scope, plus project and local scope when an entry of show --installs --json has folders inside this repository (the list covers every repository). --deep also asks each code-navigation tool to answer --version. Verify changes no configuration file. With the nudge installed, it refreshes the nudge's summary in the engine's state folder, and that's all it writes. This skill changes nothing.

Then:

  1. Explain the error and warn findings first, then info, each in one or two plain lines: what it means here and the fix. Name files the way the finding names them.
  2. Drift (EP-DRIFT-EDITED, EP-DRIFT-MISSING): offer both ways out. To keep the user's edit, do nothing; the next setup shows the file as a conflict and leaves it unless the user picks it. To put the owned version back, run /efficiency-playbook:setup and pick that row.
  3. Instructions that cost tokens twice or load too much (EP-DUPLICATE-BLOCK, EP-PACK-PRESENT, EP-ANCESTOR-INSTRUCTIONS, EP-SIZE-CAP): give the token cost the finding reports and the fix it names, such as a claudeMdExcludes entry. For files the engine doesn't own, give the user the edit to make; don't make it.
  4. Report-only findings (EP-HIDDEN-UNICODE, EP-SECURITY-RULE-UNENFORCED): name the file and say why it matters. For a prose security rule, suggest the permission rule or setting that would enforce it.
  5. Policy (EP-POLICY-UNREADABLE): a managed settings file couldn't be read, so what it allows is unknown. Name the file, and say that the organization's managed settings win and only an administrator can change them.
  6. Machine facts (agent version, a missing tool): say what to install or update, with a user-level command where there is one.
  7. End with one line: clean, or the number of problems and the first one to fix.

If the user asks what is installed, run show --scope <scope> --json. It lists each owned item with its status (ok, edited, missing) and where its value comes from.

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.

Reviews can't be read right now.

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.