agentleFS
cukascukas/claudes-ai-buddies/skills/forge/SKILL.md

forge

Skill9 starsChanged 8 months agoMITView on GitHub

Evolutionary multi-AI code forge — three AIs build, test, and cross-pollinate

  • Deletes or force-pushes

78 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use forge-ship, forge-review and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • redteamlifeSkill

    forge-ship

    Use when the user asks to merge, release, promote, reconcile, or close out work in a repo containing `docs/forge/` or governed by FORGE. Not for per-task commits; those complete inside forge-execute-task.

    Also in 6 projects that use this

  • tonmoy007Skill

    forge-review

    Run a multi-dimensional parallel code review over the current change.

    Also in 8 projects that use this

  • weselbenSkill

    forge-docs

    Load before code changes, before writing docs or an ADR, when a user question exposes a missing how-to, and when closing a chunk of work; also loaded by forge after each squash-merge and by deep-research after a report.

    Also in 3 projects that use this

  • DailenGSkill

    forge-design

    Design, UX, and polish discipline for the forge lifecycle. Covers the design tier, the design brief in docs/DESIGN.md, UX requirements and their verification methods, the per-slice design pass, the UX defect register, and the release polish pass. Load whenever work touches a user-facing surface (GUI, terminal, library API, or operated service), whenever a UX observation needs disposing of, and whenever a release is in reach.

    Also in 3 projects that use this

  • DshamirSkill

    forge-plan

    Takes analysis.json + budget cap → derives the full phase sequence, hyperparameters, instance type, cost estimate, and acceptance thresholds. Emits plan.md (the single human gate document) and plan.json (the machine-readable spec that dispatch-v2 consumes). Refuses to plan if estimated cost exceeds budget×1.2.

    Also in 4 projects that use this

  • tonmoy007Skill

    forge-build

    Run Stage 6 of the Forge pipeline — implementation. Use when the user says

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. 0 are common, 8 are distinctive, and 13 are very specific to this project.

  • 0

    Common

    Most of the 67 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 13

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When building a plan, Claude can tag tasks:

    line 29
  2. Very specific:

    No tag or [direct] — straightforward, Claude handles normally

    line 31
  3. Very specific:

    When --fitness is omitted, run the spectest pre-phase:

    line 75
  4. Very specific:

    Trust boundary: If any proposal has "needs_review": true, the proposed test command is outside the safe allowlist.

    line 84
  5. Distinctive:

    Before dispatching: Use your judgment — if the conversation contains context that would help the engines (constraints, failed approaches, …

    line 90
  6. Distinctive:

    Keep under ~500 tokens — actionable facts only, not the full transcript

    line 94
  7. Very specific:

    Important: Always pass --cwd to bind the forge to the correct repository, especially in async/background mode.

    line 111
  8. Very specific:

    Run via Bash tool with run_in_background: true.

    line 123
  9. Distinctive:

    If accepted → skip to Phase 2 (read results)

    line 130
  10. Very specific:

    Read $FORGE_DIR/manifest.json.

    line 140
  11. Very specific:

    If baseline_passes is true, warn the user: "Fitness test passes on untouched code — results may be unreliable.

    line 198
  12. Very specific:

    If stage1_accepted is true, note: "Auto-accepted in Stage 1 (score >= 88)." If close_call is true, note: "Close call — synthesis was …

    line 199
  13. Very specific:

    If close_call is true, note: "Close call — synthesis was attempted." If synthesis.wins is true, note: "Synthesis improved score from X to …

    line 200
  14. Very specific:

    If synthesis.wins is true, note: "Synthesis improved score from X to Y." The winner field becomes "synthesis" and the final patch is at …

    line 201
  15. Very specific:

    If no engine passed: show all as [UNVERIFIED], report highest scorer, ask user.

    line 203
  16. Very specific:

    All config via ~/.claudes-ai-buddies/config.json:

    line 232
  17. Distinctive:

    After scoring, forge automatically updates ELO ratings:

    line 250
  18. Distinctive:

    Claude is a pure orchestrator: Never implement directly. Dispatch all work to engine subprocesses.

    line 257
  19. Distinctive:

    Baseline check: If fitness passes on untouched code, warn user before proceeding.

    line 261
  20. Very specific:

    Prompts from lib.sh: Use ai_buddies_build_forge_prompt() — never inline prompt text.

    line 263
  21. Distinctive:

    No-op guard: If an engine's diff is empty, it gets score 0 regardless of fitness.

    line 264

“Common” is measured: kept by at least 6 in 10 of the 67 edited versions of this file we could read. “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

/forge — Evolutionary Multi-AI Code Forge (v2)

Three AI engines independently implement the same task, compete on automated fitness tests, then the best solution is refined through critique-based synthesis. Claude is a pure orchestrator — it dispatches, scores, and judges but never competes.

How to invoke

Direct forge — user specifies a focused task:

/forge "Add NaN guard to scoring" --fitness "npx jest"

Optional flags:

  • --timeout SECS — override the safety cap (default: 600s from config key forge_timeout)
  • --async — run in background, continue conversation
  • --engines claude,codex — limit which engines compete (default: all available)
  • --starter codex — override which engine runs first

Using forge inside existing planning workflows

/forge works as a tool within any plan — /build-guard, /plan-guarded, plan mode, or any task list.

The [forge] tag

When building a plan, Claude can tag tasks:

  • [forge] — algorithmic, tricky, multiple valid approaches
  • No tag or [direct] — straightforward, Claude handles normally

What to tag [forge]

  • Algorithms, scoring logic, data transformations
  • Race condition fixes, concurrency patterns
  • Performance-critical code paths
  • Anything with multiple valid approaches where three perspectives help

What NOT to tag [forge]

  • Types, imports, config, UI layout, wiring
  • Boilerplate, glue code — one obvious answer
  • Anything without a runnable fitness test

Step-by-step workflow

Phase 0: Setup

  1. Parse args. Extract the task, --fitness command, optional --timeout, --async, --engines, --starter.
  2. Detect engines. Source lib.sh and use the dynamic registry:
source "${CLAUDE_PLUGIN_ROOT}/hooks/lib.sh"
AVAILABLE=$(ai_buddies_available_buddies)  # CSV: "claude,codex,gemini,aider,..."
FORGE_TIMEOUT=$(ai_buddies_forge_timeout)

Any registered buddy with an installed binary will participate.

  1. Create forge directory:
FORGE_ID="$(date +%s)-${RANDOM}"
FORGE_DIR="/tmp/ai-buddies-${CLAUDE_SESSION_ID:-default}/forge-${FORGE_ID}"
mkdir -p "$FORGE_DIR"
  1. Tell the user how many engines are available, which is the starter, the task, and what fitness will run.

Phase 0.5: Speculative Test Generation (if no --fitness)

When --fitness is omitted, run the spectest pre-phase:

SPECTEST_RESULT=$(bash "${CLAUDE_PLUGIN_ROOT}/scripts/forge-spectest.sh" \
  --task "$TASK" --cwd "$(pwd)" --timeout "$FORGE_TIMEOUT")

Review proposals, pick best, present to user for approval. Once approved, set --fitness.

Trust boundary: If any proposal has "needs_review": true, the proposed test command is outside the safe allowlist. You MUST present the command to the user and get explicit approval before using it as --fitness. Never auto-accept unreviewed commands.

Phase 1: Dispatch via forge-run.sh (staged escalation)

Claude does NOT implement. Claude dispatches ALL engines (including a Claude subprocess) through forge-run.sh.

Before dispatching: Use your judgment — if the conversation contains context that would help the engines (constraints, failed approaches, user preferences, key decisions), summarize it. If the task is self-contained, skip it. Include:

  • The user's original ask and constraints ("must be backwards compatible")
  • Key decisions ("user wants X, not Y")
  • What was already tried and failed
  • Keep under ~500 tokens — actionable facts only, not the full transcript

Store in $CONVERSATION_CONTEXT (empty string if no relevant context).

Synchronous (default):

MANIFEST_PATH=$(bash "${CLAUDE_PLUGIN_ROOT}/scripts/forge-run.sh" \
  --forge-dir "$FORGE_DIR" \
  --task "$TASK" \
  --fitness "$FITNESS_CMD" \
  --cwd "$(pwd)" \
  --timeout "$FORGE_TIMEOUT" \
  --conversation-context "$CONVERSATION_CONTEXT")

IMPORTANT: Set the Bash tool's timeout parameter to 600000 (10 minutes) for synchronous forge runs. The default Bash timeout (120s) will kill slow engines mid-execution.

Important: Always pass --cwd to bind the forge to the correct repository, especially in async/background mode.

Async (when --async flag is set):

bash "${CLAUDE_PLUGIN_ROOT}/scripts/forge-run.sh" \
  --forge-dir "$FORGE_DIR" \
  --task "$TASK" \
  --fitness "$FITNESS_CMD" \
  --cwd "$(pwd)" \
  --timeout "$FORGE_TIMEOUT" \
  --conversation-context "$CONVERSATION_CONTEXT"

Run via Bash tool with run_in_background: true.

How staged escalation works (inside forge-run.sh)

  1. Baseline preflight — run fitness on untouched code. If it passes, warn user (fitness test is non-discriminating).
  2. Stage 1 — dispatch starter engine alone. Score it.
    • Auto-accept if: pass=true, score >= 88, lint <= 2, style >= 90
    • If accepted → skip to Phase 2 (read results)
  3. Stage 2 — dispatch remaining challengers in parallel. Score all.
    • Clear winner if spread >= 8 points → skip synthesis
  4. Stage 3 — if close call (spread < 8, >= 2 passed):
    • Losers send max 3 critique hunks (JSON) against winner's diff
    • Winner refines from critiques in fresh worktree
    • Re-score refined version; keep only if improved

Phase 2: Read Results

Read $FORGE_DIR/manifest.json. It contains:

{
  "forge_id": "...",
  "forge_dir": "...",
  "engines": ["claude","codex","gemini"],
  "task": "...",
  "starter": "claude",
  "baseline_passes": false,
  "stage1_accepted": false,
  "engines_dispatched": 3,
  "results": {
    "<engine>": {
      "pass": true,
      "score": 85,
      "diff_lines": 27,
      "files_changed": 1,
      "duration_sec": 12,
      "lint_warnings": 0,
      "style_score": 95
    }
  },
  "patches": { "<engine>": "path/to/patch.diff" },
  "winner": "codex",
  "close_call": false,
  "synthesis": {
    "pass": true,
    "score": 91,
    "wins": true,
    "patch": "path/to/synth-patch.diff",
    "original_winner_score": 85
  }
}

Phase 3: Scoreboard

Present to user — columns for available engines only:

## Forge Scoreboard: [task summary]

| | Engine 1 | Engine 2 | Engine 3 |
|---|---|---|---|
| Fitness | PASS/FAIL/TIMEOUT | ... | ... |
| Score | 85/100 | ... | ... |
| Duration | Xs | ... | ... |
| Files changed | N | ... | ... |
| Diff size | N lines | ... | ... |
| Lint warnings | N | ... | ... |
| Style score | N/100 | ... | ... |

**Starter:** [engine] (stage 1)
**Engines dispatched:** N
**Winner:** [engine] — score X/100.

If baseline_passes is true, warn the user: "Fitness test passes on untouched code — results may be unreliable. Consider a more specific test." Do NOT auto-apply. If stage1_accepted is true, note: "Auto-accepted in Stage 1 (score >= 88)." If close_call is true, note: "Close call — synthesis was attempted." If synthesis.wins is true, note: "Synthesis improved score from X to Y." The winner field becomes "synthesis" and the final patch is at patches.synthesis.

If no engine passed: show all as [UNVERIFIED], report highest scorer, ask user.

Phase 4: Converge

Ask user before applying. Show winning diff (or synthesis diff if synthesis won). Options:

  • Apply: Claude reads winning diff and applies via Edit tool.
  • Cherry-pick: Claude applies selected changes only.
  • Discard: Clean up.

Cleanup

Always run, regardless of outcome:

for engine in claude codex gemini baseline synth; do
  git worktree remove "$FORGE_DIR/wt-$engine" --force 2>/dev/null || true
done
rm -rf "$FORGE_DIR"

Graceful degradation

  • 3 engines: Full three-way staged forge.
  • 2 engines: Starter + 1 challenger. Synthesis if close.
  • 1 engine (solo): Single engine + fitness loop. No synthesis.
  • Timeout/error: Mark in scoreboard, continue with remaining engines.

Configuration

All config via ~/.claudes-ai-buddies/config.json:

KeyDefaultDescription
forge_enabled_enginesclaude,codex,geminiWhich engines can compete
forge_starter_strategyfixedfixed or rotate
forge_fixed_starterclaudeDefault starter when strategy=fixed
forge_auto_accept_score88Stage 1 auto-accept threshold
forge_clear_winner_spread8Points spread to skip synthesis
forge_enable_synthesistrueEnable critique-based synthesis
forge_max_critiques3Max critique hunks per loser
forge_require_baseline_checktrueRun fitness on base before forging
forge_timeout600Engine timeout in seconds
elo_enabledtrueTrack ELO ratings after each forge
elo_k_factor32ELO K-factor

ELO Integration (v3)

After scoring, forge automatically updates ELO ratings:

  • Winner gains points vs each loser (per task class)
  • Task class is auto-detected from the task description (algorithm, bugfix, refactor, feature, test, docs, other)
  • View ratings with /leaderboard

Rules

  • Claude is a pure orchestrator. Never implement directly. Dispatch all work to engine subprocesses.
  • Require --fitness (or run spectest pre-phase to generate one).
  • Never touch user's working tree until Phase 4 with explicit approval.
  • Always clean up worktrees, even on error.
  • Baseline check: If fitness passes on untouched code, warn user before proceeding.
  • Stage before diffing: git add -A then git diff --cached to capture new files.
  • Prompts from lib.sh: Use ai_buddies_build_forge_prompt() — never inline prompt text.
  • No-op guard: If an engine's diff is empty, it gets score 0 regardless of fitness.
  • Deterministic tiebreaker: score > lint(fewer) > style(higher) > diff(fewer) > files(fewer) > duration(less) > stable engine order.

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.