deploy-grokky
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- DevOps
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Manual integration
- External API key
- Required · Anthropic
- Operating systems
- Docker
- Runtime requirements
- Docker
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: deploy-grokky
description: Deploy Grokky — start Docker, ensure grok_spawner, build images, publish package Use when this c…
category: devops
runtime: Docker
---
# deploy-grokky output preview
## PART A: Task fit
- Use case: Deploy Grokky — start Docker, ensure grok_spawner, build images, publish package Use when this capability is needed. This skill performs a full deployment of the Grokky package: Ask: "Which host should I publish to? (e.g., localhost, dev, public)" requires Anthropic API key; runs on Docker. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Arguments / Resolve arguments / Resolve paths” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Deploy Grokky — start Docker, ensure grok_spawner, build images, publish package Use when this capability is needed. This skill performs a full deployment of the Grokky package: Ask: "Which host should I publish to? (e.g., localhost, dev, public)" requires Anthropic API key; runs on Docker. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Arguments / Resolve arguments / Resolve paths” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; may access external network resources; requires Anthropic API keys.
## Running Rules
- read files, write/modify files, run shell commands; may access external network resources; requires Anthropic API keys.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/dev`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Arguments / Resolve arguments / Resolve paths”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: deploy-grokky
description: Deploy Grokky — start Docker, ensure grok_spawner, build images, publish package Use when this c…
category: devops
source: tomevault-io/skills-registry
---
# deploy-grokky
## When to use
- Deploy Grokky — start Docker, ensure grok_spawner, build images, publish package Use when this capability is needed. T…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Arguments / Resolve arguments / Resolve paths” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; may access external network resources; requires Anthropic API keys.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "deploy-grokky" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Arguments / Resolve arguments / Resolve paths
rules -> SKILL.md triggers / order / output contract
runtime -> Docker | read files, write/modify files, run shell commands | may access external network resources
guardrails -> requires Anthropic API keys + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Deploy Grokky
This skill performs a full deployment of the Grokky package:
- Ensures Docker is running
- Ensures grok_spawner is running
- Builds required Docker images
- Starts runtime containers
- Builds and publishes the package
Arguments
$ARGUMENTS may include:
key: <ANTHROPIC_API_KEY>host: <publish host>
Resolve arguments
If
hostis missing: Ask: "Which host should I publish to? (e.g.,localhost,dev,public)" Wait for user input before continuing.If
keyis missing: Run:echo $ANTHROPIC_API_KEYIf empty, ask the user to provide the key and wait.
Resolve paths
Set variables explicitly:
GROKKY_ROOT=$(cd "${CLAUDE_SKILL_DIR}/../../.." && pwd)
DOCKER_DIR=$(cd "$GROKKY_ROOT/../../docker" && pwd)
COMPOSE_FILE="$DOCKER_DIR/localhost.bleeding-edge.docker-compose.yaml"
Step 1 — Ensure Docker is running
Run:
docker info > /dev/null 2>&1
If it fails:
open -a Docker
Then retry every 3 seconds (max 10 attempts):
for i in {1..10}; do
sleep 3
docker info > /dev/null 2>&1 && break
done
If still failing after 10 attempts: Stop execution and tell user: "Docker is not running. Please start Docker manually."
Step 2 — Ensure grok_spawner is running and fresh
Check if running:
docker ps --filter "name=grok_spawner" --format "{{.Names}}"
If no output, start it:
cd "$DOCKER_DIR"
GROK_SPAWNER_CORE_MODE=true docker compose -f "$COMPOSE_FILE" up -d grok_spawner
If running, check its age:
docker inspect --format '{{.Created}}' grok_spawner
Parse the timestamp and compare to now. If the container is older than 2 days, recreate it:
cd "$DOCKER_DIR"
GROK_SPAWNER_CORE_MODE=true docker compose -f "$COMPOSE_FILE" up -d --force-recreate grok_spawner
Do NOT start any other services.
Step 3 — Detect the Docker network
The network name varies by setup. Detect it from the running grok_spawner container:
DOCKER_NETWORK=$(docker ps --filter "name=grok_spawner" --format "{{.Networks}}" | head -1)
If DOCKER_NETWORK is empty, fall back:
DOCKER_NETWORK=$(docker network ls --format "{{.Name}}" | grep -E "datagrok" | head -1)
If still empty, stop and tell user: "No datagrok Docker network found. Is the platform running?"
Step 4 — Detect required image builds
cd "$GROKKY_ROOT"
CHANGED_FILES=$(git diff --name-only HEAD -- dockerfiles/; git status --short -- dockerfiles/)
Check existing images:
EXISTING_IMAGES=$(docker images --format "{{.Repository}}:{{.Tag}}" | grep grokky || true)
Determine build flags:
Build
claude-runtimeif:dockerfiles/claude-runtime/appears in$CHANGED_FILESORgrokky-claude-runtime:adminnot found in$EXISTING_IMAGES
Build
mcp-serverif:dockerfiles/mcp-server/appears in$CHANGED_FILESORgrokky-mcp-server:adminnot found in$EXISTING_IMAGES
If neither needs building, skip to Step 6.
Step 5 — Build images (only those flagged in Step 4)
claude-runtime
cd "$GROKKY_ROOT/dockerfiles/claude-runtime"
docker build --build-arg ANTHROPIC_API_KEY=$KEY -t grokky-claude-runtime:admin .
docker rm -f grokky-claude-runtime 2>/dev/null || true
mcp-server
cd "$GROKKY_ROOT/dockerfiles/mcp-server"
docker build -t grokky-mcp-server:admin .
docker rm -f grokky-mcp-server 2>/dev/null || true
Step 6 — Build and publish
cd "$GROKKY_ROOT"
npm run build
If build fails, stop and show the error output.
If build succeeds:
grok publish $HOST
If publish fails, stop and show the error output.
Step 7 — Report results
Print:
- Whether Docker was started
- Whether grok_spawner was started
- Which images were built (or "all cached")
- Container statuses
- Publish result
Source: datagrok-ai/public — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review