Resources

Documentation

How Forged works

Forged helps founders move from a product idea to shipped software. Work takes one of two routes, and the difference is size.

Idea → Clarify → Plan → Build → Review → Ship → Improve

A plan, for an idea with several parts

Describe it → Brief → Build → One pull request

A task, for one small fix or change

You describe what you want. Forged clarifies the decisions that would change the result, turns the idea into a plan or a short brief, and coordinates AI agents to write and test the code. Both routes end in a pull request Forged has checked.

Forged proposes the route. It is only a task if all three of these hold: it fits in one pull request, it adds no new page, table, or integration, and it does not go against a decision you have already recorded. You can switch either way at any time.

You decide what moves forward at every stage.

What Forged is built for

Forged builds for the web: software people use in a browser, and the servers, APIs, and data behind it. That covers:

Web apps and SaaS products, including sign-in, accounts, billing, and settings.
Dashboards, admin panels, and internal tools.
APIs, backend services, data models, background jobs, and integrations with other services.
Marketing sites, landing pages, and content sites.
Web apps that work well on a phone, including ones people can add to their home screen.

Native iOS and Android apps, real-time or graphics-heavy games, and desktop software are outside what Forged is built for. A simple game that runs in the browser, such as a puzzle, card, or quiz game, is a web app, so Forged can build it. If you need a native app, Forged can still build everything behind it: the backend, the API, the admin panel, and the website.

Quick start

Everything starts the same way:

Create a project.
Describe what you want, in plain language.
Forged proposes a plan or a task, depending on the size of it.
Connect a GitHub repository when you are ready to build. Forged asks for it then.

A plan then goes:

Answer any clarification questions.
Review the generated plan.
Accept, edit, set aside for later, or archive suggested features.
Make any layout choices Forged asks for.
Build an accepted feature.
Review the resulting code changes and pull request.
Approve the change and take it live.
Use what you learn to plan the next improvement.

A task takes the shorter route:

Check the short brief Forged writes.
Start building it.
Review the single pull request it produces.
Approve the change and take it live.

Projects and repositories

A project is the main workspace for a software product. It brings together the product's repositories, plans, features, implementation work, and relevant context.

A project can hold several connected repositories. Plans, features, and even a single action item can span them: an action item names the repository or repositories it touches.

You connect repositories from Integrations, then Repositories, using the Forged GitHub App. Access is limited to repositories you explicitly authorize and can be revoked through GitHub. If you have not done this before, the next section walks through it from the beginning.

Forged uses repository context to understand what already exists before recommending or implementing changes. This helps it avoid duplicating existing functionality, conflicting with established architecture, or producing plans that are disconnected from the actual product.

Planning and clarification use repository access to read relevant code and documentation. When implementation begins, individual jobs receive short-lived access scoped to the work they need to perform.

Connecting GitHub

Forged works on code that lives in GitHub. The repository is where your product's code is kept, where every change is recorded, and where finished work arrives for your review.

You can try a plan or a task before you connect GitHub. Forged asks you for a repository when you choose to build, because that is where the code goes.

If you have never used GitHub before, you do not need to learn Git first. You need an account, one repository, and a few minutes.

Connecting a repository gives you:

Ownership of the code. The repository belongs to your GitHub account, not to Forged, and you can take it elsewhere at any time.
A record of every change. Each piece of work is a commit you can read, and undo if you change your mind.
A review step before anything ships. By default, agent work arrives as a pull request, so you see what changed before it goes live.
Plans that fit the product you already have. Forged reads the connected repository before proposing changes, instead of starting from a blank page.
Room for other people. An engineer, a contractor, or a co-founder can work on the same repository later without anything moving.
A path to production. Most hosting providers deploy directly from a GitHub repository.

Forged's builds can add or change GitHub Actions workflow files in a connected repository when the work needs it, for example to add a setting your deploy reads. Those workflows run in your GitHub account and can use the repository's Actions secrets, like any workflow you write yourself.

