onomojo/spec-and-dispatch
sandstorm-cli/skills/spec-and-dispatch/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add onomojo/sandstorm-desktop spec-and-dispatchInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 20, 2026, 4:14 AM5.3s2 files scanned
SKILL.md
- name:
- spec-and-dispatch
- description:
- 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.
/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:falsewithquestions) → present the questions to the user. On their reply:
Loop through questions/answers untilecho "<user's answers verbatim>" | bash "$SANDSTORM_SKILLS_DIR/spec-and-dispatch/scripts/spec-and-dispatch.sh" refine <ticket-id>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
createbeforechecksucceeds. The spec-gate pass is the precondition for dispatch. - Never call
spec_check,spec_refine, orcreate_stackMCP tools directly. This skill is the only path for this workflow. - One ticket per invocation.
Related Skills
onomojo/stack-failure-diagnostic
development
VerifiedTrustedCommunity
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 involves diagnosing a stack's failure, loop behavior, or why it stopped working — even when the user phrases it gently (e.g., 'doesn't seem to be working', 'not sure what's going on', 'can you take a look') as long as there is a failure or malfunction signal present. Falling back to raw Bash exploration of the stack's internals costs 1M+ tokens. Do NOT trigger for: status-only 'is stack N done?' / 'what's the status of stack N' (that's check-and-resume-stack), diff/logs inspection on a working stack with no failure signal (stack-inspect), or creating a new stack.
5SKILL.mdUpdated Apr 22, 2026
onomojo/stack-teardown
testing
VerifiedTrustedCommunity
Use this skill ONLY when the user has EXPLICITLY asked to tear down, destroy, remove, or dismantle a named Sandstorm stack. Trigger phrases include: 'tear down stack X', 'destroy stack X', 'remove stack X', 'dismantle stack X', 'clean up stack X and all its containers', 'I'm done with stack X, kill it'. This skill stops containers, removes the workspace, and archives the stack — it is IRREVERSIBLE and can lose unpushed work. Do NOT trigger on ambiguous phrases like 'clean up', 'reset', 'start over', 'remove the old one', 'stack is broken', or anything that might imply teardown without literal user words like tear down / destroy / delete. Do NOT trigger for: stopping containers (that's pause, not teardown), checking status, failure recovery, or as a precursor to creating a new stack. When in doubt, ASK the user before running.
5SKILL.mdUpdated Apr 20, 2026
onomojo/stack-pr
tools
VerifiedTrustedCommunity
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.
5SKILL.mdUpdated Apr 20, 2026
onomojo/stack-inspect
testing
VerifiedTrustedCommunity
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.
5SKILL.mdUpdated Apr 20, 2026