Dev To Publish

---
name: dev-to-publish
description: Turn project work into personalized, channel-specific publication packages and deliver reviewed posts through Buffer API. Use for preparing product demos, adapting project artifacts for social channels, or publishing an approved package.
---

# Dev to Publish

Work from the source project's context. Inspect applicable project instructions and existing publication tooling. Reuse the user's chosen footage, facts and approved preferences. Separate personal style, production method and delivery adapter.

If setup is missing, collect the minimum inputs: destination channels/accounts, language/audience, project/source material, optional music/branding/templates, local archive, representative content and the Buffer credential variable name. Ask for paths or supported attachments, not secrets in chat. Check actual access before claiming a capability works.

## Personalize

Use accessible user-selected examples and a bounded sample of their posts. Record scope, gaps, sources and confidence. Distinguish explicit preferences from observed patterns and proposals. Keep personal profiles, credentials and media outside the public repo. Incorporate reusable feedback with its reason; keep one-off edits on the package.

## Prepare

Read [demo-method.md](references/demo-method.md) when composing a demonstration, and [channels.md](references/channels.md) for the selected destinations. Preserve real product behavior and attribution. Verify current destination requirements through official docs or live capabilities. Select a working renderer available in the environment; retain its recipe and local masters.

Create one content record with source evidence and separate versioned packages per destination. Each package includes the exact caption, media/cover, account, format, timing and delivery assets. Verify and show the actual preview. Preparation alone does not authorize publishing.

## Deliver

Read [buffer.md](references/buffer.md) when using Buffer. The user must authorize the concrete package/account/timing, or have already granted a policy covering it. Do not manufacture approval to satisfy the CLI. Reuse existing authorization while the approved scope remains unchanged.

Use a shared receipt directory across chats. Dry-run before a write, bind approval to the package hash, preserve provider IDs and reconcile uncertain submissions before retrying. Treat draft, scheduled, processing and published as separate states. Inspect the live URL when available and archive the receipt. Do not start recurring or unattended publishing merely by installing this Skill.

## Requests

Interpret ordinary requests such as `Publication: prepare this project for X and LinkedIn`, `Publication: make a Reel from this screencast`, and `Publication: publish the approved packages now`. These are examples, not universal built-in slash commands.

Report the artifacts, actual delivery state and any specific remaining step. Distinguish executed behavior from plans and untested integrations.