Creating a GitHub account

If you do not have an account yet, start at github.com/signup (opens in a new tab). An account is free, and setting one up takes a few minutes.

Enter an email address you control. Use a work address if the product belongs to a company.
Choose a password, then a username. The username is public and becomes part of your repository addresses, so pick one you are happy to keep.
Enter the verification code GitHub sends to that email address.
Answer or skip the setup questions, and choose the Free plan. It covers everything you need to use Forged.
Turn on two-factor authentication when GitHub offers it. It protects the account that holds your product's code.

A personal account is enough to start with. If the product belongs to a company, you can create a GitHub organization later and transfer the repository into it without losing any history.

Creating your first repository

A repository, usually shortened to repo, is one product's code together with its full history. If you are starting from nothing, create an empty one and let Forged fill it.

On GitHub, select the plus icon at the top right, then New repository.
Name it after the product. Naming it in lowercase with hyphens, such as acme-invoicing, avoids trouble later.
Choose Private, unless you intend the code to be public. Private is the right default for a product you plan to sell.
Leave Add a README file, .gitignore and the license choices alone. None of them changes what Forged can do with the repository.
Select Create repository.

That is all Forged needs. You do not have to add code, choose a framework, or set anything else up first. The first feature you accept can create the application inside this repository. If the repository is still empty when your first plan starts, Forged adds a short README named after it, so there is a first commit to build on.

One repository is enough to begin with. A project can connect more later, if the product grows into more than one.

Connecting a repository to Forged

Once the repository exists, connect it from inside Forged.

Open Integrations, then Repositories.
Select Connect, the button with a plug icon above the list.
The first time, Connect takes you to GitHub to install the Forged app. Where GitHub asks which repositories it may reach, GitHub has All repositories selected for you. Change it to Only select repositories and pick the one you just created. You can add more at any time, and this keeps the rest of your account out of reach. Back in Forged, Forged connects the repositories you picked. If an owner of your GitHub organization has to approve the app first, come back once they do and select Connect again.
Once Forged can see repositories on your GitHub account that are not already connected to this project, Connect opens a short form with a list to choose from. If yours is not in it, the line under the list offers Give Forged access on GitHub, or paste its URL to type the address instead. If every repository Forged can see is already connected here, the form shows the Repository URL field and says so. Select Connect in the form to finish.

A repository that still needs authorizing shows Authorize beside it on the Repositories page. Select it to finish authorizing.

Connecting starts a first read of the repository, so Forged knows the codebase. While that runs, the repository shows Review queued and then Reviewing, and settles on Connected when it finishes. It is the first read, not the only one: Forged reads the repository again once enough new code reaches its default branch, and planning and clarification read the code as they work. A repository with nothing in it yet has nothing to read, and shows Nothing to review yet until enough code reaches that branch too, by the same measure.

The Forged GitHub App reaches only the repositories you authorize. You can change that list, or remove the app altogether, from your GitHub settings at any time.

Bringing in code you already have

If your product already exists somewhere else, in another builder tool, on your own machine, or on a different host, the code needs to reach a GitHub repository before Forged can work on it.

Some tools can push straight to GitHub from their own settings, which is the shortest route wherever it is offered. Where it is not, export or download the project, then upload it into a new repository.

Create that repository as described above. Leaving Add a README file unchecked matters more here than elsewhere: code you already have carries its own history, and a README would put a separate first commit in front of it that your upload then has to be reconciled with.

Planning an idea

Start on the Plans page and describe what you want to build in plain language.

Your idea can be brief, but it should explain the problem, intended user, and desired outcome where possible. You do not need to write a technical specification.

Before generating a full plan, Forged may ask focused questions about decisions that could materially change the result. These may cover:

Who the feature is for
What should be included in the first version
What should remain outside the scope
How permissions or roles should work
What information needs to be stored
Which workflows or integrations matter
What outcome would make the feature successful

