Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsCommunityBlog
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

Back to skills

Ru Multi Repo Workflow

ASecurity

Orchestrate 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.

22 stars
0 votes
0 copies
0 views
Added 9/20/2026
testingrustbashnodegitapisecurity

Works with

vscodecliapi

Security Analysis

A100/100

Scanned 9/20/2026

Install to Claude Code

$npx -y skills add lev-os/agents --skill ru-multi-repo-workflow --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ru Multi Repo Workflow?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Ru Multi Repo Workflow
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/lev-os-ru-multi-repo-workflow/badge)](https://www.skillsdirectory.com/skills/lev-os-ru-multi-repo-workflow)

More formats (shields.io, HTML) on the badges page.

Download Zip
Files
SKILL.md
---
name: ru-multi-repo-workflow
description: >-
  Orchestrate 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.
trigger: commit-and-release
globs: .github/workflows/*.yml
---

# ru Multi-Repo Workflow

> **Core Insight:** ru automates the mechanical. Your job is judgment: substantive merge conflicts, scope creep decisions, canonical version selection. If it doesn't require human judgment, it should just happen.

## Quick Start

```bash
# Health check
ru doctor && gh auth status

# Phase 1: Commit dirty repos
ru status --json | jq '[.repos[] | select(.dirty)]'  # Find dirty
cd /data/projects/REPO && cat AGENTS.md README.md     # Understand
git add FILES && git commit -m "MSG" && git push      # Commit

# Phase 2: Sync all repos
ru sync -j4                                           # Parallel sync
git log --oneline HEAD...origin/main                  # See divergence

# Phase 3: Review issues/PRs
ru review --dry-run                                   # See open items
gh issue view NUMBER -R owner/repo                    # Investigate

# Phase 4: Release & Monitor (for repos with GH Actions)
ls .github/workflows/*.yml 2>/dev/null && echo "Has CI"  # Detect
gh run list --limit 5                                     # Recent runs
gh run watch                                              # Monitor live
```

---

## The 4 Phases

| Phase | Summary | Key Command |
|-------|---------|-------------|
| **1. Smart Commits** | Dirty repos → understand → commit logical groups → push | `ru status` |
| **2. Smart Sync** | Pull all → resolve conflicts (CAREFUL!) → canonical version → push | `ru sync -j4` |
| **3. Issue/PR Review** | Discover 2025+ → verify independently → respond via gh | `ru review` |
| **4. Release & Monitor** | Detect CI repos → watch runs → iterate on failures until green | `gh run list` |

**Always run in order.** Can't release if not committed. Can't review if not synced.

---

## What to Surface vs Just Handle

| Surface (needs judgment) | Just Handle (mechanical) |
|--------------------------|--------------------------|
| Substantive merge conflicts | Clean fast-forwards |
| Complex feature requests | Stale issues (pre-2025) |
| PR ideas worth considering | Issues already fixed |
| Ambiguous canonical version | Obvious bugs, clear fixes |
| Security-related anything | Simple fitting features |

---

## Phase 1: Smart Commits

**The only rule:** Understand before committing. 2 minutes reading AGENTS.md saves 20 minutes of confusion.

```bash
ru status --json 2>/dev/null | jq -r '.repos[] | select(.dirty) | .name'
cd /data/projects/REPO && cat AGENTS.md README.md
git add path/to/related/files && git commit -m "$(cat <<'EOF'
Why this change exists (not what changed)

- Specific detail 1
- Specific detail 2

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
git push
```

**Deep dive:** [PHASE1-COMMITS.md](references/PHASE1-COMMITS.md) | **Prompt:** [PROMPTS.md](references/PROMPTS.md#phase-1-smart-commits)

---

## Phase 2: Smart Sync

**Key insight:** "Canonical" ≠ "Latest". Manual diff required—this cannot be mechanically determined.

| Situation | Usually Canonical | But Check |
|-----------|-------------------|-----------|
| Local ahead | Local | Unless local is experiments |
| Remote ahead | Remote | Unless remote lost work |
| Diverged, different files | Merge both | Straightforward |
| Diverged, same files | **SURFACE** | Judgment required |

```bash
ru sync -j4
git log --oneline HEAD...origin/main  # See divergence
git diff HEAD origin/main             # See actual changes
```

### SURFACE FORMAT: Conflicts

```
🚨 CONFLICT REQUIRING JUDGMENT: repo_name

Local (abc123): Refactored auth to use JWT
Remote (def456): Refactored auth to use sessions

Options:
1. Keep local (JWT approach)
2. Keep remote (session approach)
3. Manual merge

Which aligns with project direction?
```

**Deep dive:** [PHASE2-SYNC.md](references/PHASE2-SYNC.md) | **Prompt:** [PROMPTS.md](references/PROMPTS.md#phase-2-smart-sync)

---

## Phase 3: Issue/PR Review

**Key insight:** Never trust user reports blindly. Independent verification required.

| Type | Verified? | Action |
|------|-----------|--------|
| Bug, confirmed, unfixed | ✓ | Fix it, close: `gh issue close N -c "Fixed in SHA"` |
| Bug, already fixed | ✓ | Close: `gh issue close N -c "Fixed in SHA"` |
| Bug, can't reproduce | ? | Ask: `gh issue comment N -b "Need: steps, OS, error"` |
| Bug, pre-2025 | ✗ | Close: `gh issue close N -c "Closing as stale"` |
| Feature, simple, fits | ✓ | Implement, close |
| Feature, complex | ? | **SURFACE** |
| Feature, scope creep | ✗ | Decline politely |
| PR, any | — | **NEVER MERGE**, mine for ideas, close with explanation |

```bash
ru review --dry-run --json 2>/dev/null | jq '[.items[] | select(.created_at >= "2025-01-01")]'
gh issue view NUMBER -R owner/repo
gh pr diff NUMBER -R owner/repo  # THE INTEL
```

### SURFACE FORMAT: Scope Decisions

```
🤔 FEATURE REQUEST: owner/repo#42 — "Add support for X"

User's problem: [What they're trying to do]

Analysis:
+ Would help users doing Y
- Maintenance burden
- Could lead to scope creep

Options:
1. Implement as requested
2. Implement simpler version
3. Decline

My recommendation: [X] because [reason]
```

**Deep dive:** [PHASE3-REVIEW.md](references/PHASE3-REVIEW.md) | **Prompt:** [PROMPTS.md](references/PROMPTS.md#phase-3-issuepr-review)

---

## Phase 4: Release & Monitor

**Key insight:** Push triggers CI. Watch until green. Iterate on failures—don't leave broken.

### Detection: Which Repos Have CI?

```bash
# Check for workflows
ls .github/workflows/*.yml 2>/dev/null

# Check for release workflow specifically
grep -l "release\|tag" .github/workflows/*.yml 2>/dev/null
```

### The Monitor Loop

```bash
# 1. See recent runs
gh run list --limit 5

# 2. Watch active run (blocks until complete)
gh run watch

# 3. If failed: get logs, diagnose, fix, push, repeat
gh run view RUN_ID --log-failed
# ... fix the issue ...
git add . && git commit -m "fix: CI issue" && git push
gh run watch  # Monitor the fix
```

### What NOT to Commit (Ephemeral Filter)

| Skip These | Why |
|------------|-----|
| `*.log`, `*.tmp`, `*~` | Transient |
| `target/`, `node_modules/`, `dist/` | Build artifacts |
| `.env`, `*.key`, `credentials.*` | **SECRETS** |
| `.DS_Store`, `Thumbs.db` | OS junk |
| `.idea/`, `.vscode/` | IDE config |

### SURFACE FORMAT: Persistent CI Failure

```
🔴 CI FAILING: owner/repo — Run #12345

Failure: [test name or step]
Error: [key error message]

Attempted fixes:
1. [What you tried]
2. [What you tried]

This may require judgment:
- [ ] Is this a flaky test?
- [ ] Is this a real regression?
- [ ] Is this environment-specific?

Logs: gh run view 12345 --log-failed
```

**Deep dive:** [PHASE4-RELEASE.md](references/PHASE4-RELEASE.md) | **Prompt:** [PROMPTS.md](references/PROMPTS.md#phase-4-release--monitor)

---

## References

| Topic | Resource |
|-------|----------|
| **All Prompts** | [PROMPTS.md](references/PROMPTS.md) |
| Phase 1 deep dive | [PHASE1-COMMITS.md](references/PHASE1-COMMITS.md) |
| Phase 2 deep dive | [PHASE2-SYNC.md](references/PHASE2-SYNC.md) |
| Phase 3 deep dive | [PHASE3-REVIEW.md](references/PHASE3-REVIEW.md) |
| Phase 4 deep dive | [PHASE4-RELEASE.md](references/PHASE4-RELEASE.md) |
| gh command reference | [GH-COMMANDS.md](references/GH-COMMANDS.md) |
| Troubleshooting | [PITFALLS.md](references/PITFALLS.md) |

## Scripts

| Script | Purpose |
|--------|---------|
| `scripts/validate.sh` | Health check (ru, gh, jq, API connectivity) |
| `scripts/review-sweep.sh owner/repo` | Full review workflow for one repo |

---

## Validation

```bash
./scripts/validate.sh  # Full health check
```

Attribution

lev-oslev-os
View sourceMore from lev-os →
SSkills DirectorySkills Directory

Your tool, in front of Claude Code builders.

3 founder slots · $299/mo · GSC-verified traffic · sponsors can never buy grades.

See placements

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Your tool, in front of Claude Code builders.

3 founder slots · $299/mo · GSC-verified traffic · sponsors can never buy grades.

See placements

Related Skills

Screen Reader Testing

Practical guide to testing web applications with screen readers for comprehensive accessibility validation.

393431 votes

Python Testing

使用pytest、TDD方法、夹具、模拟、参数化和覆盖率要求的Python测试策略。

2456590 votes

Tdd Workflow

在编写新功能、修复错误或重构代码时使用此技能。强制执行测试驱动开发,包含单元测试、集成测试和端到端测试,覆盖率超过80%。

2456590 votes

Springboot Tdd

使用JUnit 5、Mockito、MockMvc、Testcontainers和JaCoCo进行Spring Boot的测试驱动开发。适用于添加功能、修复错误或重构时。

2456590 votes

Eval Harness

克劳德代码会话的正式评估框架,实施评估驱动开发(EDD)原则

2456590 votes
View all in testing →