Forge workflows

Start from a workflow. Make every step yours.

A workflow is a fixed sequence of steps, with approval points, that is the same for everyone who runs it. When you ask Forge for something, it picks the workflow that fits and skips any step the job does not need. These are the built-in starting points; open any card to see its steps.

Built-in workflows are off until you switch them on. When an admin asks Forge for a task, it offers to switch on the one that fits. In the Forge dashboard, an admin can also switch any workflow or step on or off, choose which steps pause for approval, and mark skills as required. To add or reorder steps, describe the change to Forge in your AI tool. On your own account, you are the admin.
Setting up for a team? An admin says “forge, help our team get set up,” and guided setup recommends workflows for the admin to approve. On your own, start with a task instead.
Finding the right one

You don’t have to pick from this list.

You don’t need to read this page to use Forge. Say “forge,” and what you’re working on, and Forge picks from the workflows you have switched on, at the start of a session or partway through. Naming a workflow works too.

When several fit, Forge asks. Forge describes each option by what it will do and what it will change. You can always answer “none of these fit.”
When nothing fits, Forge works out an approach. It proposes the steps for this one task and runs them once you confirm. Every step that changes something asks first. Or build your own workflow →
Out of the box

A built-in workflow for every stage.

Each built-in workflow is a maintained starting point for one stage of the software development lifecycle. Use it as it comes, or tailor every step, approval point, and skill. Where a description says “work item,” it means a ticket in Jira, Linear, or Notion.

Planning

Shape and scope the work before any code is written — discovery, definition, PRDs, and readiness.

Define a Feature
Take a raw idea to a ready-to-build ticket — clarified requirements, a product requirements document (PRD), and a clean handoff to engineering.
Steps
  1. Check for existing work items
  2. Gather background context
  3. Clarify requirements
  4. Collect non-functional requirements
  5. Write the problem statement
  6. Score impact (RICE)
  7. Preview & create the tracker work item
  8. Generate the PRD
  9. Build the tech handoff plan
Design

Map the system and shape the technical approach for an existing work item.

Explore Architecture
Map the system and the key technical decisions for an existing work item — a codebase scan plus an interactive architecture discussion. Read-only: it explores, it doesn't create a ticket.
Steps
  1. Resolve the work item
  2. Scan the system architecture
  3. Interactive architecture discussion — record decisions
Architecture Archeology
Reconstruct your whole architecture estate from the code and existing docs, across every product and repo, then publish the Architecture Atlas. It runs for the whole organization and needs no ticket, and it builds the map that other workflows read.
Steps
  1. Locate any existing atlas
  2. Discover the estate across repos and services
  3. Synthesize the findings into one picture
  4. Validate the reconstruction
  5. Publish the atlas
  6. Render the visual map
Development

Turn a ready work item into shipped code, one wave (a batch of stories built together) at a time.

Plan an Implementation
A reviewable build plan with the codebase left untouched — change impact, technical discovery, a test strategy, and an implementation proposal you approve before anyone writes code.
Steps
  1. Check for prior planning on the ticket
  2. Fetch the work item
  3. Readiness check
  4. Analyze change impact (blast radius)
  5. Technical discovery
  6. Define the test strategy
  7. Write the implementation proposal
  8. Notify the engineering lead
Implement a Feature
Take a ready ticket to a reviewed pull request, planned and built wave by wave.
Steps
  1. Receive the engineering handoff
  2. Readiness check
  3. Break the work into stories
  4. Plan dependencies & implementation waves
  5. Analyze change impact (blast radius)
  6. Technical discovery
  7. Define the test strategy
  8. Implement wave by wave
  9. Review the PR
  10. Complete & summarize delivery
Testing

Verify quality before and after the change lands — test strategy and structured PR review.

Plan the Tests
Plan how a change will be tested — coverage and test types per acceptance criterion — without writing any code.
Steps
  1. Fetch the work item
  2. Readiness check
  3. Check AC quality & testability
  4. Review stories (INVEST)
  5. Analyze change impact
  6. Technical discovery
  7. Define the test strategy
Review a Pull Request
A structured PR review — automated code analysis, requirement traceability, and a security scan. Start from a pull request link, with or without a ticket.
Steps
  1. Fetch the work item
  2. Check branch freshness
  3. AI-augmented PR review — analysis, AC traceability, OWASP scan
  4. Customer impact analysis
  5. Surface manual deploy tasks
Release

Work out what's shipping, then ship it — gated, versioned, and announced.

Preview a Release
A read-only dry run: what would ship since the last release, whether anything is blocking it, and draft notes with a suggested version. Stops before tagging — nothing is published, moved, or announced.
Steps
  1. Resolve the release scope
  2. Run pre-release gates — CI, blockers, migrations
  3. Draft versioned release notes
Cut a Release
Ship a release end to end: run the pre-release checks, build the version number and notes from merged PRs, plan the rollout, publish the tag, mark the shipped work on its tickets, and announce it.
Steps
  1. Resolve the release scope
  2. Run pre-release gates
  3. Check branch freshness
  4. Reconcile traceability to tracked work
  5. Build the release notes
  6. Plan the rollout
  7. Plan observability
  8. Cut the release
  9. Plan feature exposure
  10. Publish & announce
