Menú
Run the Vibin v2 build loop — pull a work item into the sprint, then retrieve → do → verify → capture → review → close, mostly inline. Use to build the backlog or resume work.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Primary entry point for a freshly cloned Vibin seed. Interviews the user, seeds the knowledge graph, scaffolds the stack, writes the permission profile, strips seed-meta, and hands off to the loop skill. Use when starting a new project, or when the user says "bootstrap" or "let's begin".
File a new work item as a card in wiki/backlog/ (v2 — card-is-spec, slug filename, proportional detail). Use whenever the user reports a bug, asks for a feature, or proposes new work mid-task — instead of inline-patching.
Bring an existing Vibin project up to date with the latest seed by diffing the project's recorded seed commit against the latest Vibin on GitHub and applying the changes. Use when the user says "migrate", "migrate-vibin", "upgrade Vibin", "apply the latest seed changes", or after a new seed release. Reads the seed commit hash from .vibin-version, audits the project's actual state, applies the migrations added since, and reconciles seed-owned files while preserving local customizations.
Run multiple sprints in parallel — partition backlog cards, create git worktrees per sprint, spawn background subagents, merge when done. Use when you want to parallelise independent concerns across concurrent sprints.
Execute a pre-composed sprint — retrieve, do, verify, capture, commit, close. No planning, no user checkpoints. Used by the loop skill after planning, and by the sprint-runner agent for parallel sprints.
One-screen v2 status — current sprint tasks + run log tail, backlog cards, knowledge-graph size. Read-only.
| name | loop |
| description | Run the Vibin v2 build loop — pull a work item into the sprint, then retrieve → do → verify → capture → review → close, mostly inline. Use to build the backlog or resume work. |
You (the working session) run a work item end to end, mostly inline. There is no spec→test→implement relay: the card is the spec, tests are the spec, and you do the work yourself. Only review and research are separate (cold) agents.
wiki/sprint.md is the one working-state file: the sprint's task list + a disposable run log.
wiki/sprint.md first — it says what's in flight. Tasks remain → continue them.
No sprint file or all tasks done → run Sprint start (below) before touching any card.The sprint boundary is the checkpoint; the sprint interior is autonomous. Don't plow from "what's this sprint about?" straight into execution — compose the plan and hard-pause for a nod first:
wiki/backlog/ and write the plan into
wiki/sprint.md: the goal + the task list (slugs) + rough order. sprint.md is the plan.Now follow the run skill (.claude/skills/run/SKILL.md) for every open task. It covers
per-card execution (retrieve → do → verify → capture → commit → close) and sprint close (retro →
archive → commit). The run skill is the canonical execution spec — don't re-derive it here.
One addition for human-driven loops: if a card has flags:[review] or a real fork appears
mid-card, pause and discuss with the user before continuing. The run skill is otherwise autonomous.
wiki/knowledge/ atoms — never native memory, never the sprint log./intake a card (slug-named); don't inline-patch.researcher agent (writes atoms, no code).review card, or a real fork. Composing a new
sprint is itself a boundary — stop and get the go-ahead, don't auto-start the next one.