Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

spec-and-dispatch

Étoiles6

Forks0

Mis à jour19 avril 2026 à 23:55

Use this skill whenever the user wants to take an existing ticket / issue, run the Sandstorm spec quality gate on it, and then (once it passes) create a stack with the ticket's verbatim body as the initial task. Trigger phrases include: 'take ticket N and build it', 'spec and dispatch N', 'fire up a stack for ticket N', 'let's work on #N', 'start issue N in a stack', 'create a stack for issue N, run the gate first'. This skill is the full start-to-dispatch flow for a ticket: fetch ticket → spec_check → (refine loop if needed) → create_stack with gateApproved=true and the ticket body as the initial task. Do NOT trigger for: dispatching follow-up work to an EXISTING stack (that's the sandstorm / check-and-resume flow), running the spec gate in isolation (that's the sandstorm-spec skill), or creating a stack without a ticket.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

onomojo

onomojo/sandstorm-desktop

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Spécialistes en gestion de projetsProfessions des affaires et des opérations financières·SOC 13-1082

Explorateur de fichiers

2 fichiers

SKILL.md

readonly

name

spec-and-dispatch

description

/spec-and-dispatch

End-to-end flow from a ticket number to a running stack.

Extract from the user's message

Ticket ID (required)
Stack name (optional — if missing, ask the user. A good default is derived from the ticket slug, e.g. fix-auth-bug-28, but let the user confirm.)

Run the gate first

bash "$SANDSTORM_SKILLS_DIR/spec-and-dispatch/scripts/spec-and-dispatch.sh" check <ticket-id>

The script prints the spec_check result payload. Three outcomes:

Passed (passed:true) → proceed to "Create the stack" below.

Gaps (passed:false with questions) → present the questions to the user. On their reply:

echo "<user's answers verbatim>" | bash "$SANDSTORM_SKILLS_DIR/spec-and-dispatch/scripts/spec-and-dispatch.sh" refine <ticket-id>

Loop through questions/answers until passed:true.

Error → relay to the user; stop.

Create the stack

Once the gate passes, confirm the stack name with the user if you don't already have one. Then:

bash "$SANDSTORM_SKILLS_DIR/spec-and-dispatch/scripts/spec-and-dispatch.sh" create <ticket-id> <stack-name>

The script fetches the ticket body verbatim and dispatches it as the initial task with gateApproved:true. No summarization, no rewrite — the ticket is the source of truth per feedback_pass_issue_verbatim.md. It prints OK stack=<name> ticket=<n> task=<task-id> or ERROR phase=<where> reason=<...>.

Relay the result.

Hard rules

Never summarize or rewrite the ticket body. The script passes it verbatim; don't try to "improve" it.
Never set branch: main. Omit the branch arg — it defaults to the stack name.
Never skip the gate by calling create before check succeeds. The spec-gate pass is the precondition for dispatch.
Never call spec_check, spec_refine, or create_stack MCP tools directly. This skill is the only path for this workflow.
One ticket per invocation.

Plus depuis ce dépôt

même dépôt

stack-failure-diagnostic

onomojo/sandstorm-desktop

Use this skill when the user reports a stack appears broken, stuck, looping, failed, or otherwise not working — and wants to understand WHY (not just restart it). Trigger phrases include: 'stack N doesn't seem to be working', 'stack N isn't working', 'stack N failed for some reason / why did stack N fail / what went wrong with stack N', 'stack N seems stuck / got stuck / stuck in an infinite loop / keeps looping / did N loops and failed', 'take a look at stack N, something went wrong / it's broken / something's clearly wrong', 'stack N hit NEEDS HUMAN INTERVENTION / keeps failing / errored out', 'figure out what's happening / going on with stack N', 'give me a summary of what happened with stack N / diagnose stack N'. The skill reads the stack's dual-loop artifacts (phase timings, review verdicts, execution summaries) from inside its container and returns one structured report — avoiding the 40+ Bash-exploration sub-turns the orchestrator would otherwise make. Make sure to use this skill for ANY request that

2026-04-216

check-and-resume-stack

onomojo/sandstorm-desktop

Use this skill whenever the user asks to CHECK the status of an existing stack AND optionally RESUME it if it's not finished. Trigger phrases include: 'check stack N', 'is stack N done', 'what's the status of stack N', 'is N finished', 'pick up where N left off', 'resume stack N', 'we paused stack N can you continue', 'take a look at stack N and if it's not done start it again'. The skill is for EXISTING stacks the user names explicitly by ID — not for new stack creation. Prefer this skill over the generic sandstorm skill whenever the user's intent is a status-check-then-maybe-resume pattern on one named stack; this skill collapses what would otherwise be 10+ MCP calls into a single script. Do NOT trigger for: creating new stacks, dispatching new work, reviewing diffs on demand, tearing down stacks, or listing multiple stacks.

