Ticket to merge

The complete delivery workflow: implement a ticket, publish a pull request, watch it, repair what CI and reviewers find, and merge. It imports two sub graphs and ships twelve prompt files.

Prerequisites

Repository folders with remotes, git credentials, GitHub read credentials and an authenticated coding harness. The agent needs repository and tracker access plus permission to publish, repair and merge the requested ticket. Read all prompts before running.

create_worktree → implementation → delivery → complete_ticket → cleanup. Delivery loops through PR observations and repairs until merged or closed. Cleanup retains unsafe worktrees.

Save, validate and run

Download all files. Choose the primary repository folder with the remote, credentials and permissions described above. Make an .orbital/ directory inside that repository and extract the archive there. Keep every relative path. From that project folder run:

orbital validate .orbital/workflow.dot

Add the required repository folders to the project in Orbital, with the repository containing the graph as its primary folder. On New run select the project and workflow graph, choose your authenticated harness and supply the goal. An empty practice repository is insufficient for this workflow.

Expected behaviour

Set work to the ticket URL and supply the delivery goal. Implementation plans, implements and reviews until approved. Delivery publishes and observes PR state, handles CI, conflicts and reviews, and waits five minutes between observations. A merge leads to ticket completion and cleanup. A closed PR leads to aborted cleanup; unsafe cleanup ends failed with the worktree retained.

Complete source

Every DOT file below is a complete runnable graph. The archive contains the same files. Prompt files are companions, not separate workflows.

workflow.dot

digraph implement_ticket {
  graph [version="1", entry="create_worktree", inputs="work", description="Deliver one ticket through reviewed implementation and a merged PR"]

  create_worktree [shape="folder", action="create"]
  implementation [import="subgraphs/implementation.dot"]
  delivery [import="subgraphs/pr-delivery.dot"]
  complete_ticket [prompt_file="prompts/complete-ticket.md", outputs="completion_summary:text"]
  cleanup_merged [shape="folder", action="remove"]
  cleanup_closed [shape="folder", action="remove"]
  complete [shape="Msquare", outcome="success"]
  closed [shape="Msquare", outcome="abandoned"]
  cleanup_pending [shape="Msquare", outcome="failed", label="Worktree retained to preserve local work"]

  create_worktree -> implementation
  implementation -> delivery [exit="approved"]
  delivery -> complete_ticket [exit="merged"]
  delivery -> cleanup_closed [exit="closed"]
  complete_ticket -> cleanup_merged
  cleanup_merged -> complete [condition="worktree.clean == true", weight="1"]
  cleanup_merged -> cleanup_pending
  cleanup_closed -> closed [condition="worktree.clean == true", weight="1"]
  cleanup_closed -> cleanup_pending
}

Download workflow.dot

subgraphs/implementation.dot

digraph implementation {
  graph [version="1", entry="plan", inputs="work", description="Plan, implement and locally review one work scope"]

  plan [prompt_file="../prompts/implementation/plan.md", outputs="implementation_plan:text"]
  implement [prompt_file="../prompts/implementation/implement.md", outputs="implementation_summary:text"]
  local_review [prompt_file="../prompts/implementation/review.md", outputs="review_verdict:choice, review_findings:json"]
  plan_review [prompt_file="../prompts/implementation/plan-review.md", outputs="implementation_plan:text"]
  implement_review [prompt_file="../prompts/implementation/implement-review.md", outputs="implementation_summary:text"]
  approved [shape="Msquare", outcome="success"]

  plan -> implement
  implement -> local_review
  local_review -> plan_review [condition="review_verdict == 'reject'", weight="2"]
  local_review -> approved [condition="review_verdict == 'pass'", weight="1"]
  plan_review -> implement_review
  implement_review -> local_review
}

Download implementation.dot

subgraphs/pr-delivery.dot

