pre-commit-check

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.