wiki-sync

Stars8

Forks0

UpdatedMay 27, 2026 at 09:36

Reconcile the wiki with the current code. Detects where the implementation has diverged from the wiki and updates the wiki pages (or flags the divergence for a decision). Use after significant code changes, or when the PostToolUse reminder fires, or when the user asks to "sync the wiki".

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.

Source

dxlbnl

dxlbnl/zod4-mock

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	wiki-sync
description	Reconcile the wiki with the current code. Detects where the implementation has diverged from the wiki and updates the wiki pages (or flags the divergence for a decision). Use after significant code changes, or when the PostToolUse reminder fires, or when the user asks to "sync the wiki".
disable-model-invocation	false

Sync the wiki with the code

The wiki is the source of truth — but implementation sometimes reveals that the wiki was wrong, incomplete, or has been outgrown. This skill closes that gap deliberately, so the wiki stays trustworthy.

STEP 0 — read the wiki

Read wiki/INDEX.md and the pages relevant to the area that changed.

Procedure

Find the divergence — compare the current code against the relevant wiki pages (requirements.md, architecture.md, the affected wiki/specs/ pages). Look for: behaviour the code has that the wiki does not describe; wiki statements the code no longer satisfies; structural drift from architecture.md; rule drift — a rule in architecture.md's Rules section whose linked decision is missing or superseded/ abandoned, a standing-constraint decision in decisions.md with no matching rule, or code that violates a binding rule.
Classify each gap:
- Code is right, wiki is stale → update the wiki page to match reality.
- Wiki is right, code drifted → this is a defect; do not edit the wiki to hide it. Add a backlog item (or flag it) so it goes through the pipeline.
- Genuine decision → the change was intentional and significant → append an entry to wiki/decisions.md and update the affected pages.
- Rule drift → if a rule's decision was superseded, update or remove the rule to match the current decision; if a standing-constraint decision has no rule, add the one-line rule (or, if it is no longer a standing constraint, retire it). If code violates a binding rule, that is a defect → file a backlog item; do not weaken the rule to hide it.
Update INDEX.md if pages were added or restructured.
Report what changed in the wiki and what was turned into backlog work.

Rules

Never edit the wiki just to make a failing reality "look consistent". The wiki must stay an honest spec.
Prefer small, precise edits to the specific pages over rewrites.
If unsure whether code or wiki is "right", surface it — do not guess.

More from this repository

same repository

bootstrap

dxlbnl/zod4-mock

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".

2026-05-318

intake

dxlbnl/zod4-mock

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.

2026-05-318

interview

dxlbnl/zod4-mock

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.

2026-05-318

manager

dxlbnl/zod4-mock

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.

2026-05-318

migrate-vibin

dxlbnl/zod4-mock

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.

2026-05-318

tdd-cycle

dxlbnl/zod4-mock

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.

2026-05-318

name	wiki-sync
description	Reconcile the wiki with the current code. Detects where the implementation has diverged from the wiki and updates the wiki pages (or flags the divergence for a decision). Use after significant code changes, or when the PostToolUse reminder fires, or when the user asks to "sync the wiki".
disable-model-invocation	false

Sync the wiki with the code

STEP 0 — read the wiki

Read wiki/INDEX.md and the pages relevant to the area that changed.

Procedure

Find the divergence — compare the current code against the relevant wiki pages (requirements.md, architecture.md, the affected wiki/specs/ pages). Look for: behaviour the code has that the wiki does not describe; wiki statements the code no longer satisfies; structural drift from architecture.md; rule drift — a rule in architecture.md's Rules section whose linked decision is missing or superseded/ abandoned, a standing-constraint decision in decisions.md with no matching rule, or code that violates a binding rule.
Classify each gap:
- Code is right, wiki is stale → update the wiki page to match reality.
- Wiki is right, code drifted → this is a defect; do not edit the wiki to hide it. Add a backlog item (or flag it) so it goes through the pipeline.
- Genuine decision → the change was intentional and significant → append an entry to wiki/decisions.md and update the affected pages.
- Rule drift → if a rule's decision was superseded, update or remove the rule to match the current decision; if a standing-constraint decision has no rule, add the one-line rule (or, if it is no longer a standing constraint, retire it). If code violates a binding rule, that is a defect → file a backlog item; do not weaken the rule to hide it.
Update INDEX.md if pages were added or restructured.
Report what changed in the wiki and what was turned into backlog work.

Rules

Never edit the wiki just to make a failing reality "look consistent". The wiki must stay an honest spec.
Prefer small, precise edits to the specific pages over rewrites.
If unsure whether code or wiki is "right", surface it — do not guess.