digraph pr_delivery {
  graph [version="1", entry="publish", inputs="work", description="Publish a change and repair it until the PR is merged or closed"]

  publish [prompt_file="../prompts/pr-delivery/publish.md", outputs="publication_summary:text"]
  probe_pr [shape="parallelogram", probes="pr"]
  address_reviews [prompt_file="../prompts/pr-delivery/address-reviews.md", outputs="repair_summary:text"]
  fix_ci [prompt_file="../prompts/pr-delivery/fix-ci.md", outputs="repair_summary:text"]
  resolve_conflicts [prompt_file="../prompts/pr-delivery/resolve-conflicts.md", outputs="repair_summary:text"]
  review_repairs [prompt_file="../prompts/pr-delivery/review-repairs.md", outputs="review_verdict:choice, review_findings:json"]
  revise_repairs [prompt_file="../prompts/pr-delivery/revise-repairs.md", outputs="repair_summary:text"]
  wait [shape="insulator", duration="5m"]
  merged [shape="Msquare", outcome="success"]
  closed [shape="Msquare", outcome="failed"]

  publish -> probe_pr
  probe_pr -> merged [condition="pr.state == 'MERGED'", weight="6"]
  probe_pr -> closed [condition="pr.state == 'CLOSED'", weight="5"]
  probe_pr -> resolve_conflicts [condition="pr.state == 'CONFLICTS'", weight="4"]
  probe_pr -> fix_ci [condition="pr.state == 'CI_FAILED'", weight="3"]
  probe_pr -> address_reviews [condition="pr.state == 'CHANGES_REQUIRED'", weight="2"]
  probe_pr -> wait
  wait -> probe_pr
  address_reviews -> review_repairs
  fix_ci -> review_repairs
  resolve_conflicts -> review_repairs
  review_repairs -> revise_repairs [condition="review_verdict == 'reject'", weight="2"]
  review_repairs -> publish [condition="review_verdict == 'pass'", weight="1"]
  revise_repairs -> review_repairs
}

Download pr-delivery.dot

prompts/complete-ticket.md

Discover and use relevant installed skills for completing tickets and communicating delivery results.

User supplied goal:

{{ inputs.goal }}

Ticket:

{{ context.work }}

Publication summary:

{{ context.publication_summary }}

Confirm from the remote that the PR delivering this work has merged. Verify that the merged change satisfies the ticket and goal. Identify any ticket-related changes that remain unpublished before marking the work complete.

Mark the supplied ticket done using its tracker’s workflow.

If the ticket is already complete, verify the recorded delivery evidence and avoid duplicate updates. Leave parent, sibling and unrelated tickets unchanged.

This step may update the supplied ticket's completion record. Leave repository files, commits, branches and pull requests unchanged.

Return `completion_summary` with the ticket’s confirmed status, merged PR link and delivery evidence.

A follow-up step cleans up the worktree.

Download complete-ticket.md

prompts/implementation/implement-review.md

Discover and use relevant installed skills for implementation and verification.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Revised implementation plan:

{{ context.implementation_plan }}

Previous implementation summary:

{{ context.implementation_summary }}

Review verdict:

{{ context.review_verdict }}

Review findings:

{{ context.review_findings | dump }}

Inspect the current changes and applicable repository instructions. Apply the revised plan and address every blocking finding. Preserve correct work and remove changes the plan identifies as outside scope.

Verify each correction and run the relevant checks for the complete change. Close all remaining defects, unmet requirements or verification gaps in the work scope and the plan. Address all required changes from the plan and review. Create or update local commits using the repository’s conventions.

This step may change repository files, run checks and create local commits. Later steps own local review and publication. The caller owns any tracker updates.

Return an updated `implementation_summary` describing the complete current change, the correction and verification for each finding, and anything still unresolved.

Download implement-review.md

prompts/implementation/implement.md

Discover and use relevant installed skills for implementation and verification.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Implementation plan:

{{ context.implementation_plan }}

Implement the planned change in the prepared worktree. Follow applicable repository instructions and preserve unrelated work.

Satisfy every requirement in the work scope and goal. If the code reveals an error in the plan, make the necessary adjustment within that scope and explain it.

Run the relevant checks. Record what each check establishes and any failures or verification gaps. Create or update local commits using the repository’s conventions.

This step may change repository files, run checks and create local commits. Later steps own publication. The caller owns any tracker updates.

Return `implementation_summary` with the changes, verification evidence, deviations from the plan and any unmet requirements.

Download implement.md

prompts/implementation/plan-review.md

Discover and use relevant installed skills for planning and communicating the plan.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Previous implementation plan:

{{ context.implementation_plan }}

Implementation summary:

{{ context.implementation_summary }}

Review verdict:

{{ context.review_verdict }}

Review findings:

{{ context.review_findings | dump }}

Read the work scope, applicable repository instructions and current changes. Investigate each blocking finding against the code and available evidence.

Revise the implementation plan to address every blocking finding. Specify each correction and how it will be verified. Preserve work that already satisfies the requirements and identify any changes that must be removed or revised.

