review-tui
Comprehensive BubbleTea TUI code review for terminal applications. Use when reviewing charmbracelet/bubbletea, lipgloss, bubbles, or Wish SSH code; optionally reviews each area concurrently.
git clone --depth 1 https://github.com/existential-birds/beagle /tmp/review-tui && cp -r /tmp/review-tui/plugins/beagle-go/skills/review-tui ~/.claude/skills/review-tuiSKILL.md
# TUI Code Review
## Arguments
- `--parallel`: Review each technology area concurrently if the agent supports it (see Step 6)
- Path: Target directory (default: current working directory)
## Gates (sequence)
Advance only when each **pass condition** is true (reduces scope drift and unsubstantiated blocking claims):
| Gate | Pass condition |
|------|----------------|
| **G1 — Scope** | Step 1 produced a concrete list of target `.go` paths (from the git command or an explicit user path). If the list is empty, you **stopped** for scope clarification **or** recorded an agreed non-git scope (e.g. single file/dir) before reviewing. |
| **G2 — Skills before review** | [review-verification-protocol](../review-verification-protocol/SKILL.md), [go-code-review](../go-code-review/SKILL.md), and [bubbletea-code-review](../bubbletea-code-review/SKILL.md) are loaded; Step 4 conditionals (tests → [go-testing-code-review](../go-testing-code-review/SKILL.md), Wish → [wish-ssh-code-review](../wish-ssh-code-review/SKILL.md)) are loaded **before** Step 5. |
| **G3 — Evidence for Critical/Major** | Each Critical/Major finding cites **file path + line** (or a short quoted snippet) from the **opened** source—not from diff hunks alone. |
| **G4 — Pre-output hygiene** | Each retained finding was checked against Step 7 **and** the loaded verification protocol **before** writing the Issues section. |
Do not start Step 5 until **G2** passes. Do not publish Critical/Major until **G3** and **G4** pass.
## Step 1: Identify Changed Files
```bash
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.go$'
```
## Step 2: Detect Technologies
```bash
# Detect BubbleTea (required for TUI review)
grep -r "charmbracelet/bubbletea" --include="*.go" -l | head -3
# Detect Lipgloss styling
grep -r "charmbracelet/lipgloss\|lipgloss\.Style" --include="*.go" -l | head -3
# Detect Bubbles components
grep -r "charmbracelet/bubbles\|list\.Model\|textinput\.Model\|viewport\.Model" --include="*.go" -l | head -3
# Detect Wish SSH server
grep -r "charmbracelet/wish\|ssh\.Session" --include="*.go" -l | head -3
# Check for test files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '_test\.go$'
```
## Step 3: Load Verification Protocol
Load the **[review-verification-protocol](../review-verification-protocol/SKILL.md)** skill and keep its checklist in mind throughout the review.
## Step 4: Load Skills
Load each applicable skill below (open its `SKILL.md` and follow it).
**Always load:**
- [go-code-review](../go-code-review/SKILL.md)
- [bubbletea-code-review](../bubbletea-code-review/SKILL.md)
**Conditionally load based on detection:**
| Condition | Skill |
|-----------|-------|
| Test files changed | [go-testing-code-review](../go-testing-code-review/SKILL.md) |
| Wish SSH detected | [wish-ssh-code-review](../wish-ssh-code-review/SKILL.md) |
## Step 5: Review Focus Areas
### Model/Update/View (Elm Architecture)
- [ ] Model is immutable (Update returns new model)
- [ ] Init returns proper initial command
- [ ] Update handles all message types
- [ ] View is pure function (no side effects)
- [ ] tea.Quit used correctly for exit
### Lipgloss Styling
- [ ] Styles defined once at package level
- [ ] Styles not created in View function
- [ ] Colors use AdaptiveColor for light/dark themes
- [ ] Layout responds to WindowSizeMsg
### Component Composition
- [ ] Sub-component updates propagated
- [ ] WindowSizeMsg passed to resizable components
- [ ] Focus management for multiple components
- [ ] Clear state machine for view transitions
### SSH Server (if applicable)
- [ ] Host keys persisted
- [ ] Graceful shutdown implemented
- [ ] PTY window size passed to TUI
- [ ] Per-session Lipgloss renderer
## Step 6: Review
**If the agent supports subagents**, dispatch one per technology area in parallel; **otherwise** run the areas sequentially. Either path produces identical output.
**Sequential (default, and the fallback when subagents are unavailable):**
1. Load applicable skills
2. Review Go code quality
3. Review BubbleTea patterns (Model/Update/View)
4. Review Lipgloss styling
5. Review component composition
6. Review SSH server (if applicable)
7. Consolidate findings
**Parallel (`--parallel`, only if the agent supports subagents):**
1. Detect all technologies upfront
2. Dispatch one subagent each for: Go quality, BubbleTea, SSH
3. Wait for all subagents
4. Consolidate findings
## Step 7: Verify Findings
Before reporting any issue:
1. Re-read the actual code (not just diff context)
2. For "unused" claims - did you search all references?
3. For "missing" claims - did you check framework/parent handling?
4. For syntax issues - did you verify against current version docs?
5. Remove any findings that are style preferences, not actual issues
## Step 8: Review Convergence
### Single-Pass Completeness
You MUST report ALL issues across ALL categories (style, logic, types, tests, security, performance) in a single review pass. Do not hold back issues for later rounds.
Before submitting findings, ask yourself:
- "If all my recommended fixes are applied, will I find NEW issues in the fixed code?"
- "Am I requesting new code (tests, types, modules) that will itself need review?"
If yes to either: include those anticipated downstream issues NOW, in this review, so the author can address everything at once.
### Scope Rules
- Review ONLY the code in the diff and directly related existing code
- Do NOT request new features, test infrastructure, or architectural changes that didn't exist before the diff
- If test coverage is missing, flag it as ONE Minor issue ("Missing test coverage for X, Y, Z") — do NOT specify implementation details like mock libraries, behaviour extraction, or dependency injection patterns that would introduce substantial new code
- Typespecs, documentation, and naming issues are Minor unless they affect public API contracts
- Do NOT request adding new dependencies (e.g. Mox, tetag and push a release after the release PR is merged
create a release PR (auto-detects previous tag)
Guides architectural decisions for Deep Agents applications. Use when deciding between Deep Agents vs alternatives, choosing backend strategies, designing subagent systems, or selecting middleware approaches.
Reviews Deep Agents code for bugs, anti-patterns, and improvements. Use when reviewing code that uses create_deep_agent, backends, subagents, middleware, or human-in-the-loop patterns. Catches common configuration and usage mistakes.
Implements agents using Deep Agents. Use when building agents with create_deep_agent, configuring backends, defining subagents, adding middleware, or setting up human-in-the-loop workflows.
Guides architectural decisions for LangGraph applications. Use when deciding between LangGraph vs alternatives, choosing state management strategies, designing multi-agent systems, or selecting persistence and streaming approaches.
Reviews LangGraph code for bugs, anti-patterns, and improvements. Use when reviewing code that uses StateGraph, nodes, edges, checkpointing, or other LangGraph features. Catches common mistakes in state management, graph structure, and async patterns.
Implements stateful agent graphs using LangGraph. Use when building graphs, adding nodes/edges, defining state schemas, implementing checkpointing, handling interrupts, or creating multi-agent systems with LangGraph.