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
- venhdev/skillstheir own version, first seen Nov 8, 2026
- faizanio/FORGEtheir own version, first seen Nov 8, 2026
- jeanchristoph/claude_forgetheir own version, first seen Nov 6, 2026
- pche-broken-artist/forge-of-thoughttheir own version, first seen Nov 6, 2026
- rmkr/skillstheir own version, first seen Nov 5, 2026
- flopperj/dotfiles-coretheir own version, first seen Nov 4, 2026
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.
redteamlifeSkillforge-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
tonmoy007Skillforge-review
Run a multi-dimensional parallel code review over the current change.
Also in 8 projects that use this
weselbenSkillforge-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
DailenGSkillforge-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
DshamirSkillforge-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
tonmoy007Skillforge-build
Run Stage 6 of the Forge pipeline — implementation. Use when the user says
Also in 3 projects that use this
Other versions78 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 78
- cwinvestments/memstack★ 425same name
- ansari-project/codev★ 298same name
- cluesmith/codev★ 298same name
- swyxio/skills★ 194same name
- simota/agent-skills★ 96same name
- alp82/forge★ 36same name
- TT-Wang/forge★ 34same name
- emiliosheinz/agent-skills★ 20same name
- MetalLegBob/solana-vibes-kit★ 19same name
- kecoma1/MQL5-SKILLS★ 17same name
68 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- add-buddySkill
- brainstormSkill
- campfireSkill
- codex-reviewSkill
- codexSkill
- gemini-reviewSkill
- geminiSkill
- leaderboardSkill
- opencode-reviewSkill
- opencodeSkill
- tribunalSkill
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
- Distinctive: line 29
When building a plan, Claude can tag tasks:
- Very specific: line 31
No tag or [direct] — straightforward, Claude handles normally
- Very specific: line 75
When --fitness is omitted, run the spectest pre-phase:
- Very specific: line 84
Trust boundary: If any proposal has "needs_review": true, the proposed test command is outside the safe allowlist.
- Distinctive: line 90
Before dispatching: Use your judgment — if the conversation contains context that would help the engines (constraints, failed approaches, …
- Distinctive: line 94
Keep under ~500 tokens — actionable facts only, not the full transcript
- Very specific: line 111
Important: Always pass --cwd to bind the forge to the correct repository, especially in async/background mode.
- Very specific: line 123
Run via Bash tool with run_in_background: true.
- Distinctive: line 130
If accepted → skip to Phase 2 (read results)
- Very specific: line 140
Read $FORGE_DIR/manifest.json.
- Very specific: line 198
If baseline_passes is true, warn the user: "Fitness test passes on untouched code — results may be unreliable.
- Very specific: line 199
If stage1_accepted is true, note: "Auto-accepted in Stage 1 (score >= 88)." If close_call is true, note: "Close call — synthesis was …
- Very specific: line 200
If close_call is true, note: "Close call — synthesis was attempted." If synthesis.wins is true, note: "Synthesis improved score from X to …
- Very specific: line 201
If synthesis.wins is true, note: "Synthesis improved score from X to Y." The winner field becomes "synthesis" and the final patch is at …
- Very specific: line 203
If no engine passed: show all as [UNVERIFIED], report highest scorer, ask user.
- Very specific: line 232
All config via ~/.claudes-ai-buddies/config.json:
- Distinctive: line 250
After scoring, forge automatically updates ELO ratings:
- Distinctive: line 257
Claude is a pure orchestrator: Never implement directly. Dispatch all work to engine subprocesses.
- Distinctive: line 261
Baseline check: If fitness passes on untouched code, warn user before proceeding.
- Very specific: line 263
Prompts from lib.sh: Use ai_buddies_build_forge_prompt() — never inline prompt text.
- Distinctive: line 264
No-op guard: If an engine's diff is empty, it gets score 0 regardless of fitness.
“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.
Files
/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 keyforge_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
- Parse args. Extract the task,
--fitnesscommand, optional--timeout,--async,--engines,--starter. - 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.
- Create forge directory:
FORGE_ID="$(date +%s)-${RANDOM}"
FORGE_DIR="/tmp/ai-buddies-${CLAUDE_SESSION_ID:-default}/forge-${FORGE_ID}"
mkdir -p "$FORGE_DIR"- 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)
- Baseline preflight — run fitness on untouched code. If it passes, warn user (fitness test is non-discriminating).
- 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)
- Auto-accept if:
- Stage 2 — dispatch remaining challengers in parallel. Score all.
- Clear winner if spread >= 8 points → skip synthesis
- 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:
| Key | Default | Description |
forge_enabled_engines | claude,codex,gemini | Which engines can compete |
forge_starter_strategy | fixed | fixed or rotate |
forge_fixed_starter | claude | Default starter when strategy=fixed |
forge_auto_accept_score | 88 | Stage 1 auto-accept threshold |
forge_clear_winner_spread | 8 | Points spread to skip synthesis |
forge_enable_synthesis | true | Enable critique-based synthesis |
forge_max_critiques | 3 | Max critique hunks per loser |
forge_require_baseline_check | true | Run fitness on base before forging |
forge_timeout | 600 | Engine timeout in seconds |
elo_enabled | true | Track ELO ratings after each forge |
elo_k_factor | 32 | ELO 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 -Athengit diff --cachedto 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.
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
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.

