peterkrueck/Claude-Code-Development-Kit

# Background Remove — Local AI Background Removal

Remove backgrounds from images using rembg (local, offline, no data sent externally). Outputs RGBA PNG with proper transparency.

## Input

Arguments after `/bg-remove`:
- **Source image path** (required) — path to the image
- **`--trim`** (optional) — auto-trim transparent padding after removal
- **`--output <path>`** (optional) — custom output path. Default: same directory, `<name>-transparent.png`

Examples:
- `/bg-remove assets/character/mascot.png`
- `/bg-remove image.png --trim`

# Context7 Guidance — Current Docs Over Training Data

The kit ships the Context7 plugin permission so you can pull **current** documentation at the version the project actually uses. Training data drifts: APIs get deprecated, defaults change, config keys get renamed. When the question is about a real library, fetch the docs — don't answer from memory.

## When to Use

Reach for Context7 when the user:

- Names a specific library, framework, SDK, or cloud service (common web frameworks, APIs, and cloud services — even ones you "know")
- Asks a setup or configuration question ("how do I wire up X middleware?")
- Plans a version migration ("upgrading to vN — what changed?")
- Is debugging library-specific behavior (an error, a deprecation, an unexpected default)
- Wants code that calls a third-party API — verify the signature before writing it

# Deploy — Safe Deployment Pipeline

<!-- ============================================================
     TEMPLATE: Customize this skill for your deployment pipeline.
     Replace every [PLACEHOLDER] and every commented "CUSTOMIZE"
     block with your actual commands. Delete the patterns you
     don't use (shadow/canary is optional). The structure —
     discover → gate → deploy → report — is the part worth keeping.
     ============================================================ -->

Pipeline shape: **discover targets → fail-stop gate → deploy → report-only checks**. The default scope is the whole project; module-level targeting is optional (see Target Discovery).

## Input

# Image Edit — Crop, Resize & Transform

Precision image manipulation using Python/Pillow. This skill exists because macOS `sips` has unreliable crop offset behavior and visual inspection alone leads to bad coordinates — images often have hundreds of pixels of invisible padding that throws off naive crops.

## Setup

The scripts need Pillow and numpy. Create a temp venv on first use:

```bash
python3 -m venv /tmp/imgcrop && /tmp/imgcrop/bin/pip install Pillow numpy -q
```

This only needs to happen once per session. The venv at `/tmp/imgcrop` persists until reboot.

# AI Image Generation (Gemini)

Generate image variations using Google's Gemini image generation model with reference images for style and character consistency. The model supports up to 14 reference images per request and can maintain consistency across multiple characters.

## Prerequisites

- **GEMINI_API_KEY** environment variable must be set
  - Get a key at https://aistudio.google.com/apikey
  - The key needs billing enabled for image generation (~$0.067/image at 1K resolution)
- **Deno** runtime installed (for the generation script)

## Workflow

### Step 1 — Understand what the user wants

# Review Work — Automated Code Review

Review uncommitted code changes using **Claude sub-agents** as independent reviewers. The invoking agent (you) triages the diff and decides who reviews; reviewers self-prime via `/prime`, verify API/library claims via Context7, and report against `progress.md` intent.

This skill is run **by an AI**, not by a human — use judgment about the change you just made. Don't apply a fixed rubric mechanically. Zero external dependencies: reviewers are Claude sub-agents.

## Process

### Step 1: Capture the Diff (+ Tests)

Run these and save the output:

```bash
git diff --stat HEAD

# Second Opinion — OpenAI Codex

Get an independent second opinion from OpenAI's Codex CLI. It uses Codex's default model — a completely different architecture and training run from Claude, which makes it genuinely useful for catching blind spots, validating reasoning on edge cases, or surfacing trade-offs Claude would miss (Claude's own errors tend to be invisible to Claude).

Codex has full read access to the project — it can read files, grep code, and explore the codebase. Its project instructions (`AGENTS.md` at the repository root) tell it to prime itself on the key docs before answering. You provide the specific question and any focused context; Codex handles the rest.

This is the **default** second-opinion engine. For a Gemini second opinion specifically, the user invokes the separate `second-opinion-gemini` skill ("ask Gemini"). When the user says "ask both", run this skill and that one, then synthesize all three views (yours + Codex + Gemini).

## When to Use

- Architecture decisions with real trade-offs
- Debugging where you've been going in circles
- Code review on tricky logic or subtle edge cases
- Validating your reasoning before the user acts on it

# Second Opinion — Gemini (explicit / fallback engine)

Get an independent second opinion from Google's Gemini Pro. This model has a completely different architecture and training from Claude, making it genuinely useful for catching blind spots, validating reasoning on edge cases, or surfacing trade-offs you might miss.

**This is NOT the default second-opinion engine.** Generic second-opinion requests route to the default `second-opinion` skill. Use this Gemini skill only when:
- The user explicitly asks for Gemini ("ask Gemini", "Gemini's take", "what does Gemini think").
- The user says "ask both" — run this *and* the default `second-opinion` skill, then synthesize all three views (yours + the default engine's + Gemini's).
- The default engine was reported unavailable and the user wants the alternate independent voice.

Gemini has full read access to the project — it can read files, grep code, and explore the codebase. Its project instructions (GEMINI.md) tell it to prime itself on the key docs before answering. You provide the specific question and any focused context; Gemini handles the rest.

## Model selection

Pinned to `gemini-3.1-pro-preview` by default for quality (smaller models give weaker second opinions; not worth the false confidence they create).

# Update Docs — Documentation Maintenance

Keep project documentation synchronized with the current state of the code. Updates the core `docs/ai-context/` files and `CLAUDE.md` as needed.

## Core Documentation Principle

**Compress aggressively — the default for every line is DELETE.** A line earns its place only when it encodes something an AI agent cannot derive from the code, git log, or spec.md. Every run prunes as much as it adds.

**Document current "is" state only — never reference legacy implementations or what changed.**

- Write as if the documentation is being read for the first time
- No "previously", "was changed from", "used to be", or "improved" language
- No migration notes or upgrade paths within the docs themselves
- If something was removed, remove it from docs — don't leave a "removed X" note