ru-multi-repo-workflow
Made by JeffOrchestrate multi-repo maintenance with ru: smart commits, careful sync, issue/PR review. Use when managing repos, syncing projects, reviewing GitHub issues, or automating maintenance en masse.
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
1Updates, enhancements, and release notes for this skill.
New: ru Multi-Repo Workflow, automate the mechanical and save judgment for the conflicts
Managing dozens of repos by hand is the wrong use of a maintainer's time. ru automates everything that doesn't need judgment: status across all repos, parallel sync, dirty-tree detection, issue/PR enumeration, release-pipeline monitoring. Your job is the substantive merge conflicts, the scope-creep decisions, the canonical-version selections: the things ru can't decide for you. Four phases, run in order, with per-repo context reads and parallel sync at -j4.
- Four phases per maintenance pass, always in order: commit dirty repos, sync all repos, review issues/PRs, watch release pipelines. You can't release what isn't committed
- ru status --json | jq '[.repos[] | select(.dirty)]' finds dirty trees across the entire portfolio in one pipe
- Parallel sync with ru sync -j4. "Canonical" is not "latest": diverged changes to the same files get surfaced for a decision, not resolved mechanically
- Per-repo context before any commit: cat AGENTS.md README.md. Two minutes reading AGENTS.md saves twenty minutes of confusion
- Phase 3 verifies every issue independently and never merges PRs: they get mined for ideas and closed with an explanation
- Phase 4 release watching: gh run list --limit 5 for recent runs, gh run watch to tail a running workflow, gh run view --log-failed to diagnose, and gh run rerun --failed for flaky jobs
- The scaling rule: if it doesn't require human judgment, it should just happen. Substantive merge conflicts, scope-creep decisions, canonical-version selections stay with you
The workflow is four phases, always run in order. Phase 1 commits dirty repos: ru status --json | jq '[.repos[] | select(.dirty)]' finds them, cat AGENTS.md README.md per repo gives the agent context, then explicit git add, git commit and git push for logical groups of changes. Phase 2 syncs all repos in parallel: ru sync -j4, then git log --oneline HEAD...origin/main and git diff HEAD origin/main per repo show the divergence. "Canonical" is not the same as "latest": when local and remote diverged on the same files, the agent surfaces the conflict instead of picking. Phase 3 re