[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MKSWGBTTHHZJB0FVB3GY1":3,"skill-same:01M71MKSWGBTTHHZJB0FVB3GY1":69},{"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":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":46,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M71MKSWGBTTHHZJB0FVB3GY1","consensus-coordinator",null,"Use when an org role acts as consensus coordinator and must pick the right agreement mechanism for a decision from its threat model. Chooses among threshold votes, Raft-style replication and Byzantine agreement; for running BFT itself see byzantine-coord.","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\u002Fconsensus-coordinator\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"consensus coordinator","consensus","coordinator","style","monomind","agreement","running","when","for","Raft","replication","github","as","use","operations","decision","pick","coordination","model","threat model","2026-11-10 10:56:23",false,"---\nname: consensus-coordinator\ndescription: \"Use when an org role acts as consensus coordinator and must pick the right agreement mechanism for a decision from its threat model. Chooses among threshold votes, Raft-style replication and Byzantine agreement; for running BFT itself see byzantine-coord.\"\ntags: [\"operations\",\"coordination\",\"agents\"]\ntools: []\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\n---\n# Consensus Coordinator — Best Practices\n\n## Focus\nPicks and runs the right agreement mechanism for a given decision — vote tally, crash-fault-tolerant replication, or Byzantine-tolerant agreement — rather than defaulting to one protocol for every situation.\n\n## Best practices\n- Match the mechanism to the actual threat model: simple threshold voting for trusted participants deciding a one-off question; Raft-style replication for maintaining one consistent log among honest-but-possibly-crashed nodes; BFT-style agreement only when participants might actively lie or act maliciously.\n- State the fault assumption explicitly before choosing a protocol — \"what can go wrong here: nothing, a crash, or an adversary\" determines everything downstream.\n- Don't pay for guarantees the situation doesn't need — BFT's O(n²) message cost and 3f+1 participant requirement are wasted overhead on a decision where every participant is already trusted.\n- Require the actual threshold to be met before treating a decision as final — a near-miss (\"almost majority\") is not a decision, it's an unresolved vote.\n- Make the decision auditable after the fact: record who voted what, under which threshold, at what time — not just the final yes\u002Fno outcome.\n- When mechanisms are layered (e.g. a quorum vote determining a Raft leader's authority to act), keep each layer's guarantee distinct — don't let a stronger claim from one layer bleed into what a weaker layer actually proved.\n\n## Common pitfalls\n- Using consensus-protocol vocabulary (leader election, fault tolerance, Byzantine tolerance) to describe what's actually a plain vote tally — this misstates what protection exists and misleads anyone relying on the report.\n- Assuming majority vote is \"good enough\" for adversarial settings — under Byzantine assumptions a bare majority can be manufactured by faulty participants; the mechanism has to match the threat.\n- Treating consensus, coordination, and replication as interchangeable — agreeing on one ordered outcome (consensus), synchronizing access to a shared resource (coordination), and copying data (replication) are different problems with different correct tools.\n- Skipping the \"what happens on incomplete participation\" case — a mechanism that silently proceeds on partial votes as though it had full participation produces a decision nobody actually agreed to.\n- Choosing a heavier protocol than necessary because it \"sounds more rigorous,\" adding message overhead and complexity the actual risk profile doesn't justify.\n\n## Tools & techniques\n- Classify the decision by threat model first (trusted\u002Fcrash-only\u002Fadversarial), then select threshold voting, Raft-style replication, or BFT-style agreement accordingly.\n- Use an explicit, named threshold (majority\u002Fsupermajority\u002Funanimous\u002Fcustom) for any vote-based decision and report the tally against it.\n- Keep a signed, independently verifiable audit trail for every consensus decision regardless of which mechanism produced it.\n- When in doubt about which mechanism actually applies, default to the weakest one that fits the stated threat model — it's cheaper to strengthen later than to have falsely claimed a guarantee that wasn't there.\n","# Consensus Coordinator — Best Practices\n\n## Focus\nPicks and runs the right agreement mechanism for a given decision — vote tally, crash-fault-tolerant replication, or Byzantine-tolerant agreement — rather than defaulting to one protocol for every situation.\n\n## Best practices\n- Match the mechanism to the actual threat model: simple threshold voting for trusted participants deciding a one-off question; Raft-style replication for maintaining one consistent log among honest-but-possibly-crashed nodes; BFT-style agreement only when participants might actively lie or act maliciously.\n- State the fault assumption explicitly before choosing a protocol — \"what can go wrong here: nothing, a crash, or an adversary\" determines everything downstream.\n- Don't pay for guarantees the situation doesn't need — BFT's O(n²) message cost and 3f+1 participant requirement are wasted overhead on a decision where every participant is already trusted.\n- Require the actual threshold to be met before treating a decision as final — a near-miss (\"almost majority\") is not a decision, it's an unresolved vote.\n- Make the decision auditable after the fact: record who voted what, under which threshold, at what time — not just the final yes\u002Fno outcome.\n- When mechanisms are layered (e.g. a quorum vote determining a Raft leader's authority to act), keep each layer's guarantee distinct — don't let a stronger claim from one layer bleed into what a weaker layer actually proved.\n\n## Common pitfalls\n- Using consensus-protocol vocabulary (leader election, fault tolerance, Byzantine tolerance) to describe what's actually a plain vote tally — this misstates what protection exists and misleads anyone relying on the report.\n- Assuming majority vote is \"good enough\" for adversarial settings — under Byzantine assumptions a bare majority can be manufactured by faulty participants; the mechanism has to match the threat.\n- Treating consensus, coordination, and replication as interchangeable — agreeing on one ordered outcome (consensus), synchronizing access to a shared resource (coordination), and copying data (replication) are different problems with different correct tools.\n- Skipping the \"what happens on incomplete participation\" case — a mechanism that silently proceeds on partial votes as though it had full participation produces a decision nobody actually agreed to.\n- Choosing a heavier protocol than necessary because it \"sounds more rigorous,\" adding message overhead and complexity the actual risk profile doesn't justify.\n\n## Tools & techniques\n- Classify the decision by threat model first (trusted\u002Fcrash-only\u002Fadversarial), then select threshold voting, Raft-style replication, or BFT-style agreement accordingly.\n- Use an explicit, named threshold (majority\u002Fsupermajority\u002Funanimous\u002Fcustom) for any vote-based decision and report the tally against it.\n- Keep a signed, independently verifiable audit trail for every consensus decision regardless of which mechanism produced it.\n- When in doubt about which mechanism actually applies, default to the weakest one that fits the stated threat model — it's cheaper to strengthen later than to have falsely claimed a guarantee that wasn't there.\n",{"name":5,"tags":43,"tools":45,"source":46,"license":14,"description":7},[32,35,44],"agents",[],"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fconsensus-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":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add monoes\u002Fmonomind --skill consensus-coordinator",{"tool":61,"command":62},"bunx","bunx skills add monoes\u002Fmonomind --skill consensus-coordinator",{"tool":64,"command":65},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill consensus-coordinator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fconsensus-coordinator\u002FSKILL.md",true,[],[70,97,133,159,182,209],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":96},"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",[],[77,78,79,80,81,82,83,84,85,86,87,88,22,89,90,91,92,93,94,95],"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":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":101,"licenseFileUrl":102,"sourceHtmlUrl":103,"categories":104,"keywords":115,"publishedAt":96},"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",[105,110],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[116,117,118,81,119,120,25,121,86,122,123,124,125,126,127,128,129,130,131,132],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":137,"sourceHtmlUrl":138,"categories":139,"keywords":143,"publishedAt":96},"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",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000031","产品经理",[126,144,145,146,147,84,148,25,149,150,151,125,152,153,154,155,156,157,31,158],"write spec","spec","user request","problem","acceptance","ask","vague","work","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":96},"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":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000033","数据分析师",[86,126,170,171,26,172,84,31,25,173,174,175,176,151,29,177,178,179,180,181],"write query","postgres","snowflake","best practices","natural-language","with","multi","sql","https","syntax","plugins","data",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":194,"publishedAt":96},"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",[188,191],{"categoryNo":189,"categoryName":190,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":192,"categoryName":193,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000023","Skill与智能体开发",[195,196,197,198,26,199,200,201,202,85,203,204,205,86,22,29,206,207,208,178],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":216,"publishedAt":96},"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",[215],{"categoryNo":192,"categoryName":193,"taxonomyType":108,"taxonomyTypeDesc":109},[197,217,218,219,220,221,222,26,223,224,122,225,226,227,22,29,228,32,178,229],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","systems"]