2026-04-206

list-stacks

onomojo/sandstorm-desktop

Use this skill whenever the user asks for a listing / overview / enumeration of their Sandstorm stacks. Trigger phrases include: 'list my stacks', 'what stacks do I have', 'show me all my stacks', 'list stacks', 'what's running', 'give me a rundown of the stacks', 'which stacks are active'. This is a pure listing — it returns every stack with its status and services. Do NOT trigger for: asking about ONE specific stack (that's check-and-resume-stack or stack-inspect), creating a new stack (that's spec-and-dispatch), or any action on a stack.

2026-04-196

stack-inspect

onomojo/sandstorm-desktop

Use this skill whenever the user wants to see DETAILED output, logs, or uncommitted changes from a specific Sandstorm stack. Trigger phrases include: 'show me the output of stack X', 'what did stack X log', 'show the task output for X', 'show container logs for stack X', 'what changed in stack X', 'show me the diff in stack X', 'what's happening inside stack X', 'dump stack X's output', 'get logs for stack X's claude container'. The skill covers three read-only probes — task output, container logs, and uncommitted diff — as subcommands. Do NOT trigger for: a quick status check (that's check-and-resume-stack), listing all stacks (that's list-stacks), or anything that modifies state. Prefer the narrower subcommand (output / logs / diff) over 'all' when the user is specific about what they want.

2026-04-196

review-and-pr

onomojo/sandstorm-desktop

Use this skill whenever the user is ready to publish the work from an existing Sandstorm stack — reviewing the diff, pushing to its branch, opening a pull request, and recording the PR on the stack. Trigger phrases include: 'make a PR for stack X', 'publish stack X', 'push and PR stack X', 'the diff looks good, ship it', 'open a pull request for stack X', 'finalize stack X', 'commit and push stack X to a PR'. This is the end-of-workflow publish step for a stack that has completed its task and whose diff the user has seen (or is about to see via this skill). Do NOT trigger for: pushing WITHOUT a PR, creating a stack from scratch, dispatching new work, or any workflow where there are no changes to publish. Do NOT trigger if the stack is still running — the skill assumes the task is finished.

2026-04-196

stack-pr

onomojo/sandstorm-desktop

Use this skill whenever the user wants to record/link/associate a pull request with an existing Sandstorm stack. Trigger phrases include: 'record PR #N for stack X', 'set PR for stack X to #N', 'link PR https://github.com/.../pull/N to stack X', 'save the PR info on stack X', 'stack X's PR is #N'. Use this after a PR has been opened externally (via gh CLI, the GitHub UI, or push_stack's downstream flow) and the user wants the Sandstorm registry to know about it — the stack status flips to pr_created and the URL/number are stored. Do NOT trigger for: creating the PR itself (that's a separate gh CLI / push flow), tearing down the stack, checking stack status, or unrelated PR operations like merging or closing.

2026-04-196

name

spec-and-dispatch

description

/spec-and-dispatch

End-to-end flow from a ticket number to a running stack.

Extract from the user's message

Ticket ID (required)
Stack name (optional — if missing, ask the user. A good default is derived from the ticket slug, e.g. fix-auth-bug-28, but let the user confirm.)

Run the gate first

bash "$SANDSTORM_SKILLS_DIR/spec-and-dispatch/scripts/spec-and-dispatch.sh" check <ticket-id>

The script prints the spec_check result payload. Three outcomes:

Passed (passed:true) → proceed to "Create the stack" below.

Gaps (passed:false with questions) → present the questions to the user. On their reply:

echo "<user's answers verbatim>" | bash "$SANDSTORM_SKILLS_DIR/spec-and-dispatch/scripts/spec-and-dispatch.sh" refine <ticket-id>

Loop through questions/answers until passed:true.

Error → relay to the user; stop.

Create the stack

Once the gate passes, confirm the stack name with the user if you don't already have one. Then:

bash "$SANDSTORM_SKILLS_DIR/spec-and-dispatch/scripts/spec-and-dispatch.sh" create <ticket-id> <stack-name>

Relay the result.

Hard rules

Never summarize or rewrite the ticket body. The script passes it verbatim; don't try to "improve" it.
Never set branch: main. Omit the branch arg — it defaults to the stack name.
Never skip the gate by calling create before check succeeds. The spec-gate pass is the precondition for dispatch.
Never call spec_check, spec_refine, or create_stack MCP tools directly. This skill is the only path for this workflow.
One ticket per invocation.