beads-check-dolt-migration
Skill9 starsChanged 3 months agoMITView on GitHub
Detect whether a beads repository needs classic-to-Dolt migration or an in-place Dolt schema upgrade.
In this repository81 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- architectSkill
- artifact-hygieneSkill
- backlog-groomSkill
- beads-migrate-to-doltSkill
- beads-setupSkill
- beadsSkill
- breakdownSkill
- browser-screenshotSkill
- circleci-statusSkill
- clean-codeSkill
- complete-taskSkill
- confluenceSkill
- contract-checkSkill
- contract-testSkill
- create-prSkill
- delegate-workSkill
- dependabot-remediationSkill
- developSkill
- diagnose-bugSkill
- do-i-need-thisSkill
- eas-build-errorSkill
- handoffsSkill
- handoffs-tidySkill
- image-studioSkill
- implement-solutionSkill
- jira-commentSkill
- jira-ticketSkill
- landscapeSkill
- model-update-checkSkill
- name-sessionSkill
- nextSkill
- outstanding-workSkill
- pair-programmingSkill
- pedantic-reviewSkill
- peer-sessionSkill
- pickupSkill
- pi-spendSkill
- plan-daySkill
- plan-to-backlogSkill
- project-briefSkill
- prompt-patternsSkill
- pr-reviewersSkill
- pr-review-requestsSkill
- pr-statusSkill
- ready-to-mergeSkill
- ready-to-releaseSkill
- reassessSkill
- rebaseSkill
- refineSkill
- release-maintenanceSkill
- release-managerSkill
- release-statusSkill
- reply-commentsSkill
- review-commentsSkill
- review-prSkill
- sanity-checkSkill
- second-opinionSkill
- setup-multirepo-gitSkill
- skills-reviewSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 6 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Read-only detection of whether a repository needs classic-to-Dolt migration, a Dolt schema upgrade, or no action.
- Very specific: line 19
After upgrading bd, especially across a minor or major version
- Very specific: line 20
When bd reports pending schema migrations or a remote migration gate
- Very specific: line 21
When bd commands fail and the storage format or schema may be stale
- Distinctive: line 22
When onboarding to a repo with beads
- Very specific: line 32
If no .beads/ directory exists, report "No beads installation found" and stop.
- Very specific: line 84
Treat the inspection output as diagnostic even when it exits non-zero.
- Very specific: line 92
Do not trust bd doctor to classify storage: newer versions may inspect configured defaults rather than the files on disk, and embedded mode …
- Distinctive: line 119
When bd 1.1+ reports pending schema migrations on a database with a remote:
- Very specific: line 121
Never set BD_ALLOW_REMOTE_MIGRATE=1 during this check.
- Distinctive: line 122
Ask the operator which single clone is the designated migrator.
- Very specific: line 124
Ask for explicit permission immediately before bd dolt push.
- Distinctive: line 130
Always preserve output from commands that may fail on old formats or a migration gate.
- Very specific: line 131
Prefer on-disk evidence over backend defaults reported by old bd doctor versions.
- Distinctive: line 132
Never recommend independent schema migration on multiple clones of one Dolt remote.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Beads Migration and Schema Check
Read-only detection of whether a repository needs classic-to-Dolt migration, a Dolt schema upgrade, or no action. Reports the current state without changing files, databases, remotes, or Git state.
When to Use
- Before running
/beads-migrate-to-dolt - After upgrading
bd, especially across a minor or major version - When
bdreports pending schema migrations or a remote migration gate - When
bdcommands fail and the storage format or schema may be stale - When onboarding to a repo with beads
Instructions
1. Check for Beads Installation
ls -la .beads/ 2>/dev/nullIf no .beads/ directory exists, report "No beads installation found" and stop.
2. Detect Storage Format
On-disk inspection is authoritative:
# Classic format indicators
test -f .beads/beads.db && echo "FOUND: SQLite database"
test -f .beads/issues.jsonl && echo "FOUND: JSONL issues file"
# Dolt format indicators
test -d .beads/dolt && echo "FOUND: server-mode Dolt directory"
test -d .beads/embeddeddolt && echo "FOUND: legacy embedded-Dolt directory"
test -f .beads/metadata.json && cat .beads/metadata.jsonissues.jsonl is not proof of classic storage: modern bd can export JSONL for interchange while Dolt remains authoritative.
3. Check Configuration, Remotes, and Worktrees
Safety gate before store-opening probes: bd may auto-migrate on store open. On an old, unknown or potentially pending schema, stop at file-only evidence unless the installed probe path is proven nonmutating. Recommend the migration core's protected-backup path for separate authorization; do not perform its backup or migration from this read-only check. The bd commands below are conditional on that proof, not permission to open an unprotected store.
cat .beads/config.yaml 2>/dev/null
git worktree list 2>/dev/nullFor a Dolt repository also run:
bd dolt status 2>&1 || true
bd dolt remote list 2>&1 || true
bd config get no-push 2>&1 || trueLook for:
sync.remoteorsync.branchin config- A configured Dolt remote
- Worktrees at
.git/beads-worktrees/from the classic sync mechanism
4. Check bd and Schema Compatibility
bd --version 2>/dev/null
bd migrate --inspect --json 2>&1 || trueTreat the inspection output as diagnostic even when it exits non-zero. On bd 1.1+, a remote-backed database with pending migrations intentionally refuses automatic migration and returns a remote_migrate_gate. Do not bypass that gate during this read-only check.
For classic data, optionally collect the legacy diagnostic too:
bd doctor --migration=pre 2>&1 || trueDo not trust bd doctor to classify storage: newer versions may inspect configured defaults rather than the files on disk, and embedded mode may not support it.
5. Classify and Report
| State | Indicators | Recommendation |
| Classic | beads.db exists, no Dolt directory | Full migration needed |
| JSONL-only | issues.jsonl exists, no SQLite or Dolt directory | Initialize Dolt and import |
| Dolt, current | Dolt directory exists, bd migrate --inspect reports no pending migrations | No migration needed |
| Dolt, pending (local-only) | Inspection reports pending migrations and no Dolt remote | Back up, then run the schema-upgrade path |
| Dolt, pending (remote-backed) | Inspection returns remote_migrate_gate | Choose exactly one designated clone to migrate and push; every other clone must adopt with bd bootstrap |
| Partial/broken Dolt | Dolt directory exists but bd list or bd dolt status fails | Diagnose and recover from backup or bootstrap; do not destroy data automatically |
| No beads | No .beads/ directory | Run bd init only if the repo should use beads |
Include in the report:
- Current storage format and mode
- bd CLI version
- Current and target schema versions, when available
- Issue count, when readable
- Configured Dolt remote or sync branch
- Whether
no-pushis enabled and will require a one-command approved override - Whether classic worktrees exist
- Any
remote_migrate_gateand its two choices - Clear recommendation: migrate classic data, upgrade schema here, adopt another clone, repair, or do nothing
Remote-Backed Upgrade Safety
When bd 1.1+ reports pending schema migrations on a database with a remote:
- Never set
BD_ALLOW_REMOTE_MIGRATE=1during this check. - Ask the operator which single clone is the designated migrator.
- The designated clone backs up, runs
BD_ALLOW_REMOTE_MIGRATE=1 bd migrate, verifies, then pushes. - Ask for explicit permission immediately before
bd dolt push. - Other clones preserve any unpushed issues, then use
bd bootstrapto adopt the published schema. They must not migrate independently because that forks schema history.
Rules
- This skill is strictly read-only. Never modify files, databases, remotes, or Git state.
- Always preserve output from commands that may fail on old formats or a migration gate.
- Prefer on-disk evidence over backend defaults reported by old
bd doctorversions. - Never recommend independent schema migration on multiple clones of one Dolt remote.
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.

