[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PB3SHWKMNJM6MD65VX8D6":3,"skill-same:01M71PB3SHWKMNJM6MD65VX8D6":72},{"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":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":49,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward",null,"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.","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\u002Fzk-steward\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"zk steward","zk","steward","query","monomind","stark","zettelkasten","snark","zero-knowledge","org","impact","design","engineer","choice","knowledge","cryptography","blockchain","security review","security","review","2026-11-10 13:02:02",false,"---\nname: zk-steward\ndescription: \"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.\"\ntags: [\"engineering\",\"security\",\"blockchain\"]\ntools: [\"monograph_query\",\"monograph_context\",\"monograph_impact\"]\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\n---\n# ZK Steward — Best Practices\n\n## Focus\nEngineers zero-knowledge proof systems — circuit design, protocol selection, and security review — for privacy-preserving and scalable smart-contract applications. (Note: despite the \"ZK\" name overlap with Zettelkasten note-taking tools, this role is zero-knowledge cryptography.)\n\n## Best practices\n- Choose the proving system by threat model, not popularity: zk-SNARKs (Groth16\u002FPLONK) need a trusted setup ceremony but give small proofs; zk-STARKs are transparent (no trusted setup) but produce larger proofs.\n- Specify and test circuits fully before building the smart-contract layer on top — circuit rework after the contract layer is expensive.\n- Get proving\u002Fverification UX (latency, proof size, gas cost of on-chain verification) right before shipping — adoption dies if proving is too slow or verification too expensive.\n- Treat every circuit constraint as a potential under-constraint bug: an attacker who can satisfy the constraints with an invalid witness breaks soundness.\n- Keep the witness generation and circuit logic in lockstep — a mismatch silently produces unprovable or incorrect proofs.\n- Document trust assumptions explicitly: what the trusted setup ceremony assumed, what the verifier trusts, what stays off-chain.\n- Match circuit language to target: Circom for Groth16\u002FPLONK pipelines, Noir (Rust-like, Aztec) for general-purpose privacy circuits, Cairo for StarkNet\u002FSTARK systems.\n\n## Common pitfalls\n- Under-constrained circuits — missing a constraint lets a malicious prover generate a valid proof for an invalid statement.\n- Reusing trusted-setup parameters across unrelated circuits, silently breaking the ceremony's security guarantees.\n- Treating \"audited circuit language\" as equivalent to \"audited circuit\" — the language's soundness doesn't cover application-level logic bugs.\n- Ignoring proof malleability or replay risk when proofs are used as authorization tokens on-chain.\n- Skipping formal specification of what the circuit is supposed to prove, making review essentially impossible.\n\n## Tools & techniques\n- Circuit fuzzing frameworks (e.g. zkFuzz-style approaches) to catch under-constrained signals before deployment.\n- Formal circuit specification and equivalence checking against a reference implementation.\n- Groth16\u002FPLONK for succinct on-chain verification cost; STARKs when transparency (no ceremony) matters more than proof size.\n- Property-based testing across the full witness space, not just happy-path inputs.\n- Independent security review of both circuit constraints and the surrounding smart-contract\u002Fverifier integration — these are separate attack surfaces.\n","# ZK Steward — Best Practices\n\n## Focus\nEngineers zero-knowledge proof systems — circuit design, protocol selection, and security review — for privacy-preserving and scalable smart-contract applications. (Note: despite the \"ZK\" name overlap with Zettelkasten note-taking tools, this role is zero-knowledge cryptography.)\n\n## Best practices\n- Choose the proving system by threat model, not popularity: zk-SNARKs (Groth16\u002FPLONK) need a trusted setup ceremony but give small proofs; zk-STARKs are transparent (no trusted setup) but produce larger proofs.\n- Specify and test circuits fully before building the smart-contract layer on top — circuit rework after the contract layer is expensive.\n- Get proving\u002Fverification UX (latency, proof size, gas cost of on-chain verification) right before shipping — adoption dies if proving is too slow or verification too expensive.\n- Treat every circuit constraint as a potential under-constraint bug: an attacker who can satisfy the constraints with an invalid witness breaks soundness.\n- Keep the witness generation and circuit logic in lockstep — a mismatch silently produces unprovable or incorrect proofs.\n- Document trust assumptions explicitly: what the trusted setup ceremony assumed, what the verifier trusts, what stays off-chain.\n- Match circuit language to target: Circom for Groth16\u002FPLONK pipelines, Noir (Rust-like, Aztec) for general-purpose privacy circuits, Cairo for StarkNet\u002FSTARK systems.\n\n## Common pitfalls\n- Under-constrained circuits — missing a constraint lets a malicious prover generate a valid proof for an invalid statement.\n- Reusing trusted-setup parameters across unrelated circuits, silently breaking the ceremony's security guarantees.\n- Treating \"audited circuit language\" as equivalent to \"audited circuit\" — the language's soundness doesn't cover application-level logic bugs.\n- Ignoring proof malleability or replay risk when proofs are used as authorization tokens on-chain.\n- Skipping formal specification of what the circuit is supposed to prove, making review essentially impossible.\n\n## Tools & techniques\n- Circuit fuzzing frameworks (e.g. zkFuzz-style approaches) to catch under-constrained signals before deployment.\n- Formal circuit specification and equivalence checking against a reference implementation.\n- Groth16\u002FPLONK for succinct on-chain verification cost; STARKs when transparency (no ceremony) matters more than proof size.\n- Property-based testing across the full witness space, not just happy-path inputs.\n- Independent security review of both circuit constraints and the surrounding smart-contract\u002Fverifier integration — these are separate attack surfaces.\n",{"name":5,"tags":43,"tools":45,"source":49,"license":14,"description":7},[44,36,34],"engineering",[46,47,48],"monograph_query","monograph_context","monograph_impact","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward",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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add monoes\u002Fmonomind --skill zk-steward",{"tool":64,"command":65},"bunx","bunx skills add monoes\u002Fmonomind --skill zk-steward",{"tool":67,"command":68},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill zk-steward","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",true,[],[73,110,137,162,189,211],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":77,"licenseFileUrl":78,"sourceHtmlUrl":79,"categories":80,"keywords":91,"publishedAt":38},"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",[81,86],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[92,93,94,30,95,96,97,98,21,99,100,101,102,103,104,105,106,107,108,109],"writing","writing plans","plans","superpowers","implementation plan","when","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":114,"sourceHtmlUrl":115,"categories":116,"keywords":120,"publishedAt":38},"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",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000031","产品经理",[103,121,122,123,124,32,125,97,126,127,128,102,129,130,131,132,133,134,135,136],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":141,"sourceHtmlUrl":142,"categories":143,"keywords":147,"publishedAt":38},"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",[144],{"categoryNo":145,"categoryName":146,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000033","数据分析师",[21,103,148,149,150,151,32,135,97,152,153,154,155,128,156,157,158,159,160,161],"write query","postgres","for","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins","data",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":174,"publishedAt":38},"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",[168,171],{"categoryNo":169,"categoryName":170,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":172,"categoryName":173,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000023","Skill与智能体开发",[175,176,177,178,150,179,180,181,182,28,183,184,185,21,22,156,186,187,188,158],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":196,"publishedAt":38},"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",[195],{"categoryNo":172,"categoryName":173,"taxonomyType":84,"taxonomyTypeDesc":85},[177,197,198,199,200,201,202,150,203,204,99,205,206,207,22,156,208,209,158,210],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":217,"publishedAt":38},"01M71PAHFJHG641X0RR432KB3G","worker-specialist","Org role guidance for a worker specialist: execute one assigned, well-scoped task with precision and report status honestly at real milestones. Covers confirming done-criteria first, surfacing blockers immediately and sharing intermediate results with peers.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworker-specialist\u002FSKILL.md",[],[218,219,220,150,221,222,223,224,225,226,154,227,22,156,228,209,229,230,231,158],"worker","worker specialist","specialist","scoped","milestones","done","one","coordination","task","first","results","report status","sharing","at"]