Skip to content

Let every dstack command take a project or ticket argument - #7

Open
petaltank wants to merge 2 commits into
feat/roadmap-0.4from
feat/command-args
Open

petaltank wants to merge 2 commits into
feat/roadmap-0.4from
feat/command-args

Conversation

@petaltank

Copy link
Copy Markdown
Collaborator

Summary

Roadmap item 1 (meta/roadmap-0.4.md). Based on #6 so it can tick the roadmap row and append to the 0.4.0 — unreleased changelog heading; GitHub retargets it to master once #6 merges.

  • /dstack-ticket <project | ticket-id | LINEAR-ID>, /dstack-yolo <project | ticket-id>, /dstack-retro <project>, /dstack <project> — new Step 0 in each command resolves $ARGUMENTS in a fixed order (project folder → local ticket id → Linear id → "nothing matched, say so").
  • A project argument skips the which-project question. A ticket argument makes that ticket the proposed pick (or yolo's starting point).
  • Nothing that's a gate moves. Findings scan still runs first; the proposed ticket still has to be on the eligible frontier with every dependency checked against the code on disk. If not, the command names the unmet dependency and falls back to its normal pick.
  • harnesses/_template/README.md records the argument as an adapter requirement; README walkthrough step 7 + a new FAQ entry show the form.

Verification

  • ./install.sh --harness claude-code <scratch> — all command files land with the new argument-hint front matter.
  • Read each Step 0 against the Step 3 findings gate and Step 4/5 dependency check for contradictions — none.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NLMK6F3vQ1HzyU1Mxqt6Kr

petaltank and others added 2 commits September 11, 2026 14:49
/dstack-ticket, /dstack-yolo, /dstack-retro, and /dstack accept an optional target: a
project folder name, a local ticket id, or (dstack-ticket only) a Linear identifier. A
project argument skips the which-project question; a ticket argument proposes that ticket
as the pick or the loop's starting point.

No gate moves. The findings scan still runs first, and a proposed ticket still has to be
on the eligible frontier with dependencies verified against the code on disk — otherwise
the command names the unmet dependency and falls back to its normal pick. An argument that
matches nothing is reported, never guessed at.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NLMK6F3vQ1HzyU1Mxqt6Kr
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NLMK6F3vQ1HzyU1Mxqt6Kr
Comment on lines +21 to +25
- **An optional target argument on each command** — a project name, or a ticket id, so a
user who already knows what they want doesn't answer a question they've already answered.
The argument selects or *proposes*; it must never bypass the findings scan or the
dependency check — see `claude-code/commands/dstack-ticket.md` Step 0 for the resolution
order and the "moves nothing that's a gate" rule.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that we need README files to have this sort of "detail" right? This should be more or less exclusively written for humans I think.

Comment on lines +17 to +28
1. **Nothing given** → the rest of this command runs exactly as written below.
2. **A folder name under `doc/dstack/`** → that project is selected; skip the "which project"
question in Step 2.
3. **A local ticket id** (`D3`, `T12` — whatever ids the project's `TODO.md` uses) found in
exactly one project's `TODO.md` → that project is selected **and** the ticket becomes the
**proposed pick**. If the id appears in more than one project's `TODO.md`, ask which.
4. **A Linear identifier** (`KAI-123` — uppercase team key, dash, number) → Fork A. Find the
project whose living doc links that issue; if none does, ask which project. The issue's
live state comes from Linear MCP in Step 4 as usual — if MCP isn't available, say so
plainly rather than guessing from the checkbox.
5. **Nothing matched** → say what was tried ("no project or ticket named `foo`") and fall
through to the normal flow. Don't invent a match.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we could use Claude Code's function hooks (soon to be released) to make a process like this deterministic, rigid and reliable (or at least more so). I'm sure this will work quite well though, I was working with something similar for a couple weeks reliably.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant