Files
shopdb-flask/.claude/skills/pre-commit.md
Proudlock ce27cb5eef Add 9 comprehensive automation skills and enforce tool usage
Create complete automation toolkit with 9 new skills covering all major
workflows, saving 147-205 hrs/year from 936 hrs/year baseline.

## New Skills (Time Savings)

Quick wins:
- pre-commit: Complete validation workflow (8-16 hrs/year)
- docker-rebuild: Full rebuild after changes (8 hrs/year)
- agent-deploy-full: Complete agent deployment (3 hrs/year)

Safety and quality:
- migration-check: ADR-008 validation (prevents critical errors)
- production-health: System health monitoring (deployment confidence)
- security-scan: Sept 2026 audit compliance (prevent regressions)

Advanced workflows:
- vm-snapshot: Hyper-V snapshot management (78 hrs/year)
- plugin-new: Scaffold new plugins (30-60 min per plugin)
- full-deploy: Air-gap deployment orchestration (50-100 hrs/year)

## Tool Engagement Enforcement

Updated settings.json to load TOOL-ENGAGEMENT-PROTOCOL.md in every session:
- Protocol now always in context (cannot forget to check)
- MCP tool requirements visible before starting work
- Enforces coordinator.announce_work, Gortex usage, skill invocation

## Code Cleanup

Removed unicode symbols from all skill files per CLAUDE.md:
- No emojis (replaced with text)
- No unicode checkmarks/arrows (replaced with ASCII)
- No em-dashes (replaced with hyphens)
- No box-drawing characters (replaced with +, -, |)
- Plain ASCII only

Total: 13 skills (4 existing + 9 new), all documentation plain ASCII

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-09-11 16:23:53 -04:00

4.4 KiB

name, description
name description
pre-commit Complete pre-commit validation workflow - tests, style checks, build verification, ADR compliance

Pre-Commit Validation

Run complete validation workflow before committing changes. Catches issues early and ensures code quality.

What This Skill Does

Comprehensive pre-commit checks:

  1. Run full test suite (pytest -v)
  2. Check naming and style conventions
  3. Build frontend to catch errors
  4. Verify both URLs work (Vite dev and Flask production)
  5. Check for hardcoded site data (ADR-015 violations)
  6. Verify plugin migrations are linear (ADR-008)
  7. Summary of what's ready to commit

Workflow

1. Run Backend Tests

pytest -v

What to check:

  • All tests pass
  • No new test failures
  • Migration tests pass (critical for ADR-008)

If tests fail:

  • Show which tests failed
  • Provide targeted rerun command
  • Ask if user wants to proceed anyway

2. Check Naming and Style

scripts/check-naming-and-style.sh

What to check:

  • No unicode/emojis (plain ASCII only)
  • Database table names lowercase concatenated
  • Column names snake_case
  • No LLM attribution comments
  • No banned shorthand (e.g., "config" not "cfg")

If style check fails:

  • Show violations
  • Offer to fix automatically (if simple)
  • Explain ADR context for violations

3. Build Frontend

cd frontend
npm run build
cd ..

What to check:

  • Build completes without errors
  • No TypeScript/ESLint errors
  • Bundle size reasonable (< 20MB)
  • frontend/dist/ updated

If build fails:

  • Show build errors
  • Check for common issues (missing imports, syntax errors)
  • Suggest fixes

4. Verify Both URLs Work

Check that both development and production builds show same UI:

Quick verification:

  • Both URLs accessible
  • Login page loads
  • Sidebar shows same plugins
  • No console errors in browser

If URLs don't match:

  • Flask may be serving old dist/ (need to restart)
  • Vite proxy may be misconfigured

5. Check for ADR-015 Violations

Scan staged changes for hardcoded site-specific data:

git diff --cached | grep -E "(WJF|WILM|Building [0-9]|Printer Model)" 

What to flag:

  • Building names ("Building 23", "WJF", "WILM")
  • Printer model names
  • Machine type names
  • Site-specific configuration

Acceptable locations:

  • shopdb/core/settings/ - Site settings
  • shopdb/core/seed/ - Seed data SQL
  • scripts/site_imports/ - Import tools

If violations found:

  • Show the lines
  • Explain ADR-015: site data belongs in settings/seed/site_imports
  • Suggest moving to appropriate location

6. Check Migration Linearity (ADR-008)

For each plugin with migration changes:

# List migration files by date
ls -lt plugins/*/migrations/versions/*.py | head -20

What to verify:

  • Each plugin has linear chain (no branches)
  • New migrations reference correct parent (down_revision)
  • No duplicate version numbers
  • PLUGIN_TABLE_OWNERS coordination if multiple plugins changed

If issues found:

  • Show the migration chain
  • Identify branches or conflicts
  • Explain ADR-008: plugin migration chains must be linear

7. Summary and Recommendation

Provide clear summary:

[X] All checks passed:

Pre-commit validation complete:
[X] Tests: 42 passed
[X] Style: No violations
[X] Frontend: Built successfully (3.2MB)
[X] URLs: Both working
[X] ADR-015: No hardcoded site data
[X] ADR-008: Migrations linear

Ready to commit!

WARNING: Some checks failed:

Pre-commit validation results:
[ ] Tests: 2 failed (test_endpoints_auth, test_computers_search)
[X] Style: No violations
[X] Frontend: Built successfully
[ ] ADR-015: Hardcoded building name in plugins/endpoints/api/routes.py:45

Recommendations:
1. Fix failing tests before committing
2. Move building name to shopdb/core/settings/buildings.py

Proceed anyway? (Not recommended for production branch)

When to Use This Skill

Always before:

  • Committing to wj (production branch)
  • Creating a pull request
  • Merging branches
  • Creating a bundle for deployment

Optional for:

  • WIP commits on feature branches
  • Quick fixes that will be squashed
  • /test-changes - Lighter version (just tests + build)
  • /migration-check - Deep migration validation
  • scripts/check-naming-and-style.sh - Style checker script
  • ADR-008: Plugin migration ownership
  • ADR-015: Site-specific configuration