agentleFS
yiyaw-labyiyaw-lab/agent-armor/mirror/SKILL.md

mirror

Skill1 starsChanged 5 months agoMITView on GitHub

Sync a skill from ~/.claude/commands/<x>.md to the public skills repo (yiyaw-lab/agent-armor; local clone ~/code/claude-code-skills) as <x>/SKILL.md — disclosure+secrets gate first, README bookkeeping (badge count, playbook diagram, catalog row) handled, then a PR with CI green; merge only on explicit approval. Curated: only named skills, never a bulk export. Modes: <skill-name> | sweep | audit.

  • Commits and pushes

6 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

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

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 1

    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:

    Nothing leaves the machine unscanned: Before writing into the clone: a secrets scan (keys/tokens/bearer strings) and a disclosure scan …

    line 10
  2. Distinctive:

    Read-only: the same four-bucket report.

    line 25

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

The law this skill runs on: a public mirror rots silently. The suite's skills are sharpened in place (~/.claude/commands — /hone edits them, lessons fold in), but the public copies in the skills repo update only when someone remembers — so the repo's contract ("this armor updates when my own workflow does") decays into stale copies and a wrong skill count. mirror makes that update a checked procedure: one command takes a named skill from the private commands dir to a reviewed PR on the public repo, with the disclosure gate and the README bookkeeping nobody remembers by hand.

Three hard invariants:

  • Curated, never bulk. Mirror ONLY the skill(s) the user names, or already-public skills that drifted. Presence in ~/.claude/commands is NOT admission — the repo's bar is "survived contact with real work," and the user decides what's public (some skills stay private on purpose: personal pipelines, unproven drafts).
  • Nothing leaves the machine unscanned. Before writing into the clone: a secrets scan (keys/tokens/bearer strings) and a disclosure scan (private paths, client/project names not already public, identifiers beyond the repo's own voice). A hit = stop and surface; never silently redact.
  • PR-gated; merge is a per-run human call. Push a branch, open the PR, wait for the repo's validate-skills CI. Merge only when the user says so in THIS run (a standing "publish it" in the invocation counts). Never force-push, never commit to main directly.

/mirror <skill-name>

  1. Sync the clone first: git -C ~/code/claude-code-skills pull --ff-only — a mirror from a stale clone re-introduces what was already fixed upstream.
  2. Read the source ~/.claude/commands/<x>.md and run both scans (invariant 2).
  3. Transform = copy, honestly. <x>/SKILL.md carries the same frontmatter (description, argument-hint) and body verbatim. Private-convention references (memory files, private/ taxonomy, TASTE.md) STAY — the README already tells readers to swap in their own conventions; flag anything that would genuinely confuse a public reader rather than silently rewriting it. If the skill ships a script, copy it under <x>/scripts/. When the public copy MUST intentionally diverge (genericized private module names, references to unpublished skills, personal-detail sanitization), make the divergence machine-visible: put <!-- mirror:transform — intentional divergence: <one line on what and why> --> as the first body line of the public SKILL.md, so a future sweep never "fixes" it back to the private text.
  4. README bookkeeping (the part nobody remembers): a NEW skill bumps the skills-N badge AND the prose count, joins its playbook-diagram line, and gets a catalog row in the section that owns it, written in that table's register. An UPDATE changes no counts. Badge, prose, diagram, and table must agree — CI validates skills, not the README; mirror owns that agreement.
  5. Branch, commit, PR: branch skill/<x>, explicit git add of only the touched files (never -A), commit, push, gh pr create. Wait for the validate check; report its verdict + the PR URL.
  6. Merge on approval only (invariant 3). After merging, confirm the default branch actually contains the change and report.

/mirror sweep

For every repo dir with a same-named ~/.claude/commands/<x>.md, diff <x>/SKILL.md against the command body. A public copy containing a mirror:transform marker is bucketed TRANSFORMED, not drifted: report its diff for awareness but never propose a verbatim sync over it (a naive diff cannot tell stale from deliberately-divergent — the marker can). Report five buckets: IN-SYNC · TRANSFORMED · DRIFTED (public copy stale — summarize what changed privately) · PRIVATE-ONLY (in commands, not mirrored — candidates; the user picks) · REPO-ONLY (mirrored but no local command — flag it, NEVER delete; it may be another machine's skill). Propose which drifted ones to sync; execute per approval, batched or per-skill as the user prefers.

/mirror audit

Read-only: the same four-bucket report; propose nothing, write nothing.

Rules

  • Lane discipline: /publish owns yiya.dev content; /harmonize converges internal parts on a named standard; a skill-body EDIT is /hone's job. mirror owns exactly the cross-repo publication mechanics for the skills repo: scan → copy → README bookkeeping → PR.
  • Never delete on sweep; REPO-ONLY is a flag, not a cleanup target.
  • Honest empty result: nothing named and nothing drifted = say so and write nothing.

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.