agentleFS
AcKeskinAcKeskin/contexture/skills/rules/SKILL.md

rules

Skill2 starsChanged 6 days agoMITView on GitHub

Manage the architectural-rule overlay: list, disable, enable, edit, sync or locate rules across the shipped, company, user and project tiers. Use on /rules, or when the user asks to override, disable or add a rule, see which rules are active or why one applies, or point at a company rules repo. Mode A only — never auto-fire.

11 other projects use 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. 0 are common, 2 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Mode A only: Every mutating command previews the before→after effect on the *effective corpus* and waits for explicit confirmation before …

    line 11
  2. Very specific:

    Run the resolver (see docs/architectural-rules-overlay.md § Resolution).

    line 25
  3. Very specific:

    Default scope = global (user manifest disabled:).

    line 32
  4. Very specific:

    If the target carries locked: true, require explicit confirmation naming the lock.

    line 33
  5. Very specific:

    Remove the key from whichever manifest disabled: set holds it (project checked before user).

    line 37
  6. Distinctive:

    Ask: whole-file override or field patch?

    line 41
  7. Very specific:

    If the target is locked: true, confirm + write a divergence entry (as in disable).

    line 45

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

rules

Front door for the architectural-rule overlay system. Manages the user/company/project tiers that layer over the shipped architectural-rules/ tree. See docs/architectural-rules-overlay.md for the model.

Mode A only. Every mutating command previews the before→after effect on the effective corpus and waits for explicit confirmation before writing. Never auto-fires.

Tier directories

  • shipped: ~/.claude/architectural-rules/, or ${CLAUDE_PLUGIN_ROOT}/architectural-rules/ in a plugin install (read-only here — never edit through this skill)
  • company: ~/.claude/architectural-rules-company/
  • user: ~/.claude/architectural-rules-local/
  • project: <project>/.claude/rules/

Manifests: ~/.claude/architectural-rules.config.yaml (user), <project>/.claude/rules.config.yaml (project).

Subcommands

/rules list

Run the resolver (see docs/architectural-rules-overlay.md § Resolution). Show the effective corpus grouped by winning tier. Annotate only non-default rules: overridden, patched, disabled, or locked-and-diverged. Plain shipped rules show name + scope only.

/rules where <key>

The debug command. For one <scope>/<name> key, list every tier that defines it, which wins, and why (override / patch deltas / disable / lock). Show orphaned patch anchors if any.

/rules disable <key> [--project | --session]

  1. Resolve the key; show exactly which rule(s) vanish from the effective corpus.
  2. Default scope = global (user manifest disabled:). --project → project manifest. --session → ephemeral, in-context note only, nothing written.
  3. If the target carries locked: true, require explicit confirmation naming the lock; on confirm, append a divergences: entry to the project manifest.
  4. Preview → confirm → write.

/rules enable <key>

Remove the key from whichever manifest disabled: set holds it (project checked before user). Preview → confirm → write.

/rules edit <key> [--editor]

  1. Resolve the current winning tier for the key.
  2. Ask: whole-file override or field patch?
    • whole-file → create ~/.claude/architectural-rules-local/<key>.md seeded with the resolved lower-tier body (a real baseline, not blank). Set origin: user.
    • field patch → create the same path with override: <key>, mode: patch, and empty remove/replace/add sections to fill in.
  3. Conversational by default: load the body into the chat; the user describes the change; apply via Edit with propose-confirm. --editor instead opens the file in $EDITOR for raw hand-editing.
  4. If the target is locked: true, confirm + write a divergence entry (as in disable).
  5. Show the resulting effective rule (post-resolution) so the user sees the merged outcome.

/rules sync

Clone or pull the company repo per the user manifest's company.repo + ref, into ~/.claude/architectural-rules-company/. Idempotent. If no company.repo is configured, no-op with a clear message — not an error. Pin ref to a tag for reproducibility.

Notes

  • This skill never edits the shipped tree. Overrides always land in the user or project tier.
  • --session disables are the fastest control: kill a rule that's in the way now, nothing persisted.
  • The resolver is shared with discover; keep behaviour identical (one source of truth in docs/architectural-rules-overlay.md).
  • Anchors (<!-- id: ... -->) stay in files but are stripped before context — do not remove them when editing a body, they are patch targets.

See docs/architectural-rules-overlay.md for the full contract.

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.