Ko-fi: https://ko-fi.com/s/fdb0e60135

Most Cursor and Claude Code configurations degrade to the same thing: you paste a vague system prompt, you coach the AI repeatedly through the same patterns every project, and the output is inconsistent because nothing is actually encoded anywhere permanent.

I spent a few weeks turning the patterns that work — the ones I kept re-explaining from scratch — into actual files. Proper format. The format Cursor and Claude Code expect. Drop them in, and they run.

Here is what I built and why each artifact required real iteration to get right.

The Code Reviewer Subagent

Claude Code supports subagents: .md files in .claude/agents/ with YAML frontmatter that defines a model, a description (which controls auto-delegation), and a system prompt. When you say "review my code," Claude Code reads the description field of every agent and delegates to the right one.

The code-reviewer agent's system prompt structures the output into four categories — correctness bugs, security issues (OWASP-tagged), data-loss risks, and performance problems — and requires a severity table and a merge verdict. That last part matters: without it, every review ends ambiguously and you're making the call yourself anyway.

Getting the OWASP tagging right took several iterations. The model would skip it when the issue wasn't an obvious injection or auth bypass. The fix was a constraint in the system prompt: every security finding must include an OWASP Top 10 reference or explicitly note "not mapped" with a reason. Now it does it consistently.

The other three subagents follow the same pattern:

• test-generator — detects your test framework (Vitest, Jest, pytest), reads your existing conventions, and produces zero-stub tests with real assertions. The hard part was getting it to produce runnable tests rather than placeholder structures. The system prompt now explicitly bans // TODO and pass in test bodies.
• dependency-auditor — runs native audit tools when available (npm audit, pip-audit), falls back to manual analysis with named CVE IDs. Naming real CVEs was the iteration — the model would otherwise produce vague "potential vulnerability" notes that are useless for prioritization.
• migration-runner — the one that required the most work.

The Migration Runner: Safe SQL Against a Live Database

Writing SQL migrations that are safe to run against a production database is not a one-shot problem. The failure mode is a migration that works fine on a test database and blocks the primary lock on a table with 50 million rows in production.

The migration-runner subagent analyzes lock risks per operation before generating SQL. An ADD COLUMN NOT NULL with a default blocks the table for the duration of the migration on older PostgreSQL versions. The safe version is three operations: add the column as nullable, backfill in batches, then add the constraint separately.

The system prompt encodes this specifically. When the agent sees an ADD COLUMN NOT NULL, it rewrites it into the three-step sequence automatically and explains why. Each migration also gets a working down block — not a comment saying "reverse this manually," an actual rollback script.

That rewrite logic took about an hour of iteration: getting the batch size right, handling the constraint name consistently, making the down block correct for each of the three steps independently.

The Lint Hook That Blocks via Exit 2

Claude Code hooks run shell scripts at specific points in the tool lifecycle. A PreToolUse hook fires before any Edit, Write, or MultiEdit call. If the hook exits with code 2, Claude Code blocks the edit.

The pre-commit-lint hook does exactly this: it runs ESLint on JS/TS files, Ruff on Python files, or cargo clippy on Rust files, parses the output, and exits 2 if there are problems. Claude Code sees the lint errors in the hook output and fixes them before retrying the edit.

The non-obvious part: the hook needs to handle the case where no linter is installed without blocking the edit. An uninstalled linter should exit 0 silently, not exit 2 and break everything. The lint.sh script checks for each linter before calling it and skips cleanly if it's absent.

The post-edit-test hook is the mirror: it fires after each edit, runs related tests (Vitest, Jest, or pytest, detected from the project), and prints [test-hook] PASS / FAIL / SKIP. It never exits 2 — it informs without blocking.

Wiring hooks requires merging a JSON snippet into .claude/settings.json. The pack includes both the shell scripts and the JSON snippets with the exact merge result documented.

The Skills: Protocols, Not Instructions

Skills are a newer Claude Code primitive: folders in .claude/skills/ with a SKILL.md that Claude Code reads when it auto-delegates based on the skill's description.

The two skills in the pack encode protocols rather than instructions:

• long-running-tasks — a checkpoint-based execution protocol. Before starting any multi-step task, write _state.json with the step list and current index. After each step completes, update the state file. On failure or restart, read the state file and resume from the last completed step. The skill includes a state.template.json and a _progress.log format. This is how you run a multi-hour pipeline through Claude Code without losing progress on a crash.

• api-integration — a production-grade API integration protocol covering: credential lookup from environment variables (never hardcoded), connection timeouts, exponential backoff with jitter, Retry-After header handling, idempotency keys on POST requests, circuit breaker state, and webhook signature verification. Every integration Claude Code writes when this skill is active follows the full protocol.

What This Is and Is Not

These are functional files. They work because they're built to the format Cursor and Claude Code expect — the frontmatter, the glob patterns, the hook lifecycle, the skill directory structure. Dropping them in is not a configuration step; it is the installation.

Each file represents 30–60 minutes of real iteration: writing the first version, running it against real inputs, finding the failure modes, and encoding the fixes as constraints. You are skipping that work.

This is not a prompt pack. Prompts are instructions you give the model at conversation start. These files modify how the toolchain itself behaves — which agent runs on which request, which rules attach to which files, which hooks fire at which points in the edit lifecycle.

The pack is 12 files: 4 subagents, 4 Cursor rules, 2 hook scripts + 2 JSON snippets, 2 skill folders.

If you use Cursor or Claude Code daily and want the setup to behave like a senior engineer without coaching it from scratch on every project: https://ko-fi.com/s/fdb0e60135