New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Muse Code Product Doctor

by asgeirtj in asgeirtj/system_prompts_leaks

Diagnoses a Muse Code installation's own failures from binary and session evidence, instead of treating the report as an ordinary repository bug.

CC0-1.0Auto-check passedDevelopment

Install Muse Code Product Doctor

skills CLI
$ npx skills add asgeirtj/system_prompts_leaks --skill doctor -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install asgeirtj/system_prompts_leaks doctor --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/asgeirtj/system_prompts_leaks.git skills-src && mkdir -p .claude/skills && cp -r skills-src/Meta/muse-code/skills/doctor .claude/skills/doctor && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
doctor
GitHub stars
69k
Token cost
~3.5k tokens
SKILL.md length
1,872 words
Files
2 (incl. scripts)
Skills in repo
128
Repo updated
First seen
Licence
CC0-1.0

At a glance

Diagnoses a Muse Code installation's own failures from binary and session evidence, instead of treating the report as an ordinary repository bug.

  • Works in 4 steps: Name the failing surface and exact… → Record the command, cwd, session id/path… → Ask for one missing handle only when it… → …
  • Debugging a Muse Code crash, auth failure, or unexpected output
  • SKILL.md covers Scope, Mental Model, Triage Questions and Product Evidence Map, plus 6 more sections
  • Runs Python scripts from its folder; calls python3

What it does

Activates only on an explicit request to debug Muse Code itself, such as a crash, a provider or auth problem, a broken plugin, or a question about what happened earlier in the current session. It treats the person as a product user rather than a repository engineer, assuming they have only the installed binary, and works toward explaining how the app behaves, gathering the smallest safe set of evidence, naming the likely failing layer, and suggesting one safe next step.

It explicitly stays out of ordinary engineering work: no third-party project bugs, benchmark tasks, build or CI failures, or local codebase debugging unless the evidence actually points back to Muse Code. It will not create issues, branches, commits or pull requests, install or change skills, plugins, settings, auth or trust, or run live network checks unless asked, and a bundled script, `scripts/session-evidence.py`, helps collect that evidence.

Secrets are handled carefully: raw prompts, model payloads, auth tokens, cookies and full session logs must never be printed, with redacted exports and presence checks preferred instead. A pure settings question with no failure to investigate is routed to a separate settings-management skill.

When your agent uses it

  • Debugging a Muse Code crash, auth failure, or unexpected output
  • Asking what happened earlier in the current Muse Code session
  • Collecting a support bundle for a broken Muse Code install
  • Understanding where Muse Code stores its state or logs

Example prompts

  • “doctor: Muse Code crashed when I tried to resume my last session.”
  • “Why did my provider auth fail in Muse Code this morning?”
  • “What happened in my earlier Muse Code session before it got stuck?”

Requirements

  • A local Muse Code installation
  • Python, to run the bundled evidence-collection script

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Name the failing surface and exact symptom.
  2. Record the command, cwd, session id/path if provided, whether the user wants
  3. Ask for one missing handle only when it blocks a safe local check. Prefer
  4. If the user only wants an explanation, explain first and avoid running checks.

What it can do on your machine

Read from SKILL.md and the folder at commit 181ebcd. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • python3

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Muse Code Product Doctor loads about 3.5k tokens when it runs. Until then it costs about 113 tokens; SKILL.md has 1,872 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~113
When it runs · the whole SKILL.md, loaded when a task matches
~3.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from asgeirtj/system_prompts_leaks at commit 181ebcd, republished under its CC0-1.0 licence (© asgeirtj). 1,872 words, ~3,520 tokens.

Download SKILL.mdSave it as .claude/skills/doctor/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
doctor
description
Diagnose Muse Code product/runtime issues from installed binary evidence. Use ONLY when the user explicitly invokes the doctor skill, asks to debug/troubleshoot Muse Code itself, asks what happened earlier in the current Muse Code session, or explicitly selects an earlier Muse Code session. Do NOT use for ordinary repository code failures or history, benchmark tasks, implementation debugging, build/test hangs, or third-party project issues.

Diagnose

Diagnose Muse Code as an installed product. Use this skill only when the user explicitly invokes doctor or clearly asks to debug/troubleshoot Muse Code itself from binary/runtime evidence. Assume the user has the binary, not the source tree. Help them understand how the app works, collect the smallest safe evidence set, identify the likely failing layer, and give the next safe action.

