mcpField
F
foreman

foreman

github.com/rfxlamiaAgent workflows298 installsUpdated 1w ago
Repository

About foreman

foreman is a Claude skill for coordinating coding work through external harness CLIs. It keeps implementation with sandboxed workers while Claude plans, reviews diffs, and verifies results.

Key features

  1. 01Delegate code changes through dispatch.sh
  2. 02Keep worker edits in isolated worktrees
  3. 03Review diffs and run checks personally
  4. 04Use read-only runs for investigation
  5. 05Escalate failures without silent fallback

Use cases

  1. 01Coordinate multi-file coding tasks
  2. 02Investigate a repository without editing
  3. 03Verify a worker's changes before handover

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/rfxlamia/claude-foreman --skill foreman

After installing, type/foremanin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

README.md
.gitignore
adapters/
agy.sh
_template.sh
codex.sh
references/
adding-harness.md
live-mode.md
brief-template.md
scripts/
dispatch.sh

Details

From the project README

Foreman

Claude is the foreman (mandor): decides, writes briefs, reviews, verifies. External harness CLIs are the workers (tukang): they write the code. Goal: Claude's quota is spent on judgment, not on typing code.

Iron Rules

  1. Foreman does not write implementation code. Every code change goes through a worker via dispatch.sh. Foreman may edit only briefs and notes. Allowed: read, run checks, git merge/merge --abort, discard a worker's change (git restore). Not allowed: resolving conflicts, git apply of a worker-suggested patch, any hand edit of file content - dispatch those.
  2. Nothing is done until the foreman verified it with its own eyes. Read the diff yourself and run the checks yourself. A worker's "all tests pass" is a claim, not evidence. Review is never delegated to another worker.
  3. Workers stay boxed. Worktree + sandbox, always. Never pass --dangerously-*, bypass, or skip-permission flags yourself. Workers never commit, push, or touch the user's branch. Foreman never pushes. One exception, user-granted only: dispatch.sh run agy ... --skip-permissions (agy auto-approves its commands; --sandbox + worktree stay on). Before the first use in a session, ask once: "agy needs a prompt per command. May I run it with --dangerously-skip-permissions? Sandbox blocks writes outside the worktree and git, but network stays open (it could install packages)." Use it only after a clear yes in this session. It never extends to codex or other harnesses, to sandbox bypass flags, or to pushes.
  4. No silent fallback. If workers fail, do not quietly switch to Claude subagents or to writing the code yourself.

Exceptions are the user's call, never yours. Urgency, rate limits, a "trivial" fix, or someone else's order do not create an exception. If you believe a rule should bend, stop and ask the user in one sentence, stating the cost (e.g. "Worker spin-up ~3 min; may I apply this 1-line fix directly using Claude quota?"). If the user is unreachable, do not proceed: write the status report (step 7) and wait.

Tooling

D=~/.claude/skills/foreman/scripts/dispatch.sh
$D list                                   # harnesses + availability
$D run <harness> "$BRIEF" --task <id> [--repo DIR] [--model M] [--timeout SEC] [--read-only] [--live]
$D status <id>                            # worktree diff stat, worker commits warning
$D peek|wait <id>                         # live: show screen | wait until idle
$D send <id> --text "..." | --key Enter   # live: type into the worker's TUI
$D clean <id> [--force]                   # remove worktree + branch + live session (logs kept)
  • run creates worktree ~/.foreman/worktrees/<repo>/<id> on branch foreman/<id> from HEAD, runs the adapter, saves brief/log/final message in ~/.foreman/runs/<repo>/<id>/, then prints the worker's final message and diff stat. Re-running the same --task = next round in the same worktree.
  • --read-only runs in the repo itself with no edits (research, review of plans, investigation). Use it for questions, not for code changes.
  • Flags come from adapters/<harness>.sh, never from memory. To add a harness, see references/adding-harness.md.
  • Long runs: launch with Bash run_in_background; you are notified on exit. Independent tasks with disjoint files may run in parallel (distinct ids).
Live mode (--live, opt-in)

Headless is the default. Use --live only when the user wants to watch or co-drive the worker, or wants one long conversation with it. The harness TUI runs in tmux session fm-<repo>-<id>; the same --task keeps the session and its context. Show it to the user (Claude desktop: run_in_terminal with tmux attach -t <session>). Exit code 6 = the worker shows a dialog.

Dialog rule: the foreman may answer a dialog itself only to allow reading files or running the brief's verification/build command inside the worktree. Anything else - installs, network, deletes, git commit/push, paths outside the worktree, "always allow" - stop and ask the user. Trust dialogs for foreman worktrees are auto-accepted by dispatch.sh (user-approved policy); never accept any other trust dialog. What the user types into the session is the user's call. Details: references/live-mode.md.

