Run any Skill in Manus with one click

sandstorm

Stars6

Forks0

UpdatedApril 1, 2026 at 00:52

Use this skill any time the user wants to work with Sandstorm agent stacks. This includes: creating, spinning up, or starting stacks; dispatching tasks or work to an inner Claude agent in a stack; checking stack status, task progress, or whether a task is done; viewing diffs, changes, or task output from a stack; pushing or publishing code changes from a stack to git; tearing down, cleaning up, or removing stacks; viewing container logs. Trigger whenever the user mentions 'stack' with a number or ID (like 'stack 1', 'stack 2', 'stack 3'), says 'sandstorm', refers to an 'isolated environment' for development, or asks to send work to an agent. Also trigger for multi-stack operations and any reference to agent workspaces. Do NOT trigger for general Docker, docker-compose authoring, CI/CD pipelines, or direct code editing unrelated to stacks.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

onomojo

onomojo/sandstorm-desktop

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

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

spec-and-dispatch

onomojo/sandstorm-desktop

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.

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

name

sandstorm

description

Sandstorm — MCP Tools Reference

Sandstorm manages isolated Docker agent stacks. Each stack is a full clone of the project repo with its own containers, ports, and an inner Claude agent.

IMPORTANT: Always use the MCP tools (mcp__sandstorm-tools__*) to manage stacks. Never use CLI commands (sandstorm up, sandstorm task, etc.) directly — the MCP tools go through the Electron app's control plane, which tracks stacks in the database and keeps the UI in sync.

Available MCP Tools

Tool	Description
`mcp__sandstorm-tools__create_stack`	Create and start a new stack
`mcp__sandstorm-tools__list_stacks`	List all stacks with status and services
`mcp__sandstorm-tools__dispatch_task`	Send a task to inner Claude in a stack
`mcp__sandstorm-tools__get_task_status`	Check task state (running, completed, failed, idle)
`mcp__sandstorm-tools__get_task_output`	View latest task output
`mcp__sandstorm-tools__get_diff`	View uncommitted changes in a stack
`mcp__sandstorm-tools__get_logs`	View container logs for a stack
`mcp__sandstorm-tools__push_stack`	Commit and push changes from a stack
`mcp__sandstorm-tools__teardown_stack`	Tear down a stack (stops containers, cleans up)

Critical Rules

NEVER set branch to main. Omit the branch parameter — it defaults to the stack name, which becomes a feature branch. Setting branch: "main" causes pushes to go directly to main, bypassing code review. This has caused loss of work.
NEVER tear down stacks unless the user explicitly asks. No inference, no cleanup, no "let me tear this down first." The ONLY valid trigger is the user directly requesting teardown.
Always create PRs after pushing. Use .sandstorm/scripts/create-pr.sh to open a pull request from the feature branch.
NEVER rewrite, summarize, or embellish ticket text when dispatching. Pass the ticket body verbatim. See the "Verbatim Ticket Dispatch" section below.

Workflows

Spec quality gate (mandatory for tickets)

Before calling create_stack or dispatch_task for a ticket:

Fetch the ticket body using the project's fetch-ticket script:
```
.sandstorm/scripts/fetch-ticket.sh <N>
```
If the script doesn't exist, warn the user: "No fetch-ticket script configured. Run sandstorm init to set up a ticket provider."
Read the project's .sandstorm/spec-quality-gate.md
Evaluate each criterion — PASS or FAIL
If any FAIL → present specific gaps to the user, enter a refinement loop (do NOT dispatch)
If all PASS → show your assumptions list, ask the user to approve
On approval → call create_stack with gateApproved: true

If you skip this step, the backend will reject the call with GATE_CHECK_REQUIRED and you will need to run the gate check anyway. Always run it proactively.

If the user explicitly says to skip the gate (e.g., "just start it", "skip the gate"), use forceBypass: true instead.

Typical flow: ticket to PR

Run spec quality gate (see above) — required before dispatch
create_stack — name, projectDir, ticket, gateApproved: true (do NOT pass branch — it defaults to the stack name)
dispatch_task — pass the verbatim ticket body as the task prompt (see Verbatim Ticket Dispatch below)
get_task_status — check when done
get_diff — review changes
push_stack — commit and push to the feature branch

Create a pull request:

.sandstorm/scripts/create-pr.sh --title "Fix auth token expiry" --body "Fixes #28"

Do NOT tear down stacks — only the user decides when to tear down.

Verbatim Ticket Dispatch

When the user says "start issue #N", "spin up a stack for issue #N", or any variation:

Fetch the full ticket body using the project's fetch-ticket script:
```
.sandstorm/scripts/fetch-ticket.sh <N>
```
Pass the ticket body verbatim as the task parameter to create_stack or dispatch_task
Do NOT summarize, rewrite, add implementation details, or "improve" the ticket text
Never add file paths, class names, or implementation steps that aren't in the ticket

If the user gives verbal instructions that differ from the ticket, update the ticket first using the project's update-ticket script:

.sandstorm/scripts/update-ticket.sh <N> "<updated body>"

Then fetch and dispatch the updated body. The ticket is the single source of truth.

Why this matters:

The inner Claude has full repo context — it can figure out implementation details itself
The inner Claude reads CLAUDE.md, understands the codebase, and makes appropriate decisions
Adding implementation specifics from the outer Claude constrains the inner Claude and can steer it wrong
Summarizing loses important details and nuance from the original ticket

