[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MBDM88934TZDX905QJHSS":3,"skill-same:01M71MBDM88934TZDX905QJHSS":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":50,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M71MBDM88934TZDX905QJHSS","automation-governance",null,"Use when an org role acts as automation governor and must decide what gets automated and what stays human, scoring value, risk and maintainability first. Requires an owner, fallback, idempotency and an explicit verdict per request before anything ships.","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\u002Fautomation-governance\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"automation governance","governance","automation","https","request","devops","audit","human","github","monomind","first","verdict","scoring","when","use","decide","planning","value","risk","as","2026-11-10 10:56:23",false,"---\nname: automation-governance\ndescription: \"Use when an org role acts as automation governor and must decide what gets automated and what stays human, scoring value, risk and maintainability first. Requires an owner, fallback, idempotency and an explicit verdict per request before anything ships.\"\ntags: [\"devops\",\"audit\",\"planning\"]\ntools: []\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\n---\n# Automation Governance — Best Practices\n\n## Focus\nDecide what should be automated, how it should be built, and what must stay human-controlled — auditing value, risk, and maintainability before any automation ships, not after.\n\n## Best practices\n- Score every automation request on four dimensions before approving: recurring time savings, data criticality, external dependency risk, and scalability from 1x to 100x load.\n- Prefer simple and robust over clever and fragile — a slightly slower workflow that's easy to debug beats a fast one nobody can maintain.\n- Require an explicit verdict per request (approve \u002F pilot \u002F partial automation \u002F defer \u002F reject) rather than defaulting to \"yes\" because it's technically feasible.\n- Every approved automation needs an owner, a fallback path, and documentation before it's marked done — no exceptions for \"quick\" automations.\n- Standardize workflow structure (trigger → validation → normalization → logic → external action → result validation → logging → error branch → fallback → completion) so every workflow is auditable the same way.\n- Require idempotency\u002Fduplicate-protection and bounded retries for anything touching external systems — retries without stop conditions turn failures into incidents.\n- Re-audit automations when their upstream APIs\u002Fschemas change, error rates rise, or volume grows significantly — approval isn't permanent.\n\n## Common pitfalls\n- Approving automation because it's possible, without checking whether the process is mature or the value is real.\n- Automating a fragile process end-to-end instead of automating the safe segments and keeping a human checkpoint at the risky ones.\n- No fallback\u002Fmanual-recovery path, so a single automation failure becomes a full outage of the underlying process.\n- Vague naming\u002Fversioning (\"final\", \"new-test\", \"fix2\") that makes it impossible to know which workflow version is live.\n- Treating \"it works in testing\" as sufficient without a scale\u002Frepetition sanity check or a dependency-failure test.\n\n## Tools & techniques\n- A mandatory four-dimension scoring rubric (time savings, data criticality, dependency risk, scalability) applied consistently across requests.\n- Standardized workflow naming: `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`.\n- A fixed testing baseline before production sign-off: happy path, invalid input, dependency failure, duplicate event, fallback\u002Frecovery, scale sanity check.\n- Integration governance checklist per connected system: source-of-truth ownership, auth\u002Ftoken lifecycle, rate limits, and write-back permissions.\n","# Automation Governance — Best Practices\n\n## Focus\nDecide what should be automated, how it should be built, and what must stay human-controlled — auditing value, risk, and maintainability before any automation ships, not after.\n\n## Best practices\n- Score every automation request on four dimensions before approving: recurring time savings, data criticality, external dependency risk, and scalability from 1x to 100x load.\n- Prefer simple and robust over clever and fragile — a slightly slower workflow that's easy to debug beats a fast one nobody can maintain.\n- Require an explicit verdict per request (approve \u002F pilot \u002F partial automation \u002F defer \u002F reject) rather than defaulting to \"yes\" because it's technically feasible.\n- Every approved automation needs an owner, a fallback path, and documentation before it's marked done — no exceptions for \"quick\" automations.\n- Standardize workflow structure (trigger → validation → normalization → logic → external action → result validation → logging → error branch → fallback → completion) so every workflow is auditable the same way.\n- Require idempotency\u002Fduplicate-protection and bounded retries for anything touching external systems — retries without stop conditions turn failures into incidents.\n- Re-audit automations when their upstream APIs\u002Fschemas change, error rates rise, or volume grows significantly — approval isn't permanent.\n\n## Common pitfalls\n- Approving automation because it's possible, without checking whether the process is mature or the value is real.\n- Automating a fragile process end-to-end instead of automating the safe segments and keeping a human checkpoint at the risky ones.\n- No fallback\u002Fmanual-recovery path, so a single automation failure becomes a full outage of the underlying process.\n- Vague naming\u002Fversioning (\"final\", \"new-test\", \"fix2\") that makes it impossible to know which workflow version is live.\n- Treating \"it works in testing\" as sufficient without a scale\u002Frepetition sanity check or a dependency-failure test.\n\n## Tools & techniques\n- A mandatory four-dimension scoring rubric (time savings, data criticality, dependency risk, scalability) applied consistently across requests.\n- Standardized workflow naming: `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`.\n- A fixed testing baseline before production sign-off: happy path, invalid input, dependency failure, duplicate event, fallback\u002Frecovery, scale sanity check.\n- Integration governance checklist per connected system: source-of-truth ownership, auth\u002Ftoken lifecycle, rate limits, and write-back permissions.\n",{"name":5,"tags":48,"tools":49,"source":50,"license":14,"description":7},[28,29,39],[],"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fautomation-governance",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":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add monoes\u002Fmonomind --skill automation-governance",{"tool":65,"command":66},"bunx","bunx skills add monoes\u002Fmonomind --skill automation-governance",{"tool":68,"command":69},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill automation-governance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fautomation-governance\u002FSKILL.md",true,[],[74,101,135,160,183,206],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":100},"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",[],[81,82,83,84,85,86,87,88,89,90,91,92,32,93,94,95,96,97,98,99],"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":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":105,"licenseFileUrl":106,"sourceHtmlUrl":107,"categories":108,"keywords":117,"publishedAt":100},"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",[109,112],{"categoryNo":110,"categoryName":111,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[118,119,120,85,121,122,36,123,90,124,125,126,127,128,129,130,131,132,133,134],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":139,"sourceHtmlUrl":140,"categories":141,"keywords":145,"publishedAt":100},"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",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000031","产品经理",[128,146,147,148,149,88,150,36,151,152,153,127,27,154,155,156,157,158,37,159],"write spec","spec","user request","problem","acceptance","ask","vague","work","scoping","idea","metrics","feature","problem statement","document",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":164,"sourceHtmlUrl":165,"categories":166,"keywords":170,"publishedAt":100},"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",[167],{"categoryNo":168,"categoryName":169,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000033","数据分析师",[90,128,171,172,173,174,88,37,36,175,176,177,178,153,31,179,26,180,181,182],"write query","postgres","for","snowflake","best practices","natural-language","with","multi","sql","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":193,"publishedAt":100},"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":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[194,25,195,196,173,197,198,199,200,89,201,202,203,90,32,31,204,205,28,26],"Workflow Automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":213,"publishedAt":100},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[212],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[195,214,215,216,217,218,39,173,219,220,124,221,222,223,32,31,224,225,26,226],"workflow architect","architect","trees","user journeys","branch","map","workflows","architecture","state","leadership","recovery","operations","systems"]