forge
Skill1 starsChanged 4 months agoMITView on GitHub
Star Forge entry point: run or resume the complete Forge lifecycle from intake through proven delivery and done.
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-docs and 8 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
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
tonmoy007Skillforge-build
Run Stage 6 of the Forge pipeline — implementation. Use when the user says
Also in 3 projects that use this
TT-WangSkillforge-status
Show current forge project status, plan, and iteration history
Also in 3 projects that use this
SupabaseSkillspark
Spark REST API for database schema, data, and email/password authentication.
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 repository3 other files it gives its agents.
- forge-planSkill
- forge-reviewSkill
- forge-workSkill
The file
We split this skill into the rules it gives an agent
12 rules. 0 are common, 3 are distinctive, and 9 are very specific to this project.
0
Common
Most of the 67 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 17
After a passing done, a source change enters amend and repeats only the affected build, proof, review, and delivery gates.
- Very specific: line 30
Add --fast-mvp when the user asks for an MVP, hackathon build, prototype, demo, or proof of concept.
- Very specific: line 34
Read the complete .starforge/state.json, especially phase, required_next_action, spawn_plan, lifecycle gates, Blueprint lock, Plan state, …
- Distinctive: line 37
Never resume from memory.
- Very specific: line 41
Keep working in the same invocation until done --strict passes or one honest user-controlled blocker prevents safe progress:
- Very specific: line 44
Run run and read .starforge/state.json.
- Very specific: line 53
After every material change, gate completion, recorded proof, or returned sub-agent wave, rerun run, reread state, and immediately continue …
- Distinctive: line 56
Stop only for a material intake answer, explicit Blueprint approval, a router-approved optional installation that requires user action, …
- Distinctive: line 61
Do not silently skip a failed route or gate.
- Very specific: line 87
When the approved Repository Contract requests a new GitHub repository, create a private repository before feature work, configure origin, …
- Very specific: line 115
If run reports blocked:isolation-required, use the operating card to either create the recommended isolated work/<name>/ project or adopt …
- Very specific: line 150
Only that predicate can declare completion.
“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
Star Forge is one coordinator-owned lifecycle:
intake -> design -> plan -> foundation -> build -> review -> deliver -> done
One $forge invocation owns that whole lifecycle. Do not make the user invoke
$forge-plan, $forge-work, or $forge-review separately. Those skills are phase
playbooks used by this coordinator. A phase transition is a reason to continue,
not a reason to hand control back.
After a passing done, a source change enters amend and repeats only the
affected build, proof, review, and delivery gates.
Resume Before Reasoning
Resolve <plugin-root> as two directories up from this skill file
(skills/forge/). Start every turn, including the first turn, a status request,
post-compaction recovery, or resumed work, with:
python3 <plugin-root>/scripts/star_forge.py run --project . --objective "<objective>"Add --fast-mvp when the user asks for an MVP, hackathon build, prototype, demo,
or proof of concept. Fast MVP reduces optional breadth, but never removes an
authority, security, privacy, proof, review, or delivery requirement.
Read the complete .starforge/state.json, especially phase,
required_next_action, spawn_plan, lifecycle gates, Blueprint lock, Plan state,
review state, and delivery state. The operating card and state are authoritative.
Never resume from memory.
Continuous Coordinator Loop
Keep working in the same invocation until done --strict passes or one honest
user-controlled blocker prevents safe progress:
- Run
runand read.starforge/state.json. - Derive capability needs from the approved or draft project class, enabled
Blueprint flags, Plan v2
Proofvalues, and Delivery Contract target. Resolve them throughstarforge.routing.resolve_routesandconfig/capability-routing.jsonusing the host-discovered capabilities. Follow capability-routing.md. - Execute the current phase with the matching playbook below. The coordinator retains lifecycle, mutation, and evidence ownership even when builders or reviewers are delegated.
- After every material change, gate completion, recorded proof, or returned
sub-agent wave, rerun
run, reread state, and immediately continue with the newly reported phase. - Stop only for a material intake answer, explicit Blueprint approval, a router-approved optional installation that requires user action, missing external authority or credentials, an unsafe destructive choice, or the exact final verdict.
Do not silently skip a failed route or gate. Do not claim that an unavailable capability ran. Report the selected fallback or consolidate unresolved authority, credentials, signing, billing, or production access into one explicit blocker.
Phase Playbooks
| Phase | Coordinator action |
setup | Let run initialize local Git and Star Forge artifacts, resolve isolation if needed, then rerun. |
intake | Use $forge-plan to ask only material unanswered decisions and record explicit assumptions. |
design | Use $forge-plan; when UI research applies, route Mobbin first, then accepted fallbacks, and record an original selected direction or an honest unavailable state. |
plan | Use $forge-plan to obtain one complete Blueprint approval, write the content lock, create and validate Plan v2, then rerun. |
foundation | Establish the approved local or GitHub foundation and coordinator-owned source-bound foundation evidence before feature work. |
build | Use $forge-work for routed task waves, verification, and required live proof. |
review | Use $forge-review for the adaptive review wave and a fresh empty fix queue. |
deliver | Use $forge-review to produce exactly the approved source handoff, private repository, preview, production result, package, or platform-specific result and its fresh delivery proof. |
done | Run the strict completion predicate and report its exact verdict. |
amend | Follow state into the approved change packet, then repeat affected build, review, deliver, and done gates. |
blocked | Read the named blockers, make every safe unblocked repair, then request only the user-controlled decision or authority that remains. |
Foundation Policy
run automatically initializes local Git, Blueprint.md, Plan.md, the ledger,
guardrails, and the starforge-builder and starforge-reviewer roles.
agents-install --project . restores those roles if they were removed.
When the approved Repository Contract
requests a new GitHub repository, create a private repository before feature work,
configure origin, establish the approved default branch and initial commit, and
install CI. Prefer the routed GitHub connector. Use
gh repo create --private only as the narrow repository-creation fallback and
only with approved write authority.
For an existing repository, verify owner, name, remote identity, visibility, and default branch before adoption. Do not overwrite it, change visibility, replace a remote, or otherwise mutate it implicitly.
The coordinator, not a builder, records foundation evidence. It must prove the current source binding, remote identity and private visibility when requested, default branch, initial or adopted commit, CI path, and every other requested Foundation Contract check.
External Authority
Blueprint approval authorizes only the non-destructive external writes explicitly listed in the Repository and Delivery contracts. Plugin installation always requires user action. Public repositories, public deployment, visibility changes, destructive replacement, paid resources, billing changes, signing identities, notarization, production data changes, and production release require specific authority. Preserve safe local progress, then surface one precise blocker if that authority is absent.
Isolation and Hooks
If run reports blocked:isolation-required, use the operating card to either
create the recommended isolated work/<name>/ project or adopt the root only when
the user has deliberately chosen that scope.
python3 <plugin-root>/scripts/star_forge.py run --project . --product-slug <name> --objective "<objective>"
python3 <plugin-root>/scripts/star_forge.py run --project . --adopt-root --objective "<objective>"On first use or after a plugin upgrade, mention once that /hooks enables bundled
observer diagnostics and compaction re-anchors. Hooks are optional observers and
do not upgrade the completion verdict.
Delegation and Evidence Ownership
Codex never auto-spawns sub-agents. Use the exact entries in spawn_plan. Delegate
real implementation to starforge-builder and review-only work to
starforge-reviewer. Respect owned files, dependencies, and the current thread
cap. When the host cap is 6, schedule waves of at most 5 sub-agents, wait between
waves, and close finished agents before dispatching more.
Builders and reviewers may return source changes or findings, but their narrative claims are not proof. The coordinator alone runs and records task verification, live proof, foundation proof, merged review state, delivery proof, and final completion against the current source hash. Never backfill evidence for work that did not run.
Completion Honesty
Run:
python3 <plugin-root>/scripts/star_forge.py done --project . --strictOnly that predicate can declare completion. It requires the approved Blueprint,
complete Plan tasks with fresh proofs, an empty fresh review queue, the exact
approved Delivery Contract result, and a clean tree. A pass writes
.starforge/final/proof.json. Quote the verdict line
verbatim, including any advisory or waived-finding suffix. If it refuses, repair
its problems and continue the loop. Never paraphrase an advisory result as
unqualified completion.
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.

