kami-debugging-playbook

Diagnose kami-kakushi failures using symptom-to-triage tables and headless measurement tools.

1|Updated Jun 29, 2026
One-click install
npx skills add https://github.com/Raynos/kami-kakushi --skill kami-debugging-playbook-raynos
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kami-debugging-playbook
Source: https://github.com/Raynos/kami-kakushi/tree/main/.claude/skills/kami-debugging-playbook
Command: npx skills add https://github.com/Raynos/kami-kakushi --skill kami-debugging-playbook-raynos

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Debugging the kami-kakushi incremental RPG involves many recurring failure modes — red verify gates, dead dev servers, mass e2e failures from the wrong app on a port, phantom UI defects caused by test harnesses, and cross-file test leakage. This Skill provides a symptom-to-triage playbook and a measurement-tool catalog so you diagnose with evidence instead of guessing. ## Core Features & Use Cases - Symptom-to-triage tables: Maps concrete symptoms (verify gate RED, port 5264 in use, e2e mass-red, orphan-id save alarms, fixture drift, gen byte-compare failures) to first moves and follow-up recipes. - Discriminating experiments: Provides worktree-HEAD verification, attribution proofs for unexpected balance changes, control-verb tests, and shared-tree-safe git bisect procedures. - Measurement catalog: Documents the full window.__qa headless play API, scripted sensors (screenshot gallery, balance sim, pacing report, fixture checks), and human-side telemetry sensors. - Use Case: When e2e tests fail en masse with nonsense errors like "__qa.fixtures is not a function", follow the playbook to probe which app answers port 5265 before debugging your own code. ## Quick Start Load this skill whenever a verify gate fails, the dev server seems dead, e2e tests are red, or any UI behavior looks wrong, then follow the matching symptom row in the triage table.

Frequently Asked Questions about kami-debugging-playbook

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a failing verify gate in this repo?

Read the gate's own error output first, since most gates name their exact fix command. Then consult the symptom-to-triage table for per-gate recipes, and check whether the red file belongs to a co-agent's uncommitted work before changing anything.

Why do e2e tests fail with nonsense errors like __qa.fixtures is not a function?

A foreign app is likely squatting the e2e port 5265, and Playwright's reuseExistingServer drives whatever answers. Probe the port with lsof and curl to confirm which app responds before debugging your own code.

How do I check if a missing UI update is a real bug or a test harness artifact?

Run a control verb — a shipped action known to work — through the same pipeline and observe it the same way. If the control also appears missing, the defect is in your observation (DOM query, channel filter, or typewriter pacing), not the game.

Why does a test pass alone but fail when run in the full suite?

Vitest runs with isolate: false, so module state leaks across files. Tests that set balance levers must call __resetBalanceLevers() in cleanup to avoid polluting subsequent files.

Can I restart or kill the dev server on port 5264 when it seems dead?

No. Reuse the shared server if it is held, and ask the human to relaunch it if truly dead. Never spawn a rival server or kill the holder — the vite singleServerGuard and guard-dev-server.sh hook block both.

When should I not use this debugging playbook?

Use dedicated skills for specific domains: kami-verify-gates for per-gate fix recipes, kami-save-and-schema for save and migration mechanics, kami-balance-analysis-toolkit for sim methodology, and the tdd skill for fixing an already-reproduced bug.