Maintenance

Capture and resolve defects end to end.

Fix a Bug
From bug report to shipped fix — triage, ticket, fix, and review. No tracker? It skips the ticket steps.
Steps
  1. Capture the bug — severity, area, reproduction
  2. Preview & create the ticket
  3. Hand off to engineering
  4. Implement the fix (optional)
  5. Review the PR & surface deploy tasks (optional)
Track & manage

Stay on top of work already in flight — status, documentation, and edits.

Check Work Item Status
A status snapshot of a work item: progress, acceptance criteria, PR health, and prior Forge activity. It changes no code.
Steps
  1. Fetch the work item
  2. Report status — progress, acceptance criteria, PR health
Gather Work Item Documentation
Pull together every doc attached to a work item — PRDs, design docs, comments, and linked Confluence or Notion pages.
Update Work Item
Direct field edit on an existing tracked work item — title, description, acceptance criteria, priority, assignee, labels, and status.
Build Recap
Turn a recent branch into an evidence-backed recap — what the work set out to do, what the code and tests actually verify, and the one gap that matters most. Ends by recommending the next workflow and offering to create or link a tracked item.
Steps
  1. Reconstruct the work item from the branch
  2. Offer to create or link a tracked item
Triage PR Feedback
Catch up on new comments across the ticket and its pull request. Filters out anything already addressed and Forge's own prior notes, then walks through what’s left with you, without changing anything. Ready to act on them? Apply PR Feedback does the same sweep and makes the changes.
Steps
  1. Fetch the work item
  2. Fetch tracker and PR comments
  3. Filter out ones already handled
  4. Discuss each remaining comment to an agreed recommendation
Also built in

Shorter or narrower paths that share steps with the workflows above.

Shape a Feature
Think a feature through before committing: clarify the idea, pin down the problem, check roadmap fit, score it, and get a brief in chat.
Break Down a Feature
Backlog refinement without touching code: readiness check, sub-issues with testable acceptance criteria, and a review of their quality.
Generate the Tests
Write the tests a recorded strategy calls for, wave by wave, with a tests-only scope.
Plan Review Fixes
The full PR review, then a decision on each finding, recorded on the ticket when there is one.
Resolve PR Findings
The full PR review, then the fixes applied in code and verified.
Apply PR Feedback
Sweep new comments across the ticket, the pull request, and the tools your team discusses work in, then act on them.
Plan a Release
A reviewable release plan with nothing shipped: the delta, the gates, untracked changes reconciled, notes drafted.
Triage a Bug
Capture a bug, investigate it, and file a well-formed ticket with severity and a fix direction.
Plan a Bug Fix
Confirm the root cause against the code and record a reviewable fix plan on the ticket.
Draft the Architecture Atlas
Build a complete atlas of your estate and leave it as a reviewable draft.
Preview the Architecture Atlas
See what an atlas would contain before building one.
Explain the Architecture
Ask how a flow works or what talks to what, answered from the atlas and the code.
The workflow editor

Every step, approval point, and skill — yours to configure.

Every workflow is a list of steps you control. Each step carries a model tier, an approval point, and the skills it should use — set once for the whole organization, or tailored for a single team.

Implement a Feature
Execute the engineering phase on a tracked work item — handoff, story breakdown, implementation waves, PR review, and delivery.
"forge, implement PROJ-412"
# Step Asks you Skills Enabled
0
Fetch Work Itemfast
Never asksAI decidesAlways asks
1
Story Breakdownbalanced
customized
Never asksAI decidesAlways asks
2
Change Impact Analysiscapable
Never asksAI decidesAlways asks
3
Technical Discoverycapable
customized
Never asksAI decidesAlways asks
1
4
AI-Augmented PR Reviewcapable
Never asksAI decidesAlways asks
2
5
Notify PM of Changesfast
Never asksAI decidesAlways asks
In practice

One feature, start to finish.

Here's how a team uses Forge workflows to ship one complex feature — from a fuzzy idea to a reviewed pull request — each person reaching for the right workflow, whether it's a Forge default or a version their team has customized.

1
Product Manager
Shape a FeatureBuilt-in

Pressure-tests the idea before anyone commits — frames the problem, checks roadmap fit, and scores it so only work worth doing moves forward.

"forge, help me shape this idea: team-level saved views"
2
Product Manager
Define a FeatureBuilt-in

Turns the validated idea into a scoped work item (PROJ-412) with a PRD and acceptance criteria, then hands off cleanly to the engineering lead.

"forge, define a feature: team-level saved views"
3
Engineering Lead
Explore ArchitectureBuilt-in

Scans the codebase through your AI tool, then runs an interactive architecture discussion — surfacing the key technical questions and recording every decision before code begins.

"forge, explore the architecture for PROJ-412"
4
Before the code lands
QA Engineer
Plan the TestsBuilt-in

Maps a test strategy to every acceptance criterion — unit, integration, and end-to-end coverage — while the code is still being written, not after.

