[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4M6K4NVF6XDRCC1SPP2BX":3,"skill-same:01M6C4M6K4NVF6XDRCC1SPP2BX":58},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":14,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6C4M6K4NVF6XDRCC1SPP2BX","effect-ts-idioms",null,"Write idiomatic modern Effect TypeScript using Effect.gen or clear pipelines, typed error channels, Context and Layer services, and resource-safe runtime boundaries. Use when building or reviewing code with Effect, @effect\u002Fplatform, Schema, Layers, or Effect-based applications.","JonasThowsen\u002F.dotfiles","JonasThowsen","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116713750?v=4","01M6C4M1ZT6HTT1X5TH96Q48AQ","Jonas Thowsen","01M6C4M247M99A8EX3SS04F8RT",0,"MIT","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Feffect-ts-idioms\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"effect","effect ts","effect ts idioms","safe","typescript","code","services","applications","write","context","use","schema","opencode","2026-11-10 10:12:30",false,"---\nname: effect-ts-idioms\ndescription: Write idiomatic modern Effect TypeScript using Effect.gen or clear pipelines, typed error channels, Context and Layer services, and resource-safe runtime boundaries. Use when building or reviewing code with Effect, @effect\u002Fplatform, Schema, Layers, or Effect-based applications.\ncompatibility: opencode\n---\n\nUse this skill to keep Effect code modern, explicit, and faithful to the library's model instead of falling back to Promise-first habits.\n\n## Mindset\n\nEffect code should make three things obvious from the type and structure:\n- success value\n- expected failure mode\n- required services\u002Fenvironment\n\nPrefer Effect-native modeling over wrapping Promise code and keeping the old design.\n\n## Default style\n\n- Use `Effect.gen` for multi-step workflows, branching, and orchestration.\n- Use `pipe(...)` plus combinators for short local transformations.\n- Keep effects lazy; describe work first, run it only at the program edge.\n- Write explicit lambdas instead of point-free or tacit style.\n\nPrefer:\n```ts\nEffect.map((user) => formatUser(user))\n```\n\nOver:\n```ts\nEffect.map(formatUser)\n```\n\nThis follows the official guidance to avoid tacit usage because it can hurt inference, overload resolution, and stack traces.\n\n## Error modeling\n\n- Put expected domain and operational failures in the error channel.\n- Reserve defects for truly unexpected bugs or violated invariants.\n- Prefer tagged, structured errors over raw strings.\n- Recover close to the boundary where a fallback is meaningful.\n\nGood defaults:\n- `Effect.fail(...)` for expected failures\n- `Effect.try(...)` \u002F `Effect.tryPromise(...)` when wrapping throwing or rejecting APIs\n- `catchTag`, `catchAll`, and `mapError` for recovery and translation\n\nAvoid:\n- throwing inside `Effect.sync`\n- burying business failures in `Option.none()` when the caller needs an explanation\n- converting everything to `unknown` or `Error` too early\n\n## Services, Context, and Layers\n\n- Model shared capabilities as services with `Context.Tag`.\n- Provide implementations with `Layer` for reusable dependency graphs.\n- Keep service interfaces small and capability-oriented.\n- Inject services through requirements, not global singletons.\n\nPrefer:\n- pure domain functions for pure logic\n- service tags for effectful capabilities\n- layers at app assembly boundaries\n\nDo not manually thread giant dependency objects through business logic if Effect requirements can model them cleanly.\n\n## Resource safety\n\n- Use scoped resource management for files, sockets, clients, subscriptions, locks, and anything requiring cleanup.\n- Prefer `Effect.acquireRelease`, `Effect.addFinalizer`, and scoped layers over manual cleanup bookkeeping.\n- Treat interruption as a normal part of execution, not an edge case.\n\nIf something must always be cleaned up, model it in the effect structure rather than relying on convention.\n\n## Runtime boundaries\n\n- Run effects at the outermost program boundary.\n- In Node apps, prefer `NodeRuntime.runMain(...)` for the main program so shutdown is graceful.\n- Avoid `Effect.runPromise` or `Effect.runSync` inside library code, helpers, or domain modules.\n- Convert external APIs at the edge, then stay inside Effect.\n\n## Concurrency and composition\n\n- Use fibers and combinators deliberately; choose sequential vs concurrent behavior explicitly.\n- Prefer `Effect.all(...)` and concurrency options for independent work.\n- Use retries, schedules, timeouts, and supervision as first-class tools instead of ad hoc loops.\n- Keep concurrent workflows readable; name intermediate effects when needed.\n\n## Data modeling\n\n- Prefer `Schema` at boundaries for parsing, validation, and encoding.\n- Prefer `Option`, `Either`, `Data`, `Chunk`, `Duration`, and other Effect data types when they make semantics clearer.\n- Avoid `null` and `undefined` in domain modeling when `Option` or a tagged union is better.\n\n## Interop rules\n\n- Wrap promise-returning APIs with `Effect.tryPromise` unless rejection is impossible.\n- Wrap callback or event APIs once, then expose an Effect-native interface.\n- Keep framework glue thin.\n\n## Review checklist\n\nWhen writing or reviewing Effect code, check:\n- Is expected failure in the error channel?\n- Are services expressed as requirements instead of hidden globals?\n- Is resource cleanup guaranteed by structure?\n- Is the runtime only used at the edge?\n- Is the code using `Effect.gen` or pipelines in a way that is easy to follow?\n- Is this still really Effect code, or just Promise code wrapped at the last second?\n","Use this skill to keep Effect code modern, explicit, and faithful to the library's model instead of falling back to Promise-first habits.\n\n## Mindset\n\nEffect code should make three things obvious from the type and structure:\n- success value\n- expected failure mode\n- required services\u002Fenvironment\n\nPrefer Effect-native modeling over wrapping Promise code and keeping the old design.\n\n## Default style\n\n- Use `Effect.gen` for multi-step workflows, branching, and orchestration.\n- Use `pipe(...)` plus combinators for short local transformations.\n- Keep effects lazy; describe work first, run it only at the program edge.\n- Write explicit lambdas instead of point-free or tacit style.\n\nPrefer:\n```ts\nEffect.map((user) => formatUser(user))\n```\n\nOver:\n```ts\nEffect.map(formatUser)\n```\n\nThis follows the official guidance to avoid tacit usage because it can hurt inference, overload resolution, and stack traces.\n\n## Error modeling\n\n- Put expected domain and operational failures in the error channel.\n- Reserve defects for truly unexpected bugs or violated invariants.\n- Prefer tagged, structured errors over raw strings.\n- Recover close to the boundary where a fallback is meaningful.\n\nGood defaults:\n- `Effect.fail(...)` for expected failures\n- `Effect.try(...)` \u002F `Effect.tryPromise(...)` when wrapping throwing or rejecting APIs\n- `catchTag`, `catchAll`, and `mapError` for recovery and translation\n\nAvoid:\n- throwing inside `Effect.sync`\n- burying business failures in `Option.none()` when the caller needs an explanation\n- converting everything to `unknown` or `Error` too early\n\n## Services, Context, and Layers\n\n- Model shared capabilities as services with `Context.Tag`.\n- Provide implementations with `Layer` for reusable dependency graphs.\n- Keep service interfaces small and capability-oriented.\n- Inject services through requirements, not global singletons.\n\nPrefer:\n- pure domain functions for pure logic\n- service tags for effectful capabilities\n- layers at app assembly boundaries\n\nDo not manually thread giant dependency objects through business logic if Effect requirements can model them cleanly.\n\n## Resource safety\n\n- Use scoped resource management for files, sockets, clients, subscriptions, locks, and anything requiring cleanup.\n- Prefer `Effect.acquireRelease`, `Effect.addFinalizer`, and scoped layers over manual cleanup bookkeeping.\n- Treat interruption as a normal part of execution, not an edge case.\n\nIf something must always be cleaned up, model it in the effect structure rather than relying on convention.\n\n## Runtime boundaries\n\n- Run effects at the outermost program boundary.\n- In Node apps, prefer `NodeRuntime.runMain(...)` for the main program so shutdown is graceful.\n- Avoid `Effect.runPromise` or `Effect.runSync` inside library code, helpers, or domain modules.\n- Convert external APIs at the edge, then stay inside Effect.\n\n## Concurrency and composition\n\n- Use fibers and combinators deliberately; choose sequential vs concurrent behavior explicitly.\n- Prefer `Effect.all(...)` and concurrency options for independent work.\n- Use retries, schedules, timeouts, and supervision as first-class tools instead of ad hoc loops.\n- Keep concurrent workflows readable; name intermediate effects when needed.\n\n## Data modeling\n\n- Prefer `Schema` at boundaries for parsing, validation, and encoding.\n- Prefer `Option`, `Either`, `Data`, `Chunk`, `Duration`, and other Effect data types when they make semantics clearer.\n- Avoid `null` and `undefined` in domain modeling when `Option` or a tagged union is better.\n\n## Interop rules\n\n- Wrap promise-returning APIs with `Effect.tryPromise` unless rejection is impossible.\n- Wrap callback or event APIs once, then expose an Effect-native interface.\n- Keep framework glue thin.\n\n## Review checklist\n\nWhen writing or reviewing Effect code, check:\n- Is expected failure in the error channel?\n- Are services expressed as requirements instead of hidden globals?\n- Is resource cleanup guaranteed by structure?\n- Is the runtime only used at the edge?\n- Is the code using `Effect.gen` or pipelines in a way that is easy to follow?\n- Is this still really Effect code, or just Promise code wrapped at the last second?\n",{"name":5,"description":7,"compatibility":31},"main","f5b4e1172fd18558c9071d150a1ffe797be04ca7","opencode\u002F.config\u002Fopencode\u002Fskills\u002Feffect-ts-idioms","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles","https:\u002F\u002Fgithub.com\u002FJonasThowsen","invaron.no","2026-11-11 04:03:33",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add JonasThowsen\u002F.dotfiles --skill effect-ts-idioms",{"tool":50,"command":51},"bunx","bunx skills add JonasThowsen\u002F.dotfiles --skill effect-ts-idioms",{"tool":53,"command":54},"pnpm","pnpm dlx skills add JonasThowsen\u002F.dotfiles --skill effect-ts-idioms","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Feffect-ts-idioms\u002FSKILL.md",true,[],[59,82,98,131,144],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":70,"publishedAt":32},"01M6C4MHG9NKR5WM5PQ3Z1TE0C","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Fskill-creator\u002FSKILL.md",[65],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[71,29,72,73,74,75,76,77,78,79,80,81],"skill creator","performance","run evals","test","variance analysis","create","run","benchmark","analysis","improve","edit",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":32},"01M6C4METZ2H1R94DPVFBM6EEX","modern-astro-v6","Build idiomatic Astro v6 applications with server-first rendering, islands, content collections, actions, and current v6-safe APIs. Use when creating, reviewing, or migrating Astro projects, pages, components, content layers, or integrations.","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Fmodern-astro-v6\u002FSKILL.md",[],[89,90,91,92,26,93,94,95,22,96,97,29,31],"astro","modern astro v6","server","actions","first","content","components","projects","integrations",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":115,"publishedAt":32},"01M6C4MC12H795H32MWYRA9JQM","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[104,107,110],{"categoryNo":105,"categoryName":106,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":108,"categoryName":109,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[116,117,118,119,120,29,121,122,123,124,95,125,126,127,76,24,128,129,130,26],"design","frontend","frontend design","creative","styling","landing","quality","css","web","react","react components","web components","artifacts","examples","Production",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":32},"01M6C4M9AJTGEJN0Q68WXDV4DG","elixir-idioms","Write idiomatic Elixir and Phoenix code with pattern matching, small composable functions, OTP-friendly boundaries, and BEAM-aware error handling. Use when creating or reviewing Elixir code, APIs, GenServers, Phoenix apps, Ecto code, or tests.","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Felixir-idioms\u002FSKILL.md",[],[138,139,29,140,141,24,142,143,27,31],"elixir idioms","elixir","beam","composable","error handling","Phoenix",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":153,"publishedAt":32},"01M6C4M42EEAKE6VBVQKTN11MK","ash-framework-idioms","Write idiomatic Ash framework code using intentful actions, code interfaces, relationship management, DSL-first modeling, and framework-native changes\u002Fpreparations instead of ad hoc helper layers. Use when creating or reviewing Ash resources, domains, actions, queries, or Phoenix integrations.","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Fash-framework-idioms\u002FSKILL.md",[150],{"categoryNo":151,"categoryName":152,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000030","开发工程师",[154,155,24,92,143,93,97,27,156,29,31],"framework","ash framework idioms","management"]