Problem
Today flow do <task> either resumes the existing session or
spawns a fresh one — there's no way to inject a one-shot
instruction at resume time. Same for the start path. This
blocks playbook-style automation that wants to nudge a parked
task on a trigger without manually opening the tab and typing.
Proposal
Add an optional instruction payload to flow do:
flow do <task> --with "<instruction>"
flow do <task> --with-file path/to/instruction.md
When provided, flow injects the instruction as the first user
message of the resumed/started session, after the bootstrap
contract runs. Behaves like the user typed it themselves.
Use case — playbook on a parked task
A scheduled playbook fires on some trigger (cron, external
webhook, status change) and wants to do "the thing" on a
specific parked task — e.g. "check if the upstream PR merged
and if so, update the brief and unpark." Today this requires
the user in the loop. With --with, the playbook can:
flow do <parked-task> --with "<playbook-specific instructions>"
- Session resumes, runs the instruction against the task's
full context (brief, updates, KB), reports back.
- Playbook closes the loop.
Open questions
- Should
--with work on a done task (auto-rollback to
in-progress like flow update task --status), or require
explicit unpark first?
- Interaction with
--fresh: does --with on a fresh session
replace or append to the bootstrap?
- How does the trigger source identify itself in the injected
message? (e.g. prefix with [playbook:<slug>] ...)
Problem
Today
flow do <task>either resumes the existing session orspawns a fresh one — there's no way to inject a one-shot
instruction at resume time. Same for the start path. This
blocks playbook-style automation that wants to nudge a parked
task on a trigger without manually opening the tab and typing.
Proposal
Add an optional instruction payload to
flow do:When provided, flow injects the instruction as the first user
message of the resumed/started session, after the bootstrap
contract runs. Behaves like the user typed it themselves.
Use case — playbook on a parked task
A scheduled playbook fires on some trigger (cron, external
webhook, status change) and wants to do "the thing" on a
specific parked task — e.g. "check if the upstream PR merged
and if so, update the brief and unpark." Today this requires
the user in the loop. With
--with, the playbook can:flow do <parked-task> --with "<playbook-specific instructions>"full context (brief, updates, KB), reports back.
Open questions
--withwork on adonetask (auto-rollback toin-progress like
flow update task --status), or requireexplicit unpark first?
--fresh: does--withon a fresh sessionreplace or append to the bootstrap?
message? (e.g. prefix with
[playbook:<slug>] ...)