Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add rjroy/vibe-garden --skill migrategit clone --depth 1 https://github.com/rjroy/vibe-gardenWrote 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/rjroy/vibe-garden/migrate)<a href="https://agentmods.dev/skills/rjroy/vibe-garden/migrate"><img src="https://agentmods.dev/badge/skills/rjroy/vibe-garden/migrate/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/rjroy/vibe-garden/migrate"><img src="https://agentmods.dev/badge/skills/rjroy/vibe-garden/migrate.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.00052 | $0.01680 |
| Opus 5.5 | $0.00021 | $0.00672 |
| Sonnet 5.5 | $0.00010 | $0.00336 |
| Haiku 4.5 | $0.00005 | $0.00168 |
Grade A, and why
migrate 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 9d 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.
How it starts
The opening of the file, as written. The whole thing — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Migrate
Help a project transition legacy lore folders into the current storage layout without rewriting their history. This skill is optional; existing files remain readable if the user does not migrate them.
Scope and safety
The helper is scripts/migrate_lore.py, resolved from this skill's installed plugin directory. It supports flat legacy directories directly under .lore/ and equivalent legacy subdirectories under .lore/work/:
specs/**→.lore/work/intents/**(legacy specs under.lore/work/use the same destination)intents,brainstorm,design,research,retros,issues,ideas,validation,stubs,diagrams, andexcavations→ matching.lore/work/directoriesplans,tasks, andnotes→ matching.lore/local/directories
Preserve nested names, numbering, bodies, and unrelated frontmatter. During explicit migration, mapped legacy documents' status is normalized per shared/frontmatter-schema.md; changed values are retained in legacy_status. In particular, legacy current/active becomes completed because it records maintained/agent-produced content, not approval or guaranteed currency. Unknown status values refuse the whole preflight. Migration does not rewrite other project histories. Legacy specs remain historical context, not newly authored intents or binding requirements.
Unmapped root directories/files are reported and left untouched; current work/, reference/, learned/, and local/ trees are not flattened or moved. The helper moves regular files of any extension, so unsupported non-HTML formats are preserved rather than discarded. Migrating .html/.htm artifacts converts ordinary headings, paragraphs, lists, links, and code to Markdown and backs up the original bytes under .lore/local/migration-backups/. Tables, SVG/complex styled markup remain raw inline HTML where possible. Scripts/styles are preserved only as escaped, inert source and their runtime/rendering behavior is not preserved. Conversion warnings and backup destinations appear in preview; it is conservative, not a promise of complete fidelity. Destination and backup collisions block the entire migration.
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.
- 9d ago First seen · 49 lines · 52 tokens per session scan A 0eca208fd357
migrate is a skill published in the GitHub repository rjroy/vibe-garden (6 stars, last pushed 10d ago), licensed MIT. It adds 52 tokens to every session and 1,680 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-08.
Other skills, from other repositories
piyaz
Use when the user wants to plan, decompose, track, or resume a multi-task project: scoping a new idea, importing or onboarding an existing repo or workspace, asking what to work on / what's next / what's blocked / where they left off, reporting task completion, dispatching work in parallel, or planning a draft task.…
onboarding
Use when the current repo has existing code but no Piyaz project that matches it, and the user wants to adopt Piyaz on day N. Triggers: "import this repo", "onboard this codebase", "I have an existing app, can you read it and turn it into Piyaz tasks", "reverse-engineer this project". Do not use when no code exists…
composer
Use when the user types /piyaz:composer, /piyaz:composer , or /piyaz:composer rework , or asks to run the next Piyaz task end-to-end, ship the backlog, compose through the ready queue, or loop through Piyaz tasks until done. Composer researches, refines, plans, implements, reviews, and fixes each task in a loop until…
decompose-feature
Use when the user wants to add a new feature, capability, or cluster of work to an existing active Piyaz project. Triggers: "add a feature for notifications", "decompose this idea into tasks", "I want to plan out the X subsystem", "extend the project with Y", "add Z to the project". Reuses the project's existing…
decompose-task
Use when an existing task in an active Piyaz project carries scope larger than 13 points worth of work (composer's research brief raised the oversize-task flag, or the user explicitly says "split this task", "decompose RZE-42", "this task is too big", "break into smaller pieces"). Composer dispatches this from its…
manage
Use when the user explicitly wants a deep CTO-mode review of a Piyaz project. Triggers: "strategic review", "audit the project", "rebalance the graph", "what's the health of this project", "deep dive on the dependency graph", "I want a thorough navigation session", "prune orphans", "connect missing edges", "audit…