Public documentation v0.1.0
Public vs private boundary
Public docs explain the product and release artifacts without exposing private operational state.
Public-safe content
Public docs may include public GitHub repository URLs, public tags and release names, role boundaries and workflows, install and upgrade commands, license information, summarized validation results, and known public limitations.
Private content to exclude
Public docs and generated profile repositories must not include credentials, tokens, keys, local runtime state, logs, memories, sessions, Kanban databases, workspace paths, run metadata, internal task identifiers, private notes, sprite credentials, SSH keys, OAuth tokens, API keys, .env files, or private deployment details users do not need.
Project-specific skill guidance
Project-specific skill instructions, examples, checklists, routing notes, customer or tenant conventions, and other scoped guidance belong in local profile-managed skills, not in published/shared skills, unless they have been generalized and passed normal review and publication gates.
How to describe internal workflow safely
Use conceptual language rather than private identifiers. Say approved release handoff instead of exposing internal board IDs or local workspace paths; say scoped publisher credentials instead of showing where a token was staged.
Release-note redaction rule
Release notes should describe user-visible changes, migration notes, validation summaries, and known limitations. They should not include raw logs, private task IDs, local paths, credential handoff details, or unapproved internal URLs.