portability
Skill4 starsChanged 48 days agoMITView on GitHub
Forge kernel data portability — getting issue data in and out of the local kernel. `forge export [--dir] [--dry-run]` writes the kernel backlog to deterministic git-tracked JSONL (D16 portability projection); `forge export --import` reads that committed snapshot back into the kernel (hydrate). `forge migrate --from beads [--dry-run] [--source <dir>]` imports a Beads issue store into the kernel — the onboarding path for users coming from Beads. Use when the user says "export the kernel backlog to JSONL", "back up / snapshot the backlog", "re-import / hydrate the backlog", "migrate from beads", or "import a beads store". Honesty: bare `forge migrate --dry-run` (no `--from`) is v2→v3 preview only; a re-import that applies nothing reports "already hydrated". NOT the cloud/backend sync of the kernel (that is `forge sync`, cloud-native), NOT a database/schema migration (plan/dev), NOT memory notes (memory), NOT syncing a git branch with main (ship).
1 other project uses a version of this.
Adopted by
Most recently taken up by
- BuilderIO/agent-nativetheir own version, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- BuilderIO/agent-native★ 7.6ksame name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository51 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/permissions-guidance.mdcCursor rule
- claim-safetySkill
- devSkill
- gatesSkill
- hermes-forgeSkill
- issue-basicsSkill
- kernelSkill
- memorySkill
- parallel-deep-researchSkill
- planSkill
- portabilitySkill
- researchSkill
- reviewSkill
- rollbackSkill
- setupSkill
- shepherdSkill
- shipSkill
- smithSkill
- sonarcloud-analysisSkill
- sonarcloudSkill
- statusSkill
- triage-readySkill
- using-forgeSkill
- validateSkill
- verifySkill
- worktreeSkill
- claim-safetySkill
- devSkill
- gatesSkill
- hermes-forgeSkill
- issue-basicsSkill
- kernelSkill
- memorySkill
- parallel-deep-researchSkill
- planSkill
- researchSkill
- reviewSkill
- rollbackSkill
- setupSkill
- shepherdSkill
- shipSkill
- smithSkill
- sonarcloud-analysisSkill
- sonarcloudSkill
- statusSkill
- triage-readySkill
- using-forgeSkill
- validateSkill
- verifySkill
- worktreeSkill
The file
Files
Moving Forge kernel issue data across a boundary: project the backlog to a git-committable snapshot (and hydrate it back), or import an existing issue store into the kernel. This is data portability — distinct from schema/database migrations and from the cloud backend sync (forge sync).
Export / re-import the backlog
forge export # write the kernel backlog to git-tracked JSONL (deterministic)
forge export --dir <path> # choose the projection directory
forge export --dry-run # show what would be written, change nothing
forge export --import # read the committed JSONL snapshot back INTO the kernel (hydrate)forge export is the D16 portability projection: a deterministic, git-committable snapshot of the backlog you can review in a diff and carry between machines or checkouts. forge export --import is the reverse — it hydrates the kernel from that on-disk snapshot; a re-import that finds everything already present reports "already hydrated" rather than claiming it imported anything.
Migrate in from Beads (or preview v2→v3)
forge migrate --from beads [--dry-run] # import a Beads issue store into the kernel
forge migrate --from beads --source <dir> # point at exported beads *.jsonl (defaults to auto-detecting .beads/)
forge migrate --dry-run # preview the v2→v3 migration (the ONLY supported mode without --from)forge migrate --from beads is the onboarding path for users coming from Beads — it imports a Beads issue store into the Forge Kernel (--dry-run reads + maps only, writing nothing). Without --from, migrate is v2→v3 preview only: --dry-run is required and applying the migration is not yet available.
Boundaries
- The cloud/backend sync of the kernel is
forge sync(cloud-native) — a different operation; this skill is the local, git-based portability projection. - A database/schema migration (adding a column, altering a table) is application work — that's plan/dev, not
forge migrate. - Persisting a decision or note is memory (
forge remember), not export. - Syncing a git branch with main before a PR is ship/worktree.
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
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.

