What task are you trying to do?
We want PawWork to help users and models agree on a plan for complex, ambiguous, or high-impact work without exposing a separate Plan Mode that users need to understand or toggle.
What do you do today?
The current plan design leans toward mode-level behavior and heavier planning workflows. That adds product complexity for non-technical users, and it can make the harness feel like a developer tool rather than an assistant that naturally asks before acting.
What would a good result look like?
plan is an ordinary model-callable tool. The model uses it when a task is complex, ambiguous, or high impact. The user sees a simple approval card such as "I plan to do this. Continue?" Before approval, the harness blocks mutating tools such as edit, write, trash, and high-risk bash through hidden internal state. There is no user-visible Plan Mode, no plan toggle, no mandatory plan file, no forced subagent, and no forced multi-option workflow.
Which audience does this matter to most?
Both
Extra context
Use the collaborative style we liked from the brainstorming workflow: understand first, ask focused questions when needed, recommend a path with trade-offs, then get approval before acting. Do not copy its spec-writing or developer-flow mechanics.
Acceptance criteria
- No user-visible Plan Mode is required for normal use.
plan remains a tool the model can call naturally.
- The user-facing approval is simple and understandable for non-technical users.
- Mutating actions are blocked before approval only through hidden harness state.
- Long plan files, mandatory multi-approach output, and forced subagent use are out of scope.
What task are you trying to do?
We want PawWork to help users and models agree on a plan for complex, ambiguous, or high-impact work without exposing a separate Plan Mode that users need to understand or toggle.
What do you do today?
The current plan design leans toward mode-level behavior and heavier planning workflows. That adds product complexity for non-technical users, and it can make the harness feel like a developer tool rather than an assistant that naturally asks before acting.
What would a good result look like?
planis an ordinary model-callable tool. The model uses it when a task is complex, ambiguous, or high impact. The user sees a simple approval card such as "I plan to do this. Continue?" Before approval, the harness blocks mutating tools such as edit, write, trash, and high-risk bash through hidden internal state. There is no user-visible Plan Mode, no plan toggle, no mandatory plan file, no forced subagent, and no forced multi-option workflow.Which audience does this matter to most?
Both
Extra context
Use the collaborative style we liked from the brainstorming workflow: understand first, ask focused questions when needed, recommend a path with trade-offs, then get approval before acting. Do not copy its spec-writing or developer-flow mechanics.
Acceptance criteria
planremains a tool the model can call naturally.