Set up the Factory

The Factory works with the system pipeline the moment you open it. You only need to change the pipeline when you want something different. This page covers what a project needs, filing work, pulling work in from trackers, and customising the pipeline for one project.

Before you start#

gh auth login
git --version   # 2.38 or later

File your first idea#

Pull work in from your tracker#

The Ideas stage takes work from more than one place. Open Customize → Flow, select Ideas, and look at Ideas come from:

• The Warden inbox: ideas you file by hand. Always on.
• GitHub issues: optionally filtered by a label, synced every 1, 6 or 24 hours. Only issues opened after you turn this on are filed.
• Pick Linear / Jira tickets: choose tickets to import from a connected Linear or Jira.
• Add a source: pull from any connected integration (Sentry, Datadog, PostHog and others), by running a skill, or by asking an agent with the project's integrations. Name the source, say whether it files bugs, features or chores, and describe what to pull.

Connect the integration first in the project's Integrations tab. Until you do, a source shows No integrations are enabled for this project yet. Pulls are read-only, take at most 20 items at a time, and file each item once.

Automations can also file work: the automation action File ideas into the Software Factory turns, for example, a nightly error report into ideas. See Automations.

Customise the pipeline#

The header shows which pipeline is in force: System pipeline, or ‹project› pipeline · Customize once you have changed it. Pick a single project, then press the pipeline button to open the pipeline studio. The first change you make gives the project its own copy; Reset to system goes back.

Start from a template… gives you a sensible base:

The studio has four tabs, and Try an idea under every tab shows how a sample idea would travel through your pipeline before you commit to it.

Flow#

The stages, left to right. Select a stage to edit it:

• Triage, Shape and Build each take a Model (Auto uses your Model policy: Planning & architecture for triage and shape, Code generation for build, Bug fixing for bugs), a Skill, and free-text instructions.
• Build sets New builds start from: Latest default branch on origin (recommended), Your current checkout, or Ask each time. It also has Agents never commit, for when you want to review and commit by hand.
• + Add a step inserts a custom stage: a skill, a workflow, a command, Ask an agent, or an Adversarial review. A step runs by itself or waits for a person, is required or advisory, can apply to some lanes only, and has a time limit (5 minutes for a command and 10 otherwise, up to 240).
• + Add an environment adds a stage after Main. Define Shipped when: a branch contains it, a matching tag contains it, or a GitHub deployment succeeded. See stages.

Lanes#

What each lane does: its shape (none, plan, spec, or triage decides), its assurance level, how it builds, who reviews, whether it is checked against the original ask, whether it merges here or opens a pull request, and whether triage may auto-accept into it. See Lanes and gates.

Who decides#

Rules that change review, merge, auto-start or the minimum level for some items, applied in order after the lane's defaults and triage's choice. Use Always needs a person to list paths (for example */migrations/* or */.github/workflows/*) where an unattended run must stop for a person.

Lifecycle rules#

Ready-made rules for the moves themselves (Migrations need a person, No unattended merge after hours or on Fridays, Large changes need a person, Link a ticket before merge and more), plus Parallel builds: what happens when two builds touch the same files (Off, Warn, Queue or Strict).

Parallel builds and worktrees#

Each chat build gets a fresh git worktree, so builds never trip over each other or over your own checkout.

• Ready to work. New worktrees clone the checkout's dependencies (node_modules, .venv) as copy-on-write clones, so a build starts in seconds. Secrets and .env* files are never copied.
• Services per worktree. Set up .warden/services.json under Assurance → Services (Warden detects most of it). Each worktree then gets its own ports, and a Factory build starts its own services and stops them when the worktree goes.
• Overlaps. With Parallel builds on Warn (the default), the Factory shows when two builds touch the same files but starts them anyway. Queue holds a build that shares more than a set number of files; Strict holds any overlap and makes edits outside the build's claimed files ask.

Up to two sandboxed builds run at once. Triage, drafting and reviews run one at a time.

Where things are stored#