Forge workflows

Every stage has a workflow. Every step is yours.

Instead of a blank prompt, Forge routes each request to a workflow: a set sequence of steps, with checkpoints, that runs the same way for every engineer. Only the steps a job needs run. These are the built-in defaults; open any card to see its steps.

Every workflow — and every step inside it — can be enabled, disabled, reordered, or customized for your team in the Forge dashboard.
Start with Set up Forge. It's the front door rather than a lifecycle stage, so it isn't in the list below — guided setup uses context available in your AI tool to recommend workflows for you or an admin to approve. Without connected tools, it works from what your AI tool can see. Say “forge, help our team get set up”.
Finding the right one

You don’t have to pick from this list.

This page is the reference, not the price of entry. With the plugin installed, say what you’re working on in your own words and Forge matches it to the workflows your organization turned on, at the start of a session or partway through. Naming a workflow still works.

When several fit, Forge asks. Each option is described by what it will do and what it will change — never by an internal name — and every list carries a “none of these fit”.
When nothing fits, it says so. If the work is the kind a workflow could carry, an admin is offered the missing one — drafted from the words they already typed. Build your own →
Out of the box

A built-in workflow for every stage.

These workflows ship with Forge — each one encodes industry best practices for its stage of the software development lifecycle. Use them as they come, or tailor every step, gate, and skill to the way your team works.

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 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. Keyless and org-wide — this is the workflow that builds the map the others consume.
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, wave by wave.

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 all the way to merged code — planned, built wave by wave, and reviewed.
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.
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 it end to end — gates, semver and notes derived from merged PRs, a metric-gated rollout plan, the published tag, feature exposure decoupled from deploy, shipped work marked traceably, and the announcement.
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.
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
Read-only status snapshot of a tracked work item — progress, acceptance criteria, PR health, and prior Forge activity.
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. Each is a real built-in with its own prompt.

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.
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, gate, and skill — yours to configure.

Every workflow is a list of steps you control. Each step carries a model tier, an approval gate, and the skills it must run — set once for the whole org, or forked for a single team.

Implement a Feature
Execute the engineering phase on a tracked work item — handoff, story breakdown, implementation waves, PR review, delivery.
"implement PROJ-784"
# Step Ask to continue 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 merged code — 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.

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

Forge scans the codebase, then runs an interactive architecture discussion — surfacing the key technical questions and recording every decision before code begins.

"explore the architecture for PROJ-412"
4
Shift-left — 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.

"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 holds up in review — and opens a pull request.

"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 merge when coverage slips.

"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.

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

Pulls a read-only snapshot whenever it's needed — progress, acceptance criteria, and PR health, written straight back to Jira, Linear, or Notion — so there's no standup chase.

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

You don't have to start with Forge.

That journey reads top to bottom. Real sessions don't. Most work starts as a blank prompt — a bug someone's chasing, a refactor that grew, an idea still being thought out loud — and only turns into something worth tracking halfway through. Forge is built to join at that moment. Ask for a workflow at any point in a session and it picks up from where you already are: the conversation you've had, the files you've opened, and the decisions you've already 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 checkpoints, from there. Nothing gets re-explained, and the last forty turns land in the audit trail 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 read-only snapshot whenever it's needed — progress, acceptance criteria, and PR health, written straight back to Jira, Linear, or Notion. No standup chase.

"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?"
Don't want to have to remember? Admins can switch on session observation in the Forge dashboard — Forge then spots product work running outside a workflow on its own and offers to pick it up, without anyone typing a thing.
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 org, or forked for a single team.

A forge-workflow session — plain-English request, a full keep/add plan, and an admin-confirmed save, scoped to one team.

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.

"Add an Infrastructure Cost Impact Review step to our PR Review workflow."
Extend a workflow

A new capable-tier step that scans Terraform, Kubernetes & cloud-config diffs and surfaces cost impact before the PR can merge.

"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 gate set to Always ask — merge pauses when coverage drops.

"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 never drifts from the code.

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

An Always-pause checkpoint wired to your security-review skill, gated to runs that touch authentication or PII.

"Create a Database Migration workflow: schema review, backwards-compat check, and a required DBA approval."
New workflow from scratch

A brand-new path — three ordered steps ending in a mandatory human approval gate before anything ships.

Workflow changes are admin-only, versioned, and scoped to your org or a single team. Forge shows a clear keep / add / modify diff against the current workflow before saving — so policy keeps evolving without losing its checkpoints.

Find out which of these
your team needs.

Setup reads how your team already ships and turns on what closes the gaps — with a reason for each. Free for individuals. Install the plugin, then run guided setup.

Start free → See how to install