Prompt file imported from lhpaul/ronda (
.cursor/commands/run-work.md). Copyright stays with the author.
Cursor Command: Run Work
/run-work is portfolio scan and batch proposal only — a fully read-only
command. It does not advance items directly in any invocation mode.
| Invocation | Routing mode | Action |
|---|---|---|
| No target | no_target_scan |
Protocol 90 scan + propose a batch (no dispatch) |
| Two or more targets | redirect_items |
Stop — re-invoke /run-items <targets> |
| One non-epic target | redirect_item |
Stop — re-invoke /run-item <target> |
Epic-like / --epic |
redirect_epic |
Stop — re-invoke /run-epic --epic <n> |
| Ambiguous target | ambiguous |
Stop — report stopReason; do not mutate |
Run the router first (read-only):
./scripts/development-workflow/run-work-router.sh [<target>...] [--json]For single-item work use /run-item. For bounded multi-item batch execution use
/run-items. For epic-scoped runs use /run-epic.
When mode is no_target_scan, follow Protocol 90 Steps 1–3 (scan + propose)
only. Do not dispatch items under /run-work:
For multi-item implementation proposals, include Protocol 90's planless overlap
disposition from workflow-batch-overlap.sh. Concrete pairs and unconfirmed
suspected pairs are serialized by default, and the proposal must show pair IDs,
typed evidence, evidence hashes, and held-item reasons.
In workflow_hub, preserve selected product repository context in
implementation handoffs so mutation-oriented follow-up commands can route the
artifact owner, local path or remote identity, and PR/reviewer/cleanup work
without re-resolving or guessing.
Render the scan output with Protocol 90 report categories kept separate:
INFORMATIONAL - not actionable in this proposal,
ACTIONABLE RESUME - can advance now,
PROPOSED BATCH - your decision, and
HELD - not included in proposed batch. The recommended approval or
/run-items command applies only to PROPOSED BATCH - your decision items;
informational records are excluded unless the operator explicitly names them in
a separate bounded command.
docs/workflow/development-workflow/protocols/90-batch-orchestrate-work-protocol.md
Routing specification: docs/workflow/development-workflow/protocols/96-run-work-routing-protocol.md
Cursor dispatch profile
In a Cursor environment only, declare the dispatch profile in force before any
mutating action, or before a /run-work scan reports — cursor-native-handoff,
cursor-parent-orchestrated, or
cursor-inline-fallback — naming the Portfolio Orchestrator (portfolio layer) as the
accountable orchestration role, with a posture valid for the current checkpoint. Other runners are unaffected by
this requirement.
Evaluation order, unconfirmed-handoff outcomes, accountability postures, the
named stop conditions and their human unblocking actions, and the
invalid-declaration boundaries are defined once, normatively, in
docs/workflow/development-workflow/integrations/cursor-dispatch-profiles.md.
Follow that document; this surface deliberately does not restate it.
Canonical GitHub Projects scan evidence
In no-target scan mode, use bash scripts/development-workflow/workflow-portfolio-scan.sh --json
and render the complete invocation report under Protocol 90 Step 1a. Do not
follow it with live board/tracker/PR reads or a historical-folder sweep.
Snapshot-aware batch/next-action classification is scoped to this repository,
project and invocation and never falls back to live reads. Other providers keep
their existing Protocol 90 paths; bounded commands always resolve fresh evidence.
Report Full scan, Partial scan (budget-limited), or Scan deferred (budget too low),
the named reason, GraphQL spend/remaining/reset and warnings, skipped work and
all four distinct portfolio categories. Propose only fully read eligible records;
partial coverage excludes new Backlog starts. The reserve and ordered decisions
are canonical in Protocol 90, including its adjacent manual archival guidance.
