[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MFNQF01RXMX3YSFEXJTBR":3,"skill-same:01M71MFNQF01RXMX3YSFEXJTBR":83},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71MFNQF01RXMX3YSFEXJTBR","change-management",null,"Use when rolling out an org change (reorg, process or tool migration, strategy pivot, culture change) using ADKAR adapted for startups. Covers communication templates, resistance patterns and change fatigue.","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\u002Fchange-management\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fchange-management\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"change","management","change management","operations","github","use","strategy","fatigue","tool","for","startups","patterns","org","advisor","communication","leadership","when","people","culture","claude-skills","2026-11-10 10:56:23",false,"---\nname: change-management\ndescription: \"Use when rolling out an org change (reorg, process or tool migration, strategy pivot, culture change) using ADKAR adapted for startups. Covers communication templates, resistance patterns and change fatigue.\"\ntags: [\"leadership\",\"operations\",\"people\",\"communication\"]\ntools: []\nlicense: MIT\nsource: https:\u002F\u002Fgithub.com\u002Falirezarezvani\u002Fclaude-skills\nsource_path: \"c-level-advisor\u002Fskills\u002Fchange-management\"\nsource_commit: 19392f7a08264ed00486a251f5b2098321771f94\n---\n# Change Management Playbook\n\nMost changes fail at implementation, not design. The ADKAR model tells you why and how to fix it.\n\n## Keywords\nchange management, ADKAR, organizational change, reorg, process change, tool migration, strategy pivot, change resistance, change fatigue, change communication, stakeholder management, adoption, compliance, change rollout, transition\n\n## Core Model: ADKAR Adapted for Startups\n\nADKAR is a change management model by Prosci. Original version is for enterprises. This is the startup-speed adaptation.\n\n### A — Awareness\n\n**What it is:** People understand WHY the change is happening — the business reason, not just the announcement.\n\n**The mistake:** Communicating the WHAT before the WHY. \"We're moving to a new CRM\" before \"here's why our current process is killing us.\"\n\n**What people need to hear:**\n- What is the problem we're solving? (Be honest. If it's \"we need to cut costs,\" say that.)\n- Why now? What would happen if we didn't change?\n- Who made this decision and how?\n\n**Startup shortcut:** A 5-minute video from the CEO or decision-maker explaining the \"why\" in plain language beats a formal change announcement document every time.\n\n---\n\n### D — Desire\n\n**What it is:** People want to make the change happen — or at least don't actively resist it.\n\n**The mistake:** Assuming communication creates desire. Awareness ≠ desire. People can understand a change and still hate it.\n\n**What creates desire:**\n- \"What's in it for me?\" — answer this for each stakeholder group, honestly\n- Involving people in the \"how\" even if the \"what\" is decided\n- Addressing fears directly: \"Some people are worried this means their role is changing. Here's the truth: [honest answer]\"\n\n**What destroys desire:**\n- Pretending the change is better for everyone than it is\n- Ignoring the legitimate losses people will experience\n- Making announcements without any consultation\n\n**Startup shortcut:** Run a short \"concerns and questions\" session within 48 hours of announcement. Not to reverse the decision — to address the fears and show you're listening.\n\n---\n\n### K — Knowledge\n\n**What it is:** People know HOW to operate in the new world — the specific skills, behaviors, and processes.\n\n**The mistake:** Announcing the change and assuming people will figure it out.\n\n**What people need:**\n- Step-by-step documentation of new processes\n- Training or practice sessions before go-live\n- Clear answers to \"what do I do when [common scenario]?\"\n- Who to ask when they're stuck\n\n**Types of knowledge transfer:**\n| Method | Best for | When |\n|--------|---------|------|\n| Live training | Skill-based changes, complex tools | Before go-live |\n| Documentation | Process changes, reference material | Always |\n| Video walkthroughs | Tool migrations | Available 24\u002F7, self-paced |\n| Shadowing \u002F peer learning | Behavior changes | Weeks 2–4 after launch |\n| Office hours | Any change with many edge cases | First 4–6 weeks |\n\n---\n\n### A — Ability\n\n**What it is:** People have the time, tools, and support to actually do things differently.\n\n**The mistake:** \"We've trained everyone\" ≠ \"everyone can now do it.\" Training is knowledge. Ability is practice.\n\n**What creates ability:**\n- Time to practice before being evaluated\n- A safe environment to make mistakes (no public shaming for early struggles)\n- Reduced load during transition (if you're asking people to learn new skills, don't simultaneously pile on new work)\n- Access to help (a Slack channel, a point person, documentation)\n\n**Signs of ability gap:**\n- People revert to old behavior under pressure\n- Workarounds emerge (people invent their own way around the new system)\n- Training scores are high but actual behavior hasn't changed\n\n---\n\n### R — Reinforcement\n\n**What it is:** The change sticks. The new behavior becomes the default.\n\n**The mistake:** Declaring victory at go-live. Changes fail because they're never reinforced.\n\n**What creates reinforcement:**\n- Visible measurement (are we tracking adoption?)\n- Recognition of early adopters (\"Sarah fully migrated to the new workflow in week 2 — ask her how\")\n- Leader modeling (if the CEO uses the old way, everyone will)\n- Removing the old option (when possible — eliminate the path of least resistance)\n- Consequences for non-adoption (stated clearly, applied consistently)\n\n**Adoption vs. compliance:**\n- **Compliance:** People do it when watched, revert when not\n- **Adoption:** People do it because they believe it's better\n\nOnly reinforcement creates adoption. Compliance is the result of enforcement. Aim for adoption.\n\n---\n\n## Change Types and ADKAR Application\n\n### Process Change (new tools, new workflows)\n\n**Timeline:** 4–8 weeks for full adoption\n**Hardest phase:** Ability (people know what to do but haven't built the habit)\n**Critical reinforcement:** Remove or deprecate the old tool\u002Fprocess\n\n**Communication sequence:**\n1. Week -2: Announce the why + go-live date\n2. Week -1: Training sessions available\n3. Week 0 (go-live): Launch + point person available\n4. Week 2: Adoption check-in (who's using it? Who isn't?)\n5. Week 4: Feedback collection + public wins\n6. Week 8: Old system deprecated\n\n---\n\n### Org Change (reorg, new leader, team splits\u002Fmerges)\n\n**Timeline:** 3–6 months for full stabilization\n**Hardest phase:** Desire (people fear for their roles and relationships)\n**Critical reinforcement:** Consistent behavior from new leadership\n\n**Communication sequence:**\n1. Day 0: Announce the change with the \"why\" — in person or synchronous video\n2. Day 1: 1:1s with most affected team members by their manager\n3. Week 1: FAQ published with honest answers to the 10 most common concerns\n4. Week 2–4: New structure is operating (don't delay implementation)\n5. Month 2: First retrospective — what's working, what needs adjustment\n6. Month 3–6: Regular check-ins on team health and morale\n\n**What to say when a leader is leaving or being replaced:**\nBe honest about what you can share. Never: \"We can't share the reasons.\" Always: either a truthful explanation or \"we're not able to share the specifics, but I can tell you [what this means for you].\"\n\n---\n\n### Strategy Pivot (new direction, killed products)\n\n**Timeline:** 3–12 months for full alignment\n**Hardest phase:** Awareness (people don't believe the pivot is real)\n**Critical reinforcement:** Resource reallocation that visibly proves the pivot is happening\n\n**Communication sequence:**\n1. Internal first, always. Employees should never hear about a pivot from a press release.\n2. All-hands with full context: what changed in the market, what you're doing, what it means for teams\n3. Each team leader runs a \"what does this mean for us?\" conversation with their team\n4. Resource reallocation announced within 2 weeks (if the money doesn't move, people won't believe the pivot)\n5. First milestone of the new direction celebrated publicly\n\n**What kills pivots:** Announcing a new direction while still funding the old one at the same level.\n\n---\n\n### Culture Change (values refresh, behavior expectations)\n\n**Timeline:** 12–24 months for genuine behavior change\n**Hardest phase:** Reinforcement (behavior doesn't change just because values were announced)\n**Critical reinforcement:** Visible decisions that reflect the new values\n\n**Communication sequence:**\n1. Build with input: involve a representative sample of the company in defining the change\n2. Announce with story: \"Here's what we observed, here's what we're changing and why\"\n3. Behavior anchors: for each culture change, state the specific behavior in observable terms\n4. Leader behavior: leadership team must visibly model the new behavior first\n5. Performance integration: new expected behaviors appear in reviews within one cycle\n6. Celebrate the right behaviors: when someone exemplifies the new culture, name it publicly\n\n---\n\n## Resistance Patterns\n\nResistance is information, not defiance. Diagnose before responding.\n\n| Resistance pattern | What it signals | Response |\n|-------------------|-----------------|---------|\n| \"This won't work\" | Awareness gap or credibility gap | Explain the evidence base for the change |\n| \"Why now?\" | Awareness gap | Explain urgency — what happens if we don't change |\n| \"I wasn't consulted\" | Desire gap | Acknowledge the gap; involve them in the \"how\" now |\n| \"I don't have time for this\" | Ability gap | Reduce their load or push the timeline |\n| \"We tried this before\" | Trust gap | Acknowledge what's different this time. Be specific. |\n| Silent non-compliance | Could be any gap | 1:1 conversation to diagnose |\n\n**The worst response to resistance:** Dismissing it. \"Some people are resistant to change\" as if resistance is a personality flaw rather than a signal.\n\n---\n\n## Change Fatigue\n\nWhen organizations change too fast, people stop believing any change will stick.\n\n### Signals\n- Eye-rolls during change announcements (\"here we go again\")\n- Low attendance at change-related sessions\n- Fast compliance on paper, slow adoption in practice\n- \"Last month we were doing X, now we're doing Y\" comments\n\n### Prevention\n- **Finish what you start.** Don't announce a new change while the last one is still being absorbed.\n- **Space changes.** One significant change at a time. Give 2–3 months of stability between major changes.\n- **Announce what's NOT changing.** People in change-fatigue need to know what's stable.\n- **Show results.** Publish what the previous change achieved before launching the next.\n\n### When you're already in change fatigue\n- Pause non-critical changes\n- Run a \"change inventory\": how many changes are in progress simultaneously?\n- Prioritize ruthlessly: which changes are essential now? Which can wait?\n- Communicate stability: \"Here's what is NOT changing this quarter\"\n\n---\n\n## Key Questions for Change Management\n\n- \"Who are the most skeptical people about this change? Have we talked to them directly?\"\n- \"Do people understand why we're doing this, or just what we're doing?\"\n- \"Have we given people time to practice before we measure performance on the new way?\"\n- \"Is the old way still available? If so, people will use it.\"\n- \"Are leaders modeling the new behavior themselves?\"\n- \"How many changes are we running simultaneously right now?\"\n\n## Red Flags\n\n- Change announced on Friday afternoon (people stew over the weekend)\n- \"This is final, questions are not welcome\" framing\n- No published FAQ or way to ask questions safely\n- Old system\u002Fprocess still running 6 weeks after \"go-live\"\n- Leaders exempted from the change they're asking everyone else to make\n- No measurement of adoption — assuming go-live = success\n\n## Detailed References\n- `references\u002Fchange-playbook.md` — ADKAR deep dive, resistance counter-strategies, communication templates, change fatigue management\n","# Change Management Playbook\n\nMost changes fail at implementation, not design. The ADKAR model tells you why and how to fix it.\n\n## Keywords\nchange management, ADKAR, organizational change, reorg, process change, tool migration, strategy pivot, change resistance, change fatigue, change communication, stakeholder management, adoption, compliance, change rollout, transition\n\n## Core Model: ADKAR Adapted for Startups\n\nADKAR is a change management model by Prosci. Original version is for enterprises. This is the startup-speed adaptation.\n\n### A — Awareness\n\n**What it is:** People understand WHY the change is happening — the business reason, not just the announcement.\n\n**The mistake:** Communicating the WHAT before the WHY. \"We're moving to a new CRM\" before \"here's why our current process is killing us.\"\n\n**What people need to hear:**\n- What is the problem we're solving? (Be honest. If it's \"we need to cut costs,\" say that.)\n- Why now? What would happen if we didn't change?\n- Who made this decision and how?\n\n**Startup shortcut:** A 5-minute video from the CEO or decision-maker explaining the \"why\" in plain language beats a formal change announcement document every time.\n\n---\n\n### D — Desire\n\n**What it is:** People want to make the change happen — or at least don't actively resist it.\n\n**The mistake:** Assuming communication creates desire. Awareness ≠ desire. People can understand a change and still hate it.\n\n**What creates desire:**\n- \"What's in it for me?\" — answer this for each stakeholder group, honestly\n- Involving people in the \"how\" even if the \"what\" is decided\n- Addressing fears directly: \"Some people are worried this means their role is changing. Here's the truth: [honest answer]\"\n\n**What destroys desire:**\n- Pretending the change is better for everyone than it is\n- Ignoring the legitimate losses people will experience\n- Making announcements without any consultation\n\n**Startup shortcut:** Run a short \"concerns and questions\" session within 48 hours of announcement. Not to reverse the decision — to address the fears and show you're listening.\n\n---\n\n### K — Knowledge\n\n**What it is:** People know HOW to operate in the new world — the specific skills, behaviors, and processes.\n\n**The mistake:** Announcing the change and assuming people will figure it out.\n\n**What people need:**\n- Step-by-step documentation of new processes\n- Training or practice sessions before go-live\n- Clear answers to \"what do I do when [common scenario]?\"\n- Who to ask when they're stuck\n\n**Types of knowledge transfer:**\n| Method | Best for | When |\n|--------|---------|------|\n| Live training | Skill-based changes, complex tools | Before go-live |\n| Documentation | Process changes, reference material | Always |\n| Video walkthroughs | Tool migrations | Available 24\u002F7, self-paced |\n| Shadowing \u002F peer learning | Behavior changes | Weeks 2–4 after launch |\n| Office hours | Any change with many edge cases | First 4–6 weeks |\n\n---\n\n### A — Ability\n\n**What it is:** People have the time, tools, and support to actually do things differently.\n\n**The mistake:** \"We've trained everyone\" ≠ \"everyone can now do it.\" Training is knowledge. Ability is practice.\n\n**What creates ability:**\n- Time to practice before being evaluated\n- A safe environment to make mistakes (no public shaming for early struggles)\n- Reduced load during transition (if you're asking people to learn new skills, don't simultaneously pile on new work)\n- Access to help (a Slack channel, a point person, documentation)\n\n**Signs of ability gap:**\n- People revert to old behavior under pressure\n- Workarounds emerge (people invent their own way around the new system)\n- Training scores are high but actual behavior hasn't changed\n\n---\n\n### R — Reinforcement\n\n**What it is:** The change sticks. The new behavior becomes the default.\n\n**The mistake:** Declaring victory at go-live. Changes fail because they're never reinforced.\n\n**What creates reinforcement:**\n- Visible measurement (are we tracking adoption?)\n- Recognition of early adopters (\"Sarah fully migrated to the new workflow in week 2 — ask her how\")\n- Leader modeling (if the CEO uses the old way, everyone will)\n- Removing the old option (when possible — eliminate the path of least resistance)\n- Consequences for non-adoption (stated clearly, applied consistently)\n\n**Adoption vs. compliance:**\n- **Compliance:** People do it when watched, revert when not\n- **Adoption:** People do it because they believe it's better\n\nOnly reinforcement creates adoption. Compliance is the result of enforcement. Aim for adoption.\n\n---\n\n## Change Types and ADKAR Application\n\n### Process Change (new tools, new workflows)\n\n**Timeline:** 4–8 weeks for full adoption\n**Hardest phase:** Ability (people know what to do but haven't built the habit)\n**Critical reinforcement:** Remove or deprecate the old tool\u002Fprocess\n\n**Communication sequence:**\n1. Week -2: Announce the why + go-live date\n2. Week -1: Training sessions available\n3. Week 0 (go-live): Launch + point person available\n4. Week 2: Adoption check-in (who's using it? Who isn't?)\n5. Week 4: Feedback collection + public wins\n6. Week 8: Old system deprecated\n\n---\n\n### Org Change (reorg, new leader, team splits\u002Fmerges)\n\n**Timeline:** 3–6 months for full stabilization\n**Hardest phase:** Desire (people fear for their roles and relationships)\n**Critical reinforcement:** Consistent behavior from new leadership\n\n**Communication sequence:**\n1. Day 0: Announce the change with the \"why\" — in person or synchronous video\n2. Day 1: 1:1s with most affected team members by their manager\n3. Week 1: FAQ published with honest answers to the 10 most common concerns\n4. Week 2–4: New structure is operating (don't delay implementation)\n5. Month 2: First retrospective — what's working, what needs adjustment\n6. Month 3–6: Regular check-ins on team health and morale\n\n**What to say when a leader is leaving or being replaced:**\nBe honest about what you can share. Never: \"We can't share the reasons.\" Always: either a truthful explanation or \"we're not able to share the specifics, but I can tell you [what this means for you].\"\n\n---\n\n### Strategy Pivot (new direction, killed products)\n\n**Timeline:** 3–12 months for full alignment\n**Hardest phase:** Awareness (people don't believe the pivot is real)\n**Critical reinforcement:** Resource reallocation that visibly proves the pivot is happening\n\n**Communication sequence:**\n1. Internal first, always. Employees should never hear about a pivot from a press release.\n2. All-hands with full context: what changed in the market, what you're doing, what it means for teams\n3. Each team leader runs a \"what does this mean for us?\" conversation with their team\n4. Resource reallocation announced within 2 weeks (if the money doesn't move, people won't believe the pivot)\n5. First milestone of the new direction celebrated publicly\n\n**What kills pivots:** Announcing a new direction while still funding the old one at the same level.\n\n---\n\n### Culture Change (values refresh, behavior expectations)\n\n**Timeline:** 12–24 months for genuine behavior change\n**Hardest phase:** Reinforcement (behavior doesn't change just because values were announced)\n**Critical reinforcement:** Visible decisions that reflect the new values\n\n**Communication sequence:**\n1. Build with input: involve a representative sample of the company in defining the change\n2. Announce with story: \"Here's what we observed, here's what we're changing and why\"\n3. Behavior anchors: for each culture change, state the specific behavior in observable terms\n4. Leader behavior: leadership team must visibly model the new behavior first\n5. Performance integration: new expected behaviors appear in reviews within one cycle\n6. Celebrate the right behaviors: when someone exemplifies the new culture, name it publicly\n\n---\n\n## Resistance Patterns\n\nResistance is information, not defiance. Diagnose before responding.\n\n| Resistance pattern | What it signals | Response |\n|-------------------|-----------------|---------|\n| \"This won't work\" | Awareness gap or credibility gap | Explain the evidence base for the change |\n| \"Why now?\" | Awareness gap | Explain urgency — what happens if we don't change |\n| \"I wasn't consulted\" | Desire gap | Acknowledge the gap; involve them in the \"how\" now |\n| \"I don't have time for this\" | Ability gap | Reduce their load or push the timeline |\n| \"We tried this before\" | Trust gap | Acknowledge what's different this time. Be specific. |\n| Silent non-compliance | Could be any gap | 1:1 conversation to diagnose |\n\n**The worst response to resistance:** Dismissing it. \"Some people are resistant to change\" as if resistance is a personality flaw rather than a signal.\n\n---\n\n## Change Fatigue\n\nWhen organizations change too fast, people stop believing any change will stick.\n\n### Signals\n- Eye-rolls during change announcements (\"here we go again\")\n- Low attendance at change-related sessions\n- Fast compliance on paper, slow adoption in practice\n- \"Last month we were doing X, now we're doing Y\" comments\n\n### Prevention\n- **Finish what you start.** Don't announce a new change while the last one is still being absorbed.\n- **Space changes.** One significant change at a time. Give 2–3 months of stability between major changes.\n- **Announce what's NOT changing.** People in change-fatigue need to know what's stable.\n- **Show results.** Publish what the previous change achieved before launching the next.\n\n### When you're already in change fatigue\n- Pause non-critical changes\n- Run a \"change inventory\": how many changes are in progress simultaneously?\n- Prioritize ruthlessly: which changes are essential now? Which can wait?\n- Communicate stability: \"Here's what is NOT changing this quarter\"\n\n---\n\n## Key Questions for Change Management\n\n- \"Who are the most skeptical people about this change? Have we talked to them directly?\"\n- \"Do people understand why we're doing this, or just what we're doing?\"\n- \"Have we given people time to practice before we measure performance on the new way?\"\n- \"Is the old way still available? If so, people will use it.\"\n- \"Are leaders modeling the new behavior themselves?\"\n- \"How many changes are we running simultaneously right now?\"\n\n## Red Flags\n\n- Change announced on Friday afternoon (people stew over the weekend)\n- \"This is final, questions are not welcome\" framing\n- No published FAQ or way to ask questions safely\n- Old system\u002Fprocess still running 6 weeks after \"go-live\"\n- Leaders exempted from the change they're asking everyone else to make\n- No measurement of adoption — assuming go-live = success\n\n## Detailed References\n- `references\u002Fchange-playbook.md` — ADKAR deep dive, resistance counter-strategies, communication templates, change fatigue management\n",{"name":5,"tags":44,"tools":45,"source":46,"license":14,"description":7,"source_path":47,"source_commit":48},[34,22,36,33],[],"https:\u002F\u002Fgithub.com\u002Falirezarezvani\u002Fclaude-skills","c-level-advisor\u002Fskills\u002Fchange-management","19392f7a08264ed00486a251f5b2098321771f94","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fchange-management",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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add monoes\u002Fmonomind --skill change-management",{"tool":64,"command":65},"bunx","bunx skills add monoes\u002Fmonomind --skill change-management",{"tool":67,"command":68},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill change-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fchange-management\u002FSKILL.md",true,[72,77],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",1072,{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fchange-playbook.md","REFERENCE","参考文档",12125,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fchange-management\u002Freferences\u002Fchange-playbook.md",[84,112,147,173,196,223],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":111},"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",[],[92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,31,110],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","blockchain","2026-11-10 13:02:02",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":116,"sourceHtmlUrl":117,"categories":118,"keywords":129,"publishedAt":111},"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",[119,124],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[130,131,132,96,133,134,35,135,101,136,137,138,139,140,141,142,143,144,145,146],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":151,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":111},"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",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000031","产品经理",[140,158,159,160,161,99,162,35,163,164,165,139,166,167,168,169,170,171,24,172],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","document",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":177,"sourceHtmlUrl":178,"categories":179,"keywords":183,"publishedAt":111},"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",[180],{"categoryNo":181,"categoryName":182,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000033","数据分析师",[101,140,184,185,28,186,99,24,35,187,188,189,190,165,23,191,192,193,194,195],"write query","postgres","snowflake","best practices","natural-language","with","multi","sql","https","syntax","plugins","data",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":208,"publishedAt":111},"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",[202,205],{"categoryNo":203,"categoryName":204,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":206,"categoryName":207,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000023","Skill与智能体开发",[209,210,211,212,28,213,214,215,216,100,217,218,219,101,104,23,220,221,222,192],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":230,"publishedAt":111},"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",[229],{"categoryNo":206,"categoryName":207,"taxonomyType":122,"taxonomyTypeDesc":123},[211,231,232,233,234,235,236,28,237,238,136,239,240,34,104,23,241,22,192,242],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","recovery","systems"]