Turn a personal-use Skill that contains personal experience, local configuration, or real data into a public candidate that others can use immediately and that does not leak the maintainer's privacy. Core principles:The public layer keeps only reusable mechanisms; personal facts go in the private layer; conclusions bind to real candidates; external actions do only the step the user has explicitly authorized。
This skill is a process-orchestration layer: use skill-creator for producing and validating structural compliance, skill-lint's modular rules for acceptance, git-workflow for Git/PR/privacy prechecks, and release-workflow and skill-publish-sync for version assets and platform sync. Do not duplicate the detailed rules they already maintain; only chain the steps together in the publicization scenario.
When to read which reference
| Current stage | Read |
|---|---|
| Before starting: determine goals, write scope, authorization, and risks | Publicization design precheck |
| Split into three layers: generic/example/private; design the configuration contract | Layering and configuration contract |
| Strip personal experience file by file; design placeholders and a registry | Stripping personal experience |
| Align version, CHANGELOG, README, and release fields | Version and index sync |
| Run static gates, tests, and privacy checks | Pre-release gates |
| Execute external actions such as PR/migration/platform upload | Release execution and authorization boundaries |
| Reusable checklist requiring three cases | Case checklist |
Shared constraints
- Precheck before acting: Before any stripping or refactoring, complete the design precheck; when goals, write scope, and actions are already explicitly authorized, record them and execute directly, asking only for missing information that would still change the plan.
- Single source for personal use and public release: By default, do not maintain two implementations, a "personal version" and a "public version"; put personal differences in local configuration or a data directory, and build release candidates from the same source. Exceptions must record the reason and the sync responsibility for the two sources.
- Same source still requires checking feature scope: One source does not mean the release artifact can be arbitrarily trimmed; first check the features and compatibility entry points the user has confirmed. When personal use and public release are required to be consistent, the allowlist should cover the full generic functionality, excluding only personal configuration, runtime state, and internal maintenance materials; if personal hardcoding is found, make it configurable rather than evading remediation with a separate trimmed package.
- ignore does not untrack tracked files: Writing a file into
.gitignoredoes not remove an already tracked file from version control; if local configuration was once tracked, save a copy first, then untrack it item by item, with path-based hard exclusion in the release package as a fallback. - Dual-channel protection: Version-control ignore rules block commits, and the release package allowlist blocks packaging; both are required, and both need regression verification (including positive and negative cases).
- Static checks are a lower bound: Passing security scans, link checks, and example validation does not mean semantic privacy has been eliminated or behavior has been accepted; independent review and real verification by artifact type cannot be skipped.
- Structural validation must first align with the target specification: Different repositories have different legal locations for
version、authorand other release fields. Before usingquick_validate, first read the target project's release specification and skill-lint'sreferences/frontmatter-metadata-policy.md; fields required by the project specification must not be deleted just because a general-purpose validator's allowlist is narrower. When tools are incompatible, the target repository's structural rules take precedence, and record NOT_VERIFIED. - Tiered authorization for external actions: Organizing, layering, and writing tests are work that can be advanced autonomously; for push, PR, merge, platform upload, public repository migration, and tag/Release, separately verify whether the authorization already present in the session covers the current target, write scope, and action; authorization remains valid, and only ask again when it is missing or the target changes; completion of the previous step does not imply the next step.
- Candidate-bound evidence: All passing conclusions are bound to the current candidate OID/hash; after the candidate changes, rerun the affected checks and do not reuse old evidence.
Main flow
- Precheck: Fix the target Skill, target form (public repository directory/standalone repository/platform package), current version and baseline, allowed write scope, and stop conditions. Identify known risk categories (see the risk table in the precheck reference), and if necessary first ask the user to adjudicate high-risk items.
- Authoritative repository adjudication: When migrating a private repository Skill into a public repository, first confirm in the precheck whether the public repository directory is the "authoritative source" or an "export snapshot of the same source code," and write it into the precheck output. The gate artifacts differ for the two forms: an authoritative public repository source must synchronize the README and suite index according to the public repository project specification; an export snapshot must state the source OID, manifest, and synchronization direction in the CHANGELOG/task record, and the public repository directory must not independently change the implementation. This step only determines scope and does not produce external writes.
- Layering: Classify files into the general layer (committed), the example layer (committed
*.example.*and schema), and the private layer (local data, not committed). Design the configuration contract: parsing order, default behavior, bad-configuration handling, and validation entry point. - Stripping: Process personal experience file by file—placeholder-ize, generalize, structure (write as steps/criteria rather than narrative), or move entirely into the private layer. Clarify licensing and external sources first; third-party materials are deleted, replaced, or annotated according to the user's adjudication.
- Synchronize version and index：
SKILL.mdversion, latest CHANGELOG entry, README index (including the recent updates section), and release fields (license/homepage/author) aligned at once; CHANGELOG historical entries are likewise de-specified. - Gate: Static security scan, Harness failure review, quick_validate, links/references, examples against schema, ignore positive and negative cases, and (if there are scripts) offline tests. Write evidence into the task card.
- Forward check: Complete isolated installation and first-time configuration according to the public usage instructions; select the remaining checks according to the candidate's actual capabilities, seecapability applicability table. Record nonexistent capabilities as "not applicable" and state the basis; record applicable but unexecuted items as
NOT_VERIFIED, and state the blocking scope and recovery conditions item by item. - Independent review: Assign a read-only reviewer with no prior context to provide structured findings; the PM independently accepts, and does not rely on self-reports.
- Execution and closure: According to authorization, proceed through safe-push → safe-pr (Draft) → merge/migration/platform upload; write back task status and evidence, and clearly identify NOT_VERIFIED items.
Definition of done
Publicization preparation phase complete = layered implementation with positive and negative example verification, personal anchors cleared or exemption registered, version references consistent, all key gates executed and passed, independent review with no open blocking items, task card records evidence.
Gates fall into two categories:
- Key gates: static security scan, privacy check, applicable behavior verification, real artifact generation, version and index consistency. If a key gate is not executed or not passed, the publicization preparation phase remains incomplete and must not be overridden with
NOT_VERIFIED. - Other applicable gates: links/references, examples and schema, ignore positive and negative examples, platform or Runtime coverage of extensions, etc. If not executed, record
NOT_VERIFIED, and state the scope it does not block and the recovery conditions; it blocks release or stability statements that depend on that conclusion.
Items judged as "not applicable" per the capability applicability table are not NOT_VERIFIED, nor do they block any conclusion, but the basis for the judgment must be stated.
Complete does not equal published—before formal release, candidate binding evidence acceptance must still be completed per skill-lint; release is based on real remote receipts/platform receipts and must be within the scope the user has authorized.
Boundaries
- Does not replace skill-lint's formal acceptance, git-workflow's Git gates, or each platform's release contract.
- Does not automatically scan the entire disk for privacy; bounded by the current candidate file list and the context specified by the task.
- Binary and non-UTF-8 materials go through git-workflow's privacy pre-check manual review path; this skill does not invent a skip switch.
- Follow minimal necessity when handling legal/customer materials; information that cannot be confirmed as real is treated as suspected specific information.
Dependencies required by phase
skill-creator: Skill editing and structure validation;skill-lint: quality/privacy/candidate evidence review.git-workflow: Git commit, push, PR, identity and full history pre-check.release-workflow: required only when building a release package or Release;skill-publish-sync: required only when uploading to the target platform.
First confirm that the corresponding skills and execution tools are available; when missing, pause the phase that depends on them and state the gap, retaining the organization work that can be completed independently. This skill does not embed the above scripts, nor does it guarantee that copying its directory alone is sufficient to complete Git/platform operations. Usage instructions within the Skill are written in SKILL.md and on-demand references; README refers only to the external index of the target repository or suite.