# Agent Workflow Bundle — Turn a working conversation into a public asset > Self-contained build artifact generated from the canonical public Workflow and its referenced public assets. ## Agent instruction Use this bundle as the operating procedure for the user’s task. Execute the ordered steps end-to-end and apply each embedded asset where it appears. Do not merely summarize the workflow. Do not claim completion until the workflow’s success signal and embedded verification requirements have been checked. Everything required by the public workflow is embedded below; do not make the user manually provide the referenced Skill, Prompt, or Template files again. ## Workflow contract - source: workflows/turn-conversation-into-public-asset - canonical human page: https://wbeen-personal-kb.vercel.app/workflows/#workflow-turn-conversation-into-public-asset - lifecycle: stable - version: 1.0.0 - intended outcome: A reusable public asset is produced without treating the private conversation itself as publishable source material. - success signal: The published asset is useful without exposing private conversation context, credentials, local paths, or source-only notes. ### Known limitations - This workflow does not publish automatically. - The source conversation must be reviewed; extraction is not permission to disclose it. ## Ordered execution ## Step 1 — execute **Action:** Extract a reusable source candidate from the conversation **Why now:** Keep the conversation itself private **Embedded asset:** skills/conversation-to-source — Conversation-to-Source Turn a long AI conversation into distinct public-ready source candidates while preserving sensitivity boundaries and review decisions. ### Inputs - Conversation export or working notes - Intended audience and publishing boundary - Candidate asset types to look for ### Outputs - One candidate source per reusable asset - Sensitivity and review classification - Evidence pointer back to the source material - Unresolved items requiring human review ### Guardrails - Generalize or omit private, client, company, and personal details. - Classify ambiguity as review rather than silently publishing it. - Preserve enough provenance to re-check the extracted candidate. - Never treat extraction as publication approval. ### Verification - Every candidate has a declared sensitivity state. - A reviewer can trace the candidate to its source location. - Private or ambiguous material is excluded from public output. ### Source instructions ## What it does Conversation-to-Source separates reusable public-source candidates from the private conversation that produced them. It treats extraction as a classification and review step, not as automatic publishing. ## When to reach for it Use it after a long AI-assisted working session when decisions, insights, workflows, or templates are useful beyond the original context and need a safer source boundary. ## What one run does 1. Identify reusable assets and describe their intended audience. 2. Create one candidate source per asset instead of copying the transcript. 3. Attach sensitivity and review status to every candidate. 4. Preserve a source pointer and unresolved questions. 5. Hand candidates to a scoped review or publishing step. ## Common failure modes - Treating a coherent conversation as automatically public. - Copying names, internal systems, credentials, or personal details into a candidate. - Losing provenance so a reviewer cannot re-check an extraction. - Publishing the candidate before a human boundary check. ## It’s working if A reviewer can understand each candidate without the private transcript, see its sensitivity classification, and trace it back to evidence when needed. ## Where it fits This is an **Execute**-phase extraction skill. It sits before Scope & Acceptance Criteria and Public-safe Publishing, which decide whether a candidate is ready for a specific public outcome. ## Step 2 — clarify **Action:** Check what can be generalized and published **Why now:** Reject private-only source material **Embedded asset:** templates/public-private-boundary-checker — Public/Private Boundary Checker A pre-publish checklist that catches company, client, and personal context before anything ships to the public layer. ### Sections - No company-internal information - No client, partner, or personal names - No internal URLs, tickets, or system names - No personal finance/health/family details - Numbers and dates are safe to publish - Quotes are short and attributed - visibility is public or generalized - sourceSensitivity is public or generalized - Safe for the AI-readable export - All related links point to public content ### Source instructions ## When to use Run this checklist against every content item before it moves from staging to the public site — no exceptions, including AI-generated drafts. ## Checklist 1. No company-internal information (roadmaps, metrics, systems). 2. No client, partner, or personal names. 3. No internal URLs, tickets, or system names. 4. No personal finance/health/family details. 5. Numbers and dates are safe to publish. 6. Quotes are short and attributed. 7. `visibility` is `public` or `generalized`. 8. `sourceSensitivity` is `public` or `generalized`. 9. Safe for the AI-readable export (`/llms-full.txt`, `/md/`). 10. All related links point to public content. ## Related prompt Conversation-to-Source Extractor — classify assets before this checklist sees them. ## Step 3 — publish-operate **Action:** Publish the reviewed public-safe asset **Why now:** Keep machine-readable mirrors aligned **Embedded asset:** skills/public-safe-publishing — Public-safe Publishing Move a reviewed public-ready asset through a repeatable publishing gate without leaking private context or overstating verification. ### 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 ### 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. ### 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. ### Source instructions ## 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. ## Workflow completion The workflow is successful when: The published asset is useful without exposing private conversation context, credentials, local paths, or source-only notes. Report the task result, the evidence used to verify it, and any unresolved limitation. If a required verification step cannot be performed, say so instead of treating the workflow as complete.