Scope

  • Use this skill ONLY when the user explicitly invokes doctor, asks to use the doctor skill, or clearly asks to debug/troubleshoot broken Muse Code product behavior: app, CLI, TUI, desktop, crash, provider/model, settings, auth, trust, skills, plugins, MCP, session, resume, export, trace, approvals, sandbox, update, or unexpected output.
  • Use this skill when the user asks how Muse Code itself works, where Muse Code stores state, what a Muse Code log/session/trace means, or how to collect a Muse Code support bundle.
  • Use this skill when the user asks what happened earlier in the current Muse Code session or explicitly selects an earlier Muse Code session for evidence. This does not include ordinary repository history or an unspecified third-party agent session.
  • Do NOT use this skill for ordinary repository engineering: code implementation, third-party project bugs, benchmark/eval tasks, build or test failures, command hangs, toolchain issues, CI failures, or local debugging inside a non-Muse Code codebase. Handle those with the normal engineering workflow unless the evidence points to Muse Code itself.
  • Treat the user as a product user first, not as a repository engineer.
  • For pure settings questions or explicitly requested settings edits with no product failure to investigate, use the manage-settings skill instead; Diagnose reads settings only as evidence for a failure it is investigating.
  • Do not create issues, branches, commits, PRs, install/enable/disable skills or plugins, change settings/auth/trust, upload logs, run live-provider/network checks, or edit code unless the user explicitly asks.
  • Do not print secrets, raw prompts, raw model payloads, auth tokens, API keys, cookies, bearer headers, or full session logs. Prefer redacted exports, key/value presence checks, and concise summaries.
  • If a surface has no standalone app log, say so and use session logs, crash reports, trace inspection, or export evidence instead of inventing a path.

Mental Model

Explain the relevant product path before asking for logs:

  • The binary reads settings/auth/trust from the user's config directory and writes sessions, crashes, model catalog cache, and memory under the data directory.
  • A Muse Code session is the main handle for resume, trace inspection, export, and support. Prefer a session id or session log path over screenshots of terminal output.
  • Provider/auth failures are often config, environment, model catalog, network, or credential problems. Separate those before blaming the model.
  • Skills/plugins/MCP are loaded product capabilities. Diagnose discovery, activation, trust, validation, and runtime errors separately.
  • A trace/export explains what the binary saw and did. It is evidence, not a transcript to paste raw.

Triage Questions

  1. Name the failing surface and exact symptom.
  2. Record the command, cwd, session id/path if provided, whether the user wants to inspect or continue that session, approximate time, provider/model if relevant, and whether the issue reproduces.
  3. Ask for one missing handle only when it blocks a safe local check. Prefer: exact command, session id/path, time window, and whether they can reproduce.
  4. If the user only wants an explanation, explain first and avoid running checks.

Product Evidence Map

Collect the smallest read-only set that explains the issue. Adapt the map to the symptom; do not run every row by default.

The config/data roots below are Muse Code's entire local state surface. A config, log, or session file outside them is not Muse Code state — never present one as the product's active configuration, logs, or session evidence. Variables such as CODEX_HOME matter only for explicitly requested import/compat evidence and stay attributed to the product that owns them.

  1. Build/provenance: muse --version; also note command -v muse when multiple copies may exist.
  2. Config/data roots: $XDG_CONFIG_HOME/muse or $HOME/.config/muse; $XDG_DATA_HOME/muse or $HOME/.local/share/muse.
  3. Local files: settings.json, auth.json, and trust.json; read settings when relevant, but report auth/trust presence and provider names only.
  4. Data dirs: sessions, memory, model-catalog, and crashes under the data dir. For crashes, summarize report metadata and file path, not session content.
  5. Session evidence: prefer muse export --redacted --out <file> for the latest workspace session, or muse export --session <id-or-session.jsonl> --redacted --out <file> when the user provides a handle.
  6. Continuation handles: if the user provides a Muse Code session id and wants to continue that session, point them to muse resume <session-id> or muse resume --last for interactive continuation. Use muse exec --session-id <session-id> "<follow-up>" only on explicit request for headless continuation. Add --allow-workspace-switch to the muse exec --session-id command only after confirming the session belongs to another workspace; interactive muse resume does not take this flag. If an exit, fork, or handoff message printed muse resume <session-id>, treat that command as the canonical handle.
  7. Trace evidence: use muse trace inspect --session-log <session.jsonl> --render-mode compact; add --run-id <uuid> or --all-runs for multi-run logs; use --format json only when structured analysis is needed.
  8. User support bundle: use /feedback when available; otherwise prefer a redacted export, trace inspection, crash metadata, and concise reproduction steps.
  9. Skills/plugins/MCP: use muse skills list --enabled-only --json and safe muse plugins ... --help or validation commands when the symptom points there.
  10. Environment: check relevant non-secret variables by presence/value only, such as MUSE_MODEL, base-url variables with credentials redacted, XDG dirs, CODEX_HOME for import/compat issues, and telemetry variables by presence only.

