[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4M42EEAKE6VBVQKTN11MK":3,"skill-same:01M6C4M42EEAKE6VBVQKTN11MK":66},{"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":23,"publishedAt":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":14,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":6,"updatedAt":46,"install":47,"resources":60},"01M6C4M42EEAKE6VBVQKTN11MK","ash-framework-idioms",null,"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.","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\u002Fash-framework-idioms\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34],"framework","ash framework idioms","code","actions","Phoenix","first","integrations","write","management","use","opencode","2026-11-10 10:12:30",false,"---\nname: ash-framework-idioms\ndescription: 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.\ncompatibility: opencode\n---\n\nUse this skill to keep Ash code aligned with the framework's intended style instead of recreating Ecto-context patterns or building custom wrapper layers around features Ash already provides.\n\n## Core mindset\n\nAsh applications should express domain behavior in:\n- resources\n- actions\n- relationships\n- calculations and aggregates\n- changes, validations, and preparations\n- code interfaces\n\nPrefer Ash-native DSL and action modeling over hand-written helper modules that assemble queries and changesets everywhere.\n\n## Primary rules\n\n- Put business behavior in well-named actions.\n- Use code interfaces for function-style access from the rest of the app.\n- Keep controllers, LiveViews, and other web modules thin.\n- Prefer resource capabilities over bespoke helper functions.\n- Reach for `Ash.Query` \u002F `Ash.Changeset` directly only when customizing invocation of an already meaningful action, or when building framework-level tooling.\n\n## Actions over helpers\n\nAsh is not meant to stop at generic CRUD.\n\nPrefer:\n- many small, intentful actions\n- `:open`, `:archive`, `:top`, `:assign_reviewer`, `:publish`, `:approve`\n\nOver:\n- one generic `:read`, `:update`, `:destroy` plus a pile of helper functions in contexts or LiveViews\n\nBad shape:\n- web layer builds filters, sorting, limits, and domain rules manually every time\n\nBetter shape:\n- define a named action that captures the behavior\n- expose it via a code interface\n- optionally customize the query when needed at the call site\n\nIf you see a helper like `top_tickets(user_id)` that mostly builds an Ash query, strongly consider making it a read action plus a code interface instead.\n\n## Code interfaces are the default app-facing API\n\nWhen Ash resources\u002Factions are called from application code, prefer code interfaces on the domain or resource.\n\nUse them for:\n- create\u002Fupdate\u002Fdestroy flows\n- `get_by` accessors\n- calculation exposure\n- authorization checks\n\nPrefer:\n- `MyApp.Support.open_ticket(subject)`\n- `MyApp.Dashboards.get_dashboard_group_by_id!(id, load: [...])`\n\nOver:\n- calling `Ash.get!`, `Ash.read!`, `Ash.create!`, etc. directly from controllers, LiveViews, or unrelated modules unless the module is intentionally composing\u002Fcustomizing the action call\n\nImportant guidance:\n- use `get_by` code interfaces instead of sprinkling `Ash.get!` in web modules\n- use generated `can_*?` functions for UI authorization checks when relevant\n- use `default_options` sparingly for stable interface defaults\n\n## DSL-first modeling\n\nAsk before writing helper code: \"Does Ash already have a way to model this?\"\n\nUsually prefer Ash features like:\n- action arguments\n- `accept` \u002F `default_accept`\n- validations\n- changes\n- preparations\n- calculations\n- aggregates\n- identities\n- relationships and `manage_relationship`\n- policies\n\nAvoid writing boilerplate conversion or orchestration code if the DSL can describe it directly.\n\n## Use the right extension point\n\n- **Changes** customize create\u002Fupdate\u002Fdestroy behavior.\n- **Preparations** customize read and generic action behavior.\n- **Validations** enforce business rules.\n- **Calculations** expose derived values.\n- **Aggregates** expose counts\u002Fsums\u002Fetc.\n- **Relationships** model traversal and related-data management.\n\nDo not put read-query logic into custom helper modules when a preparation on a read action is the right home.\nDo not put write-side orchestration into controllers when a change on the action is the right home.\n\n## Relationship management\n\nPrefer `manage_relationship` when the intent is standard relationship CRUD from action input.\n\nUse `change manage_relationship(...)` when:\n- input comes from action arguments\n- you want AshPhoenix\u002FAshGraphQL\u002FAshJsonApi to understand the behavior naturally\n\nUse `Ash.Changeset.manage_relationship\u002F4` directly when:\n- building related values programmatically in a custom change\n- the flow is conditional or transformed before relationship management\n\nAvoid manually updating foreign keys and join records unless there is a genuinely special case.\n\n## Keep web layers thin\n\nIn Phoenix or LiveView code:\n- call domain\u002Fresource code interfaces\n- pass action args and options\n- keep filtering, loading, and domain semantics in the Ash layer\n\nDo not treat Ash like a glorified Repo wrapper.\n\nBad pattern:\n- controller or LiveView manually builds query\u002Ffilter\u002Fsort\u002Fload chains that represent domain behavior\n\nGood pattern:\n- named resource action + code interface, with optional query customization only when truly needed\n\n## Defaults are for bootstrapping, not the end state\n\n`defaults [...]` is a good starting point, but mature Ash resources often need more expressive action sets.\n\nDo not stop at generic CRUD if the resource has meaningful domain operations.\n\n## Custom changes and preparations\n\n- Anonymous functions are fine for prototyping.\n- Prefer modules for lasting behavior.\n- Module-based changes\u002Fpreparations are more reusable, more organized, and support advanced features like atomic or batch behavior.\n\nIf behavior matters enough to keep, give it a proper module.\n\n## Nested actions and context\n\nWhen invoking nested actions from changes or preparations:\n- preserve scope\u002Fcontext properly\n- prefer `scope: context` or the relevant Ash helpers for threading shared context\n\nDo not manually drop important actor\u002Ftenant\u002Fshared information.\n\n## Query customization guidance\n\nIt is okay to customize invocation outside the action when necessary, for example:\n- adding an extra filter to a named read action\n- adding dynamic loads\n- providing tenant\u002Factor\u002Fcontext options\n\nBut the base meaning should still live in the action itself.\n\nThink:\n- actions define the capability\n- code interfaces expose the capability ergonomically\n- ad hoc query building refines the capability for a specific call site\n\n## Review checklist\n\nWhen writing or reviewing Ash code, check:\n- Should this helper actually be an action?\n- Should this direct `Ash.*` call be a code interface call instead?\n- Is query logic living in a preparation or named read action where it belongs?\n- Is write logic living in changes\u002Fvalidations\u002Fmanage_relationship where it belongs?\n- Is the web layer too aware of Ash internals?\n- Is this recreating framework behavior that Ash already provides?\n\n## Good outcomes\n\nIdiomatic Ash code tends to have:\n- thin web modules\n- rich, named actions\n- clear code interfaces\n- less boilerplate helper code\n- fewer manual query pipelines scattered across the app\n- behavior described declaratively in the resource\u002Fdomain DSL\n","Use this skill to keep Ash code aligned with the framework's intended style instead of recreating Ecto-context patterns or building custom wrapper layers around features Ash already provides.\n\n## Core mindset\n\nAsh applications should express domain behavior in:\n- resources\n- actions\n- relationships\n- calculations and aggregates\n- changes, validations, and preparations\n- code interfaces\n\nPrefer Ash-native DSL and action modeling over hand-written helper modules that assemble queries and changesets everywhere.\n\n## Primary rules\n\n- Put business behavior in well-named actions.\n- Use code interfaces for function-style access from the rest of the app.\n- Keep controllers, LiveViews, and other web modules thin.\n- Prefer resource capabilities over bespoke helper functions.\n- Reach for `Ash.Query` \u002F `Ash.Changeset` directly only when customizing invocation of an already meaningful action, or when building framework-level tooling.\n\n## Actions over helpers\n\nAsh is not meant to stop at generic CRUD.\n\nPrefer:\n- many small, intentful actions\n- `:open`, `:archive`, `:top`, `:assign_reviewer`, `:publish`, `:approve`\n\nOver:\n- one generic `:read`, `:update`, `:destroy` plus a pile of helper functions in contexts or LiveViews\n\nBad shape:\n- web layer builds filters, sorting, limits, and domain rules manually every time\n\nBetter shape:\n- define a named action that captures the behavior\n- expose it via a code interface\n- optionally customize the query when needed at the call site\n\nIf you see a helper like `top_tickets(user_id)` that mostly builds an Ash query, strongly consider making it a read action plus a code interface instead.\n\n## Code interfaces are the default app-facing API\n\nWhen Ash resources\u002Factions are called from application code, prefer code interfaces on the domain or resource.\n\nUse them for:\n- create\u002Fupdate\u002Fdestroy flows\n- `get_by` accessors\n- calculation exposure\n- authorization checks\n\nPrefer:\n- `MyApp.Support.open_ticket(subject)`\n- `MyApp.Dashboards.get_dashboard_group_by_id!(id, load: [...])`\n\nOver:\n- calling `Ash.get!`, `Ash.read!`, `Ash.create!`, etc. directly from controllers, LiveViews, or unrelated modules unless the module is intentionally composing\u002Fcustomizing the action call\n\nImportant guidance:\n- use `get_by` code interfaces instead of sprinkling `Ash.get!` in web modules\n- use generated `can_*?` functions for UI authorization checks when relevant\n- use `default_options` sparingly for stable interface defaults\n\n## DSL-first modeling\n\nAsk before writing helper code: \"Does Ash already have a way to model this?\"\n\nUsually prefer Ash features like:\n- action arguments\n- `accept` \u002F `default_accept`\n- validations\n- changes\n- preparations\n- calculations\n- aggregates\n- identities\n- relationships and `manage_relationship`\n- policies\n\nAvoid writing boilerplate conversion or orchestration code if the DSL can describe it directly.\n\n## Use the right extension point\n\n- **Changes** customize create\u002Fupdate\u002Fdestroy behavior.\n- **Preparations** customize read and generic action behavior.\n- **Validations** enforce business rules.\n- **Calculations** expose derived values.\n- **Aggregates** expose counts\u002Fsums\u002Fetc.\n- **Relationships** model traversal and related-data management.\n\nDo not put read-query logic into custom helper modules when a preparation on a read action is the right home.\nDo not put write-side orchestration into controllers when a change on the action is the right home.\n\n## Relationship management\n\nPrefer `manage_relationship` when the intent is standard relationship CRUD from action input.\n\nUse `change manage_relationship(...)` when:\n- input comes from action arguments\n- you want AshPhoenix\u002FAshGraphQL\u002FAshJsonApi to understand the behavior naturally\n\nUse `Ash.Changeset.manage_relationship\u002F4` directly when:\n- building related values programmatically in a custom change\n- the flow is conditional or transformed before relationship management\n\nAvoid manually updating foreign keys and join records unless there is a genuinely special case.\n\n## Keep web layers thin\n\nIn Phoenix or LiveView code:\n- call domain\u002Fresource code interfaces\n- pass action args and options\n- keep filtering, loading, and domain semantics in the Ash layer\n\nDo not treat Ash like a glorified Repo wrapper.\n\nBad pattern:\n- controller or LiveView manually builds query\u002Ffilter\u002Fsort\u002Fload chains that represent domain behavior\n\nGood pattern:\n- named resource action + code interface, with optional query customization only when truly needed\n\n## Defaults are for bootstrapping, not the end state\n\n`defaults [...]` is a good starting point, but mature Ash resources often need more expressive action sets.\n\nDo not stop at generic CRUD if the resource has meaningful domain operations.\n\n## Custom changes and preparations\n\n- Anonymous functions are fine for prototyping.\n- Prefer modules for lasting behavior.\n- Module-based changes\u002Fpreparations are more reusable, more organized, and support advanced features like atomic or batch behavior.\n\nIf behavior matters enough to keep, give it a proper module.\n\n## Nested actions and context\n\nWhen invoking nested actions from changes or preparations:\n- preserve scope\u002Fcontext properly\n- prefer `scope: context` or the relevant Ash helpers for threading shared context\n\nDo not manually drop important actor\u002Ftenant\u002Fshared information.\n\n## Query customization guidance\n\nIt is okay to customize invocation outside the action when necessary, for example:\n- adding an extra filter to a named read action\n- adding dynamic loads\n- providing tenant\u002Factor\u002Fcontext options\n\nBut the base meaning should still live in the action itself.\n\nThink:\n- actions define the capability\n- code interfaces expose the capability ergonomically\n- ad hoc query building refines the capability for a specific call site\n\n## Review checklist\n\nWhen writing or reviewing Ash code, check:\n- Should this helper actually be an action?\n- Should this direct `Ash.*` call be a code interface call instead?\n- Is query logic living in a preparation or named read action where it belongs?\n- Is write logic living in changes\u002Fvalidations\u002Fmanage_relationship where it belongs?\n- Is the web layer too aware of Ash internals?\n- Is this recreating framework behavior that Ash already provides?\n\n## Good outcomes\n\nIdiomatic Ash code tends to have:\n- thin web modules\n- rich, named actions\n- clear code interfaces\n- less boilerplate helper code\n- fewer manual query pipelines scattered across the app\n- behavior described declaratively in the resource\u002Fdomain DSL\n",{"name":5,"description":7,"compatibility":34},"main","f5b4e1172fd18558c9071d150a1ffe797be04ca7","opencode\u002F.config\u002Fopencode\u002Fskills\u002Fash-framework-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":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add JonasThowsen\u002F.dotfiles --skill ash-framework-idioms",{"tool":53,"command":54},"bunx","bunx skills add JonasThowsen\u002F.dotfiles --skill ash-framework-idioms",{"tool":56,"command":57},"pnpm","pnpm dlx skills add JonasThowsen\u002F.dotfiles --skill ash-framework-idioms","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Fash-framework-idioms\u002FSKILL.md",true,[61],{"path":62,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"LICENSE","许可证",1072,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-ponder\u002FLICENSE",[67,90,105,136,148],{"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":78,"publishedAt":35},"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",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[79,80,81,82,83,84,85,86,87,88,89,33],"skill creator","performance","run evals","test","variance analysis","create","run","benchmark","analysis","improve","edit",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":35},"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",[],[97,98,27,29,99,33,100,101,102,103,104,30,34],"astro","modern astro v6","applications","server","content","components","safe","projects",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":120,"publishedAt":35},"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",[111,114,117],{"categoryNo":112,"categoryName":113,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":115,"categoryName":116,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[121,122,123,124,125,33,126,127,128,129,130,102,131,132,133,84,26,134,135,99],"frontend","design","frontend design","creative","styling","landing","artifacts","quality","css","web","react","react components","web components","examples","Production",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":35},"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",[],[143,144,31,145,146,26,147,28,33,34],"elixir idioms","elixir","beam","composable","error handling",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":35},"01M6C4M6K4NVF6XDRCC1SPP2BX","effect-ts-idioms","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.","https:\u002F\u002Fgithub.com\u002FJonasThowsen\u002F.dotfiles\u002Fblob\u002Fmain\u002Fopencode\u002F.config\u002Fopencode\u002Fskills\u002Feffect-ts-idioms\u002FSKILL.md",[],[155,156,157,158,26,159,99,31,160,33,161,34,103],"effect","effect ts","effect ts idioms","typescript","services","context","schema"]