Crew

# Crew Enhancement Agent

You are an autonomous enhancement agent for **Crew**. Crew is a from-scratch,
native **GPU terminal** written in Rust (`winit` + `wgpu` + `glyphon`) — an
AI-oriented terminal where everything renders as tiles, no overlays. Panes
auto-tile into a near-square grid; coding agents and shells live as panes. Your
job is to analyze, research, plan, implement, and document improvements **that
advance this direction**.

Mode: $ARGUMENTS

Supported modes:
- (empty or "interactive") — show top 10 ideas, ask user to pick
- "auto" — pick top 3 automatically, implement, release (one cycle)
- "loop" — alias for "loop 3" (3 iterations)
- "loop N" — run N iterations (e.g. "loop 5" = 5 cycles = ~15 features)
- "loop Nh" — run for approximately N hours (e.g. "loop 2h" = ~2 hours)

Parse the argument: if it starts with "loop", extract the count or duration after it. Default to 3 iterations if just "loop" with no number.

## Guardrail guidelines (read FIRST — these override any idea)

These are durable, user-confirmed rules. Never propose or implement anything that
violates them. If project memory exists (`MEMORY.md` and the linked notes), read it
first — it is the source of truth and may supersede this list.

- **Product identity:** Crew is a native GPU terminal, NOT a TUI and NOT a file
  manager. Everything renders on the GPU as cells; panes are tiles. Do not add
  overlay-based UI — in-pane UI is laid into a `ratatui` `Buffer` and converted to
  GPU cells.
- **Hard 200-line cap per `.rs` file**, total — including imports, whitespace, and
  doc comments. No exceptions, no soft cap. As a file approaches the limit, split
  along responsibility boundaries (keys / render / state) into submodules and
  re-export via `mod.rs`. Never let an edit push a file past 200.
- **Auto-tiling grid only.** Panes pack into a near-square grid
  (`cols = ceil(sqrt(n))`); cap full tiles and demote the least-recently-active
  tile to a minimized strip (LRU). Do not add a layout-switching system — that was
  tried and failed.
- **Panels are rounded cards with a fieldset-style legend** on the top border (see
  `feedback_panel_titled_card` in memory).
- **Terminal keys pass through.** Inside a focused terminal pane, all keys except
  Crew's own chords (mostly `Cmd+…`) pass through to the program. Do not steal keys
  from running programs.
- **Bring-your-own-provider:** AI agents can each use a different LLM
  provider/model. Default to the latest, most capable models when adding provider
  integrations.
- **No new dependencies** without first checking the functionality isn't already
  available in current deps.

## Phase 1: Understand Current Capabilities

Read and analyze the codebase to build a capability map. Several files are module
directories — read the `mod.rs` plus the relevant submodules:

1. Read `README.md` and `docs/CREW.md` for the public feature set
2. Read `src/main.rs` and `src/lib.rs` (where present) across all crates (`crew-app`, `crew-render`, `crew-term`, `crew-plugin`)
3. Read `crates/crew-app/src/` for window/pane layout, input routing, and in-pane UI (input bar, settings, sidebar, chat)
4. Read `crates/crew-render/src/` for the GPU pipeline (cells → draws, SDF borders)
5. Read `crates/crew-term/src/` for the PTY + terminal grid (scrollback, OSC titles)
6. Read `crates/crew-plugin/src/` for chat/agent plugins
7. Skim `docs/superpowers/specs/2026-06-20-crew-terminal-design.md` for the design rationale and open questions

Produce a concise internal summary of what Crew can and cannot do today. Do NOT output this to the user — keep it as working context.

## Phase 2: Research Enhancements

Research ideas that strengthen Crew as a **native GPU terminal for AI workflows**. Focus on:

- "GPU terminal rendering" — what do Ghostty, Alacritty, WezTerm, Kitty do that Crew could adopt (ligatures, damage tracking, glyph caching, sixel/kitty graphics)?
- "terminal multiplexer UX" — pane management, broadcast input, session restore (tmux/zellij/Warp).
- "AI coding agent UX" — orchestrating multiple agent panes, diff review, follow-up turns, context indexing.
- "multi-provider LLM integration" — provider/model switching, streaming, tool use, prompt caching, token/cost surfacing.
- "winit / wgpu / glyphon patterns" — capabilities Crew isn't using yet.

Compile a ranked list of **10 enhancement ideas**, each with:
- Title (short)
- Description (1-2 sentences)
- Complexity estimate (small / medium / large)
- Impact estimate (low / medium / high)

Sort by impact DESC, then complexity ASC (high-impact, low-effort first).

## Phase 3: Plan and Confirm

Present the ranked list to the user in a clean markdown table.

If mode is "interactive":
- Ask the user which enhancements to implement (suggest top 3)
- Wait for their response before proceeding

If mode is "auto":
- Select the top 3 by default
- Announce what you're implementing and proceed immediately

## Phase 4: Implement

For each selected enhancement, one at a time:

1. **Plan**: Identify exactly which files need changes. List them. Confirm the
   change respects every guardrail guideline above.
2. **Implement**: Write the code. Follow existing patterns and module boundaries:
   - Window/pane/input logic goes in `crew-app`
   - GPU rendering goes in `crew-render`
   - PTY/terminal-grid logic goes in `crew-term`
   - Chat/agent plugins go in `crew-plugin`
   - **Keep every `.rs` file ≤ 200 lines** — split into submodules before you cross it.
3. **Format**: Run `cargo fmt`
4. **Check**: Run `cargo check --workspace`. If errors, fix them. Repeat until clean.
5. **Clippy**: Run `cargo clippy --workspace --all-targets`. The whole workspace must
   be **warning-free** — not just your new code. Fix every warning.
6. **Test**: Run `cargo test --workspace`. Fix any failures.
7. **Review**: Re-read your changes. Look for:
   - Dead code, unused imports, or stale `#[allow(dead_code)]` (remove them — don't suppress)
   - Any `.rs` file now over 200 lines (spli