work-items(work-loop): no argument surface — scope, ordering, and mode live in prose the skill never reads

[kyle-sexton]

This was generated by AI during a loop-lane launch-prompt design session.

Context

/work-items:work-loop takes no arguments; its frontmatter states cycle behavior "comes from the
launch prompt's standing rules and persisted config." In practice that pushes every per-run
choice into prose the operator must re-paste, and prose is not enforcement: a launch prompt
cannot reorder selection, cannot raise a merge rung, and cannot narrow scope in any way the skill
actually reads.

/source-control:babysit-loop does better — it takes <owner/repo> [tier] [--drain] plus
per-dimension overrides — but the two lanes are inconsistent, and neither exposes the knobs an
operator running a fleet actually reaches for.

Concretely, running the same lane across several machines against one repository requires giving
each machine a different slice of the work. There is no argument for that today, so the operator
writes prose that the skill ignores.

Separately, per-mode instruction text loads regardless of the mode in play, so a safe-tier run
carries autopilot-only contract text into context and vice versa.

Proposed work

• Give work-loop an argument surface: repository scope, ordering strategy, and mode.
• Where an argument would be inert because the value binds from a config seam, say so in the
  argument-hint rather than accepting it silently.
• Apply progressive disclosure so per-mode instructions live in mode-scoped files loaded on
  demand, keeping a single mode's context clean.

Acceptance criteria

• work-loop accepts scope and mode arguments, documented in argument-hint
• An argument that cannot bind (seam-only, e.g. merge rung) is rejected with a clear message
  rather than silently ignored
• Per-mode instruction text is not loaded for modes that are not running
• Two lanes on one repository can be given non-overlapping slices by argument

References

• plugins/work-items/skills/work-loop/SKILL.md (no arguments)
• plugins/source-control/skills/babysit-loop/SKILL.md (argument surface, tier flooring)
• plugins/work-items/skills/work/SKILL.md (Selection Priority — ordering is fixed)

Metadata

Found while writing repeatable launch prompts for three lanes across three machines. The prompts
had to carry ordering preferences that the skill does not read.

[kyle-sexton]

This was generated by AI during triage.

Verified

Confirmed against plugins/work-items/skills/work-loop/SKILL.md frontmatter at this commit:

argument-hint: "(no arguments — cycle behavior comes from the launch prompt's standing rules and persisted config)"

The skill genuinely takes no arguments, exactly as filed. The contrast with /source-control:babysit-loop (which takes <owner/repo> [tier] [--drain]) is real.

Classification

• Work class: C3 scoped — an argument surface plus progressive-disclosure restructuring, bounded by the skill's own files.
• Priority: medium (no directive or severity signal sets it higher; the inertness is a usability gap, not a correctness failure).

Blocked by #1295 — cluster member, not separately human-gated

Carries a blocked-by edge to #1295 and deliberately no human-gated label; resolving #1295 unblocks this without a second human touch.

The shared decision: acceptance criterion 4 — "two lanes on one repository can be given non-overlapping slices by argument" — presupposes that multi-lane-per-repository is a supported configuration. #1295 shows that configuration currently corrupts durable state and explicitly offers "declare it unsupported" as a live alternative. If that alternative wins, this item's slicing argument is designing a surface for a configuration the skill refuses, and the scope collapses to the remaining two criteria.

Independent of #1295, and safe to carry forward under either branch:

• The progressive-disclosure criterion (per-mode instruction text not loaded for modes not running) is a pure context-hygiene improvement with no multi-lane dependency.
• The inert-argument criterion (an argument that cannot bind is rejected with a clear message rather than silently ignored) is likewise independent.