build-check

Files (1)

• SKILL.md

SKILL.md (first lines)

# Build Check Skill

## Purpose
Auto-detect the project's build system and run compilation/type-checking after creating or modifying files. Catches errors (missing imports, type mismatches, DI failures) before the user discovers them at runtime.

## Activation
Run once per logical change set — after completing a multi-file feature or a self-contained modification, NOT after each individual file:
- After completing a multi-file feature (run once at the end)
- After a single-file change that could affect compilation (run once for that change)
- When the user asks to build or check compilation

---

## How It Works

This skill does NOT hardcode build commands. It detects them from the project.

Results cached in `.claude/idev/build-check/cache.json` after first detection.

---

## Phase 1: Detect Build System

Scan for build configuration files. Check ALL — do not assume any stack:

```
.NET:
  Glob for *.sln → dotnet build {solution.sln}
  Glob for *.csproj (if no .sln) → dotnet build {project.csproj}
  Check for specific project to build (API project .csproj for faster builds)

Node.js/TypeScript:
  Read package.json → check scripts section:
    "build" → npm run build / yarn build / pnpm build
    "typecheck" or "tsc" → npm run typecheck (preferred — faster than full build)
    "check" → npm run check (Svelte)
  Detect package manager: look for yarn.lock, pnpm-lock.yaml, or package-lock.json

Python:
  Glob for pyproject.toml → check for build tool (poetry, setuptools, hatch)
  Check for mypy.ini or pyproject.toml [tool.mypy] → mypy for type checking
  Check for ruff.toml or pyproject.toml [tool.ruff] → ruff check

Java:
  Glob for pom.xml → mvn compile
  Glob for build.gradle → gradle compileJava / ./gradlew compileJava

Go:
  Glob for go.mod → go build ./...

Rust:
  Glob for Cargo.toml → cargo check (faster than cargo build)

Ruby:
  Glob for Gemfile → bundle exec ruby -c (syntax check)
  Check for sorbet → srb tc (type check)

PHP:
  Glob for composer.json → check for phpstan or psalm → phpstan analyse / psalm
```

---

## Phase 2: Generate Cache

Write detected build commands to `.claude/idev/build-check/cache.json`:

```json
{
  "generated": "YYYY-MM-DD",
  "projects": [
    {
      "name": "ProjectName",
      "root": "relative/path/to/project",
      "layer": "backend|frontend",
      "buildCommand": "dotnet build path/to/project.csproj",
      "typeCheckCommand": "npm run typecheck (if different from build)",
      "lintCommand": "npm run lint (if available)",
      "workingDirectory": "relative/path (if command must run from specific dir)",
      "timeout": 120000
    }
  ],
  "quickChecks": {
    "backend": "dotnet build path/to/api.csproj --no-restore",
    "frontend": "npx tsc --noEmit"
  }
}
```

---

## Phase 3: When to Run

### Pre-flight: DBScripts check
Before running any build, check for unapplied database migrations:
```
1. Scan for DBScripts/ folder in the project
2. Compare scripts against .claude/idev/db-preflight/applied.json
3. If unapplied scripts exist:
   → WARN: "N unapplied DBScripts found — builds may fail with 'Invalid object name' errors"
   → List the unapplied scripts
   → Ask user: apply first, or proceed with build anyway?
4. This prevents the recurring 500 errors from missing schema changes
```
The db-preflight skill provides the full scanning and error-mapping logic.
build-check invokes it as a lightweight pre-flight, not a full replacement.

### After creating a NEW feature (multi-file):
```
1. Wait until ALL files are created (entity, DTOs, service, controller, etc.)
2. Run db-preflight pre-flight (check for unapplied DBScripts)
3. Run the backend build command
4. If frontend files were also created, run frontend type-check
5. Report results: success or list of errors
```

### After modifying a SINGLE file:
```
1. Determine which project the file belongs to (check file path against project roots)

From TheophilusChinomona/idev, MIT.

More from TheophilusChinomona/idev