{"id":19916,"plugin_id":"plugins_6aa18553c9cc8191b84488f479859228","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:15:57.311Z","digest":"c18707766cd1a9f50c72da1cc62f125b84e0e3b23a50e2979e402d3a33940146","against":null,"payload":{"name":"workflow-to-skill-compiler","description":"Use when a repository has a valuable agentic workflow, prompt chain, playbook, command, or runbook that should become a portable ChatGPT/Codex Skill without losing its real decision logic.","included_files":[],"skill_md_contents":"---\nname: workflow-to-skill-compiler\ndescription: Use when a repository has a valuable agentic workflow, prompt chain, playbook, command, or runbook that should become a portable ChatGPT/Codex Skill without losing its real decision logic.\n---\n\n# Workflow to Skill Compiler\n\nConvert source workflows into portable Skills. Preserve behavior, not file shape.\n\n## Compilation rules\n\n1. Define one user job for the Skill. If the source mixes unrelated jobs, split it before conversion.\n2. Trace the source workflow from trigger to evidence, decisions, actions, validation, and stop conditions.\n3. Write Skill metadata for discovery. The `description` must say when to use the Skill, not merely what topic it contains.\n4. Keep the main `SKILL.md` focused on execution. Move deep reference material into `references/` and deterministic mechanical helpers into `scripts/`.\n5. Replace source-repository assumptions with portable contracts. Remove absolute paths, personal machine locations, private aliases, hidden environment assumptions, and undocumented dependencies.\n6. Preserve meaningful gates. Do not flatten approval, safety, testing, evidence, or verification steps just to make the Skill shorter.\n7. Prefer host capabilities over unnecessary bundled runtime code. Add MCP only when the workflow genuinely needs external data/actions that cannot be represented honestly as Skill guidance.\n8. Keep tool names capability-oriented where possible so the Skill can travel across compatible hosts.\n9. When the workflow touches files, repositories, generated artifacts, or local workspace state, integrate the `host-workspace-operator` contract. Prefer read/list/search/grep for discovery, patch/write only for authorized mutations, shell for repository commands, and `sandbox-python-executor` for deterministic Python work.\n10. Add `agents/openai.yaml` only when interface metadata, product targeting, invocation policy, icons, or documented MCP tool dependencies materially improve the Skill. Do not invent dependencies for host-native filesystem, shell, patch, search, or Python tools.\n11. Run public-distribution review before packaging. Internal workflows may contain capabilities that should never be mirrored into a public Skill.\n\n## Workspace-capability compilation\n\nWhen the source workflow includes operations such as:\n\n- reading files\n- listing directories\n- searching concepts or filenames\n- exact grep/regex lookup\n- creating or editing files\n- applying focused patches\n- running tests or repository commands\n- deterministic Python/file processing\n\nrepresent those operations as host-native capability requirements in the Skill instructions. Do not hard-code one product's tool names unless the current host contract requires it.\n\nFor generated Plugins, the main Autopilot should install the canonical workspace Skill with:\n\n```bash\npython3 <autopilot-skill>/scripts/install_host_workspace_skill.py <target-plugin>\n```\n\nThe installer is intentionally non-destructive. If the target already contains a customized `host-workspace-operator`, review it instead of overwriting it.\n\n## Quality gate\n\nReject the compilation if:\n\n- it is mostly a pasted prompt with no operating logic\n- it cannot explain its trigger and completion condition\n- it depends on files that will not exist after installation\n- it silently drops source validation or approval gates\n- multiple Skills are near-duplicates with different names\n- the Skill description is so broad that it will collide with unrelated workflows\n- generated instructions claim tools or permissions the Plugin does not actually provide\n- mutation operations are mixed into read-only discovery without a clear authorization boundary\n- the Skill says it searched, read, wrote, patched, ran shell, or executed Python without host evidence\n\n## Handoff\n\nAfter compilation, pass the Skill set and its workspace-capability needs to `plugin-experience-architect`. The experience brief should state which host-native operations the Plugin benefits from and which are mutation-capable. Then run the main Autopilot generation and validation gates.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}