From fleet
Spawn one or many parallel Claude agents on Jira tickets, with full-auto mode and Jira-aware prompt construction. Single-ticket form replaces a manual bytedesk-feature-start when you already know the ticket; multi-ticket form fires N sessions in parallel ("kick off the whole sprint"). Use when the user says "fleet spawn", "/fleet:spawn", "kick off these tickets", "spawn agents for", "/fleet:spawn BDP-N BDP-M", or any phrasing about launching one or more sessions from existing Jira tickets.
npx claudepluginhub bytedeskai/bytedesk-marketplace --plugin fleet<BDP-N> [BDP-M ...] # one or more existing Jira ticket keysThis skill is limited to using the following tools:
Spawns one or more sessions in the multi-session command center, with each session's prompt auto-built from its Jira ticket description. Every spawn:
Prevents silent decimal mismatch bugs in EVM ERC-20 tokens via runtime decimals lookup, chain-aware caching, bridged-token handling, and normalization. For DeFi bots, dashboards using Python/Web3, TypeScript/ethers, Solidity.
Share bugs, ideas, or general feedback.
Spawns one or more sessions in the multi-session command center, with each session's prompt auto-built from its Jira ticket description. Every spawn:
/tmp/<TICKET>-prompt.txt (ticket context + applicable rule files + safety rails + exit condition).spawn-claude-feature <TICKET> <slug> --prompt-file /tmp/<TICKET>-prompt.txt --full-auto.For new feature work without a ticket yet, use /bytedesk-feature-start instead — it handles ticket creation. This skill assumes the tickets already exist.
Three facts about the spawn-claude-feature runtime that any wrapper skill (or any human writing prompts for it) needs to know:
Every spawned session runs in a fresh git worktree under <repo>/.claude/worktrees/<TICKET>-<slug>/. It's a clean checkout — there's no shared node_modules/, bin/obj/, .next/, .venv/, or any other dep/build state from the parent tree. If the work needs to build, the prompt must include the install/restore step explicitly:
npm install (or pnpm install / yarn per the project's lockfile)dotnet restorepip install -r requirements.txt or uv syncWrapper skills should match the language stack and inject the right command before any compile/test step in the prompt template they write.
--full-auto semantics--full-auto adds --dangerously-skip-permissions to the spawned claude. The session can run any command without asking — git push, rm, anything. Safety must be encoded in the prompt itself (the "Hard constraints" block in the template below). Omit --full-auto only when the work touches something destructive enough that step-by-step approval is warranted.
--prompt-file is requiredUse spawn-claude-feature ... --prompt-file PATH, never an inline prompt string. Two reasons:
Always write the prompt to a temp file (/tmp/<TICKET>-prompt.txt is the convention) and pass the path.
For each ticket key in the arguments:
mcp__plugin_atlassian_atlassian__getJiraIssue (cloudId bytedesk.atlassian.net, format markdown). If status is Done, refuse with a clear message — don't re-spawn closed work.BDP-N=my-slug, use that instead.getTransitionsForJiraIssue to find the transition id; usually 21 for BDP)./tmp/<TICKET>-prompt.txt using the Prompt template below. Pull in the ticket's description verbatim.spawn-claude-feature <TICKET> <TICKET>-<slug> --prompt-file /tmp/<TICKET>-prompt.txt --full-auto./fleet suggestion.If multiple tickets are passed, do them in parallel where possible: fetch tickets and write prompt files concurrently, then sequence the spawns one after another (each spawn is fast — <2s — and sequencing them avoids the rare race on tmux session creation).
You are picking up Jira ticket <TICKET> in a fresh worktree on branch feature/<TICKET>-<slug>.
Read first:
1. https://bytedesk.atlassian.net/browse/<TICKET>
(use mcp__plugin_atlassian_atlassian__getJiraIssue with cloudId=bytedesk.atlassian.net)
2. The applicable rule files in .claude/rules/ for this work-type:
<list rules based on summary keywords: frontend.md, backend.md, database.md, kubernetes.md, etc>
3. Any ADRs in docs/architecture/adr/ relevant to the area being changed.
Ticket description (verbatim):
<insert ticket description from getJiraIssue>
Hard constraints (full-auto safety):
- Never `git push --force`.
- Never modify CI workflows or repository settings.
- Never touch sibling worktrees in .claude/worktrees/.
- Stop and post a one-paragraph plan in this terminal BEFORE writing code.
Wait 30s for the user to intervene; if no intervention, proceed.
- Open the PR with `/bytedesk-pr-ready` when the work is green.
- When merged: comment on <TICKET> with the PR link + commit SHA, then transition to Done.
Exit when: PR is merged, Jira is Done, you've left a brief lessons summary in the chat.
Spawned 3 sessions:
BDP-360 · feature/BDP-360-project-dns-host-ui · https://bytedesk.atlassian.net/browse/BDP-360
BDP-361 · feature/BDP-361-deploy-tab-redesign · https://bytedesk.atlassian.net/browse/BDP-361
BDP-362 · feature/BDP-362-virtualized-file-tree · https://bytedesk.atlassian.net/browse/BDP-362
Dashboard: http://127.0.0.1:7681/
Status: /fleet
If only one ticket was spawned, drop the count line; just print the single session.
/fleet:spawn BDP-360
/fleet:spawn BDP-360 BDP-361 BDP-362
/fleet:spawn BDP-360=dns-host-ui # custom slug for one ticket
/fleet:spawn BDP-360 BDP-361=deploy-tab BDP-362 # mix of default and custom