skill-porting-and-publishing

Topics in the source

• Skill porting and publishing
• When to Use
• 1. Decide the canonical side before writing a file
• 2. Read the target repo's contracts before writing
• 3. De-couple on five axes
• Configuration is a gate, not advice
• 4. Delegate the mechanical port, verify it yourself
• 5. Swap the runtime over without a gap

Move a skill that grew inside a private runtime into a shared, publishable repo, and make that repo the single source afterwards. Applies to any skill that has to survive leaving one machine: agent roles → roles, home paths → env vars, one vendor CLI → a documented contract, private repos → nothing. "refactor this skill and port it to ", "make it runtime-agnostic", "publish this skill". Any skill whose body names a person, a machine path, a model id, a private repo, or a bot product. A batch port whose reviewer needs one report: source → target, files, sections, demotions. Not for: rewriting a skill's methodology (that is curation/audit territory), or a one-off doc edit in a repo that already owns the file. When the destination repo's own contract governs skill ownership and placement, decide repo-owned vs general capability first; porting a general capability into a project repo pollutes it just as badly as leaving repo-bound methodology outside. One copy, and it lives where future readers will find it. Default for a publishable collection: the public repo is canonical, the runtime's skill directory becomes a symlink into it, and anything machine-specific lives in a directory the

This is an excerpt. Refer to the complete source and its current requirements.