A guide for people who are not developersForge

Software projects fail in boring ways. You describe what you want too vaguely and get the wrong thing. You lose two days of work because nothing was saved properly. You come back after a week and cannot remember what you were doing. You ship something that quietly broke last Tuesday and nobody noticed.

Forge is a set of instructions that runs inside Claude Code. It does not write your software for you so much as it insists on doing it in an order that works, and it stops at the points where a human has to make a real decision.

Three phases, in order, with a hard stop between each. You cannot skip ahead, and neither can Claude. Think of it the way a building goes up: drawings get approved before anyone pours concrete.

How /forge knows where you are

You never tell it which phase you are in. It looks at your project and works it out. Expand a rung to see what happens in that situation.

Forge comes in two editions. They do the same job and produce the same project. The only difference is which generation of Claude model the instructions inside are written for, and that matters more than it sounds like it should.

Newer models follow instructions closely and check their own work without being told to. Older ones needed to be reminded, repeatedly and in detail. Give a newer model the older style and it over-checks everything and wastes effort. So there is one edition per generation rather than one that tries to suit both.

If you are not sure which you are on, install the first one. It is the maintained edition, and it is what the rest of this guide describes.

Two commands. Claude Code fetches Forge from a public catalog and installs it for you. These install the Claude 5 edition, which is the one you want unless you read section 03 and decided otherwise.

# point Claude Code at the catalog, then install the plugin
claude plugin marketplace add DailenG/dailens-claude-toolbelt
claude plugin install forge-workflow@dailen

Confirm when it asks, then run /reload-plugins or restart Claude Code. Type / and you should see forge in the list along with three others. Those three are manual overrides you will probably never need.

When a new version ships later, claude plugin marketplace update dailen pulls it down.

The manual way, if you would rather

Prefer to drop the folder into place by hand? Download the zip from the releases page, close Claude Code, then extract it so the folder lands here:

C:\Users\<you>\.claude\skills\forge-workflow\

On Windows, that .claude folder is hidden. Paste the path into the Explorer address bar rather than trying to click your way to it. Check it worked:

# should report no problems
claude plugin validate $env:USERPROFILE\.claude\skills\forge-workflow --strict

# should list forge-workflow@skills-dir
claude plugin list

Restart Claude Code and you land in the same place as the two-command install above.

Make an empty folder, open Claude Code inside it, and type /forge. Nothing else.

It will start asking questions in small batches, three to seven at a time, with lettered options where there is a sensible shortlist. Most rounds you can answer with a few letters and a phrase.

The confidence score

After each round it scores how well it understands ten areas, and reports the lowest one, not the average. That is deliberate. Averaging lets a single unanswered question hide behind nine confident ones, and that question is usually the one that wrecks the project later.

It keeps going until the lowest score reaches 95. In practice that is six to eight rounds and maybe twenty minutes.

Choosing the technology

Once it understands the problem, it presents two or three options for what to build it in, with honest downsides for each, and recommends one. You can accept or override. If you override, your reason gets written down alongside the original recommendation, so in a year you can see why.

Phase 1 ends with a written specification and a full stop. Claude will not approve its own spec. This is the most valuable twenty minutes in the project, so actually read it.

When you approve, the spec becomes a living document. It can still change, but only by adding a dated amendment explaining what changed and why, never by quietly rewriting history.

This phase touches your computer, so it is the one most likely to need you. It assumes nothing is installed and checks everything, but only installs what is genuinely missing.

Work happens in slices. A slice is one complete piece of usable behaviour, not one technical layer. "Scan a folder and print what it found" is a slice. "The database code" is not, because on its own it does nothing you can look at.

Hardest slice goes first. That feels backwards, and it is correct: if something is going to turn out impossible, you want to find out on day one, not in week three.

Why write the test before the thing works

Because a test that has never failed has not been shown to test anything. Plenty of tests pass because they check nothing at all, or check the wrong thing entirely, and you cannot tell the difference by reading them. Watching it fail first, then pass, proves it is connected to reality.

After each slice you get a short report: what works now, what does not yet, what is next. By default it carries straight on to the next slice. If you would rather approve each one, say so and it will wait.

Forge blocks things on purpose. A block is not a malfunction, it is the system doing the one job you cannot do by staring at the screen. Here is how to read the common ones.

Real work gets interrupted. A meeting overruns, the day ends, a fortnight passes. This is the thing Forge is best at, and it needs nothing from you.

Claude keeps a file called CONTINUE.md that always describes exactly where things stand and what the very next action is. It updates it before starting anything risky, not afterwards, so an interruption cannot catch it out.

When you return, that file is loaded automatically before you say a word. Then, crucially, it checks the notes against the actual project. If the notes claim two tests are failing but three are, it says so and asks you rather than carrying on from a false picture.

A release is a numbered, frozen snapshot you can point people at. Forge cuts the first one as soon as anything works end to end, then again after each meaningful addition, rather than saving them all up for a big finish.

Before any release, Claude switches out of autopilot and asks. It also refuses to cut version 1.0 until every single requirement in your spec has a test proving it works. Not "the code exists", but "here is the check that demonstrates it".

Each release comes with a plain-language paragraph saying what this version proves the tool can now do. That paragraph is what you will actually read in six months when you are trying to remember where you got to.

Forge creates these. You never have to edit them, but knowing what they are helps.

The vocabulary you will meet, without the jargon. Terms are underlined like this throughout the page, so you can check one without leaving your place.

If you only remember four things

• Type /forge. It figures out the rest.
• Read the spec before approving it. Twenty minutes there saves days later.
• A block is the system working. Never ask it to bypass one.
• You can leave at any moment. Come back and say "please continue".