Create stack and dispatch work (for a ticket)

# 1. Fetch the ticket body verbatim
TICKET_BODY=$(.sandstorm/scripts/fetch-ticket.sh 28)

# 2. Create stack with the unmodified ticket body as the task
mcp__sandstorm-tools__create_stack({
  name: "issue-28-fix-auth-bug",
  projectDir: "/path/to/project",
  ticket: "28",
  gateApproved: true,
  task: <TICKET_BODY — the full, unmodified ticket text>
})

NEVER pass branch: "main". Omit the branch parameter entirely.

The task parameter dispatches work immediately after creation — no need to call dispatch_task separately.

Monitor and iterate

mcp__sandstorm-tools__get_task_status({ stackId: "issue-28-fix-auth-bug" })
mcp__sandstorm-tools__get_task_output({ stackId: "issue-28-fix-auth-bug" })
mcp__sandstorm-tools__get_diff({ stackId: "issue-28-fix-auth-bug" })
mcp__sandstorm-tools__dispatch_task({ stackId: "issue-28-fix-auth-bug", prompt: "Looks good but add limit/offset params" })

Review, push, create PR

mcp__sandstorm-tools__get_diff({ stackId: "issue-28-fix-auth-bug" })
mcp__sandstorm-tools__push_stack({ stackId: "issue-28-fix-auth-bug", message: "Fix auth token expiry with user-facing error" })
.sandstorm/scripts/create-pr.sh --title "Fix auth token expiry" --body "Fixes #28"

Tool Details

`create_stack`

Parameter	Required	Description
`name`	Yes	Stack name — becomes the stack ID (e.g., `fix-auth-bug`)
`projectDir`	Yes	Absolute path to the project directory
`ticket`	No	Associated ticket ID (e.g., `PROJ-123`)
`branch`	No	Git branch name (defaults to stack name). NEVER set to `main`.
`description`	No	Short description of the work
`runtime`	No	`docker` (default) or `podman`
`task`	No	Task to dispatch immediately after creation. When working on a ticket, this MUST be the verbatim ticket body — never a summary or rewrite.
`gateApproved`	No	Set to `true` after running `/spec-check` and getting user approval. Required when `ticket` is set or task references a ticket.
`forceBypass`	No	Set to `true` to skip the spec quality gate. Only when the user explicitly requests it.

The stack builds in the background. Use get_task_status or list_stacks to check when it's ready.

`dispatch_task`

Parameter	Required	Description
`stackId`	Yes	Target stack ID
`prompt`	Yes	Task description for inner Claude. When working on a ticket, this MUST be the verbatim ticket body.
`gateApproved`	No	Set to `true` after running `/spec-check` and getting user approval. Required when the stack has a ticket or the prompt references a ticket.
`forceBypass`	No	Set to `true` to skip the spec quality gate. Only when the user explicitly requests it.

Write goal-oriented prompts. Describe WHAT to achieve, not HOW. The inner Claude has the full repo context.

When dispatching for a ticket: Pass the ticket body verbatim. Do not summarize, rewrite, or add implementation details.

For follow-up tasks (not initial ticket dispatch): goal-oriented prompts are fine.

Good follow-up: "Looks good but add limit/offset params to the list endpoint"

Bad initial dispatch: Rewriting "Fix auth bug" into "Open src/auth.ts, find line 42, change the catch block..."

`get_task_status`

Returns the current task state for a stack: running, completed, failed, or idle.

`get_task_output`

Parameter	Required	Description
`stackId`	Yes	Target stack ID
`lines`	No	Number of lines to return (default: 50)

`get_diff`

Returns the full git diff of uncommitted changes in the stack's workspace. Always review before pushing.

`get_logs`

Parameter	Required	Description
`stackId`	Yes	Target stack ID
`service`	No	Service name (e.g., `claude`, `app`). Omit for all services.

`push_stack`

Parameter	Required	Description
`stackId`	Yes	Target stack ID
`message`	No	Commit message

`teardown_stack`

Stops containers, removes workspace, archives stack to history. This is irreversible. Always check for unpushed changes first with get_diff.

Important Rules

Use MCP tools only. Never bypass with raw sandstorm CLI commands or docker commands.
No polling loops. Run get_task_status as a one-shot check when the user asks. Never write sleep/poll loops.
Review before pushing. Always get_diff before push_stack.
Check before teardown. Always get_diff before teardown_stack to avoid losing work.
Verbatim ticket dispatch. When dispatching work for a ticket, pass the ticket body verbatim as the task prompt. Never summarize, rewrite, add file paths, class names, or implementation steps that aren't in the ticket. If the user's instructions differ from the ticket, update the ticket first, then dispatch.
Stacks appear in the UI. Because MCP tools go through the Electron control plane, every stack you create will be visible in the Sandstorm Desktop UI.
NEVER use main as the branch. Omit the branch parameter so stacks always work on feature branches.
NEVER tear down stacks unless the user explicitly requests it. No automatic cleanup.
Always create PRs. After push_stack, use .sandstorm/scripts/create-pr.sh to open a pull request.
Spec quality gate. Always run /spec-check before dispatching work for a ticket. The backend enforces this — calls without gateApproved: true will be rejected with GATE_CHECK_REQUIRED.