AI/myAi
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Add build verification requirement to general-dev-workflow skill

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
claude
2026-05-28 15:01:40 +03:00
parent 39708cf340
commit 73673229a4
1 changed files with 17 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/skills/general-dev-workflow.md
+17 -2
View File
@@ -78,6 +78,19 @@ Steps:
### Phase 4: Test ### Phase 4: Test
**Goal**: Verify the code works correctly and doesn't break existing functionality. **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:** **Write tests for your changes:**
- Unit tests for individual functions/methods - Unit tests for individual functions/methods
- Integration tests if your code touches multiple systems - Integration tests if your code touches multiple systems
@@ -99,9 +112,9 @@ Steps:
- Any manual testing notes - Any manual testing notes
- Known limitations or edge cases not yet tested - 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. **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. **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. **Write for your future self.** Six months from now, you'll read your own commits and PRs. Make them clear.