Forged uses your answers together with the existing product and repository context. When you are unsure, you can say so. Forged may later make a reasonable assumption when one is required to complete the plan, but that assumption should be identified rather than presented as your confirmed decision.

Reviewing the plan

Forged converts the clarified idea into a structured set of suggested features.

Each feature may include:

A clear headline
A description of what it does and why it matters
Relevant user stories
Implementation-ready action items
Dependencies on other features
A relative size estimate

The plan is a proposal. It does not automatically commit you to building everything it contains.

For each suggested feature, you can:

Accept it for implementation
Edit it before accepting
Set it aside for Later
Archive it if it should not be pursued

Dependencies help show which features must be completed before others can work properly.

Feature sizing

Forged may estimate a feature as:

S, Small: A localized change with limited impact
M, Medium: Work involving multiple components, APIs, or moderate data changes
L, Large: Cross-cutting work, a new subsystem, a major integration, or substantial uncertainty
XL, Extra large: Probably more than one feature, and better split

Size represents relative complexity. It is not a delivery-time, price, or completion guarantee.

Large features may be easier to implement and review when divided into smaller phases.

Layouts

Some features cannot be built until a choice is made: which page something lives on, how a list is shaped, what a founder sees first. Forged collects those choices as layouts.

Each choice is drawn as a small set of options, with a short description of what each one would mean for the person using your product. You pick one. The drawings sit at their own link. Someone who is not signed in to Forged is asked to sign in before they can see them.

You can change a pick until the feature it affects starts building. If none of the options fit, Forged can draw new ones. If one is close, Refine this option draws a new version of just that one from your note, and the others stay as they are. If you had picked that one, the features it affects wait to build until its new version is drawn. Each new drawing is kept as a new round beside the earlier ones, so you can go back to any round and pick an option from it, or draw again from it. Drawing new options from the round that holds your pick clears the pick, and the features it affects wait until you choose again, from any round. Where you have set up a design system, the drawings follow your own design rules.

When a screen has one clear layout, there is nothing to choose, so Forged draws it as a screen preview for you to check instead. A plan can come with up to two, for the screens you see first, and Ask Forged can draw one when you ask to see a screen. A preview is already chosen: the build follows its picture, and it never makes a feature wait for a pick. You will find it on the plan under Screen previews and on the Layouts page. A task can have one too, for the one screen it changes: Forged draws it once you create the task, or when you ask, and it shows on the task page under What changes. If it is not quite right, write what should change and redraw it. The new drawing is kept as a new round and the build follows it, and you can go back to an earlier round and use it instead.

Every drawing uses credits: new options, a refined option, and a screen preview.

Building a feature

Once a feature is accepted, you can build it. Accepting it usually starts preparing the build straight away, and that step uses credits. If something is still holding the feature back, such as a layout choice to make, an unfinished feature it depends on, or a balance too low to cover it, preparation starts later instead.

Forged converts the feature into concrete action items and acceptance criteria. Acceptance criteria describe the observable conditions that should be true when an action item is complete.

AI agents then work through the approved action items inside isolated execution environments. Depending on the work, they may:

Read relevant code and documentation
Modify application code
Add or update tests
Run validation commands
Address implementation errors
Prepare commits
Open a pull request

The agents work from the approved feature and its action items. They are not intended to independently expand the product scope without your approval.

Work in progress lives on the Building page, where a plan's features and any tasks sit together and the build button counts what you have selected. Forged builds three features and tasks at a time by default. You can change that from 1 to 5 in the project's settings, under Features and tasks built at once. A feature that comes back to work while the project is full, for example after you retry one of its action items, shows Queued and continues when a slot frees. Work already running is never stopped.

You can pause building at any point and resume later. Nothing already finished is lost. An action item that turns out to be too big can be broken up into smaller ones from its menu.

Finished work moves to Ready to merge, and then to Merged once it is in.

Acceptance criteria

Acceptance criteria give the implementation agents an objective definition of done.

