--- name: pull_warp_feature description: Pull a feature from the upstream Warp codebase into the Galaxy fork. Use this skill whenever the user wants to port, backport, or bring over a feature from Warp into Galaxy. This skill handles cloning the Warp source, analyzing the feature for Warp-specific dependencies, planning safe replacements, and implementing the port. --- # Pull Warp Feature into Galaxy This skill orchestrates porting a feature from the upstream Warp terminal (github.com/warpdotdev/warp) into the Galaxy fork. It is intentionally cautious — Galaxy MUST NOT contain any Warp-proprietary service dependencies, Warp API calls, or Warp cloud infrastructure ties. --- ## Phase 1: Acquire Warp Source Before anything else, ensure a clean copy of the Warp source exists locally for reference. ### Steps 1. Check if `.galaxy/warp-upstream/` already exists in the project root: ```bash ls -d .galaxy/warp-upstream/.git 2>/dev/null ``` 2. **If it does NOT exist**, clone the Warp repo: ```bash mkdir -p .galaxy git clone --depth 1 https://github.com/warpdotdev/warp.git .galaxy/warp-upstream ``` Use `--depth 1` to keep it lightweight. If deeper history is needed for a specific feature, deepen later with `git fetch --unshallow`. 3. **If it DOES exist**, pull latest: ```bash git -C .galaxy/warp-upstream pull --ff-only ``` 4. **Ensure `.galaxy/` is gitignored.** Check `.gitignore` for a `.galaxy/` entry. If missing, append it: ```bash echo ".galaxy/" >> .gitignore ``` IMPORTANT: Verify the line doesn't already exist before appending. Use `grep -q "^\.galaxy/" .gitignore` first. 5. **NEVER commit the `.galaxy/` directory or its contents.** It is a local-only reference checkout. --- ## Phase 2: Identify the Feature Once the Warp source is available, ask the user: > **What feature are you looking at bringing over?** Wait for the user's response. Do NOT proceed until you have a clear answer. ### Interpreting the response - The user may describe the feature by name (e.g. "tab drag and drop", "AI suggestions", "voice input"). - The user may reference a specific file, module, or PR number. - The user may describe behavior they saw in Warp and want in Galaxy. Accept any of these as valid starting points. --- ## Phase 3: Deep Feature Analysis Once you know the target feature, perform a thorough investigation. You need to build a complete dependency map before making any promises. ### 3a. Locate the feature in Warp source Search the Warp source at `.galaxy/warp-upstream/` for the feature: - Use `grep`, `codebase_semantic_search`, and `file_glob` against `.galaxy/warp-upstream/` - Read the relevant source files in full - Identify the entry points, data models, UI components, and backend calls - Map out every file the feature touches ### 3b. Locate the corresponding code in Galaxy Search the Galaxy codebase to understand: - Does Galaxy already have a partial implementation of this feature? - What Galaxy modules correspond to the Warp modules this feature touches? - Are there naming differences? (e.g. `warp_core` → `galaxy_core`, `WarpUI` → `GalaxyUI`) ### 3c. Build the dependency inventory For EVERY dependency the feature has, categorize it into one of these buckets: **✅ SAFE — No changes needed:** - Pure UI logic (elements, views, event handlers) - Local computation (parsers, formatters, algorithms) - Terminal emulation logic - Platform-native APIs (macOS, Windows, Linux) - Local filesystem operations - Open-source crate dependencies already in Galaxy's `Cargo.toml` **⚠️ REQUIRES REPLACEMENT — Can be ported with modification:** - Warp AI / LLM calls → Must be replaced with Amazon Bedrock via `BedrockClient` - Warp API HTTP endpoints → Must be removed or replaced with local storage - Warp Drive cloud sync → Must be replaced with local `.galaxy/` storage or removed - Warp authentication/identity → Must be removed or replaced with Galaxy auth - Warp telemetry/analytics → Must be removed entirely - Warp-specific feature flags → Must be converted to Galaxy `FeatureFlag` enum variants - GraphQL queries to Warp server → Must be removed or rerouted **🚫 BLOCKED — Cannot be ported:** - Features that fundamentally require Warp's proprietary backend to function - Features that require Warp's authentication tokens with no Bedrock/local alternative - Features requiring real-time sync with Warp's cloud that cannot be made local - Warp billing/subscription gating logic ### 3d. Ask follow-up questions Based on your analysis, ask the user clarifying questions. These might include: - "This feature uses Warp's X service — do you want me to replace it with Y, or skip that part?" - "There are two sub-features here: A and B. A is clean to port, B requires major rework. Want both?" - "The Warp version uses cloud storage for Z. Should I store this in `~/.galaxy-ai/` or `.galaxy/`?" - "This depends on crate X which isn't in Galaxy yet. OK to add it?" Do NOT proceed until the user has answered your follow-up questions and you are confident you understand the scope. --- ## Phase 4: Compatibility Assessment This is the most critical phase. You must produce a detailed assessment. Go through EVERY dependency from Phase 3c and make a concrete determination. ### 4a. AI/LLM Dependencies If the feature uses Warp AI in any way: 1. **Identify every AI call site** — What prompts are sent? What models are used? What's the expected response format? 2. **Determine if Bedrock can handle it** — Galaxy uses `BedrockClient::converse_stream` (see `app/src/ai/bedrock/client.rs`). The feature's AI usage MUST be expressible as Bedrock Converse API calls. 3. **Check for Warp-specific prompt engineering** — System prompts in Warp may reference Warp-specific context. These must be rewritten for Galaxy. 4. **Check for Warp-specific tool use** — If the feature defines custom AI tools, verify they don't call Warp APIs internally. 5. **Verdict**: Can it be "Bedrockified"? If NO → the feature CANNOT be ported. Stop and inform the user. Key files for Bedrock integration reference: - `app/src/ai/bedrock/client.rs` — Client implementation - `app/src/ai/bedrock/convert_request.rs` — Request construction and system prompts - `app/src/ai/bedrock/convert.rs` — Wire format conversion - `app/src/ai/bedrock/tool_docs.rs` — Tool documentation - `app/src/ai/bedrock/stream.rs` — Response stream processing ### 4b. Cloud Storage / Warp API Dependencies If the feature calls Warp API endpoints or uses Warp Drive: 1. **List every HTTP/GraphQL call** the feature makes to Warp servers 2. **For each call, determine:** - Can it be removed entirely without breaking the feature? - Can it be replaced with local file storage in `~/.galaxy-ai/` or project-local `.galaxy/`? - Can it be replaced with a different API (e.g. direct AWS call)? 3. **If it requires Warp server and there's no local alternative** → that specific sub-feature CANNOT be ported 4. **Local storage patterns to use:** - User-scoped data: `~/.galaxy-ai//` - Project-scoped data: `.galaxy//` (ensure gitignored) - SQLite via Diesel: `app/src/persistence/` (for data that fits Galaxy's existing DB) ### 4c. Authentication Dependencies If the feature requires Warp authentication: 1. Does Galaxy have its own auth that can substitute? 2. If the feature gates on "is the user logged in" — can this gate be removed? 3. If the feature requires user identity — can it use a local config value instead? ### 4d. Telemetry / Analytics Any Warp telemetry, analytics, or tracking code MUST be stripped entirely. Do not replace it — remove it. ### 4e. Naming and Branding All references to "Warp" in user-facing strings, comments, and identifiers must be changed to "Galaxy": - `warp` → `galaxy` - `Warp` → `Galaxy` - `WARP` → `GALAXY` - `warp_core` → `galaxy_core` - `WarpUI` → `GalaxyUI` - etc. This includes: - Rust module names and paths - Struct/enum/function names - String literals shown to users - Comments and documentation - Environment variable prefixes (`WARP_` → `GALAXY_`) - Config file paths (`~/.warp/` → `~/.galaxy-ai/`) --- ## Phase 5: Present Findings and Plan Present the user with a structured summary using the `create_plan` tool. The plan MUST include: 1. **Feature summary**: What the feature does in Warp, in 2-3 sentences 2. **Files to port**: Exact list of files from `.galaxy/warp-upstream/` and where they map in Galaxy 3. **Dependency assessment table** (as a list, not a markdown table): - For each dependency: what it is, its category (SAFE / REQUIRES REPLACEMENT / BLOCKED), and the replacement strategy 4. **AI assessment**: Does it need AI? Can it be Bedrockified? What changes are needed? 5. **Cloud/API assessment**: Does it call Warp servers? What's the local replacement? 6. **Storage assessment**: Where will data live? What gets gitignored? 7. **Risk areas**: What might break? What needs extra testing? 8. **Estimated scope**: How many files are touched? Is this a 1-hour or 1-week port? **CRITICAL**: Do NOT proceed to implementation until the user explicitly approves the plan. If any part of the feature is BLOCKED, clearly state: > "The following parts of this feature CANNOT be ported because they fundamentally require Warp's proprietary infrastructure: [list]. I recommend porting only the parts that are SAFE or REQUIRES REPLACEMENT." --- ## Phase 6: Implementation Only after the user approves the plan, begin implementation. ### Implementation Rules These rules are NON-NEGOTIABLE: 1. **NEVER copy Warp API URLs, tokens, or endpoint paths into Galaxy code.** 2. **NEVER leave Warp telemetry/analytics calls in the code, even commented out.** 3. **NEVER leave `warp` branding in user-facing strings.** Internal code comments referencing the upstream origin (e.g. "Ported from Warp's X module") are acceptable. 4. **ALL AI calls MUST go through `BedrockClient`** — no direct OpenAI, Anthropic, or other provider calls. 5. **ALL cloud storage MUST be local** — `~/.galaxy-ai/` for user data, `.galaxy/` for project data, or Diesel/SQLite for persistent structured data. 6. **ALL feature flags MUST use Galaxy's `FeatureFlag` enum** in `galaxy_features/src/lib.rs`. 7. **ALL environment variables MUST use the `GALAXY_` prefix.** 8. **ALL config paths MUST use `~/.galaxy-ai/`** not `~/.warp/`. ### Implementation Procedure 1. **Create a TODO list** with discrete steps for the port. 2. **Port files one module at a time**, in dependency order (deepest dependencies first, UI last): - Copy the file from `.galaxy/warp-upstream/` to the correct Galaxy location - Rename all Warp references to Galaxy equivalents - Replace all REQUIRES REPLACEMENT dependencies with Galaxy alternatives - Remove all BLOCKED dependencies and any code paths that depend on them - Ensure all `use` / `mod` statements point to Galaxy crate names 3. **After each module**, verify it compiles: ```bash cargo check -p ``` 4. **After all modules are ported**, run full workspace checks: ```bash cargo fmt cargo clippy --workspace --all-targets --all-features --tests -- -D warnings ``` 5. **If the feature has tests in Warp**, port the tests too: - Place tests in `${filename}_tests.rs` per Galaxy convention - Update test assertions to reflect Galaxy behavior (no Warp API mocking) - Run tests: ```bash cargo nextest run --no-fail-fast -p ``` 6. **Update documentation**: - Update `GALAXY.md` if the feature changes architecture or adds commands - Update `WARP.md` if it exists and needs corresponding changes - Update `CLAUDE.md` if it exists in the project 7. **Final validation**: ```bash cargo build cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2 ``` ### Post-Implementation Audit After implementation, perform a final audit. Search the entire diff for: ```bash # In the changed files, search for any Warp leaks grep -rn "warp\.dev" grep -rn "api\.warp" grep -rn "warpdotdev" grep -rn "warp-server" grep -rn "WARP_API" grep -rn "warp_api" ``` Any hits (other than comments documenting the port origin) are bugs that must be fixed before completion. Also verify no `.galaxy/` files were staged: ```bash git status --porcelain | grep "^A.*\.galaxy/" ``` --- ## Reference: Galaxy ↔ Warp Name Mapping Common renames when porting: - `warp` → `galaxy` (crate names, binary names) - `warp_core` → `galaxy_core` - `warpui` → `galaxyui` - `warpui_core` → `galaxyui_core` - `warpui_extras` → `galaxyui_extras` - `warp_terminal` → `galaxy_terminal` - `warp_util` → `galaxy_util` - `warp_features` → `galaxy_features` - `warp_completer` → `galaxy_completer` - `warp_graphql_schema` → `galaxy_graphql_schema` - `warp_cli` → `galaxy_cli` - `WARP_` prefix env vars → `GALAXY_` - `~/.warp/` → `~/.galaxy-ai/` - Warp AI server endpoints → `BedrockClient::converse_stream` - Warp Drive → local storage in `~/.galaxy-ai/` or `.galaxy/` - `WarpAI` / `warp_ai` → `GalaxyAI` / `galaxy_ai` ## Reference: Bedrock Integration Points When replacing Warp AI calls with Bedrock: - Client: `app/src/ai/bedrock/client.rs` — `BedrockClient::converse_stream` - Request building: `app/src/ai/bedrock/convert_request.rs` - Response parsing: `app/src/ai/bedrock/stream.rs` - Tool definitions: `app/src/ai/bedrock/tool_docs.rs` - AWS credentials: `app/src/ai/aws_credentials.rs` - Model selection: `app/src/ai/llms.rs` All AI features MUST flow through these modules. Direct HTTP calls to any LLM provider are forbidden. ## Reference: Local Storage Patterns When replacing Warp cloud storage: - **User preferences / global state**: `~/.galaxy-ai//` - **Project-scoped state**: `/.galaxy//` (must be gitignored) - **Structured persistent data**: Use Diesel ORM + SQLite via `app/src/persistence/` - **Cached/temporary data**: `$TMPDIR/galaxy_/` --- ## Failure Modes — When to STOP STOP the port and inform the user if: 1. The feature's core functionality requires real-time communication with Warp's servers and there is no local alternative. 2. The feature's AI usage cannot be expressed as Bedrock Converse API calls (e.g. it requires fine-tuned Warp-specific models with no public equivalent). 3. The feature depends on Warp-proprietary data formats or protocols that are not documented in the open-source repo. 4. Porting the feature would require modifying more than 30% of Galaxy's existing codebase — this suggests architectural incompatibility. 5. The feature's tests all depend on Warp server mocks that have no Galaxy equivalent, making it untestable. In these cases, present the user with: - WHY the port is blocked - WHICH specific dependency is the blocker - WHETHER a partial port (subset of functionality) is viable - WHAT alternative approaches might achieve similar UX without the blocked dependency