Agent skill

Bubbletea Testing

by dimetron in dimetron/pi-go

A skill your agent uses whenever writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go.

MITAuto-check passedTesting & QA

Install Bubbletea Testing

skills CLI
$ npx skills add dimetron/pi-go --skill bubbletea-testing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install dimetron/pi-go bubbletea-testing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/dimetron/pi-go.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.pi-go/skills/bubbletea-testing .claude/skills/bubbletea-testing && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
bubbletea-testing
GitHub stars
207
Token cost
~3.6k tokens
SKILL.md length
699 words
Files
1
Skills in repo
21
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses whenever writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go.

  • Works in 3 steps: Force a fixed color profile → Lock terminal dimensions → Prevent git from corrupting golden files
  • Writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go
  • SKILL.md covers Architecture overview, Layer 1: Direct model unit tests, Layer 2: Golden file testing and Layer 3: Full integration with…, plus 4 more sections
  • Calls go and git

What it does

Bubbletea Testing is an agent skill from dimetron/pi-go. Use this skill whenever writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go. Triggers include any mention of testing Bubble Tea models, teatest, golden file testing for TUIs, testing tea.Cmd or tea.Msg, snapshot testing terminal output, or writing tests for any Go CLI/TUI that uses the Elm Architecture (Init/Update/View). Also use when the user asks about testing bubbletea components, bubbles, or lipgloss-styled views, or when they need CI-friendly TUI test patterns. Even if they just…

Its SKILL.md is about 3.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA. The repository describes itself as: Go implementation of AI coding agent. The licence is MIT.

When your agent uses it

  • Writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go
  • Include any mention of testing Bubble Tea models
  • Golden file testing for TUIs
  • Testing tea.Cmd

Example prompts

  • “test my TUI”
  • “add tests to my Bubble Tea app”
  • “/bubbletea-testing”

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Force a fixed color profile
  2. Lock terminal dimensions
  3. Prevent git from corrupting golden files

What it can do on your machine

Read from SKILL.md and the folder at commit 24d1f2b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • go
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Bubbletea Testing loads about 3.6k tokens when it runs. Until then it costs about 151 tokens; SKILL.md has 699 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~151
When it runs · the whole SKILL.md, loaded when a task matches
~3.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from dimetron/pi-go at commit 24d1f2b, republished under its MIT licence (© dimetron). 699 words, ~3,560 tokens.

