메뉴
Úsalo cuando el usuario quiere arrancar el stack palafito-prod (Paperclip) y, si hace falta, levantar Docker Desktop antes.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | start-palafito |
| description | Úsalo cuando el usuario quiere arrancar el stack palafito-prod (Paperclip) y, si hace falta, levantar Docker Desktop antes. |
| model | sonnet |
| context | fork |
| allowed-tools | Bash |
Levanta el servicio Paperclip de Palafito en Docker.
docker info > /dev/null 2>&1
# Arrancar Docker Desktop en Windows
powershell.exe -Command "Start-Process 'C:\\Program Files\\Docker\\Docker\\Docker Desktop.exe'"
Esperar a que el daemon responda (poll con docker info):
for i in $(seq 1 30); do
docker info > /dev/null 2>&1 && break
echo "Esperando Docker daemon... ($i/30)"
sleep 5
done
docker info > /dev/null 2>&1 || { echo "ERROR: Docker Desktop no arrancó en 150s"; exit 1; }
cd /c/palafito-prod && docker compose up -d
Si el init container (palafito-paperclip-init) ya está en estado exited con código 0 de una ejecución anterior, Docker Compose lo reconoce como completado y no lo relanza — esto es correcto.
Esperar hasta que el healthcheck pase (máx 120s):
for i in $(seq 1 24); do
STATUS=$(docker inspect --format='{{.State.Health.Status}}' palafito-paperclip 2>/dev/null)
echo "Health: $STATUS ($i/24)"
[ "$STATUS" = "healthy" ] && break
sleep 5
done
STATUS=$(docker inspect --format='{{.State.Health.Status}}' palafito-paperclip 2>/dev/null)
if [ "$STATUS" = "healthy" ]; then
echo ""
echo "✓ Paperclip Palafito corriendo en http://localhost:3101"
else
echo ""
echo "⚠ El contenedor no alcanzó estado healthy en 120s. Estado actual: $STATUS"
echo "Logs recientes:"
docker logs --tail 20 palafito-paperclip
fi
Mostrar:
http://localhost:3101docker ps --filter name=palafito-paperclip)C:\palafito-prod\ (/c/palafito-prod/ en bash)palafito-paperclip-data — no se pierden al reiniciardocker compose -f /c/palafito-prod/docker-compose.yml downMine architecture decision records (ADRs), gotcha files, runbooks, and docs/archive for cross-project lessons that warrant ai-playbook canonical specs. Use when a project lacks a populated retros/ directory but has equivalent material in other forms.
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
Orchestrate the canonical task↔PR↔release flow end-to-end. Two modes — `/dev-flow start <description>` scaffolds an OpenSpec change + branch + (optional) worktree + git hook ready for commits; `/dev-flow ship` validates the current branch + pushes + opens PR + monitors CI. Use whenever you start any non-trivial change in a playbook-consuming project. LLM-agnostic — works for Claude Code, Cursor, Antigravity, Gemini CLI, OpenCode, and humans.
Implement an OpenSpec change in parallel using multiple subagents (one per disjoint task group inside the same slice). Use when the slice's tasks.md has ≥2 task groups with disjoint write-paths AND >30 min of parallelisable work. For sequential implementation use openspec-apply-change instead.
Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"