Menu
Conventions for reading and maintaining the Vibin wiki — the single source of truth. Use when adding or editing wiki pages, organizing the wiki, or when unsure how the wiki is structured.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Primary entry point for a freshly cloned Vibin seed repo. Interviews the user about the project, stack, package manager, constraints, and initial backlog, populates the wiki/ starter pages, scaffolds the chosen stack, writes the stack-specific permission profile, and hands off to the manager skill. Use when starting a new project, or when the user says "bootstrap", "set up the project", or "let's begin".
File a new work item into wiki/backlog/inbox/. Use whenever the user reports a bug, asks for a feature, or proposes a change of direction mid-run — instead of inline-patching. Any agent (including subagents) can invoke this. Triggered by /intake "<title>" or when an agent recognises new work that should be captured.
One-question-at-a-time interviewing discipline that drives /bootstrap and /intake to ~95% confidence before writing the wiki or an item card. Use when gathering requirements for a new project or fleshing out a vague work item.
Orchestrates Vibin's wiki-driven, spec-driven, test-first build pipeline. The top-level session runs this skill to order the backlog and drive the spec-writer -> test-writer -> implementer -> reviewer pipeline (or the bug / research / chore tracks), one item at a time. Use after /bootstrap, or to resume building the backlog.
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.
Reference for the red-green-refactor test-first discipline used by the test-writer and implementer agents. Use when you need the canonical explanation of how Vibin's tests-first workflow works, or to settle a question about test ordering, "minimum" code, or trivially-passing tests.
| name | wiki |
| description | Conventions for reading and maintaining the Vibin wiki — the single source of truth. Use when adding or editing wiki pages, organizing the wiki, or when unsure how the wiki is structured. |
| disable-model-invocation | false |
The wiki/ directory is the single source of truth and the spec. Code serves the
wiki, not the other way around. When code and wiki disagree, the wiki wins (or you fix
the wiki deliberately — see /wiki-sync).
wiki/INDEX.md — the required entry point. Every agent reads it first; the
wiki-gate hook enforces this. It holds the Pages table and the conventions.wiki/vision.md — what the project is and why.wiki/requirements.md — functional requirements, constraints, assumptions, open
questions.wiki/architecture.md — stack, binding package manager, test setup, project
structure, and the binding Rules index (standing constraints, derived from
decisions.md, that agents read before writing code).wiki/backlog/ — work items, one per file, arranged in four lanes:
inbox/ → ready/ → doing/ → done/. See wiki/backlog/README.md for the
schema, lane semantics, and the per-type: track table.wiki/decisions.md — append-only ADR-style decision log.wiki/progress.md — append-only run journal kept by the manager.wiki/specs/ — one detailed, testable spec page per feature/bug item, paired with
an item card via the card's spec: frontmatter.The wiki is open-ended. Only INDEX.md is structurally required — add, split, and
restructure other pages freely.
wiki/<name>.md (or wiki/specs/<feature>.md) and add
a row to the Pages table in INDEX.md so it is discoverable. An unlinked page is
an invisible page.wiki/backlog/<lane>/B<n>-<slug>.md.
Lane = directory (no status: field). Each item has a type:
(feature/bug/research/chore) which selects the manager's track, and an
optional flags: list (review to pause for approval; blocked if stuck, with
a one-line reason in ## Notes). File new work with /intake. The manager moves
items between lanes via git mv — never copy-and-delete (the rename preserves
history).wiki/specs/, one per feature/bug item, following the
format in wiki/specs/README.md. Each spec MUST state its requirements with
stable B<n>-R<k> IDs, exactly one RFC-2119 keyword per requirement, and ≥1
GIVEN/WHEN/THEN scenario each (one scenario → one test). A blocking open question
MUST flag the item review and stops it advancing to tests. The spec page is
linked from its item card via the spec: frontmatter.decisions.md is the append-only rationale archive: never edit
a past entry, supersede it with a new one and link both. An entry belongs there only if
it establishes or changes a standing constraint (something future work must obey);
local one-off choices go in progress.md. Every standing-constraint decision is also
surfaced as a one-line rule in architecture.md's Rules section — the binding index
agents read before coding. The manager owns that Rules section: subagents write the
rationale to decisions.md and flag the constraint, the reviewer confirms the decision
exists, and the manager promotes it to a rule when the item is done.progress.md; treat it as an audit log. Use
/status for a one-screen summary of where the pipeline is right now.wiki/architecture.md declares the package manager for the project (e.g. pnpm
for a TypeScript project, uv for Python). All agents use only that one — they do not
substitute another even if generated configs or tutorials reference one. If the
declaration is missing, agents stop and ask the user.
The wiki-gate hook keys each actor's "I've read the wiki" marker against the newest wiki file. When you change the wiki, other actors' markers go stale and they must re-read before continuing — this is intentional, so everyone builds from the current spec.