Skip to content
PWR

PWR Producer

Turn a goal into a reviewable plan

PWR Producer is the planning role. It reads the repository with read-only tools and returns a structured backlog: tasks, acceptance criteria, dependencies, estimates, risks and open questions. Nothing becomes work until a person approves the plan.

Request early access

Producers, product managers and tech leads who want a first-draft plan grounded in the actual codebase.

How it works

PWR Producer, step by step

  1. 01

    Describe the goal

    Start a planning workflow or a Plan-mode conversation. Point it at a design document in the repository if there is one.

  2. 02

    Producer reads and drafts

    The Producer agent can read, list and search files. It cannot edit or run commands. It returns a plan in a fixed structure that the platform validates.

  3. 03

    You approve the plan

    Review the proposed tasks and their acceptance criteria. Applying a plan as tasks is an approval step, and so is a scope change.

  4. 04

    Tasks enter the board

    Approved tasks are created with their dependencies and can be added to a sprint for execution.

Available
Implemented and covered by automated tests in the current platform build.
Beta
Implemented; verification against the live external service is still pending.
Upcoming
Planned or in progress. Not usable yet.

Planning

Plans are structured data, not prose. The platform validates the shape before anything is created from it.

  • Structured backlog output

    Available

    A plan contains a summary, epics, tasks with acceptance criteria, dependencies, estimates and uncertainty, plus risks and open questions.

    The plan structure is validated by the platform. The quality of a plan depends on the model and on the context you provide.

  • Read-only by policy

    Available

    The Producer role is limited to reading, listing and searching files. It has no write or shell tools.

  • Plan approval before tasks exist

    Available

    A plan becomes tasks only when a person applies it. Task dependencies are checked for cycles when they are created.

  • Plan-mode conversations on a repository

    Beta

    Ask for a plan in the workspace and get a structured proposal you can apply as tasks.

    Verified against a simulated GitHub and a stub agent sandbox; live verification is pending.

  • Budgeted goals

    Beta

    A goal runs one planning pass, waits for your approval, then queues tasks within a budget, a task limit and a parallelism limit.

    Controller logic is covered by automated tests with a stub agent and a simulated GitHub; live end-to-end verification is pending.

Analysis workflows

Templates that start a Producer or designer conversation with the right inputs.

  • Analyze an existing repository

    Beta

    Produces an architecture summary of a connected repository as the starting point for planning.

    Launch path is covered by automated tests; it reads a connected repository, which has only been verified against a simulated GitHub.

  • Review a game design document

    Beta

    The Game Designer role reads a design document from the repository and returns a spec of mechanics, rules, tunables and review findings. Available for game projects.

    Launch path is covered by automated tests; it reads a connected repository, which has only been verified against a simulated GitHub.

  • Plan technical debt reduction

    Beta

    A Plan-mode run that proposes a backlog of debt-reduction tasks for a connected repository.

    Launch path is covered by automated tests; it reads a connected repository, which has only been verified against a simulated GitHub.

Sprint preparation

  • Plan a sprint

    Beta

    A planning run that proposes sprint tasks and can create a planned sprint when you apply it.

    Launch path is covered by automated tests; it reads a connected repository, which has only been verified against a simulated GitHub.

  • Sprint analysis from Jira

    Beta

    Imports a Jira sprint as draft tasks, then reports per ticket: missing acceptance criteria, automation eligibility, dependencies, blockers, risk and a credit range.

    Verified against a simulated Jira Cloud; verification against a live Jira site is pending.

  • Sprint analysis from GitHub Issues

    Beta

    The same analysis for a GitHub milestone, using issues from the connected repository.

    Verified against a simulated GitHub; verification against live GitHub Issues is pending.

  • Fail-closed proposals

    Beta

    If the analysis is missing or malformed it is marked failed, not guessed. Tickets that were not imported are dropped from the proposal.

    Covered by automated tests with fabricated model replies; not yet exercised against a live model and a live tracker together.

Questions

Can PWR Producer change code?

No. The Producer role has read-only tools. It plans. Implementation is done by engineer roles on their own branches after you approve the plan.

Does Producer create milestones?

Not as a separate object. Plans produce epics and tasks, and tasks are grouped into sprints. With the GitHub Issues connector, a GitHub milestone is treated as a sprint.

Is there a dedicated PRD workflow?

Not today. There is a template for reviewing a game design document. For other requirement documents, use a Plan-mode run and describe the goal, or commit the document to the repository so the agent can read it.

What happens if I disagree with the plan?

Nothing is created until you apply it. You choose which tasks to approve, and tasks without acceptance criteria are refused for autonomous execution.

Read the docs

Related

Put an AI development team on your idea.

Describe what you want to build. PWR plans, builds, tests and reviews it, and you approve each step that matters.

Request early accessSee how PWR works