Download SKILL.mdSave it as .claude/skills/bubbletea-testing/SKILL.md (or your agent's skills folder).
name
bubbletea-testing
description
Use this skill whenever writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go. Triggers include any mention of testing Bubble Tea models, teatest, golden file testing for TUIs, testing tea.Cmd or tea.Msg, snapshot testing terminal output, or writing tests for any Go CLI/TUI that uses the Elm Architecture (Init/Update/View). Also use when the user asks about testing bubbletea components, bubbles, or lipgloss-styled views, or when they need CI-friendly TUI test patterns. Even if they just say "test my TUI" or "add tests to my Bubble Tea app", use this skill.

Bubble Tea Testing

Write robust, CI-friendly tests for Bubble Tea TUI applications using a three-layer strategy: direct model unit tests, golden file view snapshots, and full-program integration tests via teatest.

Architecture overview

Bubble Tea's Elm Architecture (Init, Update, View) makes TUI apps inherently testable. Update(msg) -> (model, cmd) is a pure function of state and message — no terminal, program, or event loop needed for most tests.

Three-layer strategy:

LayerCoverageSpeedTool
1. Direct model testsState transitions, commands, view content~msStandard testing
2. Golden file snapshotsVisual regression on View() output~msgolden.RequireEqual
3. Full integrationEnd-to-end user flows~secondsteatest.NewTestModel

Target ratio: 80% Layer 1 / 15% Layer 2 / 5% Layer 3.


Layer 1: Direct model unit tests

Constructing test messages

Build tea.Msg values directly — they are plain Go structs:

go
// v1
qKey   := tea.KeyMsg{Type: tea.KeyRunes, Runes: []rune("q")}
enter  := tea.KeyMsg{Type: tea.KeyEnter}
ctrlC  := tea.KeyMsg{Type: tea.KeyCtrlC}
down   := tea.KeyMsg{Type: tea.KeyDown}
resize := tea.WindowSizeMsg{Width: 80, Height: 24}

// v2 renames
qKey   := tea.KeyPressMsg{Type: tea.KeyRunes, Runes: []rune("q")}
click  := tea.MouseClickMsg{X: 10, Y: 5, Button: tea.MouseButtonLeft}
Table-driven Update tests

The standard pattern — each case specifies initial state, message, and expected outcome:

go
func TestUpdate(t *testing.T) {
    tests := []struct {
        name       string
        initial    model
        msg        tea.Msg
        wantCursor int
        wantQuit   bool
    }{
        {
            name:       "down moves cursor",
            initial:    model{cursor: 0, choices: []string{"a", "b", "c"}},
            msg:        tea.KeyMsg{Type: tea.KeyDown},
            wantCursor: 1,
        },
        {
            name:       "cursor stops at bottom",
            initial:    model{cursor: 2, choices: []string{"a", "b", "c"}},
            msg:        tea.KeyMsg{Type: tea.KeyDown},
            wantCursor: 2,
        },
        {
            name:       "q triggers quit",
            initial:    model{},
            msg:        tea.KeyMsg{Type: tea.KeyRunes, Runes: []rune("q")},
            wantQuit:   true,
        },
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            updated, cmd := tt.initial.Update(tt.msg)
            m := updated.(model)

            if m.cursor != tt.wantCursor {
                t.Errorf("cursor = %d, want %d", m.cursor, tt.wantCursor)
            }
            if tt.wantQuit {
                if cmd == nil {
                    t.Fatal("expected quit command")
                }
                if _, ok := cmd().(tea.QuitMsg); !ok {
                    t.Error("quit command did not return QuitMsg")
                }
            }
        })
    }
}
Testing commands synchronously

tea.Cmd is func() tea.Msg. Execute it directly and inspect the result:

go
func TestQuitCommand(t *testing.T) {
    m := model{}
    _, cmd := m.Update(tea.KeyMsg{Type: tea.KeyRunes, Runes: []rune("q")})

    if cmd == nil {
        t.Fatal("expected quit command")
    }
    msg := cmd() // execute synchronously
    if _, ok := msg.(tea.QuitMsg); !ok {
        t.Errorf("expected QuitMsg, got %T", msg)
    }
}
Mocking I/O dependencies

Use interfaces for anything that does real I/O, inject mocks in tests:

go
type DataFetcher interface {
    FetchItems() ([]Item, error)
}

type model struct {
    fetcher DataFetcher
    items   []Item
}

// Test mock
type mockFetcher struct {
    items []Item
    err   error
}
func (f mockFetcher) FetchItems() ([]Item, error) { return f.items, f.err }

func TestFetchSuccess(t *testing.T) {
    m := model{fetcher: mockFetcher{items: []Item{{Name: "test"}}}}
    cmd := m.fetchCmd()
    msg := cmd()
    result, ok := msg.(itemsMsg)
    if !ok {
        t.Fatalf("expected itemsMsg, got %T", msg)
    }
    if len(result.items) != 1 {
        t.Errorf("expected 1 item, got %d", len(result.items))
    }
}
Chaining update–command–message cycles

Simulate multi-step flows without a running program:

go
func TestMultiStepFlow(t *testing.T) {
    m := tea.Model(initialModel())
    var cmd tea.Cmd

    // Step 1: user presses enter
    m, cmd = m.Update(tea.KeyMsg{Type: tea.KeyEnter})

    // Step 2: execute the resulting command, feed msg back
    if cmd != nil {
        m, cmd = m.Update(cmd())
    }

    // Assert final state
    final := m.(myModel)
    if final.state != resultView {
        t.Errorf("expected resultView, got %v", final.state)
    }
}
Testing View output with substring assertions