Use Current Session Evidence First

For a question about what happened earlier in the current Muse Code session, use the sibling scripts/session-evidence.py helper before export or full trace inspection. After read_skill gives the physical Diagnose package path, run:

bash
python3 <doctor-skill-dir>/scripts/session-evidence.py --session-log <current-session.jsonl> --workspace "$PWD"

The runtime session-identity context already contains the exact current log path. Do not ask the user for a path already present there, do not guess a latest session, and do not search the session store first. A host may instead provide MUSE_CURRENT_SESSION_LOG, in which case the helper can run without a selector.

For an explicitly selected earlier Muse Code session, use the exact path or id:

bash
python3 <doctor-skill-dir>/scripts/session-evidence.py --session-log <explicit-session.jsonl> --workspace "$PWD"
python3 <doctor-skill-dir>/scripts/session-evidence.py --session-id <explicit-session-id> --workspace "$PWD"

Both explicit earlier-session forms are current-workspace scoped and fail closed on unknown workspace metadata, a mismatch, or ambiguity. Use --kind, --path, --tool, --run-id, or sequence bounds to narrow follow-up evidence. Projected events retain their source stream, and the default bound reserves evidence for both the main session and child sessions so a busy child cannot erase the parent timeline. Always compare durable actions with assistant claims, especially across compaction and child activity. Use a redacted export or compact trace only when this bounded projection is insufficient. Never paste the raw session log into model context.

Show full SKILL.md (765 more words)Show less

Diagnose Live Session Ownership Safely

Use this path when resume says a session is already open or the original terminal no longer accepts input:

  1. Select the exact session first and run scripts/session-evidence.py as above. Bound the output and compare its latest durable activity timestamps; do not start with a store-wide process or file search.
  2. Treat .session.lock as an inode-backed kernel lease, not a marker file: file existence is not lock ownership, and flock protects an open inode. Unlinking a contended pathname can let another process create and lock a new inode while the original writer still owns the old inode.
  3. Probe the exact lock read-only with a non-blocking exclusive flock. Open it without truncation, report only acquirable, contended, missing, or the read error, then close it immediately. Never resume the session as a probe.
  4. Read the lock body's PID only as a hint. A tool sandbox or PID namespace may not see the host process; ps/kill -0 absence inside it cannot prove that the host owner died. Request a host-shell check when that distinction matters.
  5. Check the bounded session evidence for prior file mutation involving .session.lock, especially rm, unlink, replacement, truncation, or recreation. If the path is missing while old activity advances, stop resume attempts and preserve evidence.

Never remove, replace, truncate, or recreate .session.lock as diagnosis or repair. Never signal the owner from Diagnose. Do not request takeover or use an owner-control endpoint. Ask the user to exit the owning process normally, then explicitly retry ordinary resume.

Classify the result before recommending an action:

EvidenceClassificationSafe next action
Lease is acquirableNo current kernel owner; a leftover pathname is harmlessRetry normal resume; do not clean the file for tidiness
contended lease with advancing session activityLive owner and active runtime; terminal attachment may be the failed layerPreserve the owner; inspect terminal/PTY evidence or exit it normally
Contended lease with bounded activity idleLive kernel owner, runtime/terminal health unknownAsk the user to exit the owning process normally, then explicitly retry ordinary resume
Legacy owner-control artifacts are presentDiagnostic leftovers from an old binary; the kernel lease remains authoritativeTreat them as diagnostic only; exit the owning process normally before ordinary resume retry
Lock path was unlinked or replaced while old activity continuesUnsafe prior mutation with possible dual writersStop further resume attempts, preserve both inode/session timelines, and escalate; do not recreate the lock

A contended lease proves a live kernel owner, not that its TUI, terminal, provider, or runtime is healthy. Pin the failing layer from activity plus host-visible evidence before proposing a product fix.

Narrowing Loop

Work from evidence:

  1. State the most likely layer in one or two concrete sentences.
  2. Say why the next check will confirm or reject that hypothesis, then run that one safe local check.
  3. Update the hypothesis from the result and continue only while the next check is still relevant and safe.
  4. If a live provider, live network, destructive command, or upload is required, state why and get explicit user approval first.
  5. If customization or local state is suspected, compare against an isolated temporary XDG config/data profile only after explaining that it will not read or mutate the user's real settings.

