The Cloud Software Factory Build Guide

A cloud software factory is an automation loop around the software development lifecycle: triage, spec, implement, review, verify, ship, monitor. At each step, a mix of agents and humans moves work forward.

This guide shows how to build one from scratch using GitHub Actions runners. Each part adds one skill to the loop, in the order that makes the next part possible. You can stop at any part and have something that works.

To understand how cloud software factories work at a high level, and how to measure ROI, read our guide to cloud software factories for engineering leaders.

Part 1: Automatic issue triage

How to build a cloud software factory: the automatic triage skill

Issue/ticket triage is the front door to any cloud software factory. An incoming issue gets read, reproduced where possible, and sorted into one of three outcomes: automatable and ready to implement, ambiguous and needing a spec, or parked pending human input.

When an issue is marked “ready to implement,” a second agent can pick up the thread as context and generate an informed draft PR. This removes the human-in-the-loop for well-scoped bug reports that land in your issue tracker.

What you have after Part 1: every new issue arrives pre-sorted, saving time on labeling, ticket sizing, and initial architecture research. An implementation agent drafts PRs for well-scoped issues, removing the need for a human in the loop.

Part 2: Spec-driven development

How to build a cloud software factory: add spec-driven development skills

Feature work often needs a human involved to spec out the user experience. This is where spec-driven development comes in.

A spec agent turns an ambiguous issue into written product and technical specifications:

• PRODUCT.md → the end-to-end user experience of the feature (product design)
• TECH.md → how the feature fits into your existing technical architecture (system design)

A human approves and iterates on these specs before any code is generated. This is the highest-leverage checkpoint in the loop, allowing your team to align with the agent on how a feature should work before it gets built.

What you have after Part 2: complex and ambiguous feature work enters the factory instead of stalling, with each issue producing a PRODUCT.md for behavior and a TECH.md for architecture. Human review moves upstream, so you approve a spec instead of correcting a finished diff.

Part 3: Self-improving code review

How to build a cloud software factory: self-improving code review

Once agents produce code at volume, review becomes the bottleneck. A review agent gives every PR a first pass, reading the diff alongside any product or technical specs (see Part 2) and leaving inline comments with suggested fixes.

Code review should be run by a sandboxed agent with access to the code being reviewed. This allows the agent to test suggestions before commenting.

In addition, we’ll build a second outer-loop agent that improves the quality of code reviews based on your team’s feedback. This agent watches pull requests, synthesizes human feedback left as comments, and opens a PR updating the review skill itself.

What you have after Part 3: every PR gets a first-pass review before a human opens it, with suggestions the agent has already built and tested. The review skill accrues your team’s conventions over time instead of you writing them up front.

Part 4: Verification with computer use

Full guide coming soon.

Verification is the step that lets an agent prove its own work before asking for approval. High-quality implementation agents should have these capabilities:

1. Computer use: the ability for agents to control a machine and interact with the software they build to verify user flows end-to-end. This saves on review time by encouraging agents to catch bugs before requesting approval.
2. Reviewable PR artifacts: Agents should be able to screenshot and ideally record their work to attach to the code they generate. This transitions human code review from investigation to confirmation.

If you want a starting point, the validate-changes-match-specs skill checks an implementation against the spec that produced it. Pair it with Warp’s cloud platform and you’ll have the computer use capabilities needed for agentic verification.

Closing the loop

Once you’ve set up these components in your repository:

• Issues arrive triaged and sorted
• Ambiguous features are specced with human review
• Bug reports are implemented without opening a code editor or terminal session
• PRs are reviewed and verified before a human is tagged for approval

For one-time setup of all of these components, use our cloud factory demo repository and have your agent run the /oz-cloud-factory-demo skill. This will stand up the skills and workflows to drive your cloud software factory.