Skip to content

/dobby:backlog: apply user-provided inline triage + name the stale-CLI degradation (no tracker command) #39

Description

@kvnwolf

Two amendments to /dobby:backlog, both surfaced by the same field session (a consumer repo on the Linear backend, 2026-08-03).

1. Optional inline triage — apply what the user provides, still never ask

The skill's no-interrogation rule ("Skip priority/assignee — don't interrogate") is correct: capture-time triage invented by the agent without backlog context is noise that later reads as deliberate signal. But when the capture request itself carries triage — "priority high, this cycle", "assign it to me, 2 points" — the skill currently has no sanctioned way to apply it, so the item lands bare in Backlog and the user immediately issues a second request to triage the item they just captured. That round-trip is pure friction, and exactly what happened in the field session: quick-capture, then the very next message was "ok, triage the issue you just created; assign it to me, set priority, estimate, and put it in the current cycle."

Amendment: after creating the item, apply any triage fields the user explicitly provided in the request (priority, estimate, cycle/milestone, assignee, relations) — and never prompt for the ones missing. The anti-interrogation rule stays intact; the change only removes the forced second pass when the decision was already in the user's head.

2. Name the stale-CLI degradation branch (tracker command missing)

Step 1 instructs bunx dobby tracker info --json / tracker search / tracker create. In the field session the consumer repo pinned an older dobby whose CLI has no tracker command at all — every invocation died with unknown command: tracker (plus the CLI's own hint if this command is expected, run 'bun update @kvnwolf/dobby'). The skill documents degradedTo: "local" (backend unreachable) but not this case: the skill is newer than the installed CLI, which is the normal state of the world for any consumer repo that hasn't bumped since the tracker commands shipped.

The session degraded sensibly on its own — it announced the mismatch, then executed the capture directly through the tracker's MCP (Linear) with manual concept-level dedup against the full issue list. The skill should sanction exactly that: if tracker is not a known command, (a) say so and suggest bun update @kvnwolf/dobby, (b) fall back to the backend's native interface (Linear MCP / gh) keeping the skill's dedup-by-concept and body-shape rules, which are CLI-independent. Same spirit as the existing degraded branch — just a second, distinct trigger.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions