Projects

A project is the durable home for a codebase across everything you do in partyline — its machines, runs, context threads, and the standing guardrails your agents build within. It's the join key that ties a repo on your laptop to the runs on the board and the shared memory your agents read.

The label

Every project has a label — a short slug (e.g. checkout-web) that machines advertise and runs point at. It's the key that joins machines, runs, and threads, so the board knows which machine can build which project.

$ ptln project

lists your team's projects. Create one:

$ ptln project new "checkout-web" --team acme

Inspect a project's promoted facts (its canon):

$ ptln project show <id>

Manage the display name, description, and repository on the web at partyline.sh/projects.

Guardrails your agents build within

A project carries standing guidance — your stack, your conventions, what "done" means — that's injected into every run in that project. Set it up once and every agent that builds a task reads it, so you're not restating "use server components, always add a migration, never touch the auth module" on each task.

There's also a Describe instructions field that shapes the Requirements Agent for every describe in the project — appended to the default prompt, never replacing it.

Projects and shared context

Projects are the substrate for Context Threads: durable facts a thread accumulates can graduate into the project's canon, so they outlive any single thread. Deleting a project removes the definition only — machines keep advertising the label, and graduated context survives.

Next: Context Threads · Runs & the board · Describe.