[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71M89V2RWXM6AHZC99RYDH1":3,"skill-same:01M71M89V2RWXM6AHZC99RYDH1":70},{"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":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":47,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M71M89V2RWXM6AHZC99RYDH1","adaptive-coordinator",null,"Use when an org role acts as adaptive coordinator and must switch team topology (hierarchical, mesh, ring, star) at phase boundaries as load or failures change. Covers trigger signals and draining in-flight work before a switch; for peer-only coordination use mesh-coordinator.","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\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fadaptive-coordinator\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"coordinator","adaptive coordinator","adaptive","monomind","change","work","peer","phase","team","coordination","when","load","use","only","trigger","STAR","for","switch","as","mesh","2026-11-10 10:56:23",false,"---\nname: adaptive-coordinator\ndescription: \"Use when an org role acts as adaptive coordinator and must switch team topology (hierarchical, mesh, ring, star) at phase boundaries as load or failures change. Covers trigger signals and draining in-flight work before a switch; for peer-only coordination use mesh-coordinator.\"\ntags: [\"operations\",\"coordination\",\"agents\"]\ntools: []\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\n---\n# Adaptive Coordinator — Best Practices\n\n## Focus\nReconfigures the coordination topology itself (hierarchical, mesh, ring, star) as workload, failure conditions, or team size change, instead of running one fixed structure for the whole task.\n\n## Best practices\n- Pick the topology from the shape of the work, not habit: hierarchical\u002Fmanager-worker for tight control and small teams, mesh for maximal resilience and independent slices, star for a single aggregation point, ring only for strictly ordered handoffs.\n- Reassess the topology at phase boundaries, not mid-task — switching structure while agents are mid-flight is how state gets lost or duplicated.\n- Escalate from flat\u002Fparallel to hierarchical once worker count or coordination overhead crosses the point where a flat structure can no longer track ownership (roughly 5-8+ concurrent workers).\n- Under agent failure or churn, prefer the topology that degrades gracefully for the situation — hierarchical protects overall efficiency, decentralized\u002Fmesh protects continuity when any single node might drop out.\n- State the topology and the reason for choosing it explicitly before dispatching work — an unstated topology is one nobody can hold you to.\n- Treat \"hybrid\" or \"adaptive\" as a real decision to make, not a way to defer the decision — if the label doesn't correspond to an actual dispatch pattern, it's not doing anything.\n- Re-evaluate after each reconfiguration whether the new topology actually reduced coordination overhead — don't assume the switch helped without checking.\n\n## Common pitfalls\n- Reconfiguring topology reactively after something already broke, instead of recognizing the load\u002Ffailure signal early enough to switch proactively.\n- Adding topology-switching machinery that itself becomes the coordination overhead it was meant to reduce — every added mode needs its own conflict-resolution path.\n- Switching structure without migrating in-flight state, silently dropping progress or duplicating work across the old and new topology.\n- Assuming a topology label (e.g. \"adaptive\") implies automatic reconfiguration when nothing is actually monitoring load or triggering the switch — a static assignment described as adaptive is just static.\n- Optimizing purely for efficiency (hierarchical) or purely for resilience (mesh) without naming the tradeoff being made for the task at hand.\n\n## Tools & techniques\n- Track a small set of trigger signals for reconfiguration: worker count crossing a threshold, repeated task failures, or a shift from independent to interdependent subtasks.\n- Keep topology state (roster, current structure, reason for the current choice) in one place that's cheap to inspect before making a switch decision.\n- When switching, drain or checkpoint in-flight work first, then redispatch under the new structure — don't reconfigure underneath running agents.\n- Default to the simplest topology that fits the current phase; add structure only when the current one is visibly the bottleneck.\n","# Adaptive Coordinator — Best Practices\n\n## Focus\nReconfigures the coordination topology itself (hierarchical, mesh, ring, star) as workload, failure conditions, or team size change, instead of running one fixed structure for the whole task.\n\n## Best practices\n- Pick the topology from the shape of the work, not habit: hierarchical\u002Fmanager-worker for tight control and small teams, mesh for maximal resilience and independent slices, star for a single aggregation point, ring only for strictly ordered handoffs.\n- Reassess the topology at phase boundaries, not mid-task — switching structure while agents are mid-flight is how state gets lost or duplicated.\n- Escalate from flat\u002Fparallel to hierarchical once worker count or coordination overhead crosses the point where a flat structure can no longer track ownership (roughly 5-8+ concurrent workers).\n- Under agent failure or churn, prefer the topology that degrades gracefully for the situation — hierarchical protects overall efficiency, decentralized\u002Fmesh protects continuity when any single node might drop out.\n- State the topology and the reason for choosing it explicitly before dispatching work — an unstated topology is one nobody can hold you to.\n- Treat \"hybrid\" or \"adaptive\" as a real decision to make, not a way to defer the decision — if the label doesn't correspond to an actual dispatch pattern, it's not doing anything.\n- Re-evaluate after each reconfiguration whether the new topology actually reduced coordination overhead — don't assume the switch helped without checking.\n\n## Common pitfalls\n- Reconfiguring topology reactively after something already broke, instead of recognizing the load\u002Ffailure signal early enough to switch proactively.\n- Adding topology-switching machinery that itself becomes the coordination overhead it was meant to reduce — every added mode needs its own conflict-resolution path.\n- Switching structure without migrating in-flight state, silently dropping progress or duplicating work across the old and new topology.\n- Assuming a topology label (e.g. \"adaptive\") implies automatic reconfiguration when nothing is actually monitoring load or triggering the switch — a static assignment described as adaptive is just static.\n- Optimizing purely for efficiency (hierarchical) or purely for resilience (mesh) without naming the tradeoff being made for the task at hand.\n\n## Tools & techniques\n- Track a small set of trigger signals for reconfiguration: worker count crossing a threshold, repeated task failures, or a shift from independent to interdependent subtasks.\n- Keep topology state (roster, current structure, reason for the current choice) in one place that's cheap to inspect before making a switch decision.\n- When switching, drain or checkpoint in-flight work first, then redispatch under the new structure — don't reconfigure underneath running agents.\n- Default to the simplest topology that fits the current phase; add structure only when the current one is visibly the bottleneck.\n",{"name":5,"tags":43,"tools":46,"source":47,"license":14,"description":7},[44,27,45],"operations","agents",[],"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fadaptive-coordinator",2,"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":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add monoes\u002Fmonomind --skill adaptive-coordinator",{"tool":62,"command":63},"bunx","bunx skills add monoes\u002Fmonomind --skill adaptive-coordinator",{"tool":65,"command":66},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill adaptive-coordinator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fadaptive-coordinator\u002FSKILL.md",true,[],[71,98,134,159,183,210],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":97},"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",[],[78,79,80,81,82,83,84,85,86,87,88,89,21,90,91,92,93,94,95,96],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","impact","query","snark","review","security review","stark","zettelkasten","cryptography","security","org","blockchain","2026-11-10 13:02:02",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":102,"licenseFileUrl":103,"sourceHtmlUrl":104,"categories":105,"keywords":116,"publishedAt":97},"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",[106,111],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[117,118,119,82,120,121,28,122,87,123,124,125,126,127,128,129,130,131,132,133],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":138,"sourceHtmlUrl":139,"categories":140,"keywords":144,"publishedAt":97},"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",[141],{"categoryNo":142,"categoryName":143,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000031","产品经理",[127,145,146,147,148,85,149,28,150,151,23,126,152,153,154,155,156,157,30,158],"write spec","spec","user request","problem","acceptance","ask","vague","request","scoping","idea","metrics","feature","problem statement","document",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":163,"sourceHtmlUrl":164,"categories":165,"keywords":169,"publishedAt":97},"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",[166],{"categoryNo":167,"categoryName":168,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000033","数据分析师",[87,127,170,171,34,172,85,30,28,173,174,175,176,23,177,178,179,180,181,182],"write query","postgres","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins","data",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":195,"publishedAt":97},"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",[189,192],{"categoryNo":190,"categoryName":191,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":193,"categoryName":194,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发",[196,197,198,199,34,200,201,202,203,86,204,205,206,87,21,177,207,208,209,179],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":217,"publishedAt":97},"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",[216],{"categoryNo":193,"categoryName":194,"taxonomyType":109,"taxonomyTypeDesc":110},[198,218,219,220,221,222,223,34,224,225,123,226,227,228,21,177,229,44,179,230],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","systems"]