"forge, plan the test strategy for PROJ-412"
5
Engineer
Implement a FeatureBuilt-in

Builds the feature wave by wave against the agreed plan — briefed on the architecture up front, so the first pass starts from the agreed design — and opens a pull request.

"forge, implement PROJ-412"
6
Running in parallel
QA Engineer
Review a Pull RequestQA · Customized

A QA-team fork adds extra code-quality and test-coverage scans, pausing the run for sign-off when coverage slips.

"forge, review the PR for PROJ-412"
DevOps Engineer
Review a Pull RequestDevOps · Customized

A DevOps-team fork checks the change's impact on infrastructure performance and cost before it ships.

"forge, review the PR for PROJ-412"
7
Anytime, throughout the build
Product Manager
Check Work Item StatusBuilt-in

A status snapshot whenever it's needed: progress, acceptance criteria, and PR health, posted to the ticket in Jira, Linear, or Notion, so nobody has to chase updates.

"forge, what's the status of PROJ-412?"
Mid-session

You don't have to start with Forge.

You can bring Forge in at any point. Most work starts as a blank prompt and only turns into something worth tracking halfway through. Ask for a workflow forty turns in, and it picks up from where you are: the conversation, the files you opened, and the decisions you made carry into it.

Turn 1
No workflow. Just you.

An engineer opens Claude Code and starts chasing a checkout bug. No ticket, no process — a blank prompt and forty minutes of digging through the codebase.

Turn 40
It turns out to matter.

The root cause is a rounding helper three teams depend on. Suddenly this needs a ticket, a test strategy, and a review trail — and none of that exists yet.

"forge, fix this"
Picked up
Forge starts from where you are.

It files the bug with what's already been found — the reproduction, the root cause, the files touched — then runs the fix as a workflow, with approval points, from there. Nothing gets re-explained, and the last forty turns land in the record instead of evaporating.

Workflows that attach at any point

Some workflows exist precisely for work already in flight — they assume a session, a branch, or a ticket that's been running for a while, and meet it where it is.

Build Recap

Reads the commits and diff on the branch you've been working on and reconstructs what you actually built — acceptance criteria mapped to real code and tests — then drafts the work item nobody wrote up front.

"forge, what did we just build?"
Triage PR Feedback

Pulls new comments from the ticket and its pull request, drops the ones already handled, and walks through the rest with you — built for the middle of an implementation, not the start of one.

"forge, triage the comments on PROJ-412"
Check Work Item Status

A status snapshot whenever it's needed: progress, acceptance criteria, and PR health, posted to the ticket in Jira, Linear, or Notion.

"forge, what's the status of PROJ-412?"
Review a Pull Request

Runs the full structured review — code analysis, requirement traceability, security scan — on a PR that was opened without Forge ever being involved.

"forge, review the PR for PROJ-412"
Preview a Release

Works out what would ship right now from the delta since the last release, checks for blockers, and drafts the notes — without tagging or publishing anything.

"forge, what would ship in the next api release?"
An admin can also switch on session observation in the Forge dashboard. Forge then notices product work happening outside a workflow and offers to pick it up.
Custom workflows

Your process, your workflows.

Need something the defaults don't cover? An admin says so in Claude Code, Codex, or Cursor — “forge, create a workflow for our incident postmortems” — and describes it in plain English from there. Forge drafts it, shows exactly what changes, and saves it — across the organization, or tailored for a single team.

An admin asks in plain English, Forge shows the proposed workflow, and it saves only after the admin confirms.

What you can ask for

Just say what you want — no skill name to remember, no config files, no YAML. Each example shows something you could type (left) and the workflow Forge builds in response (right): extend a default, fork it for one team, or create a brand-new path.

"forge, add an Infrastructure Cost Impact Review step to our PR Review workflow."
Extend a workflow

A new capable-tier step that scans Terraform, Kubernetes, and cloud-config diffs and surfaces cost impact before the review step completes.

"forge, create a PR Review workflow for the QA team with a Test Coverage Review step."
Fork for a team

A QA-scoped fork of PR Review with an added coverage check set to Always asks — the run pauses for sign-off when coverage drops.

"forge, in Implement a Feature, add a step to update CLAUDE.md when the architecture changes."
Keep docs in sync

A fast-tier step that refreshes your CLAUDE.md / AGENTS.md so agent guidance keeps up with the code.

"forge, add a Security & Privacy Review to any workflow that touches auth or PII, and always require sign-off."
Add a compliance approval

A step set to Always asks, wired to your security-review skill, for runs that touch authentication or PII.

"forge, create a Database Migration workflow: schema review, backward-compatibility check, and a required DBA approval."
New workflow from scratch

A brand-new path — three ordered steps ending in a required human approval before the run continues.

Only admins can change workflows, and every change is logged. Before saving, Forge shows what it will keep, add, and modify.

Find out which of these
fit how you work.

Ask Forge for what you need and it names the workflow that fits. For a team, guided setup recommends a set, with a reason for each. Free for individuals.

Start free → See how to install