vibekit-doctorlisted

# vibekit-doctor A read-mostly health check for the vibekit plugin and the repo it lives in. Answers one question: **does vibekit actually work here, end to end?** The doctor does not install, upgrade, or migrate. It diagnoses. It writes only when the user passes `--fix`, and even then only to safe, deterministic targets (rebuild an index, recreate a `docs/` subdir). ## When to invoke - The user reports vibekit "isn't working" / "skill not found" / "AGENTS.md is wrong". - After pulling a new vibekit version, before the first run. - After hand-editing `skills/`, `.vibekit/`, or a runtime registration file. - Periodically as a hygiene check on long-lived projects. Do NOT invoke for: - Diagnosing a *feature* failure (failed verify-gate, broken plan). That is the relevant skill's failure path, not a doctor concern. - Diagnosing a Claude Code / Codex / Gemini / opencode runtime bug. The doctor checks vibekit's contracts; runtime bugs are out of scope. ## Operations ### `check` Run every check below in order. Output a single YAML report. **Read-only.** ```yaml verdict: ok | warn | critical checks: - name: <check name> status: ok | info | warn | critical detail: <one-line, verbatim> evidence: <path / line / command output, optional> summary: ok: <int> info: <int> warn: <int> critical: <int> ``` `verdict` is the worst status across all checks. Any `critical` → `critical`. Any `warn` and no `critical` → `warn`. Otherwise `ok`. `info` rows are recorded b