You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current gw create workflow is fast once the user already knows the workspace name, repository set, branch, tracking mode, and source metadata. In practice, that information often already exists in a pull request, issue, or task URL.
Users still have to translate the source into Grove flags by hand:
Turn an external task or PR URL into a reviewed creation plan and then a ready-to-work Grove workspace, without teaching Grove core about GitHub, GitLab, Linear, Notion, Slack, or any coding agent.
This should become Grove's flagship workflow: task → safe multi-repo workspace.
Proposed user flow
User runs gw grab <url>.
A resolver identifies source metadata, primary repository, branch, and whether the branch should be tracked.
Grove maps the canonical remote to a discovered local repository, cloning it if needed.
Grove suggests a workspace name and repository set:
the primary repository is always included;
the user may choose a preset or additional repositories;
only the primary repository tracks the source branch, while sibling repos create the same branch from their configured bases.
Grove prints a concise plan and asks for confirmation.
The existing workspace service creates the workspace, runs setup, records provenance, and reports readiness/failures.
Source: GitHub PR #123 — Add data-source status
Workspace: feat-data-source-status
Branch: feat/data-source-status
Repos:
api track origin/feat/data-source-status
web create from origin/main
contracts create from origin/main
Architecture
Provider-specific URL resolution belongs in a plugin, not Grove core.
Suggested shape:
A reference gw-grab plugin implements the user-facing command and GitHub PR resolver first.
Define a small, versioned resolver result schema containing:
source provider, URL, ref, and title;
canonical primary repo remote;
branch and branch mode;
suggested workspace name;
optional warnings or provider-specific limitations.
The plugin composes existing stable Grove commands/JSON rather than duplicating worktree orchestration.
If a small core API is needed, keep it provider-neutral and route it through the same workspace lifecycle used by the CLI.
Existing primitives from #48/v1.1.8 already provide most of the foundation: --track, per-repo tracking, source provenance, git URL cloning, and gw repos --json.
MVP: GitHub pull requests
Create and release the gw-grab reference plugin.
Resolve a public or authenticated GitHub PR using gh.
Match owner/repo to a local clone via canonical remote identity.
Clone a missing primary repo into the configured repo directory.
Suggest workspace name, branch, source metadata, and tracking mode.
Allow optional preset/additional-repo selection.
Print a plan and require confirmation unless --yes is passed.
Delegate creation to Grove and preserve source provenance.
Provide useful behavior for fork PRs, missing/deleted remote branches, and ambiguous local clones.
Acceptance criteria
After plugin installation, gw grab <github-pr-url> creates a usable workspace without requiring manual repo or branch flags.
The primary repo contains the PR branch and tracks the correct upstream when possible.
Additional repos use the same branch name from their configured base branches.
gw status --format json preserves the original source metadata.
The plan can be consumed non-interactively and failures return non-zero status.
Resolver and orchestration behavior have unit and e2e coverage.
Typical resolution + workspace creation completes in under 30 seconds, excluding user-defined setup hooks and large first-time clones.
Later providers
Only add these after the GitHub PR flow demonstrates real usage:
GitHub issues
GitLab merge requests/issues
Linear/Jira tasks
Notion/Slack sources
Each should reuse the same resolver contract and workspace plan.
Non-goals
Provider SDKs or task interpretation in Grove core.
Automatically guessing cross-repo dependencies without an explicit preset/blueprint.
Problem
The current
gw createworkflow is fast once the user already knows the workspace name, repository set, branch, tracking mode, and source metadata. In practice, that information often already exists in a pull request, issue, or task URL.Users still have to translate the source into Grove flags by hand:
The desired experience is:
Goal
Turn an external task or PR URL into a reviewed creation plan and then a ready-to-work Grove workspace, without teaching Grove core about GitHub, GitLab, Linear, Notion, Slack, or any coding agent.
This should become Grove's flagship workflow: task → safe multi-repo workspace.
Proposed user flow
gw grab <url>.--agent <name>is requested, Grove composes the containerized handoff from Grove 1.2: Containerized agent workspaces and handoff #64 rather than implementing an agent runtime ingw-grab.Example plan:
Architecture
Provider-specific URL resolution belongs in a plugin, not Grove core.
Suggested shape:
gw-grabplugin implements the user-facing command and GitHub PR resolver first.Existing primitives from #48/v1.1.8 already provide most of the foundation:
--track, per-repo tracking, source provenance, git URL cloning, andgw repos --json.MVP: GitHub pull requests
gw-grabreference plugin.gh.owner/repoto a local clone via canonical remote identity.--yesis passed.Acceptance criteria
gw grab <github-pr-url>creates a usable workspace without requiring manual repo or branch flags.gw status --format jsonpreserves the original source metadata.Later providers
Only add these after the GitHub PR flow demonstrates real usage:
Each should reuse the same resolver contract and workspace plan.
Non-goals
gw-grab; optional handoff composes Grove 1.2: Containerized agent workspaces and handoff #64.Dependencies
gw-grabcomposes instead of private state or duplicated orchestration.--agenthandoff after task/workspace resolution.