Update to OmniSkill

{
  "description": "Port an agent Skill across ChatGPT, Codex, Claude, API agents, or another compatible host without losing its decision logic, evidence gates, activation boundary, or completion conditions. Use when a Skill is tied to one vendor's paths, tool names, keys, hooks, subagents, packaging, or runtime assumptions and needs a portable core plus host adapters. Do NOT claim a host is behaviorally supported unless that host was actually tested.\n",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 275
    }
  ],
  "name": "skill-portability-compiler",
  "skill_md_contents": "---\nname: skill-portability-compiler\ndescription: >\n  Port an agent Skill across ChatGPT, Codex, Claude, API agents, or another compatible host without losing its decision logic, evidence gates, activation boundary, or completion conditions. Use when a Skill is tied to one vendor's paths, tool names, keys, hooks, subagents, packaging, or runtime assumptions and needs a portable core plus host adapters. Do NOT claim a host is behaviorally supported unless that host was actually tested.\n---\n\n# Skill Portability Compiler\n\n> Separate behavior from host mechanics, then adapt only what truly differs.\n\n## Why This Skill Is Needed & Target State\n\n**Why this skill is needed:** Skills frequently become tightly coupled to specific vendor runtime quirks (e.g. Claude Code tool names, Cursor rules syntax, Codex plugin schemas). When porting to another agent, authors often rewrite the entire skill by hand, introducing behavioral discrepancies and losing core evidence gates.\n\n**Target state:** The core behavioral logic, decision gates, and domain invariants remain vendor-neutral, while host-specific adapters automatically bridge runtime differences while documenting and testing behavioral differences.\n\n## Step 1: Extract the portable core\n\nRead the source Skill and classify each element as:\n\n- activation metadata\n- behavioral rule\n- domain knowledge\n- decision policy\n- evidence gate\n- deterministic mechanic\n- reference material\n- host-specific syntax\n- environment assumption\n- packaging metadata\n\nPreserve the first seven in the portable core unless they are unsafe or obsolete\n\n## Step 2: Find host coupling\n\nSearch for:\n\n- vendor names in required instructions\n- hard-coded tool function names\n- fixed install paths\n- environment variables\n- required API keys\n- hook syntax\n- subagent syntax\n- model-family assumptions\n- package/manifest fields\n- shell commands that presume one runtime\n\nFor each coupling ask: does the user job require this, or is it only one implementation path\n\nMove implementation-only coupling into an adapter\n\n## Step 3: Build the capability matrix\n\nRead `../omni-skill/references/host-adapters.md`\n\nFor every target host record:\n\n- capability required by the Skill\n- capability known to exist\n- evidence source\n- adapter needed\n- fallback behavior\n- test status\n\nUnknown is not supported\n\n## Step 4: Compile adapters\n\nKeep adapters small\n\nAn adapter may define:\n\n- installation layout\n- manifest metadata\n- invocation or lifecycle conventions\n- mapping from abstract capability to real host tool\n- script runtime differences\n- resource loading differences\n\nDo not copy the entire core into every adapter\n\n## Step 5: Remove false dependencies\n\nA valid portable Skill must not require:\n\n- an Anthropic key only because one historical evaluator used Anthropic\n- `uv`, Node, Bun, or Python unless the actual Skill job needs that runtime\n- filesystem or shell permissions merely because one host offered them\n- MCP when instructions and host-native tools are sufficient\n\nIf a deterministic helper genuinely requires a runtime, declare it as a capability requirement and provide an honest fallback or unsupported status\n\n## Step 6: Re-test activation and behavior\n\nStructural translation is insufficient\n\nFor every target host claimed as tested, rerun:\n\n- positive activation\n- negative activation\n- critical behavior assertions\n- failure paths\n- pressure cases where relevant\n\nRecord host and model details when exposed\n\n## Step 7: Assign host status\n\nUse exactly one:\n\n- `SUPPORTED_TESTED`\n- `SUPPORTED_STRUCTURAL_ONLY`\n- `ADAPTER_REQUIRED`\n- `UNSUPPORTED`\n- `UNKNOWN`\n\nIf only static translation was done, use `SUPPORTED_STRUCTURAL_ONLY`\n\n## Output contract\n\nReturn:\n\n1. portable core summary\n2. removed host assumptions\n3. capability matrix\n4. adapter files or patch plan\n5. behavior preserved checklist\n6. host-by-host test evidence\n7. portability status per host\n8. unresolved gaps\n"
}