A useful criterion describes a result that can be observed or tested, such as:

A user with the correct role can access the new workflow
An unauthorized user receives an appropriate error
Submitted information is saved and appears after the page is refreshed
Existing behavior continues to pass its tests

Acceptance criteria should describe the required outcome rather than repeat the implementation steps.

They are available during implementation so you can inspect what the agents are building toward. You do not need to approve every criterion individually.

Reviewing and shipping changes

When implementation is complete, Forged prepares the resulting code changes for review.

You can inspect the pull request, including:

The files that changed
The implementation approach
Test results
Any unresolved findings
Whether the acceptance criteria were addressed

A new project merges a pull request once any required checks pass. Turn off automatic merging on Ready to merge, and you merge each one yourself.

Where an automated workflow has been explicitly configured, Forged can coordinate later steps after approval. With automatic merging off, the change remains in a pull request until you or your team decide to merge and deploy it.

Tasks

Not everything needs a plan. A bug report or one small change can go straight to a short brief and a single pull request.

Describe it on Home, in Ask Forged, or on the Tasks page. Forged writes a brief saying what changes and how it will check the result. Nothing builds until you say so, and a saved task waits as Ready to build.

Until you choose Build task, Edit brief on its page lets you change what changes and how Forged checks it. The name stays as it is. If the task has layouts, saving a new "What changes" draws them again, which uses credits.

You can try a plan or a task before you connect GitHub. Forged writes the brief as usual, and asks you for a repository when you choose to build.

A task reads the same product context as a plan, is built and reviewed the same way, and every check is proven before its pull request opens. It simply starts from a short brief instead of a clarification round and a drafted plan.

A task cannot go against a decision you have already recorded. Where one would, Forged names the decision and offers to turn it into a plan instead, so the two can be weighed together. You can switch either way at any time.

One word, two meanings. A task in this sense stands next to plans. The units of work inside a feature are called action items, and they are described under Building a feature above.

Effort

Effort is how hard Forged works on a given step. It runs from Low, the quickest, through Medium and High, to Extra high, which is slower and more careful. The level is also what it costs: Low uses the fewest credits and Extra high the most.

You set it in Settings, AI models, for the three kinds of work that use credits: chat (answering questions in Ask Forged and on Home, and clarifying what you want to build), planning, and building. Forged recommends a level for each, and any of them can be reset to the recommendation.

A task is the lighter version of the same process. Its draft is written in the chat, so it follows the chat setting, and the task is then built under the building setting.

Work that Forged does for free has no setting. Forged sets how carefully it reads your repository, checks its health, analyzes your design system, fixes a merge conflict, and works out what a change to a plan's spec touches, and the same page lists what each of those runs on.

Work that is already running keeps the effort it started with. At any level, an action item that keeps failing review is moved to a stronger model so that it does not get stuck, and the action item says so.

Credits

New accounts get $250 in credits: up to $10 to try Forged when they sign up, and the rest when they add a payment method.

Chat (Ask Forged and clarifying), planning and tasks, and building all draw on the same balance, and each piece of work shows what it has used.

Forged reading your code to understand it is free. That covers reading a repository when you connect it and again as it changes, Product Health checks, and analyzing your design system. Planning and building read your code too, as part of the work. It is the planning and building that use credits, not the reading.

Free work has a daily limit, not a schedule: one repository review and one health check a day per repository, and one design system scan a day per project. A run that fails, or a health check that ends as a partial check, does not count toward the day. If you cancel a design system scan after it has started, it still counts as that day's scan. If you cancel it while it is still waiting to start, it does not.

Fixing a merge conflict is free too: choose Fix the conflict on a stuck feature's page or its Ready to merge row. Its limit is not daily: Forged tries at most 3 times per feature, and a try that fails counts.

Working out what a spec change touches is free as well. When a document you added to a plan changes, Forged works it out once, the first time the plan's page shows the change.

