Dev Run Workflow Complete Guide: How an Issue Becomes a PR in 10 Phases

Introduction

DevLoop Runner's Dev Run takes a GitHub issue as input and automatically implements the code and creates a PR. But "issue in, PR out" doesn't tell you what's happening inside.

Under the hood, Dev Run executes 10 structured phases in sequence. It plans, defines requirements, designs, implements, tests, documents, and evaluates—just like a development team working through a systematic process.

This article walks you through all 10 phases and explains what each one does.

The Big Picture

Dev Run's 10 phases are organized into three groups.

Loading diagram...

Group	Phases	Purpose
Planning	Planning, Requirements, Design, Test Scenario	Decide what to build and how
Implementation	Implementation, Test Implementation, Testing, Documentation	Write code, test it, document it
Results	Report, Evaluation	Review outcomes and evaluate quality

Each phase builds on the previous one's output, so strong planning leads to better implementation quality.

The 4 AI Team Members

Dev Run assigns 4 AI personas to handle their respective phases as a team.

Persona	Role	Phases
Aoi	PM (Project Manager)	Planning, Requirements, Evaluation
Riku	Tech Lead	Design, Implementation, Report
Sumire	QA Engineer	Test Scenario, Test Implementation, Testing
Kohaku	Tech Writer	Documentation

Each persona specializes in their domain, producing more focused and optimized outputs than a single AI handling everything. The job detail page shows which persona is working on which phase in real time.

Planning Phases

1. Planning

Assigned to: Aoi (PM)

The first phase of every Dev Run. Aoi reads the GitHub issue and builds an understanding of the task.

What happens:

• Analyzes the issue content and objectives
• Develops an implementation strategy
• Identifies risks
• Estimates overall effort

Key point: Planning is the only phase that cannot be skipped. Every Dev Run starts here. The clearer your issue description, the better the plan—and the better every subsequent phase.

2. Requirements

Assigned to: Aoi (PM)

Building on the plan, Aoi organizes the specific requirements.

What happens:

• Details functional requirements
• Defines non-functional requirements (performance, security, etc.)
• Clarifies acceptance criteria
• Detects and fills in ambiguous or missing requirements

Deliverable: A requirements document. Implicit requirements not stated in the issue are supplemented through codebase analysis.

3. Design

Assigned to: Riku (Tech Lead)

Riku designs the architecture and implementation approach based on the requirements.

What happens:

• Architecture design
• Identifies target files and analyzes impact scope
• Data structure and API design
• Checks consistency with existing code

Deliverable: A design document detailing which files to change, how to change them, and how existing code is affected.

4. Test Scenario

Assigned to: Sumire (QA Engineer)

Before implementation begins, Sumire designs the test scenarios. This test-first approach determines what needs to be tested upfront.

What happens:

• Identifies test cases
• Designs happy path, error, and boundary value tests
• Identifies edge cases
• Sets test priorities

Key point: Creating test scenarios before implementation improves code quality. With clear test criteria established, the implementation is less likely to drift from requirements.

Implementation Phases

5. Implementation

Assigned to: Riku (Tech Lead)

Riku writes the actual code based on the design document.

What happens:

• Implements code according to the design
• Generates code that follows existing coding conventions
• Creates and edits necessary files
• Adds code comments

Key point: Since Riku implements based on the design document he created himself, consistency between design and implementation is maintained.

6. Test Implementation

Assigned to: Sumire (QA Engineer)

Sumire writes the test code based on the scenarios from Phase 4.

What happens:

• Creates test code
• Follows testing framework conventions
• Builds mocks and stubs
• Prepares test data

Key point: Separating test scenarios (Phase 4) from test implementation (Phase 6) clearly distinguishes "what to test" from "how to test it."

7. Testing

Assigned to: Sumire (QA Engineer)

Sumire runs the tests and verifies the results.

What happens:

• Executes tests
• Aggregates and analyzes results
• Analyzes root causes of failures
• Checks coverage

Key point: If tests fail, the report includes the cause and suggested remediation. Reviewing test results helps you objectively evaluate implementation quality.

8. Documentation

Assigned to: Kohaku (Tech Writer)

Kohaku creates or updates documentation to reflect the code changes.

What happens:

• Creates technical documentation for changes
• Updates API documentation
• Updates README and guides
• Records change history

Key point: Automating documentation updates prevents the common problem of "code changed but docs are still outdated."

Result Phases

9. Report

Assigned to: Riku (Tech Lead)

Riku reviews all changes and compiles a summary.

What happens:

• Lists changed files with a summary of changes
• Reviews implementation decisions
• Organizes resolved issues and remaining tasks
• Generates the PR description

Deliverable: A results report. Reviewers can read this report to quickly understand what changed and why.

10. Evaluation

Assigned to: Aoi (PM)

The final phase. Aoi evaluates overall quality against the original requirements.

What happens:

• Assesses achievement against requirements
• Reviews quality of each phase's deliverables
• Issues a final verdict (PASS / PASS WITH ISSUES / FAIL)

What the verdicts mean:

Verdict	Meaning
PASS	All requirements met
PASS WITH ISSUES	Requirements met, but minor issues detected
FAIL	Requirements not met (re-execution recommended)

For PASS or PASS WITH ISSUES, a draft PR is created. After review, you can use Finalize to publish the PR.

Phase Skipping and Execution Modes

Not every task needs all 10 phases. DevLoop Runner offers execution modes and phase skipping for flexibility.

Three Execution Modes

Mode	Phases Executed	Use Case
Full	All 10 phases	New features, complex changes
Plan Only	Planning, Requirements, Design	Pre-review, design exploration
Implementation Only	Planning, Implementation, Documentation, Report	Quick fixes with clear requirements

For details on choosing the right mode, see the Execution Mode Guide.

Phase Skipping

Even in Full mode, you can skip individual phases. Every phase except Planning can be skipped.

For example, if tests aren't needed for a change, you can skip Test Scenario, Test Implementation, and Testing to reduce execution time.

For more on phase skipping, see the Skip Phases Guide.

When Issues Are Found: Rollback

If you find problems during review, you can roll back to a specific phase and re-execute from there.

For example, if the design approach is wrong, roll back to the Design phase and restart. Outputs from already-completed phases are preserved, so you don't have to start from scratch.

For details on rollback, see the Rollback Guide.

Summary

• Dev Run creates PRs from issues through a 10-phase structured workflow
• 4 AI personas (Aoi, Riku, Sumire, Kohaku) each handle their area of expertise
• Phases are grouped into Planning, Implementation, and Results
• Planning is the only non-skippable phase—issue quality drives overall quality
• Execution modes and phase skipping allow flexible runs tailored to each task
• Rollback lets you restart from a specific phase when issues are found

Understanding what happens in each phase helps you review more efficiently and write better issues. Know the workflow, and you'll collaborate more effectively with your AI team.