[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DJJ75MC4PZFD3NBY8CHQXP":3,"skill-same:01M6DJJ75MC4PZFD3NBY8CHQXP":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6DJJ75MC4PZFD3NBY8CHQXP","debug-mantra",null,"Four-mantra debugging discipline — reproduce, trace the fail path, falsify the hypothesis, cross-reference every breadcrumb. Recite the mantra block verbatim at the start of any debugging session, then apply the four steps in order before proposing any fix. Trigger on \u002Fdebug-mantra and proactively whenever debugging starts — user reports a bug, says something is broken\u002Fthrowing\u002Ffailing, asks to debug\u002Fdiagnose\u002Finvestigate an issue, or pastes a stack trace or error log.","danchamorro\u002Fpi-agent-toolkit","danchamorro","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F19739839?v=4","01M6DJG9M33RM5P1GFCFG9DSJE","Dan Chamorro","01M6DJG9QYKDT43HSTFG1JPK82",17,"MIT","https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fengineering\u002Fdebug-mantra\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"debug mantra","debug","user","trigger","issue","reference","reports","bug","discipline","session","fix","broken","trace","reproduce","stack","investigate","hypothesis","start","debugging","diagnose","2026-11-10 10:12:30",false,"---\nname: debug-mantra\ndescription: Four-mantra debugging discipline — reproduce, trace the fail path, falsify the hypothesis, cross-reference every breadcrumb. Recite the mantra block verbatim at the start of any debugging session, then apply the four steps in order before proposing any fix. Trigger on \u002Fdebug-mantra and proactively whenever debugging starts — user reports a bug, says something is broken\u002Fthrowing\u002Ffailing, asks to debug\u002Fdiagnose\u002Finvestigate an issue, or pastes a stack trace or error log.\n---\n\n# Debug Mantra\n\nFour-step discipline for any debug session. Recite verbatim, then apply in order.\n\n## Recite this — verbatim, as the first thing in your first response\n\n> **Mantra:**\n> 1. **First is reproducibility.** Can the issue be reproduced reliably?\n> 2. **Know the fail path.** Debugger first; then source trace + knob enumeration; then in-code instrumentation.\n> 3. **Question your hypothesis.** What would disprove it?\n> 4. **Every run is a breadcrumb.** Cross-reference all of them.\n\nThen begin work.\n\n---\n\n## 1. Reproduce reliably\n\nBuild a runnable repro before anything else.\n\n- **Reliable repro** → capture the exact steps, inputs, and environment as a runnable artifact: failing test, curl script, CLI invocation, replay harness.\n- **Flaky repro** → the bug is not yet debuggable. Raise the rate first: loop the trigger, parallelise, add stress, narrow timing windows, inject sleeps. 50% flake is debuggable; 1% is not.\n- **No repro at all** → stop. Say so explicitly. Ask the user for env access, captured artifacts (HAR, log dump, core), or permission to instrument. Do **not** proceed to hypothesise.\n\nTarget: a fast (1–5 s), deterministic pass\u002Ffail signal. Pin time, seed the RNG, freeze network, isolate filesystem.\n\n## 2. Know the fail path\n\nOnce reproducible, find *where* the code breaks and *what stops it from breaking*. The differential narrows the search. Try in this order — escalate only when the prior tactic fails.\n\n1. **Attach a debugger.** If the env supports it, attach and step to the failure site. One breakpoint beats ten logs. Do this **before** turning any knobs.\n2. **Source trace + knob enumeration.** If no debugger (or it can't reach the bug), trace the code path end-to-end and list every knob that can influence the outcome:\n   - config flags, env vars, feature toggles\n   - branch conditions, input shape\n   - timing, concurrency, build options\n   Each knob is a candidate axis to flip in the differential. Flip one at a time.\n3. **In-code instrumentation.** If outside knobs can't move the failure, go inside: `printf` \u002F log statements at the suspected fail site, dump the relevant internal state. Tag every probe with a unique prefix (e.g. `[DBG-a4f2]`) so cleanup is a single grep. Let the trace show where reality diverges from your model.\n\n## 3. Falsify the hypothesis\n\nWhen a candidate root cause surfaces, scrutinise it **before** testing it.\n\n- Does it actually explain the symptom end-to-end? Walk it through.\n- What is the simplest **proof**? What is the cleanest **disproof**?\n- Run the **disproof first**. If the hypothesis survives, it's real. If it dies, you saved yourself from chasing a phantom.\n- Generate 3–5 ranked hypotheses, not one. Single-hypothesis thinking anchors on the first plausible idea.\n\n## 4. Every run is a breadcrumb\n\nMaintain a running **ledger** of every experiment in this session. Each entry: what changed, what happened, what it ruled in or out.\n\n- When a new hypothesis surfaces, walk the ledger. Does it hold for **every** prior observation, not just the most recent?\n- If any past run contradicts it, the hypothesis is wrong or incomplete — refine or discard.\n- When in doubt, design the **single experiment** whose outcome makes it certain. Run that next, instead of churning on adjacent runs.\n- Update the ledger after every run. It is your memory across the session.\n\n---\n\n## Operating rules\n\n- Recite the mantra block **once** per debug session, in your first response. Do not re-recite mid-session.\n- Recite **verbatim**. Never paraphrase, shorten, or skip lines of the recital.\n- If the user says \"skip the mantra\" → skip the recital but still apply the four steps silently.\n- Apply the four steps **in order**:\n  - Do not propose a fix before #1 is satisfied (reliable repro exists).\n  - Do not start testing hypotheses before #2 has narrowed the fail path.\n  - Do not commit to a hypothesis before #3 has tried to disprove it.\n  - Do not declare a hypothesis correct until #4 confirms it against every prior breadcrumb.\n- If you catch yourself proposing a fix without a reliable repro, stop and return to step 1.\n- The mantra is a constraint **you** carry through the session — not advice to deliver back to the user.\n","# Debug Mantra\n\nFour-step discipline for any debug session. Recite verbatim, then apply in order.\n\n## Recite this — verbatim, as the first thing in your first response\n\n> **Mantra:**\n> 1. **First is reproducibility.** Can the issue be reproduced reliably?\n> 2. **Know the fail path.** Debugger first; then source trace + knob enumeration; then in-code instrumentation.\n> 3. **Question your hypothesis.** What would disprove it?\n> 4. **Every run is a breadcrumb.** Cross-reference all of them.\n\nThen begin work.\n\n---\n\n## 1. Reproduce reliably\n\nBuild a runnable repro before anything else.\n\n- **Reliable repro** → capture the exact steps, inputs, and environment as a runnable artifact: failing test, curl script, CLI invocation, replay harness.\n- **Flaky repro** → the bug is not yet debuggable. Raise the rate first: loop the trigger, parallelise, add stress, narrow timing windows, inject sleeps. 50% flake is debuggable; 1% is not.\n- **No repro at all** → stop. Say so explicitly. Ask the user for env access, captured artifacts (HAR, log dump, core), or permission to instrument. Do **not** proceed to hypothesise.\n\nTarget: a fast (1–5 s), deterministic pass\u002Ffail signal. Pin time, seed the RNG, freeze network, isolate filesystem.\n\n## 2. Know the fail path\n\nOnce reproducible, find *where* the code breaks and *what stops it from breaking*. The differential narrows the search. Try in this order — escalate only when the prior tactic fails.\n\n1. **Attach a debugger.** If the env supports it, attach and step to the failure site. One breakpoint beats ten logs. Do this **before** turning any knobs.\n2. **Source trace + knob enumeration.** If no debugger (or it can't reach the bug), trace the code path end-to-end and list every knob that can influence the outcome:\n   - config flags, env vars, feature toggles\n   - branch conditions, input shape\n   - timing, concurrency, build options\n   Each knob is a candidate axis to flip in the differential. Flip one at a time.\n3. **In-code instrumentation.** If outside knobs can't move the failure, go inside: `printf` \u002F log statements at the suspected fail site, dump the relevant internal state. Tag every probe with a unique prefix (e.g. `[DBG-a4f2]`) so cleanup is a single grep. Let the trace show where reality diverges from your model.\n\n## 3. Falsify the hypothesis\n\nWhen a candidate root cause surfaces, scrutinise it **before** testing it.\n\n- Does it actually explain the symptom end-to-end? Walk it through.\n- What is the simplest **proof**? What is the cleanest **disproof**?\n- Run the **disproof first**. If the hypothesis survives, it's real. If it dies, you saved yourself from chasing a phantom.\n- Generate 3–5 ranked hypotheses, not one. Single-hypothesis thinking anchors on the first plausible idea.\n\n## 4. Every run is a breadcrumb\n\nMaintain a running **ledger** of every experiment in this session. Each entry: what changed, what happened, what it ruled in or out.\n\n- When a new hypothesis surfaces, walk the ledger. Does it hold for **every** prior observation, not just the most recent?\n- If any past run contradicts it, the hypothesis is wrong or incomplete — refine or discard.\n- When in doubt, design the **single experiment** whose outcome makes it certain. Run that next, instead of churning on adjacent runs.\n- Update the ledger after every run. It is your memory across the session.\n\n---\n\n## Operating rules\n\n- Recite the mantra block **once** per debug session, in your first response. Do not re-recite mid-session.\n- Recite **verbatim**. Never paraphrase, shorten, or skip lines of the recital.\n- If the user says \"skip the mantra\" → skip the recital but still apply the four steps silently.\n- Apply the four steps **in order**:\n  - Do not propose a fix before #1 is satisfied (reliable repro exists).\n  - Do not start testing hypotheses before #2 has narrowed the fail path.\n  - Do not commit to a hypothesis before #3 has tried to disprove it.\n  - Do not declare a hypothesis correct until #4 confirms it against every prior breadcrumb.\n- If you catch yourself proposing a fix without a reliable repro, stop and return to step 1.\n- The mantra is a constraint **you** carry through the session — not advice to deliver back to the user.\n",{"name":5,"description":7},"main","b762a116c343f012c9b23009a7f2d9af217b8b00","dotfiles\u002Fpersonal-skills\u002Fengineering\u002Fdebug-mantra",1,"https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit","https:\u002F\u002Fgithub.com\u002Fdanchamorro","https:\u002F\u002Fdanchamorro.com","Python engineer by day, SaaS founder by night","2026-08-24 04:44:54",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add danchamorro\u002Fpi-agent-toolkit --skill debug-mantra",{"tool":64,"command":65},"bunx","bunx skills add danchamorro\u002Fpi-agent-toolkit --skill debug-mantra",{"tool":67,"command":68},"pnpm","pnpm dlx skills add danchamorro\u002Fpi-agent-toolkit --skill debug-mantra","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fengineering\u002Fdebug-mantra\u002FSKILL.md",true,[],[73,105,124,139,171,186],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":85,"publishedAt":44},"01M6DJKPTTD68WF0YJRZ4XNRVH","1password-developer","Work with 1Password developer features including SSH key management, the SSH agent, 1Password Environments for secrets injection, and the op CLI. Use this skill whenever the user mentions 1Password, op CLI, 1Password SSH agent, 1Password Environments, secret references, op run, op inject, or wants to manage SSH keys through 1Password, secure .env files with 1Password, or inject secrets at runtime. Also trigger when the user wants to stop storing plaintext secrets on disk or asks about securing developer credentials.","https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fsecurity-environment\u002F1password-developer\u002FSKILL.md",[79,84],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[86,87,88,89,90,27,91,92,93,94,95,96,97,98,99,100,101,102,103,104],"1password developer","developer","1password","cli","work","env","runtime","references","manage","files","use","management","disk","secrets","credentials","ssh","injection","run","secure",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":44},"01M6DJKJ8FW4D1R7009DBJAN0Z","plan-reviewer","Use when creating, refining, or reviewing implementation plans, migration plans, refactoring proposals, feature plans, implementation trackers, or committable phase plans; especially when turning a rough plan into executable phases or checking whether a plan is concrete, testable, safe, dependency-aware, and suitable for parallel work.","https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fplanning\u002Fplan-reviewer\u002FSKILL.md",[],[112,113,114,115,116,117,118,119,96,120,90,121,122,123],"plan reviewer","reviewer","plan","plans","feature","implementation","migration","dependency","proposals","parallel","refactoring","safe",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":44},"01M6DJKC1N9DDSGDNE8AZJ4NZ0","brainstorm","Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions \"brainstorm\".","https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fplanning\u002Fbrainstorm\u002FSKILL.md",[],[126,131,132,133,96,134,135,136,114,137,138,26],"get","shared","stress-test","interview","branch","decision","test","design",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":151,"publishedAt":44},"01M6DJK7Z2833PKW7PHQR7P956","youtube-video-context","Use this skill whenever the user gives a YouTube URL and asks to summarize, digest, analyze, extract transcript\u002Fcontext, decide whether a video is worth watching, or understand what a video is about. Prefer the summarize CLI for YouTube\u002Fvideo context instead of web search. Use Codex as the default summarize backend when possible, and use the local Whisper large-v3 model for transcription fallback. Do not use this for ordinary web pages; use the installed web-access tools for webpage research.","https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fmedia\u002Fyoutube-video-context\u002FSKILL.md",[145,148],{"categoryNo":146,"categoryName":147,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":149,"categoryName":150,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000021","资料检索与研究",[152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,96,170],"youtube video context","youtube","context","Video","web search","access","dlp","search","cpp","model","local","as","v3","pages","yt-dlp","local whisper","do","default","decide",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":44},"01M6DJK3RXFZP1M42D0MEG19D8","thermos","Launch both thermo-nuclear review subagents in parallel. Use for thermos, double thermo review, or combined bug\u002Fsecurity and code-quality branch audits.","https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fengineering\u002Fthermos\u002FSKILL.md",[],[173,178,179,31,96,135,180,121,181,182,183,184,185],"subagents","nuclear","quality","code-quality","code","launch","security","review",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":44},"01M6DJK0D7GN2THPKEYQTXSAYM","thermo-nuclear-review","Comprehensive security and correctness audit of a branch's changes. Use for thermo nuclear, thermonuclear, or deep review requests, or branch\u002FPR diff audits focused on bugs, breaking changes, security issues, devex regressions, and feature-gate leaks.","https:\u002F\u002Fgithub.com\u002Fdanchamorro\u002Fpi-agent-toolkit\u002Fblob\u002Fmain\u002Fdotfiles\u002Fpersonal-skills\u002Fengineering\u002Fthermo-nuclear-review\u002FSKILL.md",[],[185,179,193,194,195,135,184,196,197,198,116,96,199,200,201],"thermo nuclear review","audit","deep review","pr","issues","deep","diff","thermonuclear","gate"]