Keep the revised plan complete enough for implementation. Cover the work scope and goal without adding unrelated work. State assumptions and material risks.

Return the revised plan as `implementation_plan`. Leave repository files and tracker records unchanged.

Later steps will implement and publish the changes. The caller owns any tracker updates.

Download plan-review.md

prompts/implementation/plan.md

Discover and use relevant installed skills for planning and communicating the plan.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Read the supplied work scope, relevant linked context and applicable repository instructions. Inspect the affected code and tests. For ticket-based work, read the identified ticket.

Plan the changes needed to satisfy the work scope. Use the goal to guide decisions without expanding that scope. Choose the smallest implementation that meets every requirement.

Explain the required behaviour, affected components, implementation order and how each acceptance criterion will be verified. Ground decisions in the inspected code.

Return the plan as `implementation_plan`. Leave repository files and tracker records unchanged.

Later steps will implement and publish the changes.

Download plan.md

prompts/implementation/review.md

Discover and use relevant installed skills for code review and communicating findings.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Implementation plan:

{{ context.implementation_plan }}

Implementation summary:

{{ context.implementation_summary }}

Review the current change against the work scope, goal, plan and applicable repository instructions. Inspect the complete branch diff against its target, including uncommitted changes, affected code and relevant tests.

Review only requirements and defects that can be verified through automated checks or code inspection. For each rejection, identify the requirement, concrete evidence, required correction and machine-checkable completion condition.

Use the work scope, plan and summary as context. Verify their claims against the code and available evidence.

Reject unmet requirements, correctness or security defects, violations of mandatory repository rules, missing verification of required behaviour and changes made which are outside the work scope. Treat preferences as non-blocking unless repository instructions require them.

Human reviews, manual acceptance, visual approval and user sign-off are non-blocking. Report them as outstanding without requiring their completion to pass.

Compare each finding with previous reviews and attempted corrections. If the same finding returns without new evidence or a materially different actionable correction, recognise that the review is looping. Do not reject again for that finding. Report the unresolved concern and explain why another repair pass would not advance it

For each blocking finding, identify the requirement or defect, supporting evidence and the correction needed.

This step is read-only. Leave files, commits, branches, pull requests and tracker records unchanged.

Return review_verdict as reject only when actionable, machine-checkable blocking findings remain. Otherwise return pass. Keep outstanding human or manual checks and concerns excluded. Return `review_findings` as an array containing those findings, or an empty array when the review passes.

Download review.md

prompts/pr-delivery/address-reviews.md

Discover and use relevant installed skills for addressing pull request feedback, verification and communicating with reviewers.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Publication summary:

{{ context.publication_summary }}

Inspect the current PR, its published head, review decisions and unresolved threads. Read the affected code and applicable repository instructions.

Address feedback within the work scope and goal. Make the required local changes, verify them and create or update local commits using the repository’s conventions. Preserve unrelated work.

For feedback already satisfied by the published change, reply with supporting evidence and resolve the thread. For feedback requiring a new local change, keep the thread unresolved until that correction is published and verified. Check existing replies before posting to avoid duplicates.

Explain with evidence when a requested change is unnecessary or outside scope.

If the PR has merged or closed, report that state without modifying it.

This step may change repository files, run checks, create local commits, reply to reviews and resolve addressed threads. Later steps own local review and publication. The caller owns any tracker updates.

Return `repair_summary` with the feedback addressed, changes, verification evidence, published corrections confirmed, and threads awaiting publication or further resolution.

Download address-reviews.md

prompts/pr-delivery/fix-ci.md

Discover and use relevant installed skills for diagnosing CI failures, implementing corrections and verification.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Publication summary:

{{ context.publication_summary }}

Inspect the current PR, published head and failing checks. Read their logs, affected code and applicable repository instructions. Confirm the failures belong to the current published change.

Identify the cause of each failure. Use focused local checks where possible and compare against the target branch when needed to distinguish defects in this change from existing failures or external problems.

Correct failures within the work scope and goal. Preserve unrelated work. Rerun a failed remote check when the evidence supports a transient failure; do not rerun checks repeatedly without investigating.

Verify the corrections and create or update local commits using the repository’s conventions.

If the PR has merged or closed, report that state without modifying it.

This step may change repository files, run checks, rerun remote CI and create local commits. Later steps own local review and publication. The caller owns any tracker updates.

You need to get the PR into a state where required CI checks are green.

