I Spent 4,500+ Hours Coding with AI. This Is the Claude Code Setup I Ended Up With.

The engineering instructions, curated skills, and three-stage review workflow I use to keep AI-assisted development fast, controlled, and verifiable.

Table of Contents

• 1. The Story Behind This Setup
• 2. Core Engineering Philosophy
• 3. The Three-Prompt Review Workflow
• 4. Curated Skills & Upstream Attribution
  • Superpowers (Jesse Vincent)
  • Ponytail (Dietrich Gebert)
  • I Have ADHD (ayghri)
• 5. Repository Structure
• 6. Adoption Guide
• 7. Credits

1. The Story Behind This Setup

This repository is not a speculative prompt collection.

It is the setup I arrived at after spending an estimated 4,500+ hours actively building, debugging, refactoring, and deploying software alongside AI coding agents.

[!NOTE] The 4,500+ hours figure is a personal working estimate based on roughly six productive hours per day over a little more than two years of daily engineering work. It is not tracked automated telemetry.

The Tooling Journey

My day-to-day workflow evolved across multiple waves of AI developer tooling:

• Cursor for inline completions and multi-file agent edits.
• Claude Code CLI for autonomous terminal-driven task loops and micro-diff inspections.
• Antigravity IDE & Gemini CLI for multi-agent workflows, skill architectures, and background automations.
• Codex, OpenCode, and Amazon Q, exploring how different models reason about API contracts, context limits, and tool-calling.

I do not claim equal usage across all these platforms. What became clear through thousands of hours across all of them was a universal pattern:

Unconstrained AI coding agents fail predictably.
They suffer from confirmation bias, over-engineer simple utilities into speculative generic frameworks, write code against hallucinated APIs, quietly reformat adjacent files, and declare "tests pass!" without actually executing them.

This repository represents the guardrails, prompts, and behavioral directives I built to reduce those failure modes. It is a practical, personal setup designed for real production work.

2. Core Engineering Philosophy

Note that the approval gates in CLAUDE.md are behavioral instructions the agent follows, not mechanically enforced security boundaries; real enforcement comes from your coding tool's native permission settings.

3. The Three-Prompt Review Workflow

Rather than allowing an agent to jump straight from user prompt to code editing, non-trivial engineering tasks follow a structured progression:

flowchart TD
    User([Task Request]) --> Classify{Task Lifecycle}
    Classify -->|Spike / Bounded| Quick[Direct TDD & Minimal Fix]
    Classify -->|Architectural / Breaking| Brainstorm[Brainstorm & Spec Approval]
    Brainstorm --> P1[1. Planning Prompt]
    P1 -->|Inspects repo & drafts plan| Plan[Implementation Plan]
    Plan --> P2[2. Critical Plan Review]
    P2 -->|Red-teams assumptions in fresh context| RevPlan[Approved Plan]
    RevPlan --> Code[Implementation & TDD]
    Code --> P3[3. Production Readiness Review]
    P3 -->|Audits git diff, staged files & runs tests| Done([Reviewed & Ready to Merge])

Lifecycle Routing

• Spike: 1 cheap probe command -> 2-sentence finding.
• Bounded: Covers isolated repairs and 1-3 file non-breaking enhancements. Propose in chat for approval first if altering public API contracts, database schemas, or financial logic; otherwise execute autonomously.
• Architectural: Subsystems, multi-service features, or breaking contract changes -> Strictly executes the 3-stage review pipeline below.

Stage 1: Planning (prompts/planning.md)

• Job: Inspect the repository, map requirements to acceptance criteria, and define how each criterion will be verified.
• Safety Boundary: Hard instruction: "Stop once the plan is saved and wait for my approval. Do not touch implementation code."
• What It Prevents: Premature code generation against hallucinated file paths, wrong package versions, or incorrect architectural assumptions.
• Visual Architecture Modeling: For smaller, direct flows, inline Mermaid diagrams work well. But once an architecture involves multiple services, cross-cutting class dependencies, or evolving business logic, text alone can obscure integration blind spots. In those scenarios, I generate a visual model before locking in an approach. For creating clean, editorial-grade architecture diagrams, I frequently reference Cathryn Lavery's diagram-design.

Stage 2: Critical Plan Review (prompts/critical-plan-review.md)

• Job: Act as an independent senior principal engineer red-teaming the plan before a single line of code is written. Run in a fresh context or subagent to reduce confirmation bias.
• Focus: Identifies race conditions, missing error boundaries, timeout policies, idempotency risks, and over-engineering.
• The YAGNI Brake: Explicitly forces the model to distinguish genuine failure modes from low-probability hypothetical edge cases, stopping speculative complexity before it starts.
• What It Prevents: The agent confidently executing an architectural flaw that would require a complete rewrite later.

Stage 3: Production Readiness Review (prompts/production-readiness-review.md)

• Job: Audit the raw git state (git status, git diff, git diff --cached, and untracked files) against the approved plan. Run in a fresh context or subagent.
• Focus: Hunts for logical bugs, null-pointer boundaries, integration breaks, secrets leakage, and uncommitted artifacts.
• Remediation Rule: Fix confirmed issues with the smallest targeted edit. If a fix requires architectural changes or alters public contracts, it must pause and ask first.
• What It Prevents: Merging orphaned untracked files, broken staged diffs, weakened test assertions, or cosmetic reformatting regressions.

4. Curated Skills & Upstream Attribution

Rather than accumulating dozens of overlapping, noisy plugins, this setup incorporates a lean, carefully selected collection of open-source skill packs.

[!TIP] Global by Design: CLAUDE.md is designed as a global instruction set (used as your global ~/.claude/CLAUDE.md, or adapted for GEMINI.md / agent system prompt) to establish baseline engineering behavior across every project you touch. The three review prompts in prompts/ are your personal operational templates, used as prompt suffixes during non-trivial tasks rather than committed to client codebases.

Superpowers

Repository: obra/superpowers by Jesse Vincent (Obra)
License: MIT

Jesse Vincent's superpowers suite provides foundational process discipline for agentic development: