How partyline works

"Software factory" is the term the industry has settled on for systems where AI agents turn ideas into shipped code. partyline solves that problem, but it isn't a factory. A factory is a conveyor belt — work in one end, artifacts out the other, people watching from the catwalk. That framing gets the hard part wrong: the hard part isn't producing code, it's keeping people in command of what gets built and what ships.

partyline is the software assembly line for your team and its coding agents — multiplayer, on your own models, with humans in command. Like an assembly line, it schedules work across your machines, isolates processes (every task builds in its own git worktree), enforces gates before anything lands, and gives your team and its agents shared surfaces to meet on: Planning, the Build Board, Parties.

The assembly line — ideas in, PRs out — runs in three stages, and each stage is a place you stay in control:

1. Plan — the agent interviews your idea into an epic ▸ feature ▸ task tree with readiness scores.
2. Build — promote the tasks you approve to the backlog; agents build each one in its own isolated git worktree, on your hardware.
3. Ship — every change runs your tests and an independent reviewer; what passes reaches the board's Review column for a human Accept, what fails is quarantined.

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

The loop, end to end

1. Plan

Open a thread's Planning page and click Planning agent — pick the machine and project, the model, and the intake mode, then type the idea. That starts a live session: the agent asks the product, technical, and UX questions only you can answer — one decision at a time, multiple-choice with a recommended option — and co-authors the plan doc with you. Finalize records the result as an epic ▸ feature ▸ task tree with readiness scores. The same interview runs from the terminal as ptln plan (ptln shape and ptln describe are legacy aliases that still work). Full guide: Planning agent →

2. Build

Promote the tasks you approve from Planning to the Build Board — a single task, or a whole feature as a chain (its tasks built one at a time in order, halting on failure, each opening its own PR off the project's base branch — the chain orders the building, not the merging: the PRs are independent, and it's up to you what order they land in). An agent builds each task in its own isolated worktree, so runs never collide with your working tree or each other. Two ways in from the terminal:

$ 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: Build & Ship →

3. 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 lands in the board's Review column with its PR link and review grade, waiting for a human Accept; what fails is quarantined for a human to approve or discard — never shipped on trust. Full guide: Trust gates →

What happens to a passing change 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.

crank or a party?

Two different things run agents, and picking the wrong one is the difference between a branch and a conversation.

crank builds. It takes work that is already specified and drives it, one task at a time, each in its own git worktree, all sharing one context thread — sequentially on purpose, so task n sees what task n−1 recorded. It stops on its brakes (a task cap, a token budget, K consecutive failures, a per-task timeout) and leaves branches: ptln work "<task>" for a single task, ptln crank --file backlog.txt for a backlog, or a run dispatched from the board, which the daemon picks up and runs as crank. Nobody has to be present, and crank will not ask you what you meant — an under-specified task produces a bad branch rather than a question, which is why readiness is scored before work starts.

A party decides. It is a room, not a builder: people (on the web, in Slack, or from the CLI) and agents on their own machines, addressing each other in one conversation — directives, status, findings, hand-offs, a decision that needs several perspectives before anyone writes code. Planning is a party. Agents brought into one from the web run with read-only tools; the output is an agreement, and often a plan, not a diff.

So: if you can already say what "done" looks like, that is crank. If the next thing needed is a decision, an interview, or another pair of eyes, that is a party — and its result becomes the tasks crank then builds.

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.
• Skills — your team's reusable procedures, so an agent doesn't rediscover "how we do a migration here" on every run.
• Tamper-evident run log — every step of every run is recorded in a hash-chained log you can inspect.

Skills — procedures your agents can reuse

A skill is a reusable procedure written as a SKILL.md (a name, a description, and a markdown body, in the Agent Skills format). It's the how-we-do-it sibling of a project's guardrails: guardrails say what's true about the codebase, a skill says how to carry out a specific job.

The library is per-team and lives at Settings → Skills (/settings/skills); clicking one opens its page (/settings/skills/<name>) with the rendered body, its version history and who pushed each version, an enable switch, and delete for owners and admins. The terminal is the primary authoring path:

$ ptln skill push ./my-skill

ptln skill list shows the library, ptln skill pull fetches one, and ptln skill install puts skills into an engine on this machine. The web adds a modest create/edit form for the same thing.

Approval is a boundary, not a formality. An owner or admin's push is approved on the spot — they are the approver. Anyone else's push lands as proposed, including a new version of an already-approved skill, because a new version is new content. Only a skill that is both active and enabled is written into a run's workspace; an unapproved one is never handed to an autonomous worker.

You don't have to use all of it

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

Next: Planning agent · Build & Ship · Trust gates · Projects.