The software factory

partyline turns an idea into shipped code with AI agents doing the building. The pipeline has four stages, and each one is a place you stay in control:

  1. Describe — a Requirements Agent interviews your idea into a plan of bounded, buildable tasks.
  2. Plan — you review that plan on the board, edit it, and send the tasks you approve to the backlog.
  3. Build — agents pick up tasks and build each one in its own isolated git worktree, on your hardware.
  4. Verify & ship — every change runs your tests and an independent reviewer; what passes is prepared for review, what fails is quarantined.

Agents run on your machines, in your git, with your model keys. The server coordinates the work — the plan, the board, the run log, the pull requests — but never holds a model key.

The pipeline, end to end

1. Describe

Start a describe conversation from the web (partyline.sh/work) or the terminal:

$ ptln describe

The agent asks the product, technical, and UX questions only you can answer, then writes a scored backlog item — an Epic, Feature, or Task — in the planning tree. It picks the kind; you make the decisions. Full guide: Describe →

2. Plan

Open the plan on the board at partyline.sh/work. A well-specified feature decomposes into a tree of tasks, each small enough to build and merge on its own. Edit them, re-order them, and promote the ones you approve — a single task, or a whole feature as a chain (built one at a time, halting on failure).

3. Build

An agent builds each task in its own isolated worktree, off a fresh main, so parallel work never collides. Two ways in:

$ ptln work "add a dark-mode toggle to the navbar"

runs one task autonomously and leaves a branch. To drain a backlog one task at a time, sharing a single context thread:

$ ptln crank --file backlog.txt --thread checkout

Or dispatch straight from the board — the daemon picks the run up on the right machine. Full guide: Runs & the board →

4. Verify & ship

Before any change is eligible to merge, it clears two gates: your test suite and an independent adversarial reviewer that didn't write the code. What passes is prepared for review; what fails is quarantined for a human to approve or discard — never shipped on trust. Full guide: Trust gates →

What "prepared for review" means depends on the run's merge policy:

  • manual (the default for local ptln crank / ptln work) — leaves a branch, nothing pushed.
  • pr (the default when you dispatch from the board) — pushes and opens a pull request.
  • auto — opens a PR and enables GitHub auto-merge, but only when the base branch gates on required checks; otherwise it leaves the PR open.

What keeps it coherent

  • Context Threads — a shared memory every agent reads at launch and keeps current, so a fleet building in parallel doesn't contradict itself.
  • Projects — standing guardrails (stack, conventions, what "done" means) injected into every run in a project.
  • Tamper-evident run log — every step of every run is recorded in a hash-chained log you can inspect.

You don't have to use all of it

Describe without building. Run a single task. Or use just the session manager, Context Threads, or terminal sharing on their own. The factory is what you get when you connect them end to end.

Next: Describe · Runs & the board · Trust gates · Projects.