The product gap (not a parity gap)
Workflow mode, goal mode, and auto mode all shipped and work. But from a
user's chair:
/workflow synthesizes a script from conversation context every time. The
six built-in workflow scripts we ship (workflows/*.workflow.js —
operate_best_of_n, parallel_scout, read_audit, staged_fix, issue_audit,
stopship) are never offered anywhere. A user cannot list them, read what
they do, or launch one by name.- Goal mode is set via
/config goal. There is no visible entry point from
the main surface; nothing tells a new user it exists.
- Auto mode parity landed, but the decision "should this ask be a goal, a
workflow, or plain auto?" is undocumented at the point of use.
References exist (Grok /workflows run dashboard + /deep-research preset;
dsh dsh-goal/dsh-workflow presets) but this issue is NOT parity-driven —
those are terrible products too. This is product management: a feature a
user can't see doesn't exist.
Proposal (product-minded)
/workflow with no args → a visible catalog/dashboard, not a silent
context-synthesis start: list built-in workflows (name, one-line what it
does, source), plus live/retained runs with phase/roster/progress à la
grok's run dashboard. Enter launches; ? shows the script. Saved
user workflows (~/.codewhale/workflows/) join the same catalog.- Explicit objective stays:
/workflow <objective> keeps current
synthesis behavior; /workflow run <name> launches a named built-in or
saved script directly.
- The trio is a visible choice, not config archaeology: wherever modes
are surfaced (status bar mode segment / mode picker), goal/workflow/auto
appear as siblings with one-line "when to use this" copy.
- Each built-in workflow gets a real description in its front-matter
that the catalog renders — written for a user deciding, not for the
engine.
Acceptance
Notes
The product gap (not a parity gap)
Workflow mode, goal mode, and auto mode all shipped and work. But from a
user's chair:
/workflowsynthesizes a script from conversation context every time. Thesix built-in workflow scripts we ship (
workflows/*.workflow.js—operate_best_of_n, parallel_scout, read_audit, staged_fix, issue_audit,
stopship) are never offered anywhere. A user cannot list them, read what
they do, or launch one by name.
/config goal. There is no visible entry point fromthe main surface; nothing tells a new user it exists.
workflow, or plain auto?" is undocumented at the point of use.
References exist (Grok
/workflowsrun dashboard +/deep-researchpreset;dsh
dsh-goal/dsh-workflowpresets) but this issue is NOT parity-driven —those are terrible products too. This is product management: a feature a
user can't see doesn't exist.
Proposal (product-minded)
/workflowwith no args → a visible catalog/dashboard, not a silentcontext-synthesis start: list built-in workflows (name, one-line what it
does, source), plus live/retained runs with phase/roster/progress à la
grok's run dashboard. Enter launches;
?shows the script. Saveduser workflows (
~/.codewhale/workflows/) join the same catalog./workflow <objective>keeps currentsynthesis behavior;
/workflow run <name>launches a named built-in orsaved script directly.
are surfaced (status bar mode segment / mode picker), goal/workflow/auto
appear as siblings with one-line "when to use this" copy.
that the catalog renders — written for a user deciding, not for the
engine.
Acceptance
/workflow(no args) renders built-ins + saved scripts + live runs;launching one is ≤2 keystrokes from an empty prompt.
/config goal), with status/pause/resume/clear visible once active.explained trio.
not the engine.
Notes
AUTO_MODE_PARITY.md); this issue is the visibility layer over working
machinery — no engine rework implied.
remain separate; this issue does not depend on them.