docs/skills/general-dev-workflow.md

@@ -78,6 +78,19 @@ Steps:
 ### Phase 4: Test
 **Goal**: Verify the code works correctly and doesn't break existing functionality.
 
+**Build verification (critical for compiled languages):**
+- Run `dotnet build <solution>` (for .NET projects) or equivalent build command for your tech stack
+- Fix any compilation errors before proceeding
+- If your project has multiple build targets, test all of them (e.g., multiple Dockerfiles, web + API)
+- **Docker projects**: Run `docker compose --build` to verify all Docker images build successfully
+- Check build artifacts exist and are correct size (no suspiciously small binaries)
+
+**Why build verification matters:**
+- Catches missing dependencies, import errors, and configuration issues early
+- Prevents "it works on my machine" problems during code review
+- Docker builds especially must be verified as they catch missing project references and file copies
+- A failed build blocks reviewers and CI/CD pipelines
+
 **Write tests for your changes:**
 - Unit tests for individual functions/methods
 - Integration tests if your code touches multiple systems
@@ -99,9 +112,9 @@ Steps:
 - Any manual testing notes
 - Known limitations or edge cases not yet tested
 
-**Output**: Passing tests, code coverage report, test summary.
+**Output**: Passing tests, code coverage report, test summary, successful build.
 
-**Checkpoint**: Can you confidently say the code works? Are there any untested paths you're worried about?
+**Checkpoint**: Does the code compile without errors? Can you confidently say the code works? Are there any untested paths you're worried about?
 
 ---
 
@@ -184,6 +197,8 @@ Problem it solves / value it adds (2-3 sentences)
 
 **Keep phases focused.** Don't mix planning with implementation. Don't test in Phase 2. This separation helps catch problems early.
 
+**Verify builds before review.** Always run a full build (`dotnet build` or `docker compose --build`) in Phase 4 before opening the PR. Build errors block reviewers and waste CI/CD time. If you're changing Dockerfiles or project dependencies, this is especially critical.
+
 **Commit frequently.** Small commits are easier to review, easier to revert if needed, and easier to understand. Aim for 50-200 lines per commit.
 
 **Write for your future self.** Six months from now, you'll read your own commits and PRs. Make them clear.