agentleFS
Sign inStart free
MoeenNehzatiMoeenNehzati/famulus/skills/update-standards/SKILL.md

update-standards

Skill4 starsChanged 4 months agoMITView on GitHub

Use when the user asks to create, change, or audit a canonical repository standard. Do not use for generic policy or documentation work.

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

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When this skill is used, begin with:

    line 12
  2. Distinctive:

    Read the target, relevant schema definitions, and validator output.

    line 24
  3. Distinctive:

    Keep the operational relationships honest:

    line 26
  4. Distinctive:

    Update source and source-unit digests only when their referenced evidence changed.

    line 34
  5. Distinctive:

    Never change a digest merely to silence validation without inspecting the source.

    line 35
  6. Distinctive:

    Run focused validation for every edited document, then the repository standards validator and tests for changed enforcement.

    line 38
  7. Distinctive:

    Stop rather than inventing policy when ownership, the intended compatibility boundary, the correct remedy, or the truth of an evidence …

    line 42

≈ “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
<!-- BEGIN BLUEPRINT INTERFACES -->

Generated from blueprint.yaml. Do not edit this block by hand.

Used Interfaces: none

<!-- END BLUEPRINT INTERFACES -->

When this skill is used, begin with:

Skill: update-standards

The schema is the field-level authority. Resolve only definitions for fields being changed; do not load the whole schema, restate it here, or infer fields from older examples.

Maintenance workflow

  1. Identify the canonical target, its pinned import closure, every direct dependent, and whether the repository registers a generated view for it.
  2. Read the target, relevant schema definitions, and validator output. Change the smallest semantic unit that expresses the requested policy.
  3. Keep the operational relationships honest:
    • each violated requirement has an applicable remedy;
    • checks, tests, assurances, reviews, and evidence claims name only mechanisms that actually exist and state their limitations;
    • removed or superseded policy leaves no stale links or enforcement.
  4. Bump the edited document's revision. Recompute its digest in each direct dependent, update the pinned revision, and repeat outward until the import closure is current. Change standard_version only for a compatibility change.
  5. Update source and source-unit digests only when their referenced evidence changed. Never change a digest merely to silence validation without inspecting the source.
  6. Regenerate registered Markdown views from their YAML authority; never edit a generated view as policy. Standards without a registered view remain YAML-only.
  7. Run focused validation for every edited document, then the repository standards validator and tests for changed enforcement. Inspect the exact diff before claiming alignment.

Stop rather than inventing policy when ownership, the intended compatibility boundary, the correct remedy, or the truth of an evidence claim is unresolved.

Report

Report semantic changes, revision/digest cascades, regenerated views, evidence or enforcement changes, validation results, and any unresolved semantic-review remainder.

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.

Check your setup, free