From Idea to Verified Sprint

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. The compatibility table 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 for planning, routing, readiness review, scheduling, and pull-request writing are enabled.

Discover the newest active version before starting:

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

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.

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.

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.

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.

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:

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 with the idea task, sprint dates, and launcher presets.
2. Inspect it in the Workflow UI as planning and delivery child runs advance.
3. Learn how composition works when you are ready to connect saved workflows of your own.