Common Diagnosis Paths

  • Startup/auth: binary path -> version -> config load -> auth provider present -> model/catalog selection -> first network boundary.
  • Provider/model: selected provider/model -> base URL with credentials redacted -> auth presence -> model catalog cache -> trace request/error summary.
  • Session/resume: session id/path -> workspace match -> session log exists -> resume/export/trace command -> whether the user wants inspection or continuation.
  • Skills/plugins/MCP: list/discovery -> activation/trust -> validation output -> runtime trace or startup diagnostic.
  • Desktop/TUI: packaged app/binary version -> session id -> UI-visible symptom -> crash/report metadata -> trace/export evidence. Say when source-only tests cannot prove a packaged-app issue.

Fix Boundary

  • Settings-only fix: propose the exact change and apply it only after explicit user request; preserve unknown settings fields and verify with a read-back or focused command.
  • Workspace code fix: switch to the RED-before-GREEN engineering loop only when the user explicitly asks to fix code in the current repo. Reproduce first, edit surgically, rerun the same check, and report incomplete if it still fails.
  • Product bug report: if the evidence points to Muse Code itself and no local fix is safe, give a concise support bundle with symptom, version, config/data paths, session/crash paths, redacted export/trace evidence, likely cause, and next action.

Completion Report

Include:

  • Symptom and affected surface.
  • Product mental model relevant to this failure.
  • Evidence collected, paths inspected, commands and outcomes.
  • Redactions applied.
  • Most likely cause and confidence.
  • Fix made, proposed, or not made.
  • Remaining uncertainty and the next safest check.

© asgeirtj, CC0-1.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (scripts) in Meta/muse-code/skills/doctor of asgeirtj/system_prompts_leaks.

  • SKILL.md
  • scripts/session-evidence.py

Open the folder on GitHubat commit 181ebcd

Compare with similar skills

Muse Code Product Doctor next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Muse Code Product Doctor compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Muse Code Product Doctor this skillasgeirtj/system_prompts_leaks69k—~3.5kAutomated safety check: PassCC0-1.0
Octocode Code Researchbgauryy/octocode949—~1.5kAutomated safety check: PassMIT
Root Cause Investigationgarrytan/gstack136k—~13kAutomated safety check: NotesMIT
Evidence-Driven TraceYeachan-Heo/oh-my-claudecode40k—~2.6kAutomated safety check: PassMIT
Targeted Emergency Bug FixVeryGoodOpenSource/vgv-wingspan109—~1.9kAutomated safety check: PassMIT
OMC Session DebuggerYeachan-Heo/oh-my-claudecode40k—~361Automated safety check: PassMIT

Similar skills

  • Octocode Code Research

    bgauryy/octocode

    Researches code with evidence: traces callers, imports and cross-repo links, diagnoses failures and reports findings with exact file and line references and a confidence label.

    949 GitHub stars~1.5k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Root Cause Investigation

    garrytan/gstack

    Debugs in four phases (investigate, analyze, hypothesize, implement) under one rule: no fix is made until the root cause is found.

    136k GitHub stars~13k tokensUpdated today
    DevelopmentAuto-check: notes

  • Evidence-Driven Trace

    Yeachan-Heo/oh-my-claudecode

    Explains why something happened by generating competing hypotheses, gathering evidence in parallel, ranking explanations and proposing the next discriminating probe.

    40k GitHub stars~2.6k tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • Targeted Emergency Bug Fix

    VeryGoodOpenSource/vgv-wingspan

    Applies a minimal fix to an emergency bug through triage, root-cause location, a hotfix branch and a blast-radius check, with tests and review still required.

    109 GitHub stars~1.9k tokensUpdated 4 days ago
    DevelopmentAuto-check passed

  • OMC Session Debugger

    Yeachan-Heo/oh-my-claudecode

    Diagnoses a broken oh-my-claudecode session or repository state from logs, traces, state and a narrow reproduction, then names the smallest next fix.

    40k GitHub stars~361 tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • Flowstudio Power Automate Debug

    github/awesome-copilot

    Official

    Debug failing Power Automate cloud flows using the FlowStudio MCP server.

    40k GitHub starsUsed in 2 repos~5k tokens
    DevelopmentAuto-check passed

More from asgeirtj/system_prompts_leaks

