Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add AgentToolkit/altk-evolve/plugin install evolve-liteWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/agenttoolkit/altk-evolve/publish)<a href="https://agentmods.dev/skills/agenttoolkit/altk-evolve/publish"><img src="https://agentmods.dev/badge/skills/agenttoolkit/altk-evolve/publish/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/agenttoolkit/altk-evolve/publish"><img src="https://agentmods.dev/badge/skills/agenttoolkit/altk-evolve/publish.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00026 | $0.01481 |
| Opus 5.5 | $0.00010 | $0.00592 |
| Sonnet 5.5 | $0.00005 | $0.00296 |
| Haiku 4.5 | $0.00003 | $0.00148 |
Grade A, and why
publish scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
97% identical to evolve-lite:publish — 14 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 153 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Publish an Entity
Overview
Publish one or more private entities from .evolve/entities/<type>/ into a
configured write-scope repo. <type> is the directory the entity was saved
in: guideline for learned guidelines, or a native memory type (user,
feedback, project, reference) for entities saved by adapt-memory or the
EVOLVE.md save flow. The entity is stamped with
visibility: public, owner, published_at, and source, moved into
the local clone of the write repo under the same <type>/ directory, and
committed / pushed to the remote.
The same local clone is also what /evolve-lite:sync pulls from — so you
and anyone else publishing to the same repo stay in sync.
Workflow
Step 1: Require a write-scope repo
Read evolve.config.yaml. If no entry has scope: write, tell the user:
"You need at least one write-scope repo to publish to. Run /evolve-lite:subscribe with --scope write to set one up, then come back."
Then stop.
If identity.user is missing, ask for it and add it to the config.
Step 2: First-time setup
Ensure .evolve/ is gitignored at the project root:
grep -qxF '.evolve/' .gitignore 2>/dev/null || echo '.evolve/' >> .gitignore
Step 3: Pick the target write-scope repo
Filter repos: to entries with scope: write (Step 1 already aborted if
there were zero, so at least one exists here).
- Exactly one entry → use it as default.
- Multiple entries → show a numbered list with
notesand ask which to publish to.
Let {repo} be the chosen repo name and {branch} its configured branch (default main).
Step 4: List and select entities
List the .md files in every type directory under .evolve/entities/, skipping
.evolve/entities/subscribed/ (other people's entities, never yours to
publish). Show each as {type}/{filename} and ask the user which to publish.
Step 5: Run publish script
For each selected file, run:
python3 ${CLAUDE_PLUGIN_ROOT}/skills/evolve-lite/publish/scripts/publish.py \
--entity "{filename}" \
--type "{type}" \
--repo "{repo}" \
--user "{identity.user}"
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago Changed · +7 lines · +12 tokens per session 66a2e642dd47
- 1mo ago First seen · 146 lines · 14 tokens per session scan A e5e8dca0a791
publish is a skill published in the GitHub repository AgentToolkit/altk-evolve (124 stars, last pushed yesterday), licensed Apache-2.0. It adds 26 tokens to every session and 1,481 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 97% identical to evolve-lite:publish, differing in 14 lines, and is treated as a copy.
Other skills, from other repositories
shelve
A conversation-archiving workflow that saves finished topics or imported conversations as Markdown records with a checked summary. A memory shelf is a collection of these saved conversation records.
triage-aging-prs
Drive an aging pull-request backlog to zero. Inventories every open PR, finds the STRUCTURAL blockers first (a required check that can never run, a reviewer that never fires, chronically red CI), triages every unresolved review thread in parallel and VERIFIES each finding against the code before fixing it, then merges…
review-comments
Systematically pull, categorize, and address all PR review comments — code change requests, questions, and suggestions. This skill fetches comments via gh api, groups them by file, implements fixes, handles disagreements diplomatically, and pushes a single commit. You should not try to handle PR review feedback…
commit
Automatically analyzes code changes and creates git commits with conventional commit messages when the user indicates they want to save their work, commit changes, or says 'commit this', 'save my changes', 'let's commit'. Auto-detects commit type, scope, and ticket reference from branch name.
merge-pr
Safely merge PR with verification and Linear integration. ALWAYS use when the user says 'merge the PR', 'merge this', 'ship it', or wants to merge an approved pull request. Runs tests, checks CI, verifies approvals, squash merges, cleans up branches, and moves Linear ticket to Done.
review-code
Review a branch's diff against its base for REAL defects only — bugs the diff makes certain, quoted CLAUDE.md/AGENTS.md violations, contradictions of recent git history, unaddressed prior-PR review comments, and in-code guidance the change ignores — each scored 0–100 and reported only at ≥80 confidence, ending in a…