[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DWM4VCZ21P4YN4CDEZH769":3,"skill-same:01M6DWM4VCZ21P4YN4CDEZH769":86},{"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":25,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6DWM4VCZ21P4YN4CDEZH769","programming-elixir",null,"Elixir and Phoenix practices: pattern matching, supervision, process lifecycle, concurrency design. Use when writing or reviewing a mix.exs project.","Muvon\u002Foctomind-tap","Muvon","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F25336907?v=4","01M6DWA4KTRX4J73CW5CECKAD0","01M6DWA4QSWFGYE6WDMAMFF1WE",6,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fprogramming-elixir\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000036","内容创作者",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"programming","programming elixir","elixir","use","when","writing","mix","project","pattern matching","matching","process","file","best practices","lifecycle","development","developer","pattern","otp","concurrency","design","2026-11-10 10:12:30",false,"---\nname: programming-elixir\ntitle: \"Elixir Development Best Practices\"\ndescription: \"Elixir and Phoenix practices: pattern matching, supervision, process lifecycle, concurrency design. Use when writing or reviewing a mix.exs project.\"\nlicense: Apache-2.0\ncompatibility: \"Requires Elixir and Erlang\u002FOTP.\"\ndomains: developer\nrules:\n  - file(mix.exs)\n  - content(elixir)\n---\n\n## Overview\n\nWrite Elixir as clear data transformations with explicit process and failure ownership. As of 2026-10: Elixir 1.20 is the current stable line (released June 2026) and Phoenix 1.8.x the current Phoenix line, with gradual compiler type inference across language constructs. Inspect the project's Elixir\u002FErlang requirements and locked Phoenix\u002FEcto versions first. Elixir 1.20 requires OTP 27+; select a documented compatible pair rather than independently upgrading runtimes.\n\n## Mental model\n\nModules organize behavior; processes own concurrent activity and state. Supervision restores failed processes, not lost database transactions or external side effects. Validate untrusted input and represent expected failures explicitly; let unexpected defects fail where a deliberate supervision boundary can handle them.\n\n## Functions, data, and current typing\n\n- Use functions and pattern matching for ordinary domain logic. A GenServer is not required to encapsulate a module or make it \"OTP-first.\"\n- Use clauses and guards when they clarify accepted shapes. Validate untrusted input before entering functions whose patterns assume internal invariants; don't add catch-all success defaults to hide malformed data.\n- Keep `{:ok, value}`\u002F`{:error, reason}` contracts consistent. Use `with` for dependent fallible steps, but normalize ambiguous failure shapes in their owning functions. A large `else` reconstructing which step failed signals unclear contracts.\n- Use `case` for branching and pipes for linear transformations; do not force every condition into `with`. Keep error reasons useful to callers without leaking sensitive input.\n- Elixir 1.20 infers types through expressions, guards, clauses, and dependency information. Treat verified-bug\u002Fdead-code warnings as evidence to investigate. This is not complete compile-time proof of program correctness.\n- Keep `@spec` and `@type` for documented contracts and existing analysis tools. Do not invent new set-theoretic annotation syntax: user-supplied signatures and typed structs for that system remain future work in the 1.20 release.\n- Structs provide a known shape, not automatic field validation. Use changesets or explicit constructors for boundary checks; `@enforce_keys` does not validate values.\n- Keep external keys as strings or map them through an explicit allowlist. Unbounded `String.to_atom\u002F1` can exhaust the atom table; `to_existing_atom\u002F1` still raises and does not prove an atom is allowed for this operation.\n- Use `Stream` for deferred traversal when needed; consume it deliberately. Avoid assuming laziness removes the memory cost of a later full materialization.\n\n## Process and task ownership\n\n- Introduce a GenServer when serial access to state or a managed lifecycle is needed. Long callbacks block its mailbox; move independent work to supervised tasks with explicit result handling.\n- Choose supervision strategy from dependency relationships: `:one_for_one` for independent children, `:rest_for_one` when later children depend on earlier ones. Specify restart\u002Fshutdown policy; a Task normally has temporary restart behavior.\n- `Task.async` links caller and task, so task failure can terminate its caller. Use supervised `async_nolink` when that coupling is undesirable, and consume results, failures, and monitor messages.\n- Bound fan-out with `Task.async_stream` or equivalent limits. Set concurrency according to downstream capacity, with a deliberate timeout policy. Lazy input alone does not make unbounded spawning safe.\n- Task closures copy captured data into another process. Extract only required values; avoid capturing an entire LiveView socket or large state object.\n- A `GenServer.call` timeout does not cancel work already accepted by the server. Account for uncertain completion before retrying a mutation; a cast provides no processing acknowledgement.\n- Do not synchronously call a GenServer from itself; direct self-calls fail rather than becoming useful serialization. Keep internal computation in functions, or redesign the interaction.\n- Supervision is not durable job storage. Work that must survive node loss needs the application's durable job mechanism and idempotent effects.\n\n## Persistence and Phoenix boundaries\n\n- Changesets cast allowed external fields, validate domain rules, and translate declared database constraint failures. Back race-sensitive invariants with actual database constraints; preflight checks alone are insufficient.\n- Use `Ecto.Multi` for named dependent database operations when it improves clarity. Handle the failed operation and reason; returned `changes_so_far` contains prior operation results, while the transaction's database writes roll back. Transactions do not make external API calls reversible.\n- Respect existing Phoenix context APIs so controllers and LiveViews share authorization and domain rules. Avoid blanket rules forbidding meaningful domain validation in changesets.\n- Phoenix 1.8 generators thread a `Scope` struct (`current_scope`) from authentication into context functions. When the project uses scopes, pass the scope explicitly and filter queries by it rather than reading the user from assigns deep inside contexts.\n- Authorize protected operations on the server, including LiveView events. A hidden button and a successful initial mount do not establish ongoing authorization.\n- In supported LiveView versions, use `assign_async`\u002F`start_async` for lifecycle-managed work, with loading\u002Ferror rendering. Capture needed values before starting work; avoid blocking callbacks with `Task.await`.\n- Use streams for large changing collections when their identity\u002Fupdate model fits. They reduce retained collection state; they do not remove the need for query limits or pagination.\n\n## Example\n\nAccept only known external values without creating atoms or disguising errors:\n\n```elixir\ndefmodule Visibility do\n  @spec parse(term()) :: {:ok, :public | :private} | {:error, :invalid_visibility}\n  def parse(\"public\"), do: {:ok, :public}\n  def parse(\"private\"), do: {:ok, :private}\n  def parse(_), do: {:error, :invalid_visibility}\nend\n```\n\nThe final clause returns an explicit expected failure. Internal callers can pattern-match the result without rescuing exceptions or silently selecting a default.\n\n## Checklist\n\n- Verify Elixir\u002FOTP compatibility and supported library APIs.\n- Keep process boundaries motivated by concurrency\u002Flifecycle, not code organization.\n- Check expected failures, compiler warnings, atom handling, and boundary validation.\n- Check task links, bounded work, timeouts, duplicate effects, and transaction limits.\n- Use installed formatter, `mix compile --warnings-as-errors`, ExUnit, and existing analysis tools when authorized. Format checks alone do not prove compilation or behavior; use async tests only when their shared resources are isolated.\n\n## References\n\n- [Elixir stable documentation](https:\u002F\u002Felixir-lang.org\u002Fdocs\u002F) and [1.20 typing release](https:\u002F\u002Felixir-lang.org\u002Fblog\u002F2026\u002F06\u002F03\u002Felixir-v1-20-0-released\u002F)\n- [Elixir 1.20 OTP requirements](https:\u002F\u002Felixir.hexdocs.pm\u002F1.20.0\u002Fchangelog.html)\n- [Official code anti-patterns](https:\u002F\u002Felixir.hexdocs.pm\u002Fcode-anti-patterns.html)\n- [Task ownership and concurrency](https:\u002F\u002Felixir.hexdocs.pm\u002FTask.html)\n- [GenServer call semantics](https:\u002F\u002Felixir.hexdocs.pm\u002FGenServer.html) and [supervision policies](https:\u002F\u002Felixir.hexdocs.pm\u002FSupervisor.html)\n- [Ecto changesets](https:\u002F\u002Fecto.hexdocs.pm\u002FEcto.Changeset.html) and [transactions with Multi](https:\u002F\u002Fecto.hexdocs.pm\u002FEcto.Multi.html)\n- [Phoenix scopes](https:\u002F\u002Fhexdocs.pm\u002Fphoenix\u002Fscopes.html)\n- [LiveView async operations and streams](https:\u002F\u002Fphoenix-live-view.hexdocs.pm\u002FPhoenix.LiveView.html)\n","## Overview\n\nWrite Elixir as clear data transformations with explicit process and failure ownership. As of 2026-10: Elixir 1.20 is the current stable line (released June 2026) and Phoenix 1.8.x the current Phoenix line, with gradual compiler type inference across language constructs. Inspect the project's Elixir\u002FErlang requirements and locked Phoenix\u002FEcto versions first. Elixir 1.20 requires OTP 27+; select a documented compatible pair rather than independently upgrading runtimes.\n\n## Mental model\n\nModules organize behavior; processes own concurrent activity and state. Supervision restores failed processes, not lost database transactions or external side effects. Validate untrusted input and represent expected failures explicitly; let unexpected defects fail where a deliberate supervision boundary can handle them.\n\n## Functions, data, and current typing\n\n- Use functions and pattern matching for ordinary domain logic. A GenServer is not required to encapsulate a module or make it \"OTP-first.\"\n- Use clauses and guards when they clarify accepted shapes. Validate untrusted input before entering functions whose patterns assume internal invariants; don't add catch-all success defaults to hide malformed data.\n- Keep `{:ok, value}`\u002F`{:error, reason}` contracts consistent. Use `with` for dependent fallible steps, but normalize ambiguous failure shapes in their owning functions. A large `else` reconstructing which step failed signals unclear contracts.\n- Use `case` for branching and pipes for linear transformations; do not force every condition into `with`. Keep error reasons useful to callers without leaking sensitive input.\n- Elixir 1.20 infers types through expressions, guards, clauses, and dependency information. Treat verified-bug\u002Fdead-code warnings as evidence to investigate. This is not complete compile-time proof of program correctness.\n- Keep `@spec` and `@type` for documented contracts and existing analysis tools. Do not invent new set-theoretic annotation syntax: user-supplied signatures and typed structs for that system remain future work in the 1.20 release.\n- Structs provide a known shape, not automatic field validation. Use changesets or explicit constructors for boundary checks; `@enforce_keys` does not validate values.\n- Keep external keys as strings or map them through an explicit allowlist. Unbounded `String.to_atom\u002F1` can exhaust the atom table; `to_existing_atom\u002F1` still raises and does not prove an atom is allowed for this operation.\n- Use `Stream` for deferred traversal when needed; consume it deliberately. Avoid assuming laziness removes the memory cost of a later full materialization.\n\n## Process and task ownership\n\n- Introduce a GenServer when serial access to state or a managed lifecycle is needed. Long callbacks block its mailbox; move independent work to supervised tasks with explicit result handling.\n- Choose supervision strategy from dependency relationships: `:one_for_one` for independent children, `:rest_for_one` when later children depend on earlier ones. Specify restart\u002Fshutdown policy; a Task normally has temporary restart behavior.\n- `Task.async` links caller and task, so task failure can terminate its caller. Use supervised `async_nolink` when that coupling is undesirable, and consume results, failures, and monitor messages.\n- Bound fan-out with `Task.async_stream` or equivalent limits. Set concurrency according to downstream capacity, with a deliberate timeout policy. Lazy input alone does not make unbounded spawning safe.\n- Task closures copy captured data into another process. Extract only required values; avoid capturing an entire LiveView socket or large state object.\n- A `GenServer.call` timeout does not cancel work already accepted by the server. Account for uncertain completion before retrying a mutation; a cast provides no processing acknowledgement.\n- Do not synchronously call a GenServer from itself; direct self-calls fail rather than becoming useful serialization. Keep internal computation in functions, or redesign the interaction.\n- Supervision is not durable job storage. Work that must survive node loss needs the application's durable job mechanism and idempotent effects.\n\n## Persistence and Phoenix boundaries\n\n- Changesets cast allowed external fields, validate domain rules, and translate declared database constraint failures. Back race-sensitive invariants with actual database constraints; preflight checks alone are insufficient.\n- Use `Ecto.Multi` for named dependent database operations when it improves clarity. Handle the failed operation and reason; returned `changes_so_far` contains prior operation results, while the transaction's database writes roll back. Transactions do not make external API calls reversible.\n- Respect existing Phoenix context APIs so controllers and LiveViews share authorization and domain rules. Avoid blanket rules forbidding meaningful domain validation in changesets.\n- Phoenix 1.8 generators thread a `Scope` struct (`current_scope`) from authentication into context functions. When the project uses scopes, pass the scope explicitly and filter queries by it rather than reading the user from assigns deep inside contexts.\n- Authorize protected operations on the server, including LiveView events. A hidden button and a successful initial mount do not establish ongoing authorization.\n- In supported LiveView versions, use `assign_async`\u002F`start_async` for lifecycle-managed work, with loading\u002Ferror rendering. Capture needed values before starting work; avoid blocking callbacks with `Task.await`.\n- Use streams for large changing collections when their identity\u002Fupdate model fits. They reduce retained collection state; they do not remove the need for query limits or pagination.\n\n## Example\n\nAccept only known external values without creating atoms or disguising errors:\n\n```elixir\ndefmodule Visibility do\n  @spec parse(term()) :: {:ok, :public | :private} | {:error, :invalid_visibility}\n  def parse(\"public\"), do: {:ok, :public}\n  def parse(\"private\"), do: {:ok, :private}\n  def parse(_), do: {:error, :invalid_visibility}\nend\n```\n\nThe final clause returns an explicit expected failure. Internal callers can pattern-match the result without rescuing exceptions or silently selecting a default.\n\n## Checklist\n\n- Verify Elixir\u002FOTP compatibility and supported library APIs.\n- Keep process boundaries motivated by concurrency\u002Flifecycle, not code organization.\n- Check expected failures, compiler warnings, atom handling, and boundary validation.\n- Check task links, bounded work, timeouts, duplicate effects, and transaction limits.\n- Use installed formatter, `mix compile --warnings-as-errors`, ExUnit, and existing analysis tools when authorized. Format checks alone do not prove compilation or behavior; use async tests only when their shared resources are isolated.\n\n## References\n\n- [Elixir stable documentation](https:\u002F\u002Felixir-lang.org\u002Fdocs\u002F) and [1.20 typing release](https:\u002F\u002Felixir-lang.org\u002Fblog\u002F2026\u002F06\u002F03\u002Felixir-v1-20-0-released\u002F)\n- [Elixir 1.20 OTP requirements](https:\u002F\u002Felixir.hexdocs.pm\u002F1.20.0\u002Fchangelog.html)\n- [Official code anti-patterns](https:\u002F\u002Felixir.hexdocs.pm\u002Fcode-anti-patterns.html)\n- [Task ownership and concurrency](https:\u002F\u002Felixir.hexdocs.pm\u002FTask.html)\n- [GenServer call semantics](https:\u002F\u002Felixir.hexdocs.pm\u002FGenServer.html) and [supervision policies](https:\u002F\u002Felixir.hexdocs.pm\u002FSupervisor.html)\n- [Ecto changesets](https:\u002F\u002Fecto.hexdocs.pm\u002FEcto.Changeset.html) and [transactions with Multi](https:\u002F\u002Fecto.hexdocs.pm\u002FEcto.Multi.html)\n- [Phoenix scopes](https:\u002F\u002Fhexdocs.pm\u002Fphoenix\u002Fscopes.html)\n- [LiveView async operations and streams](https:\u002F\u002Fphoenix-live-view.hexdocs.pm\u002FPhoenix.LiveView.html)\n",{"name":5,"rules":51,"title":54,"domains":41,"license":14,"description":7,"compatibility":55},[52,53],"file(mix.exs)","content(elixir)","Elixir Development Best Practices","Requires Elixir and Erlang\u002FOTP.","master","e9e4a19559669b1627b1ac5ed3f77b8e36cfad95","skills\u002Fprogramming-elixir",0,"https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap","https:\u002F\u002Foctomind.run\u002Ftap\u002F","https:\u002F\u002Fgithub.com\u002FMuvon","https:\u002F\u002Fmuvon.io","We bring ideas to life","2026-11-13 13:19:02",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add Muvon\u002Foctomind-tap --skill programming-elixir",{"tool":72,"command":73},"bunx","bunx skills add Muvon\u002Foctomind-tap --skill programming-elixir",{"tool":75,"command":76},"pnpm","pnpm dlx skills add Muvon\u002Foctomind-tap --skill programming-elixir","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fprogramming-elixir\u002FSKILL.md",true,[80],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"validate","OTHER","其他",97,"https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fprogramming-elixir\u002Fvalidate",[87,123,150,170,194,220],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":102,"publishedAt":46},"01M70SFC5CTHRKA9B97N1ARVZ2","seo-content-refresh","Finds decaying pages, picks update, merge, redirect or remove, and briefs each refresh. Use to prioritize existing content and judge whether it helped.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fseo-content-refresh\u002FSKILL.md",[93,98,101],{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000019","营销推广","SCENARIO","使用场景",{"categoryNo":99,"categoryName":100,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000035","市场营销",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"seo content refresh","seo","seo content","content refresh","refresh","content","posts","remove","web search","performance","search","traffic","access","drop","websearch","revamp","merge","diagnosis","update","decay",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":131,"publishedAt":46},"01M70SBWQCHGH7HGS51Y0GTKKW","marketing-review-program","Plans how to ask real customers for honest public reviews: site choice, invitation copy, incentive and disclosure rules. Use to start a review program.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fmarketing-review-program\u002FSKILL.md",[129,130],{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},{"categoryNo":99,"categoryName":100,"taxonomyType":20,"taxonomyTypeDesc":21},[132,133,134,135,136,137,111,113,138,139,140,141,142,143,144,145,146,147,148,149],"program","review","marketing review program","marketing","reviews","get","campaign","choice","how to","only","generated","ask","plan","product","generate","customer","how","request",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":46},"01M70SBB65Z2FC71Q7DEAXGJBG","geo-source-actions","Turns AI citation findings into ranked per-source actions for Reddit threads, listicles, review sites and videos. Records only. Use after a GEO audit.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fgeo-source-actions\u002FSKILL.md",[],[157,158,159,160,161,137,111,113,162,163,141,117,133,164,165,166,145,167,168,169],"actions","geo source actions","source","geo","sources","copilot","domains","llms","threads","youtube","audit","action","data",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":179,"publishedAt":46},"01M70S99D3Y6GF097GTXWBXHPW","commerce-ai-readiness","Audits product feeds, markup and live pages for AI shopping assistants, then lists exact fixes. Use to make a store catalog readable to AI shoppers.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fcommerce-ai-readiness\u002FSKILL.md",[176],{"categoryNo":177,"categoryName":178,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000031","产品经理",[180,181,182,183,184,185,186,187,188,189,113,190,162,141,115,191,192,145,167,193],"ai readiness","commerce ai readiness","commerce","readiness","feeds","ready","show","shopping","discover","checkout","up","ecommerce","documentation","recommend",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":203,"publishedAt":46},"01M6DWSX45J42KTK6XASKJRGPA","tap-model-training","Train, evaluate and publish the octomind-embed model behind capability auto-activation. Use when capability triggers or skill semantic() phrases change.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Ftap-model-training\u002FSKILL.md",[200],{"categoryNo":201,"categoryName":202,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000023","Skill与智能体开发",[204,205,206,207,208,190,209,210,211,212,213,214,215,216,217,148,218,219,30,121],"model","training","tap","tap model training","scope","eval","uv","auto","dataset","activate","api","capabilities","publish","change","embedding","re",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":227,"publishedAt":46},"01M6DWSQB7NSW53Z86XM81R1W1","tap-deps-authoring","Write dep scripts for the octomind-tap registry: header comments, platform.sh, mcp vs dep types, npx\u002Fuvx pattern. Use when editing deps\u002F\u003Corg>\u002F\u003Ctool>.sh.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Ftap-deps-authoring\u002FSKILL.md",[226],{"categoryNo":201,"categoryName":202,"taxonomyType":96,"taxonomyTypeDesc":97},[228,206,229,230,231,232,233,234,42,235,236,237,238,239,240,241,30,242,243,244],"deps","tap deps authoring","authoring","DEP","MCP","run","scripts","install","registry","platform","repo","editing","tool","types","write","org","for"]