chebizarro

Analyze and document codebase architecture: dependency graphs, module boundaries, API surfaces, tech debt. Use when: (1) user asks 'how is this codebase structured', (2) onboarding to a new project, (3) planning a large feature that spans modules, (4) identifying tech debt or coupling issues. NOT for: specific code changes (use refactor), reviewing a PR (use code-review).

Structured code review for PRs, diffs, or changed files. Use when: (1) reviewing a pull request, (2) checking code quality before merge, (3) auditing changes for correctness/security/performance, (4) user asks to review code or a diff. NOT for: debugging failures (use debug), running tests (use verify), or general code reading.

Manage dependencies: audit outdated packages, resolve conflicts, evaluate alternatives, handle breaking upgrades. Use when: (1) updating dependencies, (2) resolving version conflicts, (3) checking for vulnerabilities in deps, (4) evaluating a new library. NOT for: general code changes, security vulnerabilities in own code (use security-audit).

Generate or update documentation: API docs, README, CHANGELOG, ADRs. Use when: (1) user asks to document code, (2) writing a README for a new project, (3) updating docs after a change, (4) creating architecture decision records. NOT for: inline code comments (just add them), reviewing docs (use code-review).

Advanced git operations: rebase strategies, cherry-pick workflows, bisect automation, worktree management, conflict resolution, branch cleanup. Use when: (1) complex git operations beyond basic add/commit/push, (2) resolving merge conflicts, (3) reorganizing commit history, (4) managing multiple working branches. NOT for: basic git (use git tools directly), GitHub API operations (use github skill).

Language-specific idiom guides for Go, Python, TypeScript, Rust. Covers non-obvious patterns: project layout, error handling, testing idioms, build quirks, common pitfalls. Use when: (1) writing code in a specific language and need idiomatic patterns, (2) user asks 'what's the Go/Python/etc way to do X', (3) porting code between languages. NOT for: syntax questions (the model already knows syntax).

Performance profiling and analysis: identify hot paths, memory leaks, N+1 queries, benchmark before/after. Use when: (1) user reports slowness, (2) optimizing a critical path, (3) benchmarking changes, (4) diagnosing memory issues. NOT for: general debugging (use debug), code review (use code-review).

Refactor code: extract functions, rename symbols, move modules, split files, inline variables, reduce duplication. Use when: (1) user asks to refactor, (2) code needs restructuring without behavior change, (3) extracting reusable components, (4) cleaning up after a feature is stable. NOT for: adding features (that's coding), fixing bugs (use debug), style-only changes.

Complete closed-loop debugging workflow for LLM agents working on nostrc GTK applications. Covers the full cycle: identify bug → write/run test → debug with GDB/LLDB → fix code → rebuild → verify via Broadway UI → iterate. Integrates the Broadway and GDB skills into a unified methodology that an LLM can execute deterministically.

Using GTK Inspector for debugging widget trees, CSS styling, GObject lifecycle, signal handlers, layout constraints, and rendering performance in gnostr and other nostrc GTK4 apps. Covers both interactive use via Broadway/Playwright and programmatic use in tests and debug builds.

Closed-loop UI debugging for GTK4 applications using the Broadway HTML5 backend and Playwright MCP. Covers persistent browser sessions across rebuilds, GTK test utilities for widget manipulation, accessibility snapshot inspection, and rapid iteration on visual/interaction bugs in gnostr, gnostr-signer, and other nostrc GTK apps.

Debug memory errors, segfaults, and logic bugs in nostrc GTK applications using GDB (Linux) and LLDB (macOS). Covers ASan-assisted debugging, GObject reference counting, signal handler tracing, NDB transaction analysis, and structured workflows for LLM-driven crash diagnosis.