All 125 skills in this repo

  • Fleet Manager for Agent Sessions

    asgeirtj/system_prompts_leaks

    Shows one digest of coding-agent sessions across your connected machines and lets you open, read, steer, approve, stop and close them, over Herdr, tmux or MSP.

    69k GitHub stars~2.5k tokensUpdated today
    Auto-check passed

  • DOCX

    asgeirtj/system_prompts_leaks

    A skill your agent uses whenever the user wants to create, read, edit, or manipulate Word documents (.docx) or Word templates (.dotx).

    69k GitHub stars~1.9k tokensUpdated today
    Auto-check passed

  • Agents Project Coordinator

    asgeirtj/system_prompts_leaks

    Runs a goal as a project in which the agent coordinates separate agent threads, judging when to split the work, and interviews you first when nothing can be verified.

    69k GitHub stars~2.9k tokensUpdated today
    Auto-check passed

  • Muse Plugin Creator

    asgeirtj/system_prompts_leaks

    Creates and validates a new native Muse plugin package in the current workspace, limited to five capability families, and leaves installation to you.

    69k GitHub stars~1.8k tokensUpdated today
    Auto-check passed

  • Deep Research

    asgeirtj/system_prompts_leaks

    A skill your agent uses when the user's prompt requires (1) researching a topic across multiple sources, comparing options or alternatives, analyzing trends or history, understanding markets or…

    69k GitHub stars~3.3k tokensUpdated today
    Auto-check passed

  • Figma Design Inspector

    asgeirtj/system_prompts_leaks

    Inspects Figma designs through the figma CLI and Figma's MCP server to read variants, spacing, tokens and layouts and to extract assets for implementation.

    69k GitHub stars~936 tokensUpdated today
    Auto-check passed

Categories

Questions about Muse Code Product Doctor

What does Muse Code Product Doctor do?

Diagnoses a Muse Code installation's own failures from binary and session evidence, instead of treating the report as an ordinary repository bug. Activates only on an explicit request to debug Muse Code itself, such as a crash, a provider or auth problem, a broken plugin, or a question about what happened earlier in the current session. It treats the person as a product user rather than a repository engineer, assuming they have only the installed binary, and works toward explaining how the app behaves, gathering the smallest safe set of evidence, naming the likely failing layer, and suggesting one safe next step.

When should I use Muse Code Product Doctor?

Muse Code Product Doctor fits situations like: debugging a Muse Code crash, auth failure, or unexpected output; asking what happened earlier in the current Muse Code session; collecting a support bundle for a broken Muse Code install; understanding where Muse Code stores its state or logs.

How do I install Muse Code Product Doctor in Claude Code?

Run `npx skills add asgeirtj/system_prompts_leaks --skill doctor -a claude-code`. Or copy the skill folder (Meta/muse-code/skills/doctor in asgeirtj/system_prompts_leaks) into .claude/skills/doctor in your project. Claude Code loads it when a task matches its description.

How do I install Muse Code Product Doctor in Codex?

Run `npx skills add asgeirtj/system_prompts_leaks --skill doctor -a codex`. Or copy the skill folder (Meta/muse-code/skills/doctor in asgeirtj/system_prompts_leaks) into .agents/skills/doctor in your project. Codex loads it when a task matches its description.

Can I use Muse Code Product Doctor in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add asgeirtj/system_prompts_leaks --skill doctor -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/doctor, .gemini/skills/doctor, .github/skills/doctor and .opencode/skills/doctor in your project.

What does Muse Code Product Doctor need to run?

Going by SKILL.md and its folder, Muse Code Product Doctor needs Python for the scripts in its folder and the command-line tools its instructions call (python3). Our summary lists: A local Muse Code installation; Python, to run the bundled evidence-collection script.

Does Muse Code Product Doctor access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Muse Code Product Doctor safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Muse Code Product Doctor use?

Muse Code Product Doctor is published under the CC0-1.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Muse Code Product Doctor use?

About 3.5k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Muse Code Product Doctor?

Skills that share tags, products or a category with Muse Code Product Doctor: Octocode Code Research (bgauryy/octocode, 949 stars), Root Cause Investigation (garrytan/gstack, 136k stars), Evidence-Driven Trace (Yeachan-Heo/oh-my-claudecode, 40k stars) and Targeted Emergency Bug Fix (VeryGoodOpenSource/vgv-wingspan, 109 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Muse Code Product Doctor?

asgeirtj (a GitHub user) maintains it in asgeirtj/system_prompts_leaks, which has 69,367 GitHub stars. The repository holds 128 skills in this directory. The repository was last updated on October 10, 2026.

Source: asgeirtj/system_prompts_leaks on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.