mcpField
P
pre-commit-check

pre-commit-check

github.com/loxosceles-devTesting & quality101 installs
Repository

About pre-commit-check

A pre-commit review skill for developers that defines three required checks for staged files: security, code quality, and post-push risks. It also specifies verification steps and a consistent format for reporting findings.

Key features

  1. 01Security scan for staged files
  2. 02Code quality review criteria
  3. 03Build, test, and lint checks
  4. 04Infrastructure and runtime verification
  5. 05Standardized findings format

Use cases

  1. 01Checking staged changes before a commit
  2. 02Finding secrets in pending changes
  3. 03Reviewing code structure and error handling
  4. 04Verifying deployments and runtime behavior

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/loxosceles-dev/dev-skills --skill pre-commit-check

After installing, type/pre-commit-checkin Claude Code to confirm it loaded.

Details

From the project README

Pre-Commit Check

This is a strict guideline. Follow these rules exactly.

Before any commit, review only the staged files against three gates. All three must pass.

Gate 1: Security

Delegate to the security-checklist skill. Scan staged files for:

  • Hardcoded secrets, API keys, tokens, passwords
  • .env files with real values
  • Credentials, private keys, connection strings

If found: STOP. Do not proceed to Gate 2.

Gate 2: Code Quality

Review staged files against core-principles and standard best practices:

  • DRY — Does this change duplicate logic that already exists elsewhere? Check for copy-pasted code, repeated patterns that should be extracted.
  • Pure functions — Are helpers pure and testable? Are side effects isolated?
  • Fail fast — No silent defaults. Missing config or data should throw, not fall back.
  • Naming — Are variables, functions, and files named clearly?
  • Separation of concerns — Is business logic mixed with I/O or presentation?
  • Error handling — Are errors caught at the right level with actionable context?
  • Dead code — Are there leftover console.log, commented-out blocks, or unused imports?

Report issues. Minor style nits can be noted but should not block the commit.

Gate 3: Will It Break?

Before committing, ask: what will break after push that unit tests won't catch?

Unit tests run automatically — this gate is about the things they miss: runtime environment issues, missing permissions, misconfigured infrastructure, broken deployments.

Always:

  • Does the code build? Run the build.
  • Do existing tests pass? Run them.
  • Are there linter errors? Run the linter.

Infrastructure code (Lambdas, CDK, SST) — this is where most post-push failures come from:

  • Deploy to dev and invoke the Lambda directly.
  • Check CloudWatch for missing environment variables, permission errors, or import failures.
  • Verify any new SSM parameters or secrets actually exist in the target environment.
  • A Lambda can pass every unit test and still fail on invoke. Always invoke it.

Frontend:

  • Does it render without console errors?
  • Does the page load in the browser?

CI-dependent changes (workflows, build configs):

  • Run the relevant step locally if possible (build command, test suite, lint).

The rule: If verification takes less than 2 minutes, do it now. Don't push and hope CI catches it.

Output

When reporting findings, use this format:

🔴 Blocked — [reason, e.g. "hardcoded API key in config.ts"]
🟡 Fix before commit — [code quality issue with file reference]
✅ Verified — [what was tested, e.g. "build passes, Lambda invoked successfully"]

Progressive Improvement

If the developer corrects a behavior that this skill should have prevented, suggest a specific amendment to this skill to prevent the same correction in the future.

Comments

Markdown supported