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

bop-workflow

Skill1 starsChanged 50 days agoMITView on GitHub

Use when explaining how to use bop from scratch — bare minimum setup, creating cards, dispatching agents, and reading results. Good for onboarding a new user who just has a project folder.

  • Reads credentials
  • Installs packages

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every card's prompt.md is rendered and sent to the agent.

    line 83
  2. Very specific:

    Create or edit .cards/pending/<id>.jobcard/spec.md:

    line 101

≈ “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: Bare Minimum Workflow

bop is a job card system. You write specs; agents do the work. Cards live in .cards/ as directories. The filesystem is the state machine.


One-Time Setup (per machine)

# Install
brew install bop           # or: cargo install bop

# Set your API key (Claude adapter)
export ANTHROPIC_API_KEY=sk-...    # add to ~/.zshrc

# Done. No server, no database.

Per-Project Setup (one-time per folder)

cd my-project/

bop init                   # creates .cards/ skeleton
bop factory install        # starts dispatcher + merge-gate as background services

bop init creates:

.cards/
  pending/       ← new work lands here
  running/       ← agent is working on it
  done/          ← agent finished
  merged/        ← accepted into your codebase
  failed/        ← something went wrong
  templates/     ← how cards are shaped (implement, qa, etc.)
  providers.json ← which agents handle which cards
  system_context.md ← tell agents what this project is about

Tell agents what they're working on:

echo "This is a Rust CLI tool. Tests run with: cargo test" > .cards/system_context.md

Daily Loop

1. Deal a card

bop new implement fix-auth-bug

This drops a card in pending/. The dispatcher picks it up automatically.

2. Watch it run

bop status                 # card counts: 2 pending, 1 running, 5 done
bop inspect fix-auth-bug   # show spec + live log tail

Cards move: pending/ → running/ → done/ → merged/

3. Read the result

bop inspect fix-auth-bug   # shows output/result.md

Or browse in Finder — .jobcard bundles show as playing-card thumbnails.


The Agent Prompt

Every card's prompt.md is rendered and sent to the agent. Key variables:

{{system_context}}      ← your .cards/system_context.md
{{stage_instructions}}  ← what this stage should do (e.g. "write code, run tests")
{{spec}}                ← your spec.md
{{acceptance_criteria}} ← shell commands that must pass before merge

Acceptance criteria runs automatically before merge:

"acceptance_criteria": ["cargo test", "cargo clippy -- -D warnings"]

Writing a Good Spec

Create or edit .cards/pending/<id>.jobcard/spec.md:

# Fix Authentication Bug

## Problem
The login flow silently swallows JWT validation errors, causing
200 OK responses on invalid tokens.

## Expected
Return 401 with `{"error": "invalid_token"}` when JWT fails.

## Files to touch
- src/auth/middleware.rs (line ~45, validate_jwt fn)
- tests/auth_test.rs (add rejection test)

That's it. Agent reads the spec and does the work.


Templates

TemplateUse when
implementYou have clear requirements
fullFuzzy requirements (spec→plan→implement→qa)
cheapSmall fix, use local Ollama model
qa-onlyCode review an existing branch
bop new full design-new-api          # 4-stage pipeline
bop new cheap fix-typo               # local model, free
bop new qa-only review-pr-42         # just QA stage

Providers (Which Agent Runs)

.cards/providers.json maps provider names to adapter scripts:

{
  "providers": {
    "claude": { "command": "adapters/claude.zsh", "rate_limit_exit": 75 },
    "ollama":  { "command": "adapters/ollama-local.zsh", "rate_limit_exit": 75 }
  }
}

On rate-limit (exit 75), the dispatcher rotates to the next provider automatically.


Three Things Users Touch

  1. spec.md — what to build (plain markdown)
  2. system_context.md — what the project is (orientation for every agent)
  3. acceptance_criteria in meta.json — shell tests that gate merge

Everything else — prompts, providers, stages, git branches, logs — is handled automatically.


Factory Commands

bop factory status         # check services are running
bop factory start          # start dispatcher + merge-gate
bop factory stop           # pause processing
bop factory install        # register as launchd services (survives reboots)
bop factory uninstall      # remove launchd services

Useful Inspection Commands

bop status                 # counts by state
bop inspect <id>           # full detail: spec + meta + log tail
bop logs <id>              # live log stream
bop approve <id>           # clear a decision_required gate
bop kill <id>              # terminate a running agent

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.

Reviews can't be read right now.

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.