Claude Skill: Coding Sanity Check

Sanity-check generated code.

Prompt / skill content

App Building & Sanity Rules

Definition of ACTION: Any task involving coding, developing, programming, UI/UX designing, database architecting, DevOps/infrastructure configuration, or security engineering.

When the user's request meets the ACTION definition, apply this skill end-to-end: run the BEFORE then DURING then AFTER checklist and honor every non-negotiable below.

Phase Checklist

BEFORE ACTION

Mindset: Apply KISS, SOLID, DRY, and YAGNI (You Ain't Gonna Need It).
Debugging: Prioritize log analysis for clues before taking action or making assumptions.
Alignment: Preview roadmap and perform an architecture scan.
Research: Conduct technical discovery and a dependency audit (size, security, maintenance).
Planning: Break the request into phases and get user approval before starting.
Architecture: Update architecture and roadmap once the plan is approved.
Testing: Implement TDD upfront, pre-write backend and frontend tests where applicable.

DURING ACTION

Logging: Implement CRUD logging (INFO/WARN/ERROR) for both frontend and backend.
Security: Actively look for security gaps and close them automatically during development.
Atomic Commits: Never mix feature additions with refactors in a single commit.
Testing: Create unit tests for any new or complex logic. Add TDD cases on the fly as misses surface.
Config: Identify and manage environment variables and secrets early in the phase.

AFTER ACTION

Validation: Run linting, unit tests, and E2E tests. Ensure all pass.
Security Audit: List identified security gaps and the specific solutions implemented.
Documentation: Update README, Architecture, and Roadmap to reflect current state.
Versioning: Bump the semantic version in package.json based on the work implemented.
Reporting: Show 'Tests Passed' status, the last 7 commit hashes, the current version and state, whether we're on track with TDD, and any new proposed TDD cases for the next phase.
Handover: Provide a summary of changes and instructions for manual testing.

Sanity Rules, Detailed

1. Development Protocol (the mental model)

KISS, simplest thing that works. No cleverness for its own sake.
SOLID, single responsibility, open/closed, Liskov, interface segregation, dependency inversion.
DRY, one source of truth. Eliminate duplicated logic.
YAGNI, do not build it until the current phase needs it.
TDD lifecycle: forethink, red, green, refactor, validate, insights.
Atomic commits: one concern per commit, no mixing features and refactors.
Prompt discipline: small, scoped prompts. Minimize hallucination surface area.

2. TDD Workflow (the loop)

Round start: present forethought (what we learned plus proposed test cases).
Approval gate before any code is written.
Red, green, refactor is the coding loop.
End of round: validate all cases pass. Capture new cases discovered.
Insights feed the next round's forethought.

3. Event Logging Standard (non-negotiable)

Every system event gets a log entry plus log level.
Levels: DEBUG (dev detail) / INFO (normal flow) / WARN (recoverable anomaly) / ERROR (failure).
Backend: structlog. Frontend: loglevel, reporting to backend.
No silent failures, if it happened, it is logged.

4. Security (non-negotiable, every phase)

API keys, MCP transport, and OAuth tokens handled deliberately. Never committed.
Secrets always in .env, always validated by pydantic-settings.
Auth/authz can come later for UX, but security guardrails exist from day 1.
MCP server security: define transport layer and tool exposure rules.
pip-audit in CI and a private-key pre-commit hook, always on.
Security review is part of every after-action audit.

5. After-Action Audit (end of every phase)

Did we follow KISS / SOLID / DRY / YAGNI?
Are all events logged with correct levels?
Did any new security surface area open up?
Are all tests passing, including new cases found during dev?
Is CI green?
Did we bump the version in package.json?
Update CHANGELOG, ARCHITECTURE, ROADMAP to reflect reality.
Capture insights, seed next round's forethought.

6. Continuous Value Check (during every round)

Before adding anything: does this serve the current phase goal?
YAGNI gate: if it is not needed now, it goes to ROADMAP, not code.
Small phases, ship something real, check value, iterate.