vibe-coder-kit

Systematic code review skill covering both requesting a review (pre-commit checklist) and receiving and responding to review feedback. Checks code quality, security, test coverage, architectural alignment, and documentation before any code is committed.

Before committing to an implementation plan, run this skill to stress-test the proposed architecture. Catches over-engineering, circular dependencies, missing failure modes, security gaps, and scalability cliffs — before any code is written. Acts as a "second eye" on the plan.

Periodically scan project dependencies for security vulnerabilities, outdated packages, and unused dependencies. Produces a prioritized action report. Run before every major release and at least once per month.

After any significant code change — new feature, API modification, config change, or architectural refactor — run this skill to identify which documentation files are now stale and update them. Keeps docs and code from drifting apart.

Manages all git operations (commit, push, branch management, PR creation) in a standardized, safe, and consistent way. Automatically runs the code-review skill before any commit. Enforces Conventional Commits standard. Handles the full lifecycle: branch → review → commit → push → PR.

When something breaks in production: triage the severity, gather evidence, identify root cause, deploy a fix or mitigation, and write a post-mortem. Provides a calm, structured process for high-stress moments.

Use this skill whenever you learn something important during a conversation: a key architectural decision, a project-specific convention, a bug root-cause, a 3rd-party API quirk, or any fact that would help a future agent avoid re-doing the same research. Writes structured entries to the project's knowledge base so that context persists across conversations and agents.

Run this skill at the very start of any new conversation or agent session before writing a single line of code. It loads the project's architectural decisions, conventions, known gotchas, and current task status so the agent operates with full context — not as a blank slate.

Before writing any implementation code, define the acceptance criteria and test cases that the code must satisfy. Agents then write code to pass these tests — not to match a vague description. Eliminates "it works on my machine" and "I think this is what you wanted" outcomes.