public/galaxy
1
0
Fork 0
Code Issues Pull Requests Actions 6 Packages Projects Releases Wiki Activity

Document process monitoring handoff

Browse Source 
Add ACP discovery and configuration support
This commit is contained in:
Ryan Ward
2026-07-30 11:53:33 -05:00
parent ad24374f6d
commit 1a0aac51b6
18 changed files with 1280 additions and 664 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/bring-warp-feature-over/SKILL.md
+206 -174
View File
@@ -1,232 +1,264 @@
---
name: bring-warp-feature-over
description: Identify recent features merged into upstream Warp, assess eligibility for the Galaxy fork, and migrate selected features with Bedrock API adaptations. Use when syncing new Warp functionality into Galaxy.
description: Find and selectively port explicitly requested upstream Warp pull requests into Galaxy. Accepts PR/MR numbers or a user-provided feature description, confirms the selected PRs before editing, filters out Warp-only service code, preserves Galaxy's Bedrock/OpenAI/ACP provider architecture and branding, and adapts eligible local changes.
---
# bring-warp-feature-over
# Bring a Specific Warp Feature into Galaxy
Fetches recent upstream Warp changes, filters for eligible features, lets the user pick which to migrate, plans the work, and spawns agents to implement each migration.
Use this skill to identify and port selected upstream Warp functionality into Galaxy without performing a broad upstream synchronization.
## Overview
## Required scope
Galaxy is a fork of Warp that uses AWS Bedrock instead of Warp's proprietary AI APIs. When upstream Warp ships new features, this skill identifies which ones can be brought over, adapts API calls to Bedrock, and replaces Warp-specific branding where needed.
The user must provide either:
## Workflow
1. One or more upstream Warp pull request numbers, or
2. A description of the feature they want to find upstream.
### 1. Fetch recent upstream changes
Examples:
Use the GitHub API to pull merged commits from `warpdotdev/warp` on the default branch. Group by PR (commits reference `#<number>`).
- `Bring over Warp PR #12345`
- `Port PRs 12345 and 12389`
- `Find the Warp PR that added terminal search highlighting`
- `Bring over the recent worktree picker improvements`
If the user provides a description, search for candidate PRs and ask the user to confirm the matching PR number(s) before making code changes. Do not scan and port arbitrary recent history.
## Non-negotiable Galaxy boundaries
Galaxy-specific architecture always wins. Never replace or bypass:
- Bedrock provider code in `app/src/ai/bedrock/`
- OpenAI/LiteLLM provider code in `app/src/ai/openai/`
- ACP provider/runtime code in `app/src/ai/acp/` and the related ACP crate(s)
- Provider dispatch and response streaming in `app/src/ai/provider/` and `app/src/ai/blocklist/controller/response_stream.rs`
- Galaxy branding, package names, channels, settings, deployment, and installer behavior
Do not import or preserve new upstream code that depends on:
- Warp's proprietary AI API or hosted agent backend
- Warp authentication, billing, subscriptions, teams, or cloud-only flows
- Warp telemetry/analytics that phone home to Warp
- Warp server GraphQL/API endpoints unless explicitly adapted to an existing Galaxy service
- Warp-specific deployment or branding
- Oz/hosted orchestration that Galaxy cannot run locally
## Phase 0: Inspect the working tree
Before making changes:
```bash
# Fetch commits from the last N days (default 14)
curl -s "https://api.github.com/repos/warpdotdev/warp/commits?per_page=100&since=$(date -u -v-14d +%Y-%m-%dT00:00:00Z)" \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
for c in data:
sha = c['sha'][:8]
msg = c['commit']['message'].split('\n')[0]
date = c['commit']['author']['date'][:10]
print(f'{date} {sha} {msg}')
"
git --no-optional-locks status --short --branch
```
If the user specifies a date range or number of days, adjust the `since` parameter. For longer lookups, paginate with `&page=2`, etc.
Do not overwrite unrelated user work. If the working tree is dirty, keep existing changes intact and use a separate branch where possible.
## Phase 1: Resolve the requested scope
### If PR/MR numbers were provided
Use the supplied numbers directly. Do not search unrelated upstream history.
### If a feature description was provided
Search upstream GitHub for matching Warp PRs. Prefer the GitHub search API, using a concise query derived from the user’s description:
To get more detail on a specific PR:
```bash
curl -s "https://api.github.com/repos/warpdotdev/warp/pulls/<PR_NUMBER>" | python3 -c "
import json, sys
pr = json.load(sys.stdin)
print(pr.get('title'))
print(pr.get('body','')[:2000])
"
curl -sS --get 'https://api.github.com/search/issues' \
--data-urlencode 'q=<keywords> repo:warpdotdev/warp is:pr' \
--data-urlencode 'per_page=10'
```
To see the files changed in a PR:
If authentication or API rate limits prevent the search, use the public GitHub web search URL or fetch recent commit/PR metadata as a fallback. Keep the search bounded by the user’s description; do not enumerate the entire repository history.
For each candidate, collect:
- PR number and title
- State and merge status
- Updated/merged date
- Body excerpt
- Labels, when available
- Changed-file summary
Inspect candidate files before presenting them:
```bash
curl -s "https://api.github.com/repos/warpdotdev/warp/pulls/<PR_NUMBER>/files" | python3 -c "
import json, sys
files = json.load(sys.stdin)
for f in files:
print(f['status'], f['filename'])
"
curl -sS "https://api.github.com/repos/warpdotdev/warp/pulls/<PR>"
curl -sS "https://api.github.com/repos/warpdotdev/warp/pulls/<PR>/files?per_page=100"
```
### 2. Assess eligibility
Present a short ranked list with the reason each candidate matches and its likely adaptation cost. Then ask for confirmation, for example:
For each feature/PR, determine eligibility. A feature is **ineligible** if:
```text
I found these likely matches:
- It depends on Warp's server APIs that we don't have access to (e.g. `warp-server` endpoints, GraphQL mutations for Warp Cloud services)
- It's specific to "Warp Drive" syncing infrastructure (unless it can be adapted to "Galaxy Drive")
- It references "Oz" orchestration that relies on Warp's hosted agent backend
- It requires Warp's proprietary AI proxy and cannot be redirected to Bedrock
- It's purely a Warp billing, subscription, or team management feature
- It touches WASM-only paths that Galaxy doesn't ship
1. #12345 — Improve terminal search highlighting
Matches the requested behavior; mostly local terminal/UI code. Low adaptation cost.
A feature **is eligible** if:
2. #12389 — Add cloud search synchronization
Related wording, but depends on Warp cloud APIs. Likely ineligible.
- It's a client-side UX improvement (terminal, editor, completions, themes, settings)
- It's an AI feature that calls a model API we can route through Bedrock (Claude, etc.)
- It's a local-only feature (git integration, file system, SSH, etc.)
- It's a bug fix applicable to shared code paths
- It touches "Warp Drive" but can be rebranded to "Galaxy Drive"
When assessing, also note the **adaptation cost**:
- **Low**: Drop-in (UI fix, terminal behavior, keybindings)
- **Medium**: Needs Bedrock API mapping or minor branding changes
- **High**: Significant refactoring of server-dependent code to work with Bedrock
### 3. Present feature checklist to user
After assessment, present the eligible features to the user using `AskUserQuestion` with `multiSelect: true`. Group by adaptation cost. Include the PR title and a one-line summary of what it does.
Example:
```
Which features would you like to bring over?
Low effort:
- [ ] #10958 - Make worktree menu paths readable for long entries
- [ ] #11099 - Clip terminal view column to prevent split-pane footer overflow
Medium effort:
- [ ] #11049 - Add sleep auto handoff to cloud (needs Bedrock adaptation)
High effort:
- [ ] #10857 - Add orchestration create environment modal (heavy server dependency)
Which PR(s) should I port? Reply with the number(s), or say “none”.
```
### 4. Research selected features
Do not create a branch, apply patches, or edit source files until the user confirms the selected PR number(s). Research and recommendation are allowed before confirmation.
For each selected feature, perform detailed research:
If the search returns no confident match, say so and ask for a PR link, more keywords, or clarification. Do not guess.
1. **Read the PR diff** — use the GitHub API to understand what changed:
## Phase 2: Fetch and inspect only the confirmed PRs
After the user confirms PR numbers, fetch upstream refs if needed:
```bash
git fetch warp master
```
For each confirmed PR, inspect:
- PR title, state, merge commit, and description
- Files changed and additions/deletions
- New dependencies, feature flags, migrations, or generated files
- Whether the change is local-only or depends on Warp services
- Whether Galaxy has renamed or diverged from the affected paths
For local context:
```bash
git log --oneline --all -- <path>
git diff HEAD...warp/master -- <path>
```
## Phase 3: Eligibility decision
Classify each confirmed PR as one of:
### Eligible: direct port
Usually local terminal, editor, UI, completion, parser, filesystem, SSH, theme, or platform bug fixes with limited dependencies.
### Eligible: adapted port
Useful functionality that touches Galaxy provider or branding boundaries but can be redirected safely to Bedrock, OpenAI/LiteLLM, or ACP. Document the adaptation before editing.
### Ineligible
Reject the PR, or only extract isolated local hunks, when it fundamentally depends on Warp-only services such as hosted AI, Warp auth, billing, telemetry, server GraphQL, Warp Drive infrastructure, or Oz orchestration.
When a PR mixes eligible and ineligible changes, do not cherry-pick the whole PR. Port only the eligible files or hunks manually.
Summarize the decision before implementation. If the user asked to implement and the PR is clearly eligible, proceed after the PR confirmation. If the PR has meaningful adaptation risk, explain the risk and ask before making substantial changes.
## Phase 4: Create a focused working branch
Before source changes:
```bash
git switch -c port-warp-pr-<PR>
```
For multiple PRs, use a descriptive branch containing all numbers, or apply them sequentially on one focused branch.
Do not commit unless the user explicitly requests it.
## Phase 5: Apply the smallest safe change
Prefer these strategies in order:
1. Cherry-pick without committing only when the PR is narrowly scoped and service-free:
```bash
curl -s "https://api.github.com/repos/warpdotdev/warp/pulls/<PR>/files?per_page=100"
git cherry-pick -n <merge-commit-or-commit>
```
2. Apply only eligible paths:
```bash
git diff <base> <commit> -- <eligible-paths> | git apply --3way
```
3. Manually port the relevant hunks when Galaxy renamed paths, has diverged, or the PR mixes service and local changes.
2. **Map to local files** — identify corresponding files in our Galaxy fork. Check if the files exist and what state they're in.
Do not use a blanket `git merge warp/master` for this skill.
3. **Identify Bedrock adaptations** — if the feature makes AI/model calls, document:
- What model is being called and how
- What the equivalent Bedrock invocation looks like
- What request/response transformations are needed
Preserve Galaxy naming and adapt upstream imports where necessary:
4. **Identify branding changes** — flag any references to:
- "Warp Drive" → "Galaxy Drive"
- "Oz" → remove or replace
- Warp-specific UI copy that needs updating
- `warpui` → `galaxyui`
- `warpui_core` → `galaxyui_core`
- `warp_core` → `galaxy_core`
- `warp_terminal` → `galaxy_terminal`
- `warp_editor` → `galaxy_editor`
5. **Document dependencies** — note any new crates, feature flags, or config changes needed.
Do not perform repository-wide renames as part of a feature port.
### 5. Write migration plans
## Provider-specific adaptation rules
For each selected feature, create a plan file at:
```
plans/warp-migrations/<PR_NUMBER>-<short-slug>.md
```
### Bedrock and OpenAI/LiteLLM
Each plan should contain:
A PR that adds AI behavior must use Galaxy’s provider dispatch. Adapt request/response types to the existing provider interfaces rather than importing Warp’s AI client or endpoint.
```markdown
# Migration: <PR Title>
### ACP
**Source PR**: warpdotdev/warp#<number>
**Adaptation Cost**: Low | Medium | High
**Date Assessed**: <today>
ACP changes are allowed only when they preserve Galaxy’s ACP runtime, transport, launch, and model-selection architecture. Do not replace ACP with Warp’s hosted agent service or introduce a Warp-specific backend. Inspect relevant files under `app/src/ai/acp/` and the ACP crate before applying upstream changes.
## Summary
<What the feature does, 2-3 sentences>
### Shared agent/blocklist code
## Files Changed (upstream)
<List of files from the PR>
Treat `app/src/ai/agent/` and `app/src/ai/blocklist/` as manual-merge areas. Keep Galaxy’s provider selection, tool handling, persistence, and ACP integration intact even when adopting local UX or controller improvements.
## Local File Mapping
<Corresponding Galaxy files, noting any that don't exist yet>
## API and service leak checks
## Required Adaptations
- <Bedrock changes if any>
- <Branding changes if any>
- <New dependencies if any>
## Implementation Steps
1. <Step 1>
2. <Step 2>
...
## Testing Notes
<How to verify this works in Galaxy>
```
### 6. Spawn implementation agents
For each migration plan, spawn an agent using the `Agent` tool to make the code changes. Key rules for spawning:
- **Agents only write code** — they do NOT run `cargo check`, `cargo build`, or `cargo clippy`
- **Spawn agents in parallel** for independent features (no shared file conflicts)
- **Spawn sequentially** if two features touch the same files
- Each agent's prompt must include:
- The full migration plan content
- The specific files to modify and what changes to make
- Instructions to NOT run cargo commands
- Instructions to report back what files were changed
Example agent prompt structure:
```
You are implementing a Warp feature migration into the Galaxy fork.
Migration plan:
<paste plan content>
Instructions:
- Make ONLY the code changes described in the plan
- Do NOT run cargo check, cargo build, cargo clippy, or any compilation commands
- Adapt any Warp API calls to use Bedrock (see plan for specifics)
- Replace "Warp Drive" with "Galaxy Drive" where applicable
- Remove or skip any "Oz" references
- Report back: list all files you modified and a brief summary of changes
```
### 7. Verify builds (parent agent only)
After all implementation agents complete, the parent agent (you) runs:
Review new code before accepting it:
```bash
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings
grep -RInE 'api\.warp\.dev|warp\.dev/v1|WarpAIService|WarpAiClient|WARP_API_KEY|WARP_AUTH_TOKEN' app/src crates --include='*.rs'
```
If there are errors, fix them directly or re-delegate targeted fixes to agents.
New hits introduced by the port must be removed or adapted. Do not mechanically remove existing compatibility names without checking their purpose.
### 8. Instruct user to test
## Dependencies and generated files
After a clean build, present the user with testing instructions:
For each new dependency:
- List each migrated feature and how to exercise it
- Note any features that need specific configuration or feature flags enabled
- Ask the user to report back any issues they find
- Remind them to test with `cargo run` and verify the features work end-to-end
1. Check whether Galaxy already has an equivalent.
2. Add the smallest local/client-side dependency needed.
3. Reject dependencies that exist only for Warp services, hosted AI, auth, telemetry, or billing.
4. Regenerate code only when the PR genuinely changes a Galaxy-supported schema or generated source.
## Branding Reference
## Validation
| Upstream (Warp) | Galaxy equivalent |
|-----------------------|-----------------------|
| Warp Drive | Galaxy Drive |
| Oz / Orchestrator | Remove or skip |
| Warp AI / Warp Agent | Galaxy AI / Agent |
| warp-server endpoints | Skip (ineligible) |
Run focused checks based on changed files:
## Bedrock Adaptation Patterns
```bash
git diff --check
cargo fmt --all -- --check
```
When adapting AI features from Warp's proxy to Bedrock:
Typical targeted checks include:
- Warp's AI calls typically go through their proxy server — Galaxy calls Bedrock directly
- Look for the existing Bedrock integration patterns in `app/src/ai/` for how Galaxy makes model calls
- Ensure streaming responses are handled correctly (Bedrock uses different event formats)
- Check `WARP.md` "Bedrock Diagnostics" section for debugging tools
```bash
cargo check -p galaxy_terminal
cargo check -p galaxyui
cargo check -p galaxy_editor
cargo check -p galaxy
```
## Related Skills
Also check the ACP crate or affected package when ACP files change. Use the actual package names from the relevant `Cargo.toml` files.
- `fix-errors` — for resolving build failures after migration
- `add-feature-flag` — if the migrated feature needs gating
- `implement-specs` — for larger features that need full specs
For a release-ready port, run:
```bash
./script/format
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings
cargo build
```
Fix errors caused by the port, but do not pull in excluded Warp service code to make the build pass.
## Output report
Report:
- Search description, candidate PRs, and the user’s confirmed selection
- Eligibility decision for each selected PR
- Files and hunks ported
- Bedrock/OpenAI/ACP adaptations made, if any
- Warp-only changes intentionally skipped
- Dependencies or generated files changed
- Validation commands and results
- Any follow-up work or manual testing needed
If a requested PR is too intertwined with Warp's service architecture, recommend a smaller follow-up port or explain which local hunks can be extracted safely.