gopher-ai

Address pull request review feedback from humans or bots. Use when existing comments, requested changes, unresolved review threads, or CodeRabbit/codex review findings need code fixes, verification, push updates, and thread resolution. SKIP fresh code-review requests with no existing feedback; use review-deep.

Take a GitHub issue from implementation to merged PR. Use for 'complete issue #N', 'finish this issue end-to-end', or fully autonomous issue-to-merge requests. SKIP issue startup without merge intent; use start-issue.

Run end-to-end PR verification with browser testing. Use before merge or in fix-and-ship mode when the user asks to verify a PR, run E2E, browser-test, or visually check UI changes. SKIP backend-only checks with no browser/UI path; use review-deep or ship as appropriate.

Start implementation of a GitHub issue: fetch context, prepare worktree flow, implement with TDD, verify, and submit PR. Use for 'start issue #N', issue URLs, or requests to begin issue work. SKIP fully autonomous issue-to-merge requests; use complete-issue.

Start issue work in a new tmux window with its own worktree. Use when the user has tmux running and wants issue startup to continue outside the current session. SKIP when not inside a tmux session ($TMUX unset) or when the user wants to work in the current session; use start-issue directly.

Ship a PR end-to-end: verify locally, push, create/update the PR, watch CI, handle review feedback, and merge without admin override. Use for 'ship', 'ship it', or 'push and merge'. SKIP if the user only wants a PR opened; use `create-pr`.

Deep-review a PR or branch with issue and repo context, then fix actionable findings. Use for 'review my changes', 'check this PR', or post-implementation quality/spec review requests. SKIP existing human/bot review comments that need replies/thread resolution; use address-review.

Generate images via the Google Gemini API. Supports GA model selection, aspect ratios, resolutions (512/1K/2K/4K), batch generation, image editing. Trigger when user wants AI-generated visual output: image, picture, photo, graphic, illustration, banner, logo, icon, thumbnail, header, hero image. SKIP screenshot inspection or image analysis with no generation/edit request.

Get a second LLM opinion via codex/gemini/ollama on architectural decisions, design trade-offs, library or framework choices, and security-sensitive code. Use when uncertain on a 'should I' call, want a sanity check before a high-stakes commit, or facing a contested code review. SKIP for routine questions where one model's answer is clearly sufficient.

htmx for Go/templ apps: hx-* attributes, swap strategies, triggers, OOB updates, SSE, WebSockets, forms, redirects, debounce, server integration. Trigger when user writes or pastes templates containing hx-* attributes, asks about HTMX swaps/triggers/OOB updates, or wires HTMX to a Go handler. SKIP generic web, fetch/AJAX, or templUI questions with no htmx context.

Create, remove, or prune git worktrees for issue/PR isolation. Use when the user asks for a worktree, wants an isolated workspace per issue, or wants completed worktrees cleaned up.

Profile and optimize Go performance: pprof CPU/memory/block/mutex profiles, allocation analysis, escape analysis, sync.Pool, GOGC/GOMEMLIMIT tuning, benchmarks with -benchmem, PGO workflow, execution tracing. Use when user asks 'why is this slow', 'is this allocating', mentions pprof/profiling, runs benchmarks, or needs to reduce p99 latency. SKIP for general Go idioms — use `go` skill.

Idiomatic Go: interfaces, error handling, concurrency, testing, package layout, and debugging. Use when the user writes, reviews, or debugs Go code, or asks any open Go question that doesn't fit a more specific child skill. SKIP for Go performance/profiling work (use go-profiling-optimization) and explicit Gopher Guides training/API requests (use gopher-guides).

Authoritative Gopher Guides Go training materials accessed via REST API/cache wrapper. Use when reviewing Go code and the user explicitly asks 'what would Gopher Guides recommend?', 'how do professionals do this?', or wants training-material-backed practices/examples/audit. SKIP for general Go idiom questions handled by the `go` skill.

templUI component library for Go templ apps. templUI is vanilla JavaScript only - zero JS frameworks (per templui.io). Covers Script() setup, Go variable interpolation into inline JavaScript, HTML-to-templ conversion, HTMX integration, and optional Alpine.js as a separate app-level state layer. Use when user pastes templUI/templ code, builds templUI components, asks 'how do I add an icon/button/dialog/dropdown' in templ, or interpolates Go state into client-side scripts. SKIP generic htmx issues with no templUI/component context.

Create a git commit with an auto-generated conventional message from staged changes. Use for 'commit', 'save my work', or 'make a commit'. Does not push or open PRs; use `create-pr` for PR-only flow and `ship` for verify+push+merge.

Create a pull request using the repo PR template. Use when the user wants to open or submit a PR without immediately merging it. SKIP for end-to-end ship flows; use `ship` instead.

Validate bash and shell code blocks embedded in plugin commands and skills .md files. Catches syntax errors, undefined variables, unclosed quotes, missing semicolons. Use when editing files under plugins/*/commands/*.md or plugins/*/skills/*/SKILL.md, when creating a new command or skill in this repo, or when CI fails on a markdown bash-block syntax check.

Tailwind CSS v4 guidance: utility-first patterns, @theme directive for color/spacing/font config, @source for content paths, dark mode, responsive design, oklch colors, custom variants, v4 vs v3 differences. Use when user writes Tailwind utility classes, configures @theme or @source in CSS, asks about v4 syntax, or styles components.

WHEN: User asks for a code quality audit, code review, or wants to find code smells, anti-patterns, or non-idiomatic Go code in their project. Also when asked "how good is this code?" or "audit my code." WHEN NOT: When the user wants to fix bugs, run tests, or just lint (use go-lint-audit for linting).

WHEN: User wants to validate their Go project against Gopher Guides coding standards, check documentation completeness, review concurrency patterns, or validate project structure. WHEN NOT: Quick one-off Go questions (use the gopher-guides skill), or linting (use go-lint-audit).

WHEN: User wants to improve test coverage, find untested code, generate test stubs, or asks "what tests am I missing?" or "how do I improve coverage?" for a Go project. WHEN NOT: When running existing tests, debugging test failures, or benchmarking.

WHEN: User wants an automated first-pass code review on a PR, diff, or set of changes. Also when asked "review this PR", "review my changes", or "what do you think of this code?" WHEN NOT: Full project audits (use go-code-audit), or when user just wants linting (use go-lint-audit).

WHEN: User wants to run linting on their Go project, understand lint findings, improve their golangci-lint configuration, or asks "what's wrong with my code?" from a linting perspective. WHEN NOT: Deep code quality audit (use go-code-audit), or auto-fixing lint issues (use /lint-fix command).