Describe the feature or problem you'd like to solve
The current /fleet and subagent model is already very useful. Task-scoped delegation helps reduce noise and makes parallel work practical.
That said, I’d like an optional fork-like mode where a subagent can inherit a richer view of the parent task’s global context before focusing on a specific domain.
This would help in workflows where a generalist is solving a broad problem, temporarily switches into a specialist mode for one part of it, and then returns with a solution that is still aligned with the overall goal.
Today, task-scoped delegation can sometimes increase communication overhead or lead to small mismatches in goals, constraints, or architectural intent.
Proposed solution
Add an optional context inheritance mode for /fleet subagents.
For example:
minimal: current task-scoped behaviorbalanced: task context plus parent goals, constraints, and prior decisionsforked / full: a richer inheritance of the parent task context before specializing
This would preserve the strengths of the current model while giving users a better option for subtasks that still need strong global awareness.
Conceptually, this is similar to a strong full-stack engineer working on a broad problem, temporarily switching into a more specialized mode for one part of it, and then returning with a result that is still aligned with the bigger picture.
The main benefit is reducing:
- communication cost
- goal-misalignment cost
- local optimizations that are correct in isolation but weaker in the broader task context
Example prompts or workflows
-
Refactor an API across backend, frontend, tests, and docs while preserving backward compatibility.
-
Split a migration into schema, app, test, and doc subtasks, while keeping rollout and rollback constraints aligned.
-
Investigate a bug across multiple layers, delegate one area deeply, then merge the result back into the broader solution.
-
Tackle a large cross-cutting cleanup where each subtask still depends on shared architectural intent.
-
Work on a broad product or engineering task as a generalist, then temporarily delegate one part to a more domain-focused subagent without losing alignment with the parent task’s overall direction.
Additional context
I’m not suggesting that the current /fleet behavior should change by default. I think the current /fleet and subagent model is good.
This request is specifically for an additional fork-like mode that helps when a subtask benefits from temporarily carrying more of the parent task’s full context.
A possible UX could be something like:
/fleet --context=minimal/fleet --context=balanced/fleet --context=forked
or another mechanism that expresses the same idea.
Describe the feature or problem you'd like to solve
The current
/fleetand subagent model is already very useful. Task-scoped delegation helps reduce noise and makes parallel work practical.That said, I’d like an optional fork-like mode where a subagent can inherit a richer view of the parent task’s global context before focusing on a specific domain.
This would help in workflows where a generalist is solving a broad problem, temporarily switches into a specialist mode for one part of it, and then returns with a solution that is still aligned with the overall goal.
Today, task-scoped delegation can sometimes increase communication overhead or lead to small mismatches in goals, constraints, or architectural intent.
Proposed solution
Add an optional context inheritance mode for
/fleetsubagents.For example:
minimal: current task-scoped behaviorbalanced: task context plus parent goals, constraints, and prior decisionsforked/full: a richer inheritance of the parent task context before specializingThis would preserve the strengths of the current model while giving users a better option for subtasks that still need strong global awareness.
Conceptually, this is similar to a strong full-stack engineer working on a broad problem, temporarily switching into a more specialized mode for one part of it, and then returning with a result that is still aligned with the bigger picture.
The main benefit is reducing:
Example prompts or workflows
Refactor an API across backend, frontend, tests, and docs while preserving backward compatibility.
Split a migration into schema, app, test, and doc subtasks, while keeping rollout and rollback constraints aligned.
Investigate a bug across multiple layers, delegate one area deeply, then merge the result back into the broader solution.
Tackle a large cross-cutting cleanup where each subtask still depends on shared architectural intent.
Work on a broad product or engineering task as a generalist, then temporarily delegate one part to a more domain-focused subagent without losing alignment with the parent task’s overall direction.
Additional context
I’m not suggesting that the current
/fleetbehavior should change by default. I think the current/fleetand subagent model is good.This request is specifically for an additional fork-like mode that helps when a subtask benefits from temporarily carrying more of the parent task’s full context.
A possible UX could be something like:
/fleet --context=minimal/fleet --context=balanced/fleet --context=forkedor another mechanism that expresses the same idea.