CF Dotnet Service Forge

Problem

Building and changing .NET microservices in CloudFactory’s platform monorepo involved repetitive boilerplate, inconsistent application of coding standards, and slow code review cycles. Writing Technical Requirements Documents from Product Requirements Documents was tedious, and the loop between generating code, reviewing it, and fixing issues was entirely manual. Existing services made it worse: any change had to be reasoned about across the monorepo — including the ripple into the gateways that expose a service to the frontend or partners.

Can we go from a PRD to a fully functional, reviewed backend service — for both new services and changes to existing ones — using AI?

Approach

Built a forge that now ships as five Claude Code slash-command skills, four custom agent types, three deterministic workflows (build/review, PR split and publish, Copilot review and auto-fix), and three git-invariant hooks. It handles two scenarios from one entry point: new service (greenfield) and change to existing services (brownfield). A PRD is required for both.

The process:

1. Onboarding — Developer types “hello”, installs skills, agents, and hooks, then /cf-forge asks the routing question (new vs change) and four setup questions: forge workspace, platform monorepo clone, PRD path, and service/change name. After install, /cf-forge starts the whole flow from any workspace.

2. TRD Interviewer (new service) — Extracts a feature checklist from the PRD, confirms it, then asks one question at a time across the TRD sections. The output is a completed Technical Requirements Document, with service-specific requirements separated from code-generation standards.

3. PRD-TRD Validator (new service) — Checks every PRD feature is covered in the TRD, patching gaps and flagging ambiguities before code generation begins.

4. Change Planner (existing services) — Analyses the PRD against the monorepo, finds every affected service, library, and gateway, and writes a Change Plan. Brownfield work stays in the target’s existing architecture rather than forcing a rewrite.

5. Build Orchestrator — Coordinates the pipeline but does not write or review code itself. It checks the platform clone, refuses to write on main, reuses an existing non-main branch when appropriate, or cuts feature/<name> from main. Then it launches forge-review-loop.js, the deterministic workflow that owns generation, gates, review, fixes, and status updates.

6. Worker agents — The old worker skills were split into spawnable agent types: cf-backend-engineer generates, applies Change Plans, and fixes findings; cf-gateway-engineer handles services/CF.gateways; cf-backend-code-reviewer is read-only against monorepo source and writes finding files outside the clone; cf-migration scaffolds EF Core migrations after the build gate.

7. Build, migration, and review workflow — The workflow runs preflight checks for sandbox access, NuGet feeds, private package auth, Docker, and the platform clone. Generation is write-only; the build gate owns compilation. SQL/EF services get migrations after the first successful build, reusing the warm compile. Then a review/fix loop runs up to 10 rounds.

8. Three-reviewer loop — Each round combines the custom CF reviewer (CloudFactory conventions, monorepo boundaries, HashiCorp Vault, architecture, EF Core, Riok.Mapperly, testing, logging), Anthropic’s built-in code-review, and security-review. Round 1 is full-scope; later rounds are diff-scoped to touched files, and any code change re-runs all three reviewers so security is never skipped. Only Critical/High findings are fixed.

9. Coverage — Greenfield coverage runs once after the review loop converges, against the final reviewed code. If coverage is below target, the engineer adds tests and the additions go back through build and review. Coverage flags but does not block; the PR’s Codecov patch gate is authoritative.

10. Split and publish PRs — On a passing run the forge publishes the work itself. A new service is proposed as a stack of PRs: a foundation PR off main (solution, shared infra, published contracts, DbContext and migration), one PR per vertical slice, and one for the gateway, each branched off the foundation so only the foundation has to merge first. The forge-pr-split.js workflow compiles every candidate branch in isolation; anything that cannot build standalone folds into the foundation, so each published PR compiles on its own (worst case everything collapses into a single PR). A brownfield change goes out as one PR. Titles are conventional commits with a stack marker, for example feat(CF.Orders): add create-order slice (2/4), because the monorepo squash-merges and CI reads the title to pick the semver bump. Pushing is outward-facing, so the developer always confirms first and can pick a single PR or skip publishing entirely.

11. Copilot review and auto-fix — Every opened PR gets a GitHub Copilot code review requested automatically. Copilot reviews asynchronously, so the forge-copilot-review.js workflow polls the PRs until the review lands, triages the comments down to the real fixable Critical/High defects (dropping nits and style), fixes them with the engineer agents, and build-gates each touched branch: a fix that cannot be made green is reverted, never pushed. Pushed fixes trigger a Copilot re-review, and on a stacked set a foundation fix is rebased into the sibling branches. The loop runs until Copilot has nothing fixable left or a small round cap is hit.

12. Final report — The output is a durable REPORT.md covering review rounds, build gates, coverage, the published PRs, and the Copilot review outcome, plus the transcript, status file, and findings by round. If publishing was skipped or unavailable, the report gives the manual git/gh recipe instead.

13. Git hooks — Three installed PreToolUse hooks enforce rules outside the prompt: no writes to main in the platform clone, no committing forge state, and no writing .forge/ or .cf-orchestrator/ inside the monorepo. Forge state stays outside the platform repo.

Results

The input: a ~100-line Product Requirements Document.

A real run produced 77 files and 3,588 lines of code, broken down as:

Category	Files	Lines added	Lines deleted
Tests	18	1,269	14
Business logic	48	2,066	0
Environment / config	11	253	0
Total	77	3,588	14

Generated, built, migrated, reviewed, and fixed automatically, with a final report for the developer. With the publishing stages added, a passing run now ends with the PRs already open and Copilot’s Critical/High review findings fixed and pushed, leaving the developer to watch CI and merge.