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, a deterministic build/review workflow, 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 and report — 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. The final output is a durable REPORT.md, transcript, status file, findings by round, and uncommitted code on the feature branch.

10. 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 — landing as an uncommitted diff on a feature branch, with a final report and PR steps for the developer.