# From Idea to Verified Sprint
{{< tier level="sovereign" note="The included idea-to-sprint workflow composes planning and delivery into one durable run while preserving human approval and independent review." >}}

Turning an idea into a delivered sprint requires more than asking one agent to remember every decision and handoff. Valdr makes each phase explicit: clarify, specify, approve, prepare, schedule, implement, review, integrate, close, and publish.

## Run this workflow

Start **Execute Idea Through Sprint** (`valdr-workflow.idea-to-sprint`) through `pm_workflow`, then inspect the parent and child runs in Valdr UI. The task and its project become the starting scope for the run. Open **Workflows** first and note the exact imported version shown in the catalog.

Import the compatible Valdr core pack and then the official **Valdr Workflow pack** through [Settings > Valdr Packs](/valdr/docs/getting-started/configure/#import-via-the-ui). The [compatibility table](/valdr/docs/getting-started/configure/#compatible-releases) lists the exact versions and filenames. The workflow pack supplies this definition and Verdandi. Use a task in a registered Git-backed project, and make sure the [launcher presets](/valdr/docs/getting-started/configure/#create-an-agent-preset) for planning, routing, readiness review, scheduling, and pull-request writing are enabled.

| What you provide | What Valdr produces |
| --- | --- |
| One idea task with the problem and desired outcome | A reviewed specification and reviewed plan |
| Sprint name, start date, and end date | A saved plan, generated tasks, a delivery branch, and a closed sprint |
| Planning, routing, readiness-review, scheduling, and PR-writer presets | Task preparation, staffing, schedule, reviewed commits, and delivery results |
| Clarification, planning-approval, readiness, and PR-publication decisions | Linked sessions, reviews, evidence, parent/child run history, and a pull-request result |

Discover the newest active version before starting:

```text
pm_workflow {
  action: "list",
  workflowKey: "valdr-workflow.idea-to-sprint",
  latestOnly: true
}
```

```text
pm_workflow {
  action: "start",
  workflowKey: "valdr-workflow.idea-to-sprint",
  version: "<catalog-version>",
  taskKey: "IDEA-42",
  actorHandle: "your-operator-handle",
  inputs: {
    taskKey: "IDEA-42",
    sprintName: "September delivery",
    startTs: 1788739200000,
    endTs: 1789689600000,
    planLauncherConfigKey: "your-planning-preset",
    routerLauncherConfigKey: "your-router-preset",
    reviewerLauncherConfigKey: "your-readiness-review-preset",
    schedulerLauncherConfigKey: "your-scheduler-preset",
    prWriterLauncherConfigKey: "your-pr-writer-preset",
    operatorHandle: "your-pr-operator-handle"
  },
  clientRequestId: "idea-to-sprint:IDEA-42:1"
}
```

Replace the task, handles, presets, and version with values from your installation. The start call's registered `actorHandle` authorizes the planning gates. `inputs.operatorHandle` is a separate registered handle that authorizes the pull-request proposal gate. If a start omits `actorHandle` and a step needs one, Valdr uses the registered `pm` agent.

The run may encounter four guided operator checkpoints:

1. **Revalidate** after answering clarification questions, only when the idea is missing required detail.
2. **Approve spec** after previewing the reviewed specification.
3. **Approve plan** after previewing the reviewed specification, plan, and their reviews.
4. **Publish pull request** after editing or confirming the proposed title, body, and draft state. Choose **Reject** to stop publication.

Delivery can also pause at a task-readiness checkpoint before sizing and staffing. When automated repair declines a change or re-review still finds gaps, update the task and choose **Revalidate**, or choose **Stop** to block that task's preparation. These readiness gates accept the run actor or the configured operator, which defaults to `@pm`; the top-level PR operator is not propagated into that role. Because readiness is checked for every generated task, this checkpoint can appear more than once during a sprint run.

After starting the run, open **Workflows > Runs** and select the parent run. Select **Create approved plan**, **Execute generated sprint**, or **Publish reviewed delivery** to inspect each child run without losing the parent view.

{{< callout type="info" >}}
**[Start with pm_workflow, inspect in Valdr UI](/valdr/docs/valdr-mcp/workflows/#start-a-run)** — Supply the idea, dates, and presets once, then follow every approval and child run in **Runs**.
{{< /callout >}}

## One lifecycle, three governed phases

`idea-to-sprint` composes plan creation, sprint execution, and pull-request publication. Planning decides what should be built and records the approved plan. Delivery uses that exact plan and project scope to prepare, schedule, implement, review, integrate, and close its tasks. Publication freezes the completed branch evidence for one final operator decision.

{{< thumbcard src="/images/workflows/idea-to-sprint.svg" fit="contain" alt="Idea-to-sprint lifecycle moving from clarification and human-approved planning into a plan branch, sprint preparation, independent review, reviewed Git integration, sprint close, and approved pull-request publication" caption="Human authority closes planning and pull-request publication; reviewed commits advance delivery to a closed sprint." >}}

The parent run provides one end-to-end status and history while keeping planning, delivery, and publication separately inspectable. A blocked child prevents a successful parent result, while completed work remains visible when another step waits or needs correction.

## Clarify, specify, and approve

Planning starts from the idea task. A validator reads its current context and posts questions when information is missing. Your answers stay with the task, so specification and plan writers do not fill important gaps with silent assumptions.

Once the idea is ready, a specification writer produces testable requirements and a separate reviewer agent evaluates them. Requested changes return to the same writer and reviewer sessions for another bounded pass, preserving context without allowing open-ended revision.

The specification and plan receive separate approval previews after review. Feedback returns to the writer and refreshes the preview before you approve or reject it.

The plan writer inherits the reviewed specification, but review does not grant final authority. Only the operator can approve the plan for delivery. After approval, the planning child saves and verifies the plan, marks the idea task done, and returns the approved plan plus the recorded starting branch and commit to the parent run. The parent then continues into sprint delivery.

This removes the manual relay of planning artifacts while preserving the decision that matters: agents can draft and review, but a person decides what becomes delivery scope.

## Open a controlled delivery branch

Before creating the sprint, Valdr creates a dedicated plan branch from the exact starting commit recorded during planning. Every approved task delivery advances this shared branch, while the original branch remains unchanged.

Branch creation is repeat-safe. If the expected branch already points to the same commit, the workflow continues. If the starting branch moved, the plan branch drifted, or the target branch is checked out somewhere, the run blocks for inspection instead of guessing.

{{< callout type="info" >}}
**Git changes stay bounded to the workflow.** The included workflow creates local branches, commits only a completed and approved delivery record, and uses fast-forward-only local integration. For publication, it reads remote refs without fetching and pushes only the exact approved plan-branch head with a lease guard. It does not switch checkouts or merge the completed plan branch back into your original branch.
{{< /callout >}}

## Prepare and schedule the approved work

Valdr creates the sprint only after the plan branch is ready. Every generated task then passes the same preparation sequence:

1. Review readiness and block incomplete work.
2. Estimate size or identify work that must be split.
3. Assign an executor and reviewers from separate role pools, preventing self-review in the included workflow.
4. Record the staffing and mark the task ready for delivery.

Only after every generated task is prepared does scheduling begin. The scheduler may reorder the approved task list, but it cannot add, remove, or duplicate tasks.

The included workflow currently prepares, delivers, and reviews work sequentially so the order stays easy to inspect.

{{< callout type="info" >}}
**Stable staffing, current execution.** Executor and reviewer assignments remain attached to the task and review. Immediately before delivery, the workflow asks the router to choose from the current launcher-preset listing. If it cannot select one, delivery blocks for operator correction instead of launching with an uncertain route.
{{< /callout >}}

## Implement, review, and close out

Delivery launches the assigned executor and waits for the implementation session to finish. Reviewer-role agents assigned separately from the executor then evaluate the same work and publish review evidence.

The workflow checks the review's configured approval policy before routing:

- When the reviews satisfy the approval policy, the delivery becomes eligible for closeout.
- Requested changes return to the same assigned executor for another bounded implementation pass.
- Review runs again against the new implementation before the policy is checked again.
- Exhausted correction passes block instead of reporting success.

Closeout rechecks the task, completed delivery, and approved review before changing Git state. Valdr then commits the exact reviewed delivery, fast-forwards it into the plan branch, and marks the task done. A changed receipt, changed target branch, non-fast-forward history, or checked-out target blocks the run instead of integrating uncertain work.

After every generated task reaches this state, Valdr verifies that every task from the approved plan is complete and closes the sprint. The sprint child records the plan branch and its starting commit; the parent publishes the sprint close outcome and delivery results.

## Review and publish the pull request

After sprint close, Valdr records the remote identity, freezes the exact branch diff and commit range, and asks the PR-writer preset to draft a proposal. At **Publish pull request**, the authorized PR operator can edit the title, body, and draft state before approving or rejecting it.

Approval does not publish stale evidence. Valdr rechecks the remote and proposal digest, pushes the exact approved head with a lease guard, then creates or adopts the matching pull request. The parent returns the delivery branch, publication decision and outcome, pull-request number, and URL when available.

## Why this compounds

The workflow is more than a chain of agents. It preserves the exact places where authority changes hands:

| Boundary | What prevents drift |
| --- | --- |
| Idea to specification | Recorded clarification and independent spec review |
| Specification to plan | Separate artifact preview and human approval |
| Plan to sprint | One approved plan, project scope, and recorded starting commit |
| Preparation to delivery | Ready, sized, staffed tasks and a validated schedule |
| Review to Git closeout | Approved review plus the exact completed delivery record |
| Task integration to sprint close | Fast-forwarded reviewed commits plus every task from the approved plan verified complete |
| Sprint close to pull request | Frozen branch evidence, editable operator approval, a lease-guarded push, and create-or-adopt publication |

Instead of paying the coordination cost again for every feature, you operate the same reviewable system and improve the workflow definition over time.

## Start with an idea

Start with an idea task, inspect the generated specification and plan, retain final approval, and follow reviewed delivery through sprint close and pull-request publication—all within one durable run.

1. **[Run idea-to-sprint](/valdr/docs/valdr-mcp/workflows/#start-a-run)** with the idea task, sprint dates, and launcher presets.
2. **[Inspect it in the Workflow UI](/valdr/docs/ui/workflows/#run-inspector)** as planning and delivery child runs advance.
3. **[Learn how composition works](../steps/subworkflow/)** when you are ready to connect saved workflows of your own.