[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MGEEMC48ZQGG7P9X3JYYC":3,"skill-same:01M71MGEEMC48ZQGG7P9X3JYYC":93},{"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":15,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":72,"ownerDescription":6,"updatedAt":73,"install":74,"resources":87},"01M71MGEEMC48ZQGG7P9X3JYYC","click-path-audit",null,"Use when users report broken buttons that code review cannot explain: trace each UI handler's state writes and side effects to find calls that undo each other. Covers Zustand, Redux and React context stores and race conditions, also after refactors touching shared state.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fclick-path-audit\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fclick-path-audit\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"audit","click path audit","path","click","context","ui","handler","buttons","review","react","code","query","when","effects","frontend","testing","code review","zustand","broken","shared","2026-11-10 10:56:23",false,"---\nname: click-path-audit\ndescription: \"Use when users report broken buttons that code review cannot explain: trace each UI handler's state writes and side effects to find calls that undo each other. Covers Zustand, Redux and React context stores and race conditions, also after refactors touching shared state.\"\ntags: [\"frontend\",\"testing\",\"debug\",\"react\"]\ntools: [\"monograph_query\",\"monograph_context\"]\nlicense: MIT\nsource: https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC\nsource_path: \"skills\u002Fclick-path-audit\"\nsource_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735\n---\n# \u002Fclick-path-audit — Behavioural Flow Audit\n\nFind bugs that static code reading misses: state interaction side effects, race conditions between sequential calls, and handlers that silently undo each other.\n\n## The Problem This Solves\n\nTraditional debugging checks:\n- Does the function exist? (missing wiring)\n- Does it crash? (runtime errors)\n- Does it return the right type? (data flow)\n\nBut it does NOT check:\n- **Does the final UI state match what the button label promises?**\n- **Does function B silently undo what function A just did?**\n- **Does shared state (Zustand\u002FRedux\u002Fcontext) have side effects that cancel the intended action?**\n\nReal example: A \"New Email\" button called `setComposeMode(true)` then `selectThread(null)`. Both worked individually. But `selectThread` had a side effect resetting `composeMode: false`. The button did nothing. 54 bugs were found by systematic debugging — this one was missed.\n\n---\n\n## How It Works\n\nFor EVERY interactive touchpoint in the target area:\n\n```\n1. IDENTIFY the handler (onClick, onSubmit, onChange, etc.)\n2. TRACE every function call in the handler, IN ORDER\n3. For EACH function call:\n   a. What state does it READ?\n   b. What state does it WRITE?\n   c. Does it have SIDE EFFECTS on shared state?\n   d. Does it reset\u002Fclear any state as a side effect?\n4. CHECK: Does any later call UNDO a state change from an earlier call?\n5. CHECK: Is the FINAL state what the user expects from the button label?\n6. CHECK: Are there race conditions (async calls that resolve in wrong order)?\n```\n\n---\n\n## Execution Steps\n\n### Step 1: Map State Stores\n\nBefore auditing any touchpoint, build a side-effect map of every state store action:\n\n```\nFor each Zustand store \u002F React context in scope:\n  For each action\u002Fsetter:\n    - What fields does it set?\n    - Does it RESET other fields as a side effect?\n    - Document: actionName → {sets: [...], resets: [...]}\n```\n\nThis is the critical reference. The \"New Email\" bug was invisible without knowing that `selectThread` resets `composeMode`.\n\n**Output format:**\n```\nSTORE: emailStore\n  setComposeMode(bool) → sets: {composeMode}\n  selectThread(thread|null) → sets: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} RESETS: {composeMode: false, composeData: null, redraftOpen: false}\n  setDraftGenerating(bool) → sets: {draftGenerating}\n  ...\n\nDANGEROUS RESETS (actions that clear state they don't own):\n  selectThread → resets composeMode (owned by setComposeMode)\n  reset → resets everything\n```\n\n### Step 2: Audit Each Touchpoint\n\nFor each button\u002Ftoggle\u002Fform submit in the target area:\n\n```\nTOUCHPOINT: [Button label] in [Component:line]\n  HANDLER: onClick → {\n    call 1: functionA() → sets {X: true}\n    call 2: functionB() → sets {Y: null} RESETS {X: false}  ← CONFLICT\n  }\n  EXPECTED: User sees [description of what button label promises]\n  ACTUAL: X is false because functionB reset it\n  VERDICT: BUG — [description]\n```\n\n**Check each of these bug patterns:**\n\n#### Pattern 1: Sequential Undo\n```\nhandler() {\n  setState_A(true)     \u002F\u002F sets X = true\n  setState_B(null)     \u002F\u002F side effect: resets X = false\n}\n\u002F\u002F Result: X is false. First call was pointless.\n```\n\n#### Pattern 2: Async Race\n```\nhandler() {\n  fetchA().then(() => setState({ loading: false }))\n  fetchB().then(() => setState({ loading: true }))\n}\n\u002F\u002F Result: final loading state depends on which resolves first\n```\n\n#### Pattern 3: Stale Closure\n```\nconst [count, setCount] = useState(0)\nconst handler = useCallback(() => {\n  setCount(count + 1)  \u002F\u002F captures stale count\n  setCount(count + 1)  \u002F\u002F same stale count — increments by 1, not 2\n}, [count])\n```\n\n#### Pattern 4: Missing State Transition\n```\n\u002F\u002F Button says \"Save\" but handler only validates, never actually saves\n\u002F\u002F Button says \"Delete\" but handler sets a flag without calling the API\n\u002F\u002F Button says \"Send\" but the API endpoint is removed\u002Fbroken\n```\n\n#### Pattern 5: Conditional Dead Path\n```\nhandler() {\n  if (someState) {        \u002F\u002F someState is ALWAYS false at this point\n    doTheActualThing()    \u002F\u002F never reached\n  }\n}\n```\n\n#### Pattern 6: useEffect Interference\n```\n\u002F\u002F Button sets stateX = true\n\u002F\u002F A useEffect watches stateX and resets it to false\n\u002F\u002F User sees nothing happen\n```\n\n### Step 3: Report\n\nFor each bug found:\n\n```\nCLICK-PATH-NNN: [severity: CRITICAL\u002FHIGH\u002FMEDIUM\u002FLOW]\n  Touchpoint: [Button label] in [file:line]\n  Pattern: [Sequential Undo \u002F Async Race \u002F Stale Closure \u002F Missing Transition \u002F Dead Path \u002F useEffect Interference]\n  Handler: [function name or inline]\n  Trace:\n    1. [call] → sets {field: value}\n    2. [call] → RESETS {field: value}  ← CONFLICT\n  Expected: [what user expects]\n  Actual: [what actually happens]\n  Fix: [specific fix]\n```\n\n---\n\n## Scope Control\n\nThis audit is expensive. Scope it appropriately:\n\n- **Full app audit:** Use when launching or after major refactor. Launch parallel agents per page.\n- **Single page audit:** Use after building a new page or after a user reports a broken button.\n- **Store-focused audit:** Use after modifying a Zustand store — audit all consumers of the changed actions.\n\n### Recommended agent split for full app:\n\n```\nAgent 1: Map ALL state stores (Step 1) — this is shared context for all other agents\nAgent 2: Dashboard (Tasks, Notes, Journal, Ideas)\nAgent 3: Chat (DanteChatColumn, JustChatPage)\nAgent 4: Emails (ThreadList, DraftArea, EmailsPage)\nAgent 5: Projects (ProjectsPage, ProjectOverviewTab, NewProjectWizard)\nAgent 6: CRM (all sub-tabs)\nAgent 7: Profile, Settings, Vault, Notifications\nAgent 8: Management Suite (all pages)\n```\n\nAgent 1 MUST complete first. Its output is input for all other agents.\n\n---\n\n## When to Use\n\n- After systematic debugging finds \"no bugs\" but users report broken UI\n- After modifying any Zustand store action (check all callers)\n- After any refactor that touches shared state\n- Before release, on critical user flows\n- When a button \"does nothing\" — this is THE tool for that\n\n## When NOT to Use\n\n- For API-level bugs (wrong response shape, missing endpoint) — use systematic-debugging\n- For styling\u002Flayout issues — visual inspection\n- For performance issues — profiling tools\n\n---\n\n## Integration with Other Skills\n\n- Run AFTER `\u002Fsuperpowers:systematic-debugging` (which finds the other 54 bug types)\n- Run BEFORE `\u002Fsuperpowers:verification-before-completion` (which verifies fixes work)\n- Feeds into `\u002Fsuperpowers:test-driven-development` — every bug found here should get a test\n\n---\n\n## Example: The Bug That Inspired This Skill\n\n**ThreadList.tsx \"New Email\" button:**\n```\nonClick={() => {\n  useEmailStore.getState().setComposeMode(true)   \u002F\u002F ✓ sets composeMode = true\n  useEmailStore.getState().selectThread(null)      \u002F\u002F ✗ RESETS composeMode = false\n}}\n```\n\nStore definition:\n```\nselectThread: (thread) => set({\n  selectedThread: thread,\n  selectedThreadId: thread?.id ?? null,\n  messages: [],\n  drafts: [],\n  selectedDraft: null,\n  summary: null,\n  composeMode: false,     \u002F\u002F ← THIS silent reset killed the button\n  composeData: null,\n  redraftOpen: false,\n})\n```\n\n**Systematic debugging missed it** because:\n- The button has an onClick handler (not dead)\n- Both functions exist (no missing wiring)\n- Neither function crashes (no runtime error)\n- The data types are correct (no type mismatch)\n\n**Click-path audit catches it** because:\n- Step 1 maps `selectThread` resets `composeMode`\n- Step 2 traces the handler: call 1 sets true, call 2 resets false\n- Verdict: Sequential Undo — final state contradicts button intent\n","# \u002Fclick-path-audit — Behavioural Flow Audit\n\nFind bugs that static code reading misses: state interaction side effects, race conditions between sequential calls, and handlers that silently undo each other.\n\n## The Problem This Solves\n\nTraditional debugging checks:\n- Does the function exist? (missing wiring)\n- Does it crash? (runtime errors)\n- Does it return the right type? (data flow)\n\nBut it does NOT check:\n- **Does the final UI state match what the button label promises?**\n- **Does function B silently undo what function A just did?**\n- **Does shared state (Zustand\u002FRedux\u002Fcontext) have side effects that cancel the intended action?**\n\nReal example: A \"New Email\" button called `setComposeMode(true)` then `selectThread(null)`. Both worked individually. But `selectThread` had a side effect resetting `composeMode: false`. The button did nothing. 54 bugs were found by systematic debugging — this one was missed.\n\n---\n\n## How It Works\n\nFor EVERY interactive touchpoint in the target area:\n\n```\n1. IDENTIFY the handler (onClick, onSubmit, onChange, etc.)\n2. TRACE every function call in the handler, IN ORDER\n3. For EACH function call:\n   a. What state does it READ?\n   b. What state does it WRITE?\n   c. Does it have SIDE EFFECTS on shared state?\n   d. Does it reset\u002Fclear any state as a side effect?\n4. CHECK: Does any later call UNDO a state change from an earlier call?\n5. CHECK: Is the FINAL state what the user expects from the button label?\n6. CHECK: Are there race conditions (async calls that resolve in wrong order)?\n```\n\n---\n\n## Execution Steps\n\n### Step 1: Map State Stores\n\nBefore auditing any touchpoint, build a side-effect map of every state store action:\n\n```\nFor each Zustand store \u002F React context in scope:\n  For each action\u002Fsetter:\n    - What fields does it set?\n    - Does it RESET other fields as a side effect?\n    - Document: actionName → {sets: [...], resets: [...]}\n```\n\nThis is the critical reference. The \"New Email\" bug was invisible without knowing that `selectThread` resets `composeMode`.\n\n**Output format:**\n```\nSTORE: emailStore\n  setComposeMode(bool) → sets: {composeMode}\n  selectThread(thread|null) → sets: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} RESETS: {composeMode: false, composeData: null, redraftOpen: false}\n  setDraftGenerating(bool) → sets: {draftGenerating}\n  ...\n\nDANGEROUS RESETS (actions that clear state they don't own):\n  selectThread → resets composeMode (owned by setComposeMode)\n  reset → resets everything\n```\n\n### Step 2: Audit Each Touchpoint\n\nFor each button\u002Ftoggle\u002Fform submit in the target area:\n\n```\nTOUCHPOINT: [Button label] in [Component:line]\n  HANDLER: onClick → {\n    call 1: functionA() → sets {X: true}\n    call 2: functionB() → sets {Y: null} RESETS {X: false}  ← CONFLICT\n  }\n  EXPECTED: User sees [description of what button label promises]\n  ACTUAL: X is false because functionB reset it\n  VERDICT: BUG — [description]\n```\n\n**Check each of these bug patterns:**\n\n#### Pattern 1: Sequential Undo\n```\nhandler() {\n  setState_A(true)     \u002F\u002F sets X = true\n  setState_B(null)     \u002F\u002F side effect: resets X = false\n}\n\u002F\u002F Result: X is false. First call was pointless.\n```\n\n#### Pattern 2: Async Race\n```\nhandler() {\n  fetchA().then(() => setState({ loading: false }))\n  fetchB().then(() => setState({ loading: true }))\n}\n\u002F\u002F Result: final loading state depends on which resolves first\n```\n\n#### Pattern 3: Stale Closure\n```\nconst [count, setCount] = useState(0)\nconst handler = useCallback(() => {\n  setCount(count + 1)  \u002F\u002F captures stale count\n  setCount(count + 1)  \u002F\u002F same stale count — increments by 1, not 2\n}, [count])\n```\n\n#### Pattern 4: Missing State Transition\n```\n\u002F\u002F Button says \"Save\" but handler only validates, never actually saves\n\u002F\u002F Button says \"Delete\" but handler sets a flag without calling the API\n\u002F\u002F Button says \"Send\" but the API endpoint is removed\u002Fbroken\n```\n\n#### Pattern 5: Conditional Dead Path\n```\nhandler() {\n  if (someState) {        \u002F\u002F someState is ALWAYS false at this point\n    doTheActualThing()    \u002F\u002F never reached\n  }\n}\n```\n\n#### Pattern 6: useEffect Interference\n```\n\u002F\u002F Button sets stateX = true\n\u002F\u002F A useEffect watches stateX and resets it to false\n\u002F\u002F User sees nothing happen\n```\n\n### Step 3: Report\n\nFor each bug found:\n\n```\nCLICK-PATH-NNN: [severity: CRITICAL\u002FHIGH\u002FMEDIUM\u002FLOW]\n  Touchpoint: [Button label] in [file:line]\n  Pattern: [Sequential Undo \u002F Async Race \u002F Stale Closure \u002F Missing Transition \u002F Dead Path \u002F useEffect Interference]\n  Handler: [function name or inline]\n  Trace:\n    1. [call] → sets {field: value}\n    2. [call] → RESETS {field: value}  ← CONFLICT\n  Expected: [what user expects]\n  Actual: [what actually happens]\n  Fix: [specific fix]\n```\n\n---\n\n## Scope Control\n\nThis audit is expensive. Scope it appropriately:\n\n- **Full app audit:** Use when launching or after major refactor. Launch parallel agents per page.\n- **Single page audit:** Use after building a new page or after a user reports a broken button.\n- **Store-focused audit:** Use after modifying a Zustand store — audit all consumers of the changed actions.\n\n### Recommended agent split for full app:\n\n```\nAgent 1: Map ALL state stores (Step 1) — this is shared context for all other agents\nAgent 2: Dashboard (Tasks, Notes, Journal, Ideas)\nAgent 3: Chat (DanteChatColumn, JustChatPage)\nAgent 4: Emails (ThreadList, DraftArea, EmailsPage)\nAgent 5: Projects (ProjectsPage, ProjectOverviewTab, NewProjectWizard)\nAgent 6: CRM (all sub-tabs)\nAgent 7: Profile, Settings, Vault, Notifications\nAgent 8: Management Suite (all pages)\n```\n\nAgent 1 MUST complete first. Its output is input for all other agents.\n\n---\n\n## When to Use\n\n- After systematic debugging finds \"no bugs\" but users report broken UI\n- After modifying any Zustand store action (check all callers)\n- After any refactor that touches shared state\n- Before release, on critical user flows\n- When a button \"does nothing\" — this is THE tool for that\n\n## When NOT to Use\n\n- For API-level bugs (wrong response shape, missing endpoint) — use systematic-debugging\n- For styling\u002Flayout issues — visual inspection\n- For performance issues — profiling tools\n\n---\n\n## Integration with Other Skills\n\n- Run AFTER `\u002Fsuperpowers:systematic-debugging` (which finds the other 54 bug types)\n- Run BEFORE `\u002Fsuperpowers:verification-before-completion` (which verifies fixes work)\n- Feeds into `\u002Fsuperpowers:test-driven-development` — every bug found here should get a test\n\n---\n\n## Example: The Bug That Inspired This Skill\n\n**ThreadList.tsx \"New Email\" button:**\n```\nonClick={() => {\n  useEmailStore.getState().setComposeMode(true)   \u002F\u002F ✓ sets composeMode = true\n  useEmailStore.getState().selectThread(null)      \u002F\u002F ✗ RESETS composeMode = false\n}}\n```\n\nStore definition:\n```\nselectThread: (thread) => set({\n  selectedThread: thread,\n  selectedThreadId: thread?.id ?? null,\n  messages: [],\n  drafts: [],\n  selectedDraft: null,\n  summary: null,\n  composeMode: false,     \u002F\u002F ← THIS silent reset killed the button\n  composeData: null,\n  redraftOpen: false,\n})\n```\n\n**Systematic debugging missed it** because:\n- The button has an onClick handler (not dead)\n- Both functions exist (no missing wiring)\n- Neither function crashes (no runtime error)\n- The data types are correct (no type mismatch)\n\n**Click-path audit catches it** because:\n- Step 1 maps `selectThread` resets `composeMode`\n- Step 2 traces the handler: call 1 sets true, call 2 resets false\n- Verdict: Sequential Undo — final state contradicts button intent\n",{"name":5,"tags":57,"tools":59,"source":62,"license":14,"description":7,"source_path":63,"source_commit":64},[46,47,58,41],"debug",[60,61],"monograph_query","monograph_context","https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC","skills\u002Fclick-path-audit","bf70150eb2df8070024e5bdf08e4aa08959e2735","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fclick-path-audit",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-10 01:53:48",{"source":8,"skillName":5,"commands":75,"prompt":85,"zipAvailable":86},[76,79,82],{"tool":77,"command":78},"npx","npx skills add monoes\u002Fmonomind --skill click-path-audit",{"tool":80,"command":81},"bunx","bunx skills add monoes\u002Fmonomind --skill click-path-audit",{"tool":83,"command":84},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill click-path-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fclick-path-audit\u002FSKILL.md",true,[88],{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",1071,[94,121,150,177,202,229],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":120},"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.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[102,103,104,105,106,107,108,109,110,43,111,40,112,113,114,115,116,117,118,119],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","impact","snark","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain","2026-11-10 13:02:02",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":125,"sourceHtmlUrl":126,"categories":127,"keywords":134,"publishedAt":120},"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.","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",[128,131],{"categoryNo":129,"categoryName":130,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":132,"categoryName":133,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[135,136,137,106,138,139,44,140,43,42,141,142,143,144,145,146,147,148,36,149],"writing","writing plans","plans","superpowers","implementation plan","you","tasks","plan","product","write","commands","paths","suggest","coding","ZeRO",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":154,"sourceHtmlUrl":155,"categories":156,"keywords":160,"publishedAt":120},"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",[157],{"categoryNo":158,"categoryName":159,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[144,161,162,163,164,109,165,44,166,167,168,143,169,170,171,172,173,174,175,176],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":181,"sourceHtmlUrl":182,"categories":183,"keywords":187,"publishedAt":120},"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",[184],{"categoryNo":185,"categoryName":186,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000033","数据分析师",[43,144,188,189,190,191,109,175,44,192,193,194,195,168,196,197,198,199,200,201],"write query","postgres","for","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins","data",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":214,"publishedAt":120},"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",[208,211],{"categoryNo":209,"categoryName":210,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":212,"categoryName":213,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[215,216,217,218,190,219,220,221,222,110,223,224,225,43,112,196,226,227,228,198],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":6,"sourceHtmlUrl":233,"categories":234,"keywords":236,"publishedAt":120},"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",[235],{"categoryNo":212,"categoryName":213,"taxonomyType":21,"taxonomyTypeDesc":22},[217,237,238,239,240,241,242,190,243,244,42,245,246,247,112,196,248,249,198,250],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]