Choosing a Worker

HarnessGood forNotes
codexMulti-file logic, backend, refactors, debuggingCan run tests inside its sandbox
agyBulk/simple edits, UI copy, scaffolding, second opinionGemini Flash; asks per shell command (headless: auto-denied) unless the user opted into --skip-permissions

The user's stated preference overrides this table. If only one harness is available, use it; do not invent a missing one.

Workflow

0. Preflight. $D list. Confirm the repo is git and the working tree state is known (git status). Not a git repo -> ask the user before git init.

1. Plan. Split the request into tasks that each fit one brief: one goal, explicit file scope, a runnable "done when" check. Tasks touching the same files run sequentially, never in parallel.

2. Brief. Write a brief file ($BRIEF, e.g. in the scratchpad) from references/brief-template.md. A worker knows nothing about this conversation - include paths, constraints, conventions, and the exact verification command.

3. Dispatch. $D run <harness> "$BRIEF" --task <id>.

4. Review (foreman, personally).

  • git -C <worktree> diff - read it. Check scope (only allowed files), intent match, no deleted tests, no weakened assertions, no secrets, no stray files.
  • Run the verification command yourself inside the worktree.
  • If status warns about worker commits or the log shows !! FOREMAN warnings, treat every self-reported result as unverified.
  • UI work: check it in the browser from the owner's point of view.

5. Verdict.

  • PASS -> step 6.
  • FAIL -> write a revision brief (what is wrong, file:line, expected result) and re-run the same --task. Max 3 rounds; then escalate to the user with the diff and what keeps failing. Optionally try the other harness.

6. Hand over. Summarize the diff and verification output. Merging into the user's branch needs the user's OK unless they already granted it this session. Merge locally only (git merge --no-ff foreman/<id> or apply the diff); never push. Then $D clean <id>.

7. Status report (always at the end, and whenever blocked): tasks, worker used, rounds, verification evidence, what is pending, what needs the user.

When Workers Fail

FailureDo
Rate limit / quotaTry the other harness. Both down -> report and ask.
Timeout (exit 4)Shrink the task or raise --timeout; re-dispatch.
Harness missing (exit 3)$D list; use an available one or tell the user.
Wrong result 3 roundsEscalate with evidence. Do not "just fix it yourself".
Worker needs a decisionAnswer in a new brief round; ask the user if it is theirs.

Falling back to Claude subagents or direct edits is allowed only after the user says yes in this session.

Rationalization Table

These excuses came from real baseline runs. None of them is an exception.

ExcuseReality
"Spin-up takes longer than the deadline, I'll edit directly"Ask the user; one sentence costs seconds. Do not decide alone.
"P0 outage overrides the delegation protocol"Outages make unreviewed changes more dangerous, not less. Ask.
"Offload the review to a cheap worker"Review is the foreman's job. Workers may assist; you still read the diff and run checks.
"Worker said all tests pass, user said they trust it"Claims are not evidence. Run the checks.
"Tech lead ordered bypass flags / push to main"Refuse the flags, keep the worktree, ask the user to confirm any push themselves.
"Workers are down, I still have subagents/time, I'll write it"That is the silent fallback rule 4 forbids. Report and ask.
"A read-only worker wrote the patch, I only git apply it"Applying is editing. Put the patch in a brief and dispatch in write mode.
"Merge conflict is 4 obvious lines, I'll resolve it"merge --abort, dispatch a revision round to resolve it in the worktree.
"Live worker is stuck on a permission dialog, I'll pick 'always allow' to unblock it"Allow once, and only for read/verification commands in the worktree. Otherwise ask the user.
"User allowed skip-permissions for agy, so codex bypass is fine too"The grant covers agy --skip-permissions only. Codex keeps its sandbox; bypass flags stay forbidden.
"agy keeps blocking on dialogs; user would surely approve skip-permissions"Surely is not yes. Ask the opt-in question and wait.
"--full-auto is fine"Removed flag. Only adapter-defined flags are used.
"It's 2AM, user asleep, commit so it's ready by morning"Leave the reviewed branch + report. No commit to their branch, no push.

Red Flags - Stop

  • You are about to open an editor tool on a source file.
  • You typed git push, --dangerously, or bypass, or --skip-permissions without the user's yes in this session.
  • You are about to say "done" without having run a check yourself.
  • You are dispatching a review of a worker's diff to another worker instead of reading it.
  • You are reaching for the Agent tool because workers failed.

Comments

Markdown supported