From 73673229a4c8bac0e8cf58f16a7967bc3b41ed4b Mon Sep 17 00:00:00 2001 From: claude Date: Thu, 28 May 2026 15:01:40 +0300 Subject: [PATCH] Add build verification requirement to general-dev-workflow skill Updated Phase 4 (Test) to include mandatory build verification: - dotnet build for .NET projects - docker compose --build for Docker projects - Catch missing dependencies and configuration issues early - Prevent build failures during code review and CI/CD Also added tip about verifying builds before opening PR, and updated Phase 4 checkpoint to include successful build requirement. Lesson learned from docker build issues: catching these early saves reviewers and CI/CD time, and prevents 'works on my machine' problems. Co-Authored-By: Claude Sonnet 4.6 --- docs/skills/general-dev-workflow.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/docs/skills/general-dev-workflow.md b/docs/skills/general-dev-workflow.md index 16bfc24..d9264fa 100644 --- a/docs/skills/general-dev-workflow.md +++ b/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 ` (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.