Skill
swarm-debug
Systematic debugging — evidence before hypotheses, hypotheses before fixes, root cause before patches, and the diagnosis saved to the vault. Use for any real…
@anmarhaniView SkillDevelopment
Skill
/swarm-migrate
Bring existing projects into the SwarmVault — register, mirror docs, optionally mine the repo into SDLC artifacts and resume the flow mid-phase (brownfield adoption). Use when the user wants existing projects migrated/connected to the vault, or an existing codebase placed into
Install
$ npx -y skills add AnmarHani/SwarmVault --skill swarm-migrate --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/swarm-migrate
Context preview
The summary Claude sees to decide when to auto-load this skill.
Bring existing projects into the SwarmVault — register, mirror docs, optionally mine the repo into SDLC artifacts and resume the flow mid-phase (brownfield adoption). Use when the user wants existing projects migrated/connected to the vault, or an existing codebase placed into
SKILL.md
swarm-migrate.SKILL.mdname: swarm-migrate
description: Bring existing projects into the SwarmVault — register, mirror docs, optionally mine the repo into SDLC artifacts and resume the flow mid-phase (brownfield adoption). Use when the user wants existing projects migrated/connected to the vault, or an existing codebase placed into the SDLC flow.
swarm-migrate — existing-project migration
Three tiers per project; each deeper tier is opt-in with its cost stated up front. Idempotent: re-running repairs, never duplicates.
1. Discover
List candidates: `swarmvault.py register --import-claude` covers Claude Code users' `~/.claude.json` in one shot; otherwise the user names paths. Ask WHICH projects to migrate (multi-select) and, per project, the isolation flag.
2. Immediate tier (cheap, always)
Per chosen project: register + marker → first `sync` (mirrors existing CLAUDE.md/AGENTS.md/README/docs and any existing memory; builds the MOC) → wire the platforms they name with `setup`/`wire` (as swarm-init step 3; one command, no manual file edits). The project is now queryable.
3. Digest tier (token-costing, opt-in)
State the rough cost first. Analyze the repo → `10 Projects/<P>/<P> Digest.md` (architecture, conventions, entry points — not `generated`, so sync preserves it) + seed memories for footguns found in code comments/READMEs/issue notes.
4. SDLC adoption tier (most token-costing, opt-in) — place it IN the flow
Mine first, ask second (swarm-spec's brownfield mode does the work):
1. Sources: README, docs/, existing plan/TODO files, issue exports, test suites, the code. 2. Produce `docs/SRS.md` + feature specs marked `status: mined-draft`, every statement with provenance (`file:line`). 3. Detect the de-facto phase — e.g. "14 of 20 mined features implemented, no design doc" — and write flow-state accordingly. 4. Gap interview via the question queue: only gaps, conflicts, low-confidence items. Never re-ask what the repo answers. 5. Remaining work → tickets. From here `/swarm-flow` resumes the project mid-phase like any SwarmVault project.
Close
Ask once (if unset): vault as default for new projects? Show the security disclaimer (swarm-init step 4) if this user hasn't seen it. Huge monorepo → scope the deep tiers to user-chosen subpaths. A project containing its own Obsidian vault → exclude that folder from doc mirroring (no vault-in-vault).
--- *Influences: Jeffallan's spec-miner & legacy-modernizer; the original Claude Vault migration — see CREDITS.md.*
Read more
name: swarm-migrate description: Bring existing projects into the SwarmVault — register, mirror docs, optionally mine the repo into SDLC artifacts and resume the flow mid-phase (brownfield adoption). Use when the user wants existing projects migrated/connected to the vault, or an existing codebase placed into the SDLC flow.
swarm-migrate — existing-project migration
Three tiers per project; each deeper tier is opt-in with its cost stated up front. Idempotent: re-running repairs, never duplicates.
1. Discover
List candidates: `swarmvault.py register --import-claude` covers Claude Code users' `~/.claude.json` in one shot; otherwise the user names paths. Ask WHICH projects to migrate (multi-select) and, per project, the isolation flag.
2. Immediate tier (cheap, always)
Per chosen project: register + marker → first `sync` (mirrors existing CLAUDE.md/AGENTS.md/README/docs and any existing memory; builds the MOC) → wire the platforms they name with `setup`/`wire` (as swarm-init step 3; one command, no manual file edits). The project is now queryable.
3. Digest tier (token-costing, opt-in)
State the rough cost first. Analyze the repo → `10 Projects/<P>/<P> Digest.md` (architecture, conventions, entry points — not `generated`, so sync preserves it) + seed memories for footguns found in code comments/READMEs/issue notes.
4. SDLC adoption tier (most token-costing, opt-in) — place it IN the flow
Mine first, ask second (swarm-spec's brownfield mode does the work):
1. Sources: README, docs/, existing plan/TODO files, issue exports, test suites, the code. 2. Produce `docs/SRS.md` + feature specs marked `status: mined-draft`, every statement with provenance (`file:line`). 3. Detect the de-facto phase — e.g. "14 of 20 mined features implemented, no design doc" — and write flow-state accordingly. 4. Gap interview via the question queue: only gaps, conflicts, low-confidence items. Never re-ask what the repo answers. 5. Remaining work → tickets. From here `/swarm-flow` resumes the project mid-phase like any SwarmVault project.
Close
Ask once (if unset): vault as default for new projects? Show the security disclaimer (swarm-init step 4) if this user hasn't seen it. Huge monorepo → scope the deep tiers to user-chosen subpaths. A project containing its own Obsidian vault → exclude that folder from doc mirroring (no vault-in-vault).
--- *Influences: Jeffallan's spec-miner & legacy-modernizer; the original Claude Vault migration — see CREDITS.md.*
Ships withanmarhani-swarmvault
Your AI agents don't synchronise. SwarmVault does. One shared memory for Claude Code, Codex, and any other CLI agent. Real software engineering: requirements → design → tickets → review. 14 skills, the best of everything combined.
Get the whole plugin
Other skills on anmarhani-swarmvault.
@anmarhaniView SkillSkill
swarm-design-deep
The developer-driven design lane — the user commits to each approach before anything is written, then the design goes to pseudocode, algorithms, invariants,…
@anmarhaniView SkillSkill
swarm-design-ui
UI/UX design phase — propose an intentional design system (pattern, brand, color, typography, spacing, atomic components) with the user, offering distinct…
@anmarhaniView SkillSkill
swarm-design
System design phase — architecture, tech-stack options, module boundaries, data model, and ADRs from a validated SRS. Use after requirements are validated,…
@anmarhaniView SkillSkill
swarm-eject
Disconnect a project from SwarmVault and choose what happens to its knowledge — keep it, export it into the repo, or delete it. Use when the user wants to stop…
@anmarhaniView SkillSkill
swarm-flow
The SDLC router — figures out where a project stands and runs the right phase. Use at the START of any work in a SwarmVault project: continuing/resuming a…
@anmarhaniView Skill