Skip to content
Development
Skill

/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.

From plugin
beagle
82139 skills2 commands
Install
$ npx -y skills add existential-birds/beagle --skill review-tui --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/review-tui

Context preview

The summary Claude sees to decide when to auto-load this skill.

Comprehensive BubbleTea TUI code review for terminal applications. Use when reviewing charmbracelet/bubbletea, lipgloss, bubbles, or Wish SSH code; optionally reviews each area concurrently.

SKILL.md

review-tui.SKILL.md
description: Comprehensive BubbleTea TUI code review for terminal applications. Use when reviewing charmbracelet/bubbletea, lipgloss, bubbles, or Wish SSH code; optionally reviews each area concurrently.
name: review-tui
disable-model-invocation: true

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

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.go$'

Step 2: Detect Technologies

# 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 moc
Read more
Ships withbeagle

Image: NASA, Public Domain. Source Beagle is an Agent Skills marketplace: framework-aware code review, documentation, testing, architectural analysis, and git workflows for any compatible coding agent.

Get the whole plugin

Other skills on beagle.