Return `repair_summary` with the failed checks, diagnosis, corrections, verification results and anything still unresolved.

Download fix-ci.md

prompts/pr-delivery/publish.md

Discover and use relevant installed skills for publishing pull requests and communicating the change.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Inspect the prepared worktree, current branch and any associated pull request.

Push the intended local commits. Update the existing open PR, or create one against the repository’s intended target branch. Describe the complete change, its relationship to the work scope and the verification performed.

Use ticket references only when the work scope identifies an existing ticket.

Enable auto-merge if possible. Respect required checks, approvals and merge-queue rules.

If the associated PR is already merged and the branch contains follow up changes, open a new PR.

Confirm the PR URL from the remote. If publication or enabling auto-merge fails, inspect the current remote state before retrying. Preserve local work and avoid creating duplicate PRs.

This step owns publication and the merge request. Leave implementation files and tracker records unchanged. Later steps handle PR feedback, CI and conflicts. The caller owns any tracker updates.

Return `publication_summary` with the PR URL, confirmed remote state, published commits and merge-request status.

Download publish.md

prompts/pr-delivery/resolve-conflicts.md

Discover and use relevant installed skills for resolving merge conflicts and verifying the resulting change.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Publication summary:

{{ context.publication_summary }}

Inspect the current PR, its target branch, published head and prepared worktree. Read applicable repository instructions.

If the PR has merged or closed, report that state without modifying it.

Fetch the latest target branch and integrate it using the repository’s conventions. Prefer rebase. Resolve conflicts by understanding both changes. Preserve the required behaviour of the work scope, relevant target-branch changes and unrelated work.

Verify that the local branch integrates cleanly with the fetched target. Run the relevant checks and create or update local commits using the repository’s conventions.

If the conflict has already disappeared, report the evidence without introducing unnecessary changes.

This step may fetch remote changes, merge or rebase locally, resolve conflicts, run checks and create local commits. Later steps own local review and publication. The caller owns any tracker updates.

Your job is to make the PR mergeable and resolve any conflicts with the base branch.

Return `repair_summary` with the target revision, conflicts resolved, resulting changes, verification evidence and anything still unresolved.

Follow-up steps review and publish the changes, monitor the PR and return the result to the caller. The caller owns tracker updates and worktree cleanup.

Download resolve-conflicts.md

prompts/pr-delivery/review-repairs.md

Discover and use relevant installed skills for code review and communicating findings.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Publication summary:

{{ context.publication_summary }}

Repair summary:

{{ context.repair_summary }}

Review the complete current branch change against the work scope, goal and applicable repository instructions. Inspect the diff against the current target branch, including uncommitted changes, affected code and relevant tests.

Verify the corrections and verification claims in the repair summary against the code and available evidence.

Reject unmet requirements, correctness or security defects, violations of mandatory repository rules, missing verification of required behaviour and changes outside the work scope. Treat preferences as non-blocking unless repository instructions require them.

This step is read-only. Leave files, commits, branches, pull requests and tracker records unchanged.

Return `review_verdict` as `reject` when blocking findings remain, otherwise `pass`. Return `review_findings` as an array of blocking findings, each with `requirement`, `evidence` and `correction`. A pass returns an empty array.

Follow-up steps address rejected findings or publish the reviewed changes, then continue monitoring the PR.

Download review-repairs.md

prompts/pr-delivery/revise-repairs.md

Discover and use relevant installed skills for implementation and verification.

User supplied goal:

{{ inputs.goal }}

Work scope:

{{ context.work }}

Publication summary:

{{ context.publication_summary }}

Previous repair summary:

{{ context.repair_summary }}

Review verdict:

{{ context.review_verdict }}

Review findings:

{{ context.review_findings | dump }}

Inspect the current changes and applicable repository instructions. Address every blocking finding. Preserve correct work and remove changes identified as outside the work scope.

Verify each correction and run the relevant checks for the complete change. Satisfy the work scope and goal, including the required PR repairs. Create or update local commits using the repository’s conventions.

This step may change repository files, run checks and create local commits. Leave the PR and tracker records unchanged.

Return an updated `repair_summary` describing the complete repair, the correction and verification for each finding, and anything still unresolved.

Follow-up steps review the changes again, publish them after a passing review, and continue monitoring the PR.

Download revise-repairs.md

This is the workflow the shorter examples build up to. Compare it with one-shot implementation to see what waiting on a pull request adds.