[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KZDRZB9PFGWWGKB6HDD1Z":3,"skill-same:01M71KZDRZB9PFGWWGKB6HDD1Z":64},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":46,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M71KZDRZB9PFGWWGKB6HDD1Z","mastermind-debug",null,"Root-cause debugging protocol to run before any fix: test failures, bugs, unexpected behavior, build failures, performance regressions.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmastermind-debug\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35],"mastermind debug","debug","performance","fix","debugging","run","bugs","root-cause","test","build","behavior","protocol","root","2026-11-10 10:56:23",false,"---\nname: mastermind-debug\ndescription: \"Root-cause debugging protocol to run before any fix: test failures, bugs, unexpected behavior, build failures, performance regressions.\"\n---\n\n# mastermind:debug — Systematic Debugging\n\n## Overview\n\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n**Violating the letter of this process is violating the spirit of debugging.**\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf you haven't completed Phase 1, you cannot propose fixes.\n\n## When to Use\n\nUse for ANY technical issue:\n- Test failures\n- Bugs in production or staging\n- Unexpected behavior\n- Performance regressions\n- Build failures\n- Integration issues\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes that didn't work\n- Previous fix didn't resolve the issue\n- You don't fully understand what's happening\n\n**Don't skip when:**\n- Issue seems simple (simple bugs have root causes too)\n- You're in a hurry (systematic is faster than thrashing)\n- The user wants it fixed immediately (systematic approach finds the real fix faster)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n---\n\n### Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n1. **Read Error Messages Carefully**\n   - Don't skim errors or warnings\n   - They often contain the exact solution\n   - Read stack traces completely\n   - Note line numbers, file paths, error codes\n\n2. **Reproduce Consistently**\n   - Can you trigger the issue reliably?\n   - What are the exact steps?\n   - Does it happen every time?\n   - If not reproducible → gather more data, don't guess\n\n3. **Check Recent Changes**\n   - What changed that could cause this?\n   - `git diff`, recent commits, new dependencies, config changes\n   - Environmental differences between working and broken states\n\n4. **Gather Evidence in Multi-Component Systems**\n\n   **WHEN the system has multiple components (CI → build → deploy, API → service → database):**\n\n   **BEFORE proposing fixes, add diagnostic instrumentation:**\n   ```\n   For EACH component boundary:\n     - Log what data enters the component\n     - Log what data exits the component\n     - Verify config\u002Fenv propagation at each layer\n     - Check state at each boundary\n\n   Run once to gather evidence showing WHERE it breaks\n   THEN analyze evidence to identify the failing component\n   THEN investigate that specific component\n   ```\n\n   **Example:**\n   ```bash\n   # Layer 1: entry point\n   echo \"=== Input received: ===\"\n   echo \"VAR: ${VAR:+SET}${VAR:-UNSET}\"\n\n   # Layer 2: processing\n   echo \"=== State after processing: ===\"\n   env | grep VAR || echo \"VAR not in environment\"\n\n   # Layer 3: output\u002Fresult\n   echo \"=== Final state: ===\"\n   ```\n\n5. **Trace Data Flow**\n\n   **WHEN the error is deep in a call stack:**\n   - Where does the bad value originate?\n   - What called this with the bad value?\n   - Keep tracing up until you find the source\n   - Fix at the source, not at the symptom — a `null` crashing in layer 4 usually entered in layer 1\n\n---\n\n### Phase 2: Pattern Analysis\n\nOnce you understand WHERE the break is, find existing working examples:\n\n1. **Find working code that solves the same problem**\n   - Search the codebase for similar patterns\n   - Check git history for when this worked\n   - Find the canonical implementation to compare against\n\n2. **Compare against references**\n   - If implementing a pattern, read the reference implementation COMPLETELY\n   - Don't skim — read every line\n   - Understand the pattern fully before applying it\n\n3. **Compare broken vs. working**\n   - What's different?\n   - List every difference, not just the obvious one — don't assume \"that can't matter\"\n   - Environment, config, data, timing\n\n4. **Understand dependencies**\n   - What other components does this need?\n   - What settings, config, environment?\n   - What assumptions does it make?\n\n---\n\n### Phase 3: Form and Test a Hypothesis\n\n1. **State your hypothesis explicitly:**\n   > \"I believe the root cause is [X] because [evidence Y] and [evidence Z].\"\n\n2. **Test the hypothesis minimally**\n   - Change one thing and observe the result\n   - If it doesn't confirm or deny, gather more evidence\n   - A confirmed hypothesis means you understand the root cause\n\n3. **If hypothesis is wrong:** Do NOT add more fixes. Return to Phase 1 with the new information.\n\n4. **When you don't know:** Say \"I don't understand X\". Don't pretend to know. Research more or ask the user — a stated unknown beats a confident guess.\n\n---\n\n### Phase 4: Implementation\n\n1. **Write a failing test first** (before touching production code)\n   - Automated test where possible; a one-off test script if no framework\n   - Write the test so it fails for the stated root cause, not for a setup error\n   - The test MUST fail before the fix proves it\n\n2. **Implement a single fix**\n   - Address the root cause identified in Phase 3\n   - ONE change at a time\n   - No \"while I'm here\" improvements\n   - No bundled refactoring\n\n3. **Verify the fix**\n   - Test passes now?\n   - No other tests broken?\n   - Issue actually resolved?\n   - Use `Skill(\"mastermind-review\")` to verify before declaring done\n\n4. **If the fix doesn't work:**\n   - STOP\n   - Count: How many fixes have you tried?\n   - If \u003C 3: Return to Phase 1, re-analyze with the new information\n   - **If ≥ 3: STOP — this is likely an architectural problem (see Phase 4.5 below)**\n   - Do NOT attempt a 4th fix without architectural discussion\n\n---\n\n### Phase 4.5 — If 3+ Fixes Have Failed: Question the Architecture\n\n**Pattern indicating an architectural problem:**\n- Each fix reveals new coupling or shared state issues in a different place\n- Each fix creates new symptoms elsewhere\n- Fixes require \"massive refactoring\" to implement cleanly\n\n**STOP and question fundamentals:**\n- Is this design pattern fundamentally sound?\n- Are we continuing out of inertia?\n- Should we refactor the architecture rather than continue patching?\n\n**Discuss with the user before attempting more fixes.** This is not a failed hypothesis — this is the wrong architecture.\n\n---\n\n## Red Flags — STOP and Return to Phase 1\n\nIf you catch yourself thinking or doing any of these:\n\n| Thought \u002F Action | What it means |\n|---|---|\n| \"Quick fix for now, investigate later\" | You're skipping root cause. Return to Phase 1. |\n| \"Just try changing X and see if it works\" | Guessing. Return to Phase 1. |\n| \"Add multiple changes, run tests\" | Can't isolate what worked. Return to Phase 1. |\n| \"Skip the test, I'll manually verify\" | Untested fixes don't stick. Write the failing test. |\n| \"Pattern says X but I'll adapt it differently\" | Partial understanding guarantees bugs. Read the reference completely. |\n| \"Here are the main problems: …\" (listing fixes without investigation) | Solutions before evidence. Return to Phase 1. |\n| \"It's probably X, let me fix that\" | Assumed root cause. Verify it first. Return to Phase 1. |\n| \"I don't fully understand but this might work\" | You don't have a hypothesis. Return to Phase 1. |\n| Proposing solutions before tracing data flow | No root cause. Return to Phase 1. |\n| \"One more fix attempt\" (already tried 2+) | 3+ failures = architectural problem. Phase 4.5. |\n| Each fix reveals a new problem in a different place | Architectural problem. Phase 4.5. |\n\n## User Signals You're Doing It Wrong\n\nWatch for these redirections from the user:\n\n| Signal | What it means |\n|---|---|\n| \"Is that actually happening?\" | You assumed without verifying. Add evidence gathering. |\n| \"What does the output show?\" | You should have checked before proposing a fix. |\n| \"Stop guessing\" | You're proposing fixes without root cause. Phase 1. |\n| \"We keep going in circles\" | 3+ fix attempts = architectural problem. Phase 4.5. |\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|---|---|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple bugs. |\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"I'll write the test after confirming the fix works\" | Untested fixes don't stick. Test first proves it. |\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Creates new bugs. |\n| \"Reference too long, I'll adapt the pattern\" | Partial understanding guarantees bugs. Read it completely. |\n| \"I can see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern. |\n\n## Quick Reference\n\n| Phase | Key Activities | Success Criteria |\n|---|---|---|\n| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare | Identified differences |\n| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |\n| **4. Implementation** | Write failing test, fix, verify | Bug resolved, tests pass |\n\n## When the Process Reveals \"No Root Cause\"\n\nIf systematic investigation reveals the issue is truly environmental, timing-dependent, or external:\n\n1. You've completed the process\n2. Document what you investigated\n3. Implement appropriate handling (retry, timeout, clear error message)\n4. Add monitoring\u002Flogging for future investigation\n\n**But:** 95% of \"no root cause\" cases are incomplete investigation.\n\n## Supporting Techniques\n\n- **Root-cause tracing:** when a bad value crashes deep in the stack, trace it backward caller by caller until you find where it was created; fix there. Adding a guard at the crash site only hides the origin.\n- **Defense in depth:** AFTER fixing the root cause, add validation at the layers the bad value passed through unchecked — so the next bad value fails loudly at its first boundary, not silently at its fourth.\n- **Condition-based waiting:** replace arbitrary sleeps\u002Ftimeouts in flaky tests and scripts with polling for the actual condition (\"wait until the file exists \u002F the port answers\"), with a hard cap. Timing guesses are bugs waiting for a slower machine.\n\n**Related skills:**\n- `Skill(\"mastermind-review\")` — verify the fix worked before claiming success\n- `Skill(\"mastermind-plan\")` — when the root cause turns out to need a multi-file change\n\n## Impact\n\nSystematic approach vs random fixing:\n- Time to fix: 15-30 min vs 2-3 hours of thrashing\n- First-time fix rate: ~95% vs ~40%\n- New bugs introduced by the fix: near zero vs common\n","# mastermind:debug — Systematic Debugging\n\n## Overview\n\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n**Violating the letter of this process is violating the spirit of debugging.**\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf you haven't completed Phase 1, you cannot propose fixes.\n\n## When to Use\n\nUse for ANY technical issue:\n- Test failures\n- Bugs in production or staging\n- Unexpected behavior\n- Performance regressions\n- Build failures\n- Integration issues\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes that didn't work\n- Previous fix didn't resolve the issue\n- You don't fully understand what's happening\n\n**Don't skip when:**\n- Issue seems simple (simple bugs have root causes too)\n- You're in a hurry (systematic is faster than thrashing)\n- The user wants it fixed immediately (systematic approach finds the real fix faster)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n---\n\n### Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n1. **Read Error Messages Carefully**\n   - Don't skim errors or warnings\n   - They often contain the exact solution\n   - Read stack traces completely\n   - Note line numbers, file paths, error codes\n\n2. **Reproduce Consistently**\n   - Can you trigger the issue reliably?\n   - What are the exact steps?\n   - Does it happen every time?\n   - If not reproducible → gather more data, don't guess\n\n3. **Check Recent Changes**\n   - What changed that could cause this?\n   - `git diff`, recent commits, new dependencies, config changes\n   - Environmental differences between working and broken states\n\n4. **Gather Evidence in Multi-Component Systems**\n\n   **WHEN the system has multiple components (CI → build → deploy, API → service → database):**\n\n   **BEFORE proposing fixes, add diagnostic instrumentation:**\n   ```\n   For EACH component boundary:\n     - Log what data enters the component\n     - Log what data exits the component\n     - Verify config\u002Fenv propagation at each layer\n     - Check state at each boundary\n\n   Run once to gather evidence showing WHERE it breaks\n   THEN analyze evidence to identify the failing component\n   THEN investigate that specific component\n   ```\n\n   **Example:**\n   ```bash\n   # Layer 1: entry point\n   echo \"=== Input received: ===\"\n   echo \"VAR: ${VAR:+SET}${VAR:-UNSET}\"\n\n   # Layer 2: processing\n   echo \"=== State after processing: ===\"\n   env | grep VAR || echo \"VAR not in environment\"\n\n   # Layer 3: output\u002Fresult\n   echo \"=== Final state: ===\"\n   ```\n\n5. **Trace Data Flow**\n\n   **WHEN the error is deep in a call stack:**\n   - Where does the bad value originate?\n   - What called this with the bad value?\n   - Keep tracing up until you find the source\n   - Fix at the source, not at the symptom — a `null` crashing in layer 4 usually entered in layer 1\n\n---\n\n### Phase 2: Pattern Analysis\n\nOnce you understand WHERE the break is, find existing working examples:\n\n1. **Find working code that solves the same problem**\n   - Search the codebase for similar patterns\n   - Check git history for when this worked\n   - Find the canonical implementation to compare against\n\n2. **Compare against references**\n   - If implementing a pattern, read the reference implementation COMPLETELY\n   - Don't skim — read every line\n   - Understand the pattern fully before applying it\n\n3. **Compare broken vs. working**\n   - What's different?\n   - List every difference, not just the obvious one — don't assume \"that can't matter\"\n   - Environment, config, data, timing\n\n4. **Understand dependencies**\n   - What other components does this need?\n   - What settings, config, environment?\n   - What assumptions does it make?\n\n---\n\n### Phase 3: Form and Test a Hypothesis\n\n1. **State your hypothesis explicitly:**\n   > \"I believe the root cause is [X] because [evidence Y] and [evidence Z].\"\n\n2. **Test the hypothesis minimally**\n   - Change one thing and observe the result\n   - If it doesn't confirm or deny, gather more evidence\n   - A confirmed hypothesis means you understand the root cause\n\n3. **If hypothesis is wrong:** Do NOT add more fixes. Return to Phase 1 with the new information.\n\n4. **When you don't know:** Say \"I don't understand X\". Don't pretend to know. Research more or ask the user — a stated unknown beats a confident guess.\n\n---\n\n### Phase 4: Implementation\n\n1. **Write a failing test first** (before touching production code)\n   - Automated test where possible; a one-off test script if no framework\n   - Write the test so it fails for the stated root cause, not for a setup error\n   - The test MUST fail before the fix proves it\n\n2. **Implement a single fix**\n   - Address the root cause identified in Phase 3\n   - ONE change at a time\n   - No \"while I'm here\" improvements\n   - No bundled refactoring\n\n3. **Verify the fix**\n   - Test passes now?\n   - No other tests broken?\n   - Issue actually resolved?\n   - Use `Skill(\"mastermind-review\")` to verify before declaring done\n\n4. **If the fix doesn't work:**\n   - STOP\n   - Count: How many fixes have you tried?\n   - If \u003C 3: Return to Phase 1, re-analyze with the new information\n   - **If ≥ 3: STOP — this is likely an architectural problem (see Phase 4.5 below)**\n   - Do NOT attempt a 4th fix without architectural discussion\n\n---\n\n### Phase 4.5 — If 3+ Fixes Have Failed: Question the Architecture\n\n**Pattern indicating an architectural problem:**\n- Each fix reveals new coupling or shared state issues in a different place\n- Each fix creates new symptoms elsewhere\n- Fixes require \"massive refactoring\" to implement cleanly\n\n**STOP and question fundamentals:**\n- Is this design pattern fundamentally sound?\n- Are we continuing out of inertia?\n- Should we refactor the architecture rather than continue patching?\n\n**Discuss with the user before attempting more fixes.** This is not a failed hypothesis — this is the wrong architecture.\n\n---\n\n## Red Flags — STOP and Return to Phase 1\n\nIf you catch yourself thinking or doing any of these:\n\n| Thought \u002F Action | What it means |\n|---|---|\n| \"Quick fix for now, investigate later\" | You're skipping root cause. Return to Phase 1. |\n| \"Just try changing X and see if it works\" | Guessing. Return to Phase 1. |\n| \"Add multiple changes, run tests\" | Can't isolate what worked. Return to Phase 1. |\n| \"Skip the test, I'll manually verify\" | Untested fixes don't stick. Write the failing test. |\n| \"Pattern says X but I'll adapt it differently\" | Partial understanding guarantees bugs. Read the reference completely. |\n| \"Here are the main problems: …\" (listing fixes without investigation) | Solutions before evidence. Return to Phase 1. |\n| \"It's probably X, let me fix that\" | Assumed root cause. Verify it first. Return to Phase 1. |\n| \"I don't fully understand but this might work\" | You don't have a hypothesis. Return to Phase 1. |\n| Proposing solutions before tracing data flow | No root cause. Return to Phase 1. |\n| \"One more fix attempt\" (already tried 2+) | 3+ failures = architectural problem. Phase 4.5. |\n| Each fix reveals a new problem in a different place | Architectural problem. Phase 4.5. |\n\n## User Signals You're Doing It Wrong\n\nWatch for these redirections from the user:\n\n| Signal | What it means |\n|---|---|\n| \"Is that actually happening?\" | You assumed without verifying. Add evidence gathering. |\n| \"What does the output show?\" | You should have checked before proposing a fix. |\n| \"Stop guessing\" | You're proposing fixes without root cause. Phase 1. |\n| \"We keep going in circles\" | 3+ fix attempts = architectural problem. Phase 4.5. |\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|---|---|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple bugs. |\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"I'll write the test after confirming the fix works\" | Untested fixes don't stick. Test first proves it. |\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Creates new bugs. |\n| \"Reference too long, I'll adapt the pattern\" | Partial understanding guarantees bugs. Read it completely. |\n| \"I can see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern. |\n\n## Quick Reference\n\n| Phase | Key Activities | Success Criteria |\n|---|---|---|\n| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare | Identified differences |\n| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |\n| **4. Implementation** | Write failing test, fix, verify | Bug resolved, tests pass |\n\n## When the Process Reveals \"No Root Cause\"\n\nIf systematic investigation reveals the issue is truly environmental, timing-dependent, or external:\n\n1. You've completed the process\n2. Document what you investigated\n3. Implement appropriate handling (retry, timeout, clear error message)\n4. Add monitoring\u002Flogging for future investigation\n\n**But:** 95% of \"no root cause\" cases are incomplete investigation.\n\n## Supporting Techniques\n\n- **Root-cause tracing:** when a bad value crashes deep in the stack, trace it backward caller by caller until you find where it was created; fix there. Adding a guard at the crash site only hides the origin.\n- **Defense in depth:** AFTER fixing the root cause, add validation at the layers the bad value passed through unchecked — so the next bad value fails loudly at its first boundary, not silently at its fourth.\n- **Condition-based waiting:** replace arbitrary sleeps\u002Ftimeouts in flaky tests and scripts with polling for the actual condition (\"wait until the file exists \u002F the port answers\"), with a hard cap. Timing guesses are bugs waiting for a slower machine.\n\n**Related skills:**\n- `Skill(\"mastermind-review\")` — verify the fix worked before claiming success\n- `Skill(\"mastermind-plan\")` — when the root cause turns out to need a multi-file change\n\n## Impact\n\nSystematic approach vs random fixing:\n- Time to fix: 15-30 min vs 2-3 hours of thrashing\n- First-time fix rate: ~95% vs ~40%\n- New bugs introduced by the fix: near zero vs common\n",{"name":5,"description":7},"main","f7cd4595d0f8959822163e14f9787117765c931a",".claude\u002Fskills\u002Fmastermind-debug",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-14 03:30:52",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add monoes\u002Fmonomind --skill mastermind-debug",{"tool":56,"command":57},"bunx","bunx skills add monoes\u002Fmonomind --skill mastermind-debug",{"tool":59,"command":60},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill mastermind-debug","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmastermind-debug\u002FSKILL.md",true,[],[65,93,128,155,180,206],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":92},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain","2026-11-10 13:02:02",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":97,"licenseFileUrl":98,"sourceHtmlUrl":99,"categories":100,"keywords":109,"publishedAt":92},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[101,106],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":107,"categoryName":108,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000036","内容创作者",[110,111,112,76,113,114,115,116,81,117,118,119,120,121,122,123,124,125,126,127],"writing","writing plans","plans","superpowers","implementation plan","when","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":132,"sourceHtmlUrl":133,"categories":134,"keywords":138,"publishedAt":92},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[135],{"categoryNo":136,"categoryName":137,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000031","产品经理",[121,139,140,141,142,79,143,115,144,145,146,120,147,148,149,150,151,152,153,154],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":159,"sourceHtmlUrl":160,"categories":161,"keywords":165,"publishedAt":92},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[162],{"categoryNo":163,"categoryName":164,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000033","数据分析师",[81,121,166,167,168,169,79,153,115,170,171,172,173,146,174,175,176,177,178,179],"write query","postgres","for","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins","data",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":192,"publishedAt":92},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[186,189],{"categoryNo":187,"categoryName":188,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":190,"categoryName":191,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000023","Skill与智能体开发",[193,194,195,196,168,197,198,199,200,80,201,202,203,81,84,174,32,204,205,176],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","dependency","devops",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":213,"publishedAt":92},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[212],{"categoryNo":190,"categoryName":191,"taxonomyType":104,"taxonomyTypeDesc":105},[195,214,215,216,217,218,219,168,220,221,117,222,223,224,84,174,225,226,176,227],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]