Help us improve
Share bugs, ideas, or general feedback.
From kernel
Diagnoses bugs by reproducing, tracing, isolating, hypothesizing root causes; analyzes refactors by mapping deps, measuring coupling/risks. Outputs structured diagnosis and recommendations.
npx claudepluginhub ariaxhan/kernel-claude --plugin kernelHow this command is triggered — by the user, by Claude, or both
Slash command
/kernel:diagnoseThis command is limited to the following tools:
The summary Claude sees in its command listing — used to decide when to auto-load this command
<purpose>
Diagnose before fixing. The debug skill exists but no command orchestrates it.
Mixing diagnosis with implementation means the surgeon starts cutting before the X-ray.
/kernel:diagnose is the X-ray.
</purpose>
<skill_load>
Load: skills/debug/SKILL.md, skills/testing/SKILL.md, skills/architecture/SKILL.md
</skill_load>
<modes>
<mode id="bug" default="true">
<trigger>error, failing test, stack trace, "not working", exception, crash</trigger>
<steps>
<step id="reproduce">
Read error output, failing test, or stack trace.
Run the failing command/test to.../debugDiagnoses root cause of bugs, errors, or test failures using adaptive multi-perspective investigation with parallel subagents.
/debugGuides systematic debugging: intakes symptoms, defines problem, forms testable hypotheses, gathers evidence, identifies root cause, suggests fixes, and documents.
/debugRuns structured debugging with parallel agents: traces bugs via phases, diagnoses root causes with evidence, proposes minimal fixes, executes after approval. Tracks in tasks/todo.md.
/diagnoseDiagnoses compilation errors, runtime errors, performance issues, and Protheus logs in ADVPL/TLPP code, providing severity levels, root causes, fixes with examples, and preventive advice.
/diagnoseInitiates Dr. Ralph's multi-phase diagnostic workflow: interviews user on symptoms, researches via web, generates differential diagnosis, treatment plan, and SOAP report with running notes.
/diagnoseDiagnoses FilamentPHP v4 errors and issues by parsing descriptions, consulting docs, analyzing logs/caches/code, and providing root causes with code fixes.
Share bugs, ideas, or general feedback.
<skill_load> Load: skills/debug/SKILL.md, skills/testing/SKILL.md, skills/architecture/SKILL.md </skill_load>
error, failing test, stack trace, "not working", exception, crash Read error output, failing test, or stack trace. Run the failing command/test to confirm reproduction. If not reproducible, document conditions and ask for more info. Follow the call stack from error to origin. Check recent git changes: git log --oneline --since="3 days" -- {affected files} Identify when the behavior changed. Run failing test in isolation (not full suite). If multiple tests fail, find the minimal reproduction. Binary search: comment out code blocks to narrow the cause. Form 2-3 hypotheses for root cause. For each hypothesis: what evidence would confirm or reject it? Test each hypothesis with minimal code changes or debug output. <ask_user>
Use AskUserQuestion when: hypotheses formed and user may have domain knowledge
Ask: "Top hypothesis: {hypothesis}. Does this match what you're seeing, or is there context I'm missing?"
Options: investigate that, I have more context, try a different hypothesis
</ask_user>
</step>
<step id="diagnose">
Identify confirmed root cause.
List affected files and blast radius.
Recommend fix approach (don't implement yet).
Determine tier based on blast radius.
</step>
<step id="handoff">
Output structured diagnosis.
Hand off to /kernel:ingest or /kernel:forge for implementation.
If the user wants to fix immediately, transition to execute mode.
</step>
</steps>
refactor, restructure, "clean up", "simplify", coupling, dependency
Identify all files/modules touched by the refactor target.
Use Grep/Glob to find all references.
Build a dependency map of what imports/calls what.
For each file in the map: who calls this? who depends on it?
What breaks if this changes?
Identify the blast radius.
How tangled is this code with the rest of the system?
Count cross-module references.
Identify circular dependencies.
What are the edge cases in the current implementation?
What tests exist? What's untested?
What invariants must be preserved?
Produce restructuring plan with safety constraints.
List files that change, in what order.
Identify tests that must pass before AND after.
Determine tier based on file count.
Output structured diagnosis.
Hand off to /kernel:ingest with pre-identified scope.
<output_format>
Mode: bug | refactor Root cause: {one sentence} Confidence: high | medium | low
| File | Role |
|---|---|
| {path} | origin — where the bug lives / refactor starts |
| {path} | downstream — affected by the change |
{N} files affected. Tier {1|2|3}.
{what depends on what}
{what to do, not how — that's for ingest/forge}
Next: /kernel:ingest or /kernel:forge to implement. </output_format>
Record diagnosis event: agentdb emit command "diagnose" "" '{"mode":"bug|refactor","confidence":"high|medium|low","blast_radius":N,"tier":N}'