agentleFS
ryanmacleanryanmaclean/skills/bop-team/SKILL.md

bop-team

Skill1 starsChanged 50 days agoMITView on GitHub

Dogfood orchestrator for working on the bop repo itself. Use when working on the bop jobcard system — create cards before coding, execute through dispatcher flow, and verify system output.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 6 are distinctive, and 3 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.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use when working on the bop repo itself.

    line 8
  2. Distinctive:

    After finishing, verify the system ran it.

    line 9
  3. Distinctive:

    Every unit of work on bop becomes a bop card.

    line 13
  4. Very specific:

    Use layouts/bop.kdl to launch this layout: zellij --layout layouts/bop.kdl

    line 99
  5. Distinctive:

    All adapters in this repo use MIT/Apache-2.0-licensed tools only:

    line 103
  6. Very specific:

    Nested Claude sessions: When dispatching from inside Claude Code, CLAUDECODE=1 blocks spawning.

    line 121
  7. Distinctive:

    Stale worktrees: If a card fails, its git worktree persists and blocks re-dispatch.

    line 123
  8. Very specific:

    Provider cooldowns: When a provider hits rate limits (exit 75), the dispatcher rotates to the next provider in provider_chain.

    line 131
  9. Distinctive:

    Before marking any bop work complete, verify:

    line 135

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

bop-team: Dogfood Orchestrator

Use when working on the bop repo itself. Before writing code, deal a card. After finishing, verify the system ran it.

The Rule

Every unit of work on bop becomes a bop card. No exceptions.

Agent Roster (budget order, cheapest first)

AgentBinaryCostBest for
ollamaollamafreefast local, drafts, docs
opencodeopencode$code tasks, mid-complexity
codexcodex$code tasks, OpenAI models
claudeclaude$$complex reasoning, architecture

Check availability:

for a in ollama opencode codex claude; do which $a 2>/dev/null && echo "  $a: available"; done

Templates

Four shipping templates in .cards/templates/:

TemplateStagesUse When
implementimplement → qaClear requirements
fullspec → plan → implement → qaComplex/ambiguous
cheapimplement (local)Small fix, local model
ideationideation → qaBrainstorming (bop bstorm)
qa-onlyqaCode review, audit

Factory (launchd lifecycle)

bop factory install    # generate + load plists (includes icon watcher)
bop factory status     # check if services are running
bop factory start      # start dispatcher + merge-gate + icons
bop factory stop       # stop all services
bop factory uninstall  # unload + remove plists

Workflow

# 1a. Deal an implement card
bop new implement <id>

# 1b. Or brainstorm first
bop bstorm <topic words>

# 2. Note the card ID and session name printed
# 3. Work inside the zellij session (or your current session)
# 4. Write output to output/result.md
# 5. Verify it ran
make check
./target/debug/bop status

# 6. The card auto-moves to done/ when dispatcher exits 0

Installation (Quick Look)

# Build in Xcode → Product → Build
# Then register:
LSREG=/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
$LSREG -f ~/Applications/JobCardHost.app

# Preview a card
qlmanage -p examples/running-feat.jobcard

7-Pane Zellij Layout

┌────────────────┬────────────────┐
│  bop status    │  spec.md       │
│  (board)       │  (current card)│
├────────────────┼────────────────┤
│  dispatcher    │  agent stdout  │
│  log --follow  │                │
├────────────────┼────────────────┤
│  merge-gate    │  agent stderr  │
│  log --follow  │                │
├────────────────┴────────────────┤
│  shell  (bop commands live here)│
└─────────────────────────────────┘

Use layouts/bop.kdl to launch this layout: zellij --layout layouts/bop.kdl

License Compliance

All adapters in this repo use MIT/Apache-2.0-licensed tools only:

  • claude: Anthropic TOS (API usage)
  • codex CLI: MIT (github.com/openai/codex)
  • ollama: MIT (github.com/ollama/ollama)
  • opencode: MIT (github.com/sst/opencode)

Zellij Session Protocol

Sessions are named bop-<card-id>. Always resumable:

zellij attach "bop-<id>" 2>/dev/null || zellij -s "bop-<id>"

The zellij_session field in meta.json is the source of truth. Quick Look renders a live "Attach" button (green) when the field is present and stage is running.

Troubleshooting

Nested Claude sessions: When dispatching from inside Claude Code, CLAUDECODE=1 blocks spawning. The adapter already runs unset CLAUDECODE, but if launching dispatcher manually use env -u CLAUDECODE bop dispatcher --once.

Stale worktrees: If a card fails, its git worktree persists and blocks re-dispatch. Clean with:

git worktree remove --force .worktrees/job-<card-id>
git branch -D job-<card-id>

Icon\r (macOS): Finder drops Icon\r files in directories with custom icons. The dispatcher and bop status filter by .jobcard extension to ignore these.

Provider cooldowns: When a provider hits rate limits (exit 75), the dispatcher rotates to the next provider in provider_chain. If ALL providers are rate-limited, cards requeue until cooldowns expire (default 300s).

Dogfood Check

Before marking any bop work complete, verify:

  • A card exists for the work (bop status)
  • make check passes
  • The feature you built actually processed at least one card

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.