agentleFS
mqmalagrismqmalagris/agent-skills/skills/publish-skill/SKILL.md

publish-skill

Skill0 starsChanged 8 days agoMITView on GitHub

Publish one of the user's own skills from ~/.claude/skills to the mqmalagris/agent-skills GitHub repo — copies the skill under skills/<name>/, mints its .claude-plugin/plugin.json, upserts the marketplace.json entry, bumps its version, and opens a PR against main (CI-gated). Use when the user says 'publish this skill', 'push <skill> to my repo', 'add <skill> to agent-skills', 'ship this skill', or wants a locally-authored skill added to their public skill collection. NOT for third-party skills (those go in THIRD_PARTY.md, not vendored) or for editing skill content.

12 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 11 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:

    Do not use this for third-party skills — those belong in the repo's THIRD_PARTY.md, not vendored.

    line 10
  2. Distinctive:

    Confirm it's the user's own skill: If it's a fork/adaptation, note the upstream so the description can attribute it (the repo credits …

    line 14

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

publish-skill

Publishes a locally-authored skill (~/.claude/skills/<name>/) to mqmalagris/agent-skills (a dual-format Claude-marketplace + bunx skills repo). The script does all mechanical work idempotently; you supply the two editorial bits it can't guess: category and keywords.

Do not use this for third-party skills — those belong in the repo's THIRD_PARTY.md, not vendored. Skills written for an employer or a client stay out entirely: authoring one does not make it yours to publish, and the tool it drives is usually internal anyway.

Steps

  1. Confirm it's the user's own skill. If it's a fork/adaptation, note the upstream so the description can attribute it (the repo credits adapted skills). Bail if it's third-party.
  2. Decide category + keywords, and the version bump. Read the skill's SKILL.md. Category matches the repo's groups: engineering-workflow, security, development, reporting, career, product, meta, marketing. Keywords: 3-6 kebab tags. Description is derived from the SKILL.md frontmatter unless you pass --description. Pick the SemVer bump for an existing skill (default PATCH; use --bump minor for a new capability, --bump major for a breaking change) per [[reference-agent-skills-repo]] / the repo's VERSIONING.md.
  3. Run the script (kebab-case skill name = its dir name):
    python3 ~/.claude/skills/publish-skill/scripts/publish_skill.py <skill-name> \
      --category <category> --keywords tag-a,tag-b,tag-c
    It refreshes a repo cache, copies the skill, mints plugin.json, upserts marketplace.json, bumps the skill's version (PATCH on update), logs a CHANGELOG.md [Unreleased] line, validates all JSON, commits on a publish/<name>-v<version> branch, and opens a PR against main (CI validate gates it). Merge overrides: --auto-merge (merge when CI passes), --merge (merge now, squash+admin), --push-main (legacy: push straight to main, no PR). Other: --bump minor|major, --version X.Y.Z, --no-bump, --changelog "text", --description "...", --no-push, --dry-run, --skip-evals. If the skill ships an evals/ suite, the script runs it on your own Claude login before committing (scripts/eval-run.sh <name> --record) and commits the result to evals-history/<name>.jsonl, the eval trend; a suite below threshold aborts the publish.
  4. Update the README table. The script prints a suggested row and the target skills/ path. Add that row to the right group section in the repo's README.md (goes in the same PR branch, or a follow-up PR). Skip only if the user says the README doesn't matter.
  5. Report the PR URL + new version, and (post-merge) the install commands: bunx skills add mqmalagris/agent-skills -s <name> and /plugin install <name>@agent-skills.
  6. Cutting a release (optional, when done publishing). Per-skill publishes accumulate under CHANGELOG [Unreleased]. Snapshotting the collection is a separate flow that runs in GitHub Actions; follow "Cutting a release" in the repo's VERSIONING.md.

Notes

  • Re-running for the same skill updates it (no duplicate marketplace entry), preserves its category/keywords/description, and bumps the version — safe for republishing after edits.
  • Repo conventions and the full layout are in memory [[reference-agent-skills-repo]]. The script hardcodes the repo URL, author (Matheus Malagris), and MIT license to match.
  • Requires gh/git auth for the push (already configured for this user).

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.