You don't pay for work that fails, or for work Forged has to redo because of its own problem. If you pause or stop work partway, you pay for what it used up to that point, except for the final review of a finished feature while it is still running: pausing it throws its result away, so it costs nothing. If the balance runs out part of the way through, Forged stops and picks back up by itself once the balance covers the next action item. Nothing already done is lost.

When GitHub or an AI provider such as Claude is down, Forged pauses the builds that need it. They wait as long as it takes without spending credit or using up a retry, and pick up by themselves once it is back.

Auto reload is off unless you turn it on in Organization settings. It buys at least the amount you set when your available balance falls below the amount you choose, or when work needs more credit than is available. Your available balance is your balance minus credit set aside for work running now. You can change it or turn it off at any time.

Your balance, history, and payment details are in Organization settings. What each piece of work has used is on the Usage page.

When work is waiting on you

Sometimes work waits on your account or a repository rather than on a decision. The page says which, and puts the one thing to do beside it.

Waiting for credit. It picks back up by itself once your balance covers it, and nothing already done is lost. Add credit in Organization settings. Rarely, Forged stops retrying. The page then says so, and you add credit and choose Resume.
Your organization is suspended. Forged holds all of its work. Contact support to resume.
Your billing account is not taking new work, so held work will not resume. Contact support if you need it to continue.
A repository has not finished connecting. Authorize it in Repositories, then build again.
A repository needs reconnecting. Reconnect it in Repositories.
The Forged GitHub App is not installed on a repository. Building stops, and picks back up by itself once you reconnect the repository in Repositories.
A repository is archived on GitHub, so it is read only. Building stops before its next action item, and picks back up by itself once you unarchive the repository on GitHub.

Improving the product

A product continues to change after its first release.

Forged keeps the product's plans, decisions, features, action items, repository context, and implementation history connected. This gives later work access to the context that shaped earlier decisions.

You can use customer feedback, product usage, bugs, support requests, new ideas, and technical constraints to create the next plan and improvement cycle.

The goal is for each new change to fit the product rather than begin as an isolated prompt.

Core concepts

Project: A workspace for one software product and its connected context. It can hold several repositories.
Repository: A GitHub repository authorized for use within a Forged project.
Idea: A plain-language description of something you want to build, change, or improve.
Clarification: A focused conversation that resolves the most important ambiguities before planning begins.
Plan: The structured output created from an idea with several parts, its clarification decisions, product context, and what Forged read in your repositories.
Task: One small fix or change that becomes a single pull request, with a short brief instead of a plan.
Feature: One coherent unit of product functionality proposed within a plan.
User story: A description of who needs a capability, what they need to do, and why it matters.
Action item: A concrete unit of implementation work required to build a feature.
Acceptance criteria: Testable conditions that define when an action item is complete.
Layout: A choice about how something should look or work, drawn as options to pick from before the feature builds.
Effort: How hard Forged works on a given step, from Low to Extra high.
Pull request: The proposed code changes produced during implementation and submitted for review.

What you control

You decide:

What enters planning
Whether something is built as a plan or as a task
How clarification questions are answered
Which assumptions are acceptable
Which layout options are chosen
Which features are accepted
Which work is set aside for later or archived
When implementation starts, pauses, and resumes
How much effort Forged puts into each kind of work
Whether a pull request is approved
Whether merging and deployment remain manual or use an enabled automated workflow

Current limitations

Forged uses AI systems to help plan and implement software. Generated plans, code, tests, and recommendations may be incomplete, inaccurate, or unsuitable for a particular environment.

Repository context improves the quality of the result, but it does not replace founder or engineering review. You remain responsible for reviewing changes, testing the product, managing access, maintaining backups, monitoring live software, and deciding what should be deployed.

Some workflows may depend on the repositories, integrations, and deployment systems connected to a project.

Getting help

For product questions or support, contact support@tryforged.ai.

For security questions or vulnerability reports, contact security@tryforged.ai.