Prefer substring checks over exact matches — more resilient to styling changes:

go
func TestViewShowsSelection(t *testing.T) {
    m := model{
        cursor:   1,
        choices:  []string{"carrots", "celery", "kohlrabi"},
        selected: map[int]struct{}{1: {}},
    }
    view := m.View()

    if !strings.Contains(view, "[x] celery") {
        t.Errorf("expected selected celery in view:\n%s", view)
    }
    if !strings.Contains(view, "[ ] carrots") {
        t.Errorf("expected unselected carrots in view:\n%s", view)
    }
}

Principle: Assert on intent (flags, indices, content), not styling.

Testing nested/composed models

Test parent routing and child transitions independently:

go
func TestParentRoutesToActiveChild(t *testing.T) {
    parent := newParentModel()
    updated, _ := parent.Update(tea.WindowSizeMsg{Width: 80, Height: 24})
    p := updated.(parentModel)

    child := p.list.(listModel)
    if child.width != 80 {
        t.Errorf("child width = %d, want 80", child.width)
    }
}

Layer 2: Golden file testing

Packages
PackageImportUse case
goldengithub.com/charmbracelet/x/exp/goldenComponent-level View snapshots
teatestgithub.com/charmbracelet/x/exp/teatestFull-program output snapshots
Component snapshot with golden.RequireEqual
go
import "github.com/charmbracelet/x/exp/golden"

func TestTableRendering(t *testing.T) {
    tbl := table.New(
        table.WithColumns(columns),
        table.WithRows(rows),
    )
    // Compares against testdata/TestTableRendering.golden
    golden.RequireEqual(t, tbl.View())
}

golden.RequireEqual auto-escapes ANSI codes and uses go-udiff for portable diffs.

Full-program snapshot with teatest.RequireEqualOutput
go
func TestFullOutput(t *testing.T) {
    tm := teatest.NewTestModel(t, initialModel(),
        teatest.WithInitialTermSize(80, 24),
    )
    tm.Send(tea.KeyMsg{Type: tea.KeyRunes, Runes: []rune("q")})

    out, _ := io.ReadAll(tm.FinalOutput(t, teatest.WithFinalTimeout(3*time.Second)))
    // Compares against testdata/TestFullOutput.golden
    teatest.RequireEqualOutput(t, out)
}
Golden file workflow
bash
# 1. Generate initial golden files
go test ./... -update

