Split public vs internal skill packs for safer teammate onboarding

[lmeyerov]

Problem

The repo currently mixes user-facing skills and internal workflow skills in the same install surface. New teammates can unintentionally install internal-only skills (plan, eval-otel) when using generic skill install commands.

Why this matters

For initial adoption and contribution onboarding, we need a clear public skill pack boundary so users get only product-facing skills by default.

Scope

• Define and enforce a public skill pack (pygraphistry user skills) vs internal pack (team workflow/ops skills).
• Update install docs and CI to validate public-only install path.
• Preserve internal skills for team usage without exposing as default external install set.

Proposed implementation options

1. Move internal skills to a separate top-level internal directory not used by public installer flows.
2. Keep directory layout but add explicit packaging manifests/profiles and default to public-only profile.
3. (If needed) split into separate repos once structure and CI are stable.

Acceptance criteria

• Default documented install flow pulls only public skills.
• CI has a check that public install does not include internal skills.
• Internal skills remain available for core team workflows.

Related

• plans/pygraphistry-skills/findings/35-external-skills-repo-audit-supabase-databricks.md