Describe — the Requirements Agent

describe turns a rough idea into a well-specified, buildable plan. Instead of handing an agent a one-liner and hoping, you get an agent that interviews you first — the product, technical, and UX decisions that are yours to make — and then writes a scored backlog item (Epic, Feature, or Task) in the planning tree.

It runs your local agent (your auth, no server model key).

From the terminal

$ ptln describe

The agent researches your project, then asks only the questions it can't answer for you. You steer; it takes notes in a shared doc and proposes a breakdown.

Flags and in-interview commands:

  • --kind epic|feature|task — hint the top-level kind (the agent still decides how to decompose).
  • --thread <id> — attach a Context Thread so the interview reads and records shared decisions.
  • --quick — start in quick mode; /quick and /deep switch depth mid-interview.
  • /done — finish and write the item. /quit — leave without saving.

Already inside a session? The in-session twin is the /describe command.

From the web

Open partyline.sh/work and start a describe conversation in the browser — the same agent, good for non-technical teammates. It always opens a live conversation: the agent asks, you answer, and a plan takes shape in the working doc. When you're happy, send the tasks to the backlog.

The output is a plan, not one giant task

describe decomposes work into a tree whose task leaves are each small enough to build and merge independently. This is deliberate: a single 4,000-character mega-task can't be built reliably, so a well-specified feature becomes several bounded tasks you can run in parallel or as a chain. The system chooses the kinds; you approve the shape.

Customize what it asks

The default prompt is strong, but every team has standing guidance. You can add it in two places — both appended to the default (never replacing it, so the plan contract stays intact):

  • Per project — a Describe instructions field in project settings (e.g. "Prefer server components. Always propose a migration plan. Ask about auth before scoping."). Applies to every describe in that project.
  • Per conversation — an extra instructions box in the web doorway, for that one describe only.

See Projects for project-wide guardrails that also shape the build, not just the interview.

Next: Runs & the board · Trust gates · The software factory.