Wonbeen Lee wbeen / AI Product Ops notebook
Operating index
← All skills

publish & operate · operating skill

Public-safe Publishing

Check boundary, metadata, links, generated outputs, and live evidence before a public asset is treated as published.

beta v0.1.0 either invocation verified 2026-08-08
Download .md

The copied instruction points your AI to a self-contained public Skill Bundle. You can stay on this human-readable page; opening raw source is optional.

When to reach for it

  • A reviewed asset is ready to move into a public content layer.
  • The asset has public/private boundaries, metadata, links, and generated representations.
  • Publication needs a repeatable evidence-backed release decision.

Do not use when

  • The asset is still ambiguous, sensitive, or awaiting an owner decision.
  • The request is to publish private/team/company material or executable distribution.

Inputs

  • Reviewed content asset
  • Public/private boundary decision
  • Metadata and relation requirements
  • Canonical build and live verification commands

Outputs

  • Published public asset
  • Generated mirrors or indexes updated by canonical scripts
  • Release evidence and residual limitations
  • Explicit blocked result when a gate cannot be verified
Compatible agents
ChatGPTClaude CodeCodexHermes Agent

What it does

Public-safe Publishing is a release gate for a reviewed asset. It checks that the content boundary, metadata, relations, generated representations, and live behavior agree before publication is treated as complete.

When to reach for it

Use it when a public-ready asset is about to move from staging or a working branch into a public site, feed, mirror, or other explicitly public surface.

What one run does

  1. Confirm the accountable owner and public boundary.
  2. Run sanitization and content validators.
  3. Regenerate mirrors and machine-readable outputs through canonical scripts.
  4. Build and inspect critical routes and links.
  5. Record evidence, limitations, and the release decision.

Common failure modes

  • Treating a draft approval as proof that generated outputs are safe.
  • Hand-editing a mirror instead of regenerating it from source.
  • Assuming a successful build proves the live route is correct.
  • Publishing ambiguous material because the release deadline is near.

It’s working if

The release can be reproduced from public source, every critical check has evidence, and a reviewer can see exactly why the asset is safe to publish.

Where it fits

This is a Publish & Operate-phase skill. It follows clarification, execution, and evidence-first review; it is an editorial release boundary, not an executable package installer or marketplace workflow.

Verification

  • Public/private checks pass for source and generated outputs.
  • Canonical build and validators pass with a clean working tree.
  • Critical public routes and machine-readable endpoints resolve.
  • The release record states what was verified and what was not.

Guardrails

  • Never publish content merely because it is well-written or machine-generated.
  • Do not bypass sanitization, generated-output, or live-route checks.
  • Keep private registry, credentials, internal paths, and company source outside the public layer.
  • Report blocked verification instead of substituting assumptions.