# 2. Commit them
git add testdata/*.golden

# 3. Normal test runs — fails if output differs
go test ./...

# 4. After intentional UI changes — regenerate and review diff
go test ./... -update
git diff testdata/

Layer 3: Full integration with teatest

Core API
go
import (
    "bytes"
    "io"
    "testing"
    "time"

    tea "github.com/charmbracelet/bubbletea"
    "github.com/charmbracelet/x/exp/teatest"
)

func TestIntegration(t *testing.T) {
    tm := teatest.NewTestModel(t, initialModel(),
        teatest.WithInitialTermSize(80, 24),
    )

    // Interact
    tm.Send(tea.KeyMsg{Type: tea.KeyDown})
    tm.Send(tea.KeyMsg{Type: tea.KeyEnter})
    tm.Type("hello")

    // Assert intermediate output (polls reader)
    teatest.WaitFor(t, tm.Output(), func(bts []byte) bool {
        return bytes.Contains(bts, []byte("hello"))
    }, teatest.WithDuration(2*time.Second),
       teatest.WithCheckInterval(100*time.Millisecond))

    // Quit and assert final state
    tm.Send(tea.KeyMsg{Type: tea.KeyRunes, Runes: []rune("q")})
    fm := tm.FinalModel(t, teatest.WithFinalTimeout(3*time.Second))
    m := fm.(myModel)
    if !m.submitted {
        t.Error("expected submitted")
    }
}
teatest API reference
MethodPurposeBlocks?
NewTestModel(tb, model, opts...)Create & start headless programNo
tm.Send(msg)Inject any tea.MsgNo
tm.Type(s)Type string as key eventsNo
tm.Output()Live output io.ReaderNo
tm.FinalOutput(tb, opts...)Complete output after quitYes
tm.FinalModel(tb, opts...)Final tea.Model after quitYes
tm.WaitFinished(tb, opts...)Block until program exitsYes
WaitFor(tb, reader, cond, opts...)Poll reader until condition trueYes
RequireEqualOutput(tb, out)Golden file comparisonNo

Always set timeouts via WithFinalTimeout to prevent hanging tests.


CI determinism — the three critical fixes

1. Force a fixed color profile

Without this, golden files from a TrueColor dev terminal will mismatch in CI (no TTY).

go
// v1 — in test init or TestMain
import (
    "github.com/charmbracelet/lipgloss"
    "github.com/muesli/termenv"
)
func init() {
    lipgloss.SetColorProfile(termenv.Ascii)
}

// v2 — per-program
import "github.com/charmbracelet/colorprofile"
prog := tea.NewProgram(model, tea.WithColorProfile(colorprofile.Ascii))

Use termenv.Ascii for simplest golden files. Use termenv.TrueColor if testing color output.

2. Lock terminal dimensions
go
// teatest
teatest.WithInitialTermSize(80, 24)

// Direct model tests — send resize before View()
m, _ := m.Update(tea.WindowSizeMsg{Width: 80, Height: 24})
output := m.(myModel).View()

// v2
tea.WithWindowSize(80, 24)
3. Prevent git from corrupting golden files

Add to .gitattributes:

*.golden -text
testdata/** -diff linguist-generated=true

Prevents CRLF normalization and suppresses golden files from GitHub PR diffs.

Show full SKILL.md (288 more words)Show less
Handle non-deterministic elements

Spinners, timestamps, cursor blink, and animations produce varying output. Strategies:

  • Freeze spinner frame index to 0 in test setup
  • Inject a clock interface for timestamps, use fixed time.Time in tests
  • Disable cursor blink before capture
  • Seed RNGs with constant values
  • For animations, test the final state rather than intermediate frames

Bubble Tea v2 testing options

v2 (charm.land/bubbletea/v2) adds first-class ProgramOption values for testing:

go
prog := tea.NewProgram(model,
    tea.WithWindowSize(80, 24),           // Fixed dimensions
    tea.WithInput(nil),                   // Disable input
    tea.WithOutput(&buf),                 // Redirect to buffer
    tea.WithoutRenderer(),                // Headless, no rendering
    tea.WithoutSignals(),                 // Ignore OS signals
    tea.WithColorProfile(colorprofile.Ascii), // Fixed colors
)

These replace global init() hacks with explicit per-program config.

The v2 teatest package is at github.com/charmbracelet/x/exp/teatest/v2.


Community tools

knz/catwalk — data-driven text-file tests

Test cases as plain text files with input directives:

run
type hello
key enter
----
-- view:
You typed: hello

Run with -rewrite to regenerate expected output. Good for testing individual Bubbles components.

Repo: github.com/knz/catwalk

Custom direct-model harness (Noteleaf pattern)

Drive tea.Model directly without tea.NewProgram for single-threaded, faster tests:

go
type TestHarness struct {
    model tea.Model
}

func (h *TestHarness) SendKey(key tea.KeyType) {
    var cmd tea.Cmd
    h.model, cmd = h.model.Update(tea.KeyMsg{Type: key})
    // Optionally execute cmd and feed back
}

func (h *TestHarness) WaitForView(contains string, timeout time.Duration) error {
    deadline := time.Now().Add(timeout)
    for time.Now().Before(deadline) {
        if strings.Contains(h.model.View(), contains) {
            return nil
        }
        time.Sleep(10 * time.Millisecond)
    }
    return fmt.Errorf("timed out waiting for %q", contains)
}

Lighter than teatest, but doesn't test the terminal rendering pipeline.


Checklist for adding tests to a Bubble Tea app

  1. Set up test infrastructure:

    • Create testdata/ directory for golden files
    • Add .gitattributes entry: *.golden -text
    • Add init() or TestMain that sets lipgloss.SetColorProfile(termenv.Ascii)
  2. Layer 1 — Write table-driven Update tests for:

    • Every key binding and its effect on model state
    • State machine transitions (view switches, mode changes)
    • Edge cases (empty lists, max cursor, error states)
    • Commands returned by Update (execute synchronously, assert on msg type)
    • Custom message handlers (API responses, timer ticks)
  3. Layer 2 — Add golden file tests for key UI states:

    • Initial/welcome screen
    • Loading/spinner state
    • Error display
    • Main content with data populated
    • Empty state
  4. Layer 3 — Write integration tests for critical flows:

    • Startup → input → result → quit
    • Error recovery paths
    • Multi-step wizards or workflows
  5. CI pipeline:

    • Ensure go test ./... passes without -update
    • Add -update as a manual/explicit step only
    • Consider a CI step that fails if golden files are uncommitted

© dimetron, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .pi-go/skills/bubbletea-testing of dimetron/pi-go.

Open the folder on GitHubat commit 24d1f2b

Compare with similar skills

Bubbletea Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Bubbletea Testing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Bubbletea Testing this skilldimetron/pi-go207—~3.6kAutomated safety check: PassMIT
Web Application Testinganthropics/skills180k51 repos~966Automated safety check: PassApache-2.0
Diagnosing Bugsfossasia/eventyay-interpretation1.6k32 repos~2.1kAutomated safety check: PassApache-2.0
TDDpietheinstrengholt/rssmonster56430 repos~906Automated safety check: PassMIT
TDD WorkflowhellangleZ/burn-in-cceverywhere-ralph11211 repos~2.4kAutomated safety check: PassNone
TDDsanity-io/sanity6.4k20 repos~1kAutomated safety check: PassMIT

Similar skills

  • Web Application Testing

    anthropics/skills

    Official

    Tests local web applications with Python Playwright scripts, checking frontend behavior, capturing screenshots and reading browser console logs.

    180k GitHub starsUsed in 51 repos~966 tokens
    Testing & QAAuto-check passed
  • Diagnosing Bugs

    fossasia/eventyay-interpretation

    Diagnosis loop for hard bugs and performance regressions. An agent skill from fossasia/eventyay-interpretation.

    1.6k GitHub starsUsed in 32 repos~2.1k tokens
    Testing & QAAuto-check passed
  • TDD

    pietheinstrengholt/rssmonster

    Test-driven development. An agent skill from pietheinstrengholt/rssmonster.

    564 GitHub starsUsed in 30 repos~906 tokens
    Testing & QAAuto-check passed
  • TDD Workflow

    hellangleZ/burn-in-cceverywhere-ralph

    A skill your agent uses when writing new features, fixing bugs, or refactoring code.

    112 GitHub starsUsed in 11 repos~2.4k tokens
    Testing & QAAuto-check passed
  • TDD

    sanity-io/sanity

    Official

    Test-driven development with red-green-refactor loop. An agent skill from sanity-io/sanity.

    6.4k GitHub starsUsed in 20 repos~1k tokens
    Testing & QAAuto-check passed
  • Context Driven Development

    Ibrahim-3d/orchestrator-supaconductor

    A skill your agent uses when working with Conductor's context-driven development methodology, managing project context artifacts, or understanding the relationship between product.md, tech-stack.md…

    380 GitHub starsUsed in 9 repos~2.9k tokens
    Testing & QAAuto-check passed

More from dimetron/pi-go

All 21 skills in this repo
  • Vhs E2E Gif

    dimetron/pi-go

    Record a test run, a TUI session, or any terminal command as a GIF with VHS and attach it to a GitHub PR as a release-hosted asset, never a repo commit.

    207 GitHub stars~1.7k tokensUpdated 6 days ago
    Auto-check passed
  • Agents Md

    dimetron/pi-go

    Generate AGENTS.md files for Go, Rust, TypeScript, and Java projects.

    207 GitHub stars~1.7k tokensUpdated 6 days ago
    Auto-check passed
  • Memory Index

    dimetron/pi-go

    Index a folder's contents into the MemPalace semantic memory for search and retrieval.

    207 GitHub stars~1.5k tokensUpdated 6 days ago
    Auto-check passed
  • Nightly Session Watch

    dimetron/pi-go

    Nightly sweep of the last 24h of pi-go sessions — anomalous runs, loop aborts, tool error rates, token waste, real prompt-token spend, and whether the observation and palace pipelines are still…

    207 GitHub stars~1.5k tokensUpdated 6 days ago
    Auto-check passed
  • Osx Tuning

    dimetron/pi-go

    Tune macOS resource limits and sysctls for best performance with Go development, Docker/OrbStack, and Linux VMs.

    207 GitHub stars~1.6k tokensUpdated 6 days ago
    Auto-check: notes
  • Pgo

    dimetron/pi-go

    Profile-guided optimization (PGO) for the pi binary. An agent skill from dimetron/pi-go.

    207 GitHub stars~1.4k tokensUpdated 6 days ago
    Auto-check passed

Categories

Questions about Bubbletea Testing

What does Bubbletea Testing do?

A skill your agent uses whenever writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go. Bubbletea Testing is an agent skill from dimetron/pi-go. Use this skill whenever writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go.

When should I use Bubbletea Testing?

Bubbletea Testing fits situations like: writing tests for Bubble Tea (charmbracelet/bubbletea) TUI applications in Go; include any mention of testing Bubble Tea models; golden file testing for TUIs; testing tea.Cmd.

How do I install Bubbletea Testing in Claude Code?

Run `npx skills add dimetron/pi-go --skill bubbletea-testing -a claude-code`. Or copy the skill folder (.pi-go/skills/bubbletea-testing in dimetron/pi-go) into .claude/skills/bubbletea-testing in your project. Claude Code loads it when a task matches its description.

How do I install Bubbletea Testing in Codex?

Run `npx skills add dimetron/pi-go --skill bubbletea-testing -a codex`. Or copy the skill folder (.pi-go/skills/bubbletea-testing in dimetron/pi-go) into .agents/skills/bubbletea-testing in your project. Codex loads it when a task matches its description.

Can I use Bubbletea Testing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add dimetron/pi-go --skill bubbletea-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/bubbletea-testing, .gemini/skills/bubbletea-testing, .github/skills/bubbletea-testing and .opencode/skills/bubbletea-testing in your project.

What does Bubbletea Testing need to run?

Going by SKILL.md and its folder, Bubbletea Testing needs the command-line tools its instructions call (go and git).

Does Bubbletea Testing access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Bubbletea Testing safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Bubbletea Testing use?

Bubbletea Testing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Bubbletea Testing use?

About 3.6k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Bubbletea Testing?

Skills that share tags, products or a category with Bubbletea Testing: Web Application Testing (anthropics/skills, 180k stars), Diagnosing Bugs (fossasia/eventyay-interpretation, 1.6k stars), TDD (pietheinstrengholt/rssmonster, 564 stars) and TDD Workflow (hellangleZ/burn-in-cceverywhere-ralph, 112 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Bubbletea Testing?

dimetron (a GitHub user) maintains it in dimetron/pi-go, which has 207 GitHub stars. The repository holds 21 skills in this directory. The repository was last updated on October 1, 2026.

Source: dimetron/pi-go on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.