yao-open-skills-sync

name	yao-open-skills-sync
description	Manage the yao-open-skills public collection. Use this skill whenever the user wants to evaluate whether a local skill should be open sourced, import a local skill into the yao-open-skills repository, register which skills are already public, track GitHub sync status, or update the collection README and catalog after adding or refreshing a skill.

Yao Open Skills Sync

Use this skill to manage the public yao-open-skills collection in the current repo root.

This skill is not for creating arbitrary new skills from scratch. It is for intake, governance, sync tracking, and collection maintenance.

Read First

Before changing the collection, read:

• references/operating-rules.md
• references/registry-schema.md

Only read repo-wide docs under ../../docs/ if you need more human-facing detail after reviewing the references.

Primary Responsibilities

• Evaluate whether a local skill is suitable for public release
• Create a clean public copy under skills/<slug>/
• Register or update the skill in registry/skills.json
• Add or update a human-facing usage guide under docs/skills/<slug>.md
• Regenerate the README catalog and HTML navigation page so the collection homepage stays in sync
• Record whether the skill is only local, staged, published, or needs an update
• Push collection changes to GitHub when the user wants the public repo updated

Workflow

1. Inspect the source skill

Given a local path from the user:

• Confirm the path exists
• Inspect SKILL.md
• Identify what should be kept, removed, or rewritten for public release

Watch for:

• output/, downloads/, .venv/, node_modules/, caches, logs
• generated reports, exported results, .command helpers, and local scan artifacts
• private APIs, tokens, cookies, internal references, customer data
• assets or references that may not be redistributable

2. Decide whether it can be public

Use the publishing rules:

• If the skill can be cleaned into a self-contained public version, proceed
• If it mixes public logic with sensitive material, split the public part from the private part
• If it cannot be safely cleaned, stop and explain why it should not be published

3. Import the public copy

When approved:

• Copy the public version into skills/<slug>/ under the repo root
• Keep only the files needed for the public skill
• Make the structure self-contained and understandable
• Exclude local output artifacts by default unless the user explicitly wants a safe sample included

4. Register the skill

Upsert the registry entry using:

python3 scripts/register_skill.py \
  --slug <slug> \
  --title "<title>" \
  --summary "<summary>" \
  --source-local-path "<absolute-source-path>" \
  --collection-path "skills/<slug>" \
  --lifecycle active \
  --sync-status <local-only|staged|published|needs-update> \
  --github-repo yao-open-skills \
  --github-url "<url-if-known>" \
  --license "<license>" \
  --tags "tag1,tag2"

Use --last-synced-at YYYY-MM-DD only when the skill has actually been pushed to GitHub.

5. Update the README catalog

After every registry change, run:

python3 scripts/render_collection_pages.py

README and index.html are rendered views. Do not maintain the catalog table or HTML Skill cards manually.

5.5 Write the usage guide

For every published skill, add or update:

docs/skills/<slug>.md

The guide should explain:

• what the skill does
• when to use it
• the main workflow
• important inputs and outputs
• any local-only outputs that should not be committed back into the repo

6. Publish to GitHub when requested

If the user wants the collection pushed:

• ensure the public files, registry, and README are already consistent
• ensure index.html is regenerated from the registry
• commit the current repo changes with a clear message
• push to the configured yao-open-skills GitHub repository
• only after a successful push, mark relevant skills as published and set last_synced_at

If the public repo exists but the local collection has new unpublished changes, use needs-update until the push is complete.

7. Report the result

Always report:

• whether the skill was accepted for the public collection
• the final collection path
• the registry status you wrote
• whether GitHub publication is still pending
• what still needs manual confirmation, if anything

Output Expectations

When this skill completes a sync task, the result should leave the collection in a consistent state:

• public files exist under skills/<slug>/
• registry/skills.json is up to date
• README.md catalog and index.html navigation page match the registry
• if a push was requested, the GitHub repo reflects the same state

Decision Rules

• Prefer stable, explanatory slugs in kebab-case
• Do not publish raw private source directories without cleaning them
• Do not mark a skill as published unless it has actually been synced to GitHub
• If a published skill's source has changed locally, set sync_status to needs-update