[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CSZR8741VCE32FF27EBX6M":3,"skill-same:01M7CSZR8741VCE32FF27EBX6M":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":29,"updatedAt":30,"install":31,"resources":44},"01M7CSZR8741VCE32FF27EBX6M","principle-make-operations-idempotent",null,"Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs.","cameronjlarsen\u002Fengineering-toolkit","cameronjlarsen","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F44081018?v=4","01M7CSW9ZZAK2D9T98W54VH45D","Cameron Larsen","01M7CSWA0JXH6RTFHGH204RA7F",0,"MIT","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Fprinciple-make-operations-idempotent\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: principle-make-operations-idempotent\ndescription: \"Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs.\"\nuser-invocable: false\n---\n\n# Make Operations Idempotent\n\nDesign operations so they converge to the correct state regardless of how many times they run or where the previous run stopped. Every state-mutating operation should answer: \"What happens if this runs twice? What happens if the previous run crashed halfway?\"\n\n**Why:** Commands, lifecycle operations, and processing loops run where crashes, restarts, and retries are normal. If partial state changes the next run's outcome, every restart becomes a debugging session.\n\n**The idea:** derive each step from the state that exists, not from what the previous run meant to do. Read the current state, compare it to the goal, and apply only the difference. A step written this way is safe to repeat, because a repeat finds nothing left to do.\n\nAnything a run leaves behind, such as a lock, a temporary file, a half-written record, or a claimed job, must be recognizable as stale by the next run. Judge staleness by evidence that stays true wherever the previous run could have stopped, not only in the common case. A marker that the next run cannot judge turns every crash into manual cleanup. For example, write to a temporary path and rename it into place, or compare artifacts by content instead of by creation order.\n\n**The test:**\n1. What happens if this runs twice in a row?\n2. What happens if the previous run crashed at every possible point?\n3. Does re-execution converge to the same end state?\n\nIf any answer is \"it depends on what state was left behind,\" the operation needs a reconciliation step.\n","# Make Operations Idempotent\n\nDesign operations so they converge to the correct state regardless of how many times they run or where the previous run stopped. Every state-mutating operation should answer: \"What happens if this runs twice? What happens if the previous run crashed halfway?\"\n\n**Why:** Commands, lifecycle operations, and processing loops run where crashes, restarts, and retries are normal. If partial state changes the next run's outcome, every restart becomes a debugging session.\n\n**The idea:** derive each step from the state that exists, not from what the previous run meant to do. Read the current state, compare it to the goal, and apply only the difference. A step written this way is safe to repeat, because a repeat finds nothing left to do.\n\nAnything a run leaves behind, such as a lock, a temporary file, a half-written record, or a claimed job, must be recognizable as stale by the next run. Judge staleness by evidence that stays true wherever the previous run could have stopped, not only in the common case. A marker that the next run cannot judge turns every crash into manual cleanup. For example, write to a temporary path and rename it into place, or compare artifacts by content instead of by creation order.\n\n**The test:**\n1. What happens if this runs twice in a row?\n2. What happens if the previous run crashed at every possible point?\n3. Does re-execution converge to the same end state?\n\nIf any answer is \"it depends on what state was left behind,\" the operation needs a reconciliation step.\n",{"name":5,"description":7,"user-invocable":20},"main","e14e605d32e02d75d3bef1e20c21ccaa8ac05310","plugins\u002Fengineering-toolkit\u002Fskills\u002Fprinciple-make-operations-idempotent","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen","Software Engineer @TheMortgageOffice ","2026-11-04 08:21:41",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add cameronjlarsen\u002Fengineering-toolkit --skill principle-make-operations-idempotent",{"tool":37,"command":38},"bunx","bunx skills add cameronjlarsen\u002Fengineering-toolkit --skill principle-make-operations-idempotent",{"tool":40,"command":41},"pnpm","pnpm dlx skills add cameronjlarsen\u002Fengineering-toolkit --skill principle-make-operations-idempotent","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Fprinciple-make-operations-idempotent\u002FSKILL.md",true,[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7CT26RDV1NYPCSKMF6J22D6","work-unit-commits","Plan commits as reviewable work units. Trigger: implementation, commit splitting, stacked PRs, or keeping tests and docs with code.","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Fwork-unit-commits\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7CT229DK7GNGZAC9EK10HKQ","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Fwhy\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7CT20NV7VM98JYJ8ZGPJRDS","what-did-i-get-done","Summarize authored commits over a user-specified time period into a concise update","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Fwhat-did-i-get-done\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M7CT1ZDKYE78ZM563M21Y5YW","unslop","Cut AI tells from any writing.","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Funslop\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7CT1XX1VGTG1PA3P90ZRCDZ","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7CT1T7J6555NF1ZY5YCKX7W","thermo-nuclear-code-quality-review","Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.","https:\u002F\u002Fgithub.com\u002Fcameronjlarsen\u002Fengineering-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fengineering-toolkit\u002Fskills\u002Fthermo-nuclear-code-quality-review\u002FSKILL.md",[],[]]