Postplus Shared
Load shared routing and safety rules before any PostPlus ad-platform task so connect, read, diagnose, and spend-affecting writes stay separated and approval-gated.
Overview
postplus-shared is an agent skill most often used in Grow (also Launch distribution and Operate iterate) that defines shared routing, schemas, and safety gates for PostPlus ad workflows before platform-specific skills ru
Install
npx skills add https://github.com/postplusai/postplus-skills --skill postplus-sharedWhat is this skill?
- Enforces a fixed five-stage pipeline: connect account, read data, normalize, diagnose and propose, then approve and appl
- Keeps read paths and write paths separate with an explicit human approval gate before any spend-affecting change
- Routes intent through ads-router roles (connect, read, diagnose, propose, apply, sync) instead of one free-form ad-manag
- Requires deterministic adapter layers—no direct model-to-platform API calls
- Treats account binding, token storage, and billing as sensitive operations with dry-run or validation-first execution
- Five explicit ad workflow stages: connect, read, normalize, diagnose and propose, approve and apply
- Human approval gate required before any spend-affecting write
- Read and write paths must stay separate
Adoption & trust: 1 installs on skills.sh; 8 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You want an agent to manage paid ads, but mixing account connect, reporting reads, and budget writes in one chat risks unauthorized spend and inconsistent data.
Who is it for?
Solo builders using the PostPlus ad skill stack who need a shared safety and routing model before connect, read, diagnose, or apply steps on any ad platform.
Skip if: Builders who only need organic SEO or content with no paid accounts, or who want a single prompt to change budgets without approval gates and adapter layers.
When should I use this skill?
A task touches any ad platform and you need the PostPlus family’s common routing and safety model before platform-specific connect, read, diagnose, propose, apply, or sync work.
What do I get? / Deliverables
You get a deterministic five-stage ad workflow with separated read/write paths, router classification, normalized schemas, and human-approved patches before any spend-affecting apply—then hand off to platform-specific Po
- Router decision for connect vs read vs diagnose vs propose vs apply vs sync
- Alignment to normalized ad, approval, audit, and execution record schemas defined by ads-core
- Safety-compliant execution plan with dry-run or validation before live spend changes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Paid ad operations—connecting accounts, reading performance, syncing conversions, and applying budget changes—most often happen after launch when you are growing and optimizing spend, so grow/lifecycle is the canonical shelf. Lifecycle covers ongoing campaign management, conversion sync, and spend decisions rather than one-off copy or SEO content work.
Where it fits
Pull and normalize campaign performance, diagnose ROAS issues, and propose a patch that waits on your approval before any budget write.
Classify a new request as connect/discover first so account binding and tokens are handled before any read or spend action.
After an approved apply step, rely on the shared audit and execution record schema to trace what changed on the ad account.
Keep ads-read on reporting-only paths while conversion sync runs without mixing in unauthorized campaign edits.
How it compares
Use as the shared policy and stage model before platform-specific PostPlus ad skills—not as a one-shot free-form ad optimizer or an MCP server replacement.
Common Questions / FAQ
Who is postplus-shared for?
It is for solo and indie builders automating paid ads through the PostPlus skill family who need common routing, schema, and safety rules before any platform-specific work.
When should I use postplus-shared?
Use it whenever a task touches an ad platform and you need the shared model first—for example in Grow lifecycle when normalizing campaign data and proposing budget patches, in Launch distribution when connecting a new ad account before first campaigns, or in Operate iterate when
Is postplus-shared safe to install?
The skill itself encodes conservative rules (approval before spend writes, no direct API calls without adapters), but you should still review the Security Audits panel on this Prism page before enabling it in production agents.
SKILL.md
READMESKILL.md - Postplus Shared
# Shared Ads Workflow Shared routing and safety rules for the ad skill family. Use this file when a task touches any ad platform and you need the common model before platform-specific work. ## Core Rule Do not treat ad management as a single free-form agent task. Split it into five stages: 1. connect account 2. read data 3. normalize 4. diagnose and propose 5. approve and apply This family should always keep those stages separate. ## Default Flow ```mermaid flowchart LR A["User intent"] --> B["ads-router"] B --> C["connect / discover"] C --> D["read / normalize"] D --> E["diagnose"] E --> F["propose patch"] F --> G["human approval gate"] G --> H["apply changes"] H --> I["audit log"] D --> J["conversion sync"] ``` ## Safety Rules - Keep read and write paths separate. - Require explicit approval before any spend-affecting write. - Treat account binding, token storage, and billing as sensitive operations. - Prefer dry-run or validation-only mode before real execution. - Never let the model call the platform API directly without a deterministic adapter layer. ## Common Roles ### `ads-router` - classify intent - decide whether the request is connect, read, diagnose, propose, apply, or sync - route to the correct platform adapter ### `ads-core` - own the normalized ad schema - own the approval record schema - own the audit and execution record schema ### `ads-read` - pull accounts, campaigns, ad groups, ads, creatives, budgets, reports, and conversion summaries - never mutate ### `ads-diagnose` - identify wasted spend, fatigue, unstable CPA, budget constraints, and broken tracking - output reasons, not commands ### `ads-propose` - produce a structured patch for review - keep proposed changes small and explicit ### `ads-apply` - execute only approved changes - keep a full result record ### `ads-conversion-sync` - send server-side events or conversion signals back to the platform - treat this as an execution path with tracking and audit ## Shared Output Contract All platform-specific skills should be able to return at least: - `access_scope` - `account_tree` - `normalized_reports` - `diagnosis` - `proposed_patch` - `approval_record` - `execution_result` - `audit_log` ## Platform Policy Each platform adapter should declare: - auth method - readable objects - writable objects - conversion sync support - expected rate-limit behavior - known policy or access caveats ## First Version Boundary The first version should support: - connect - read - normalize - diagnose - propose - manual approve - apply a small safe action set The first version should not try to automate: - full campaign generation from scratch - unrestricted budget allocation - multi-account spend migration - self-directed creative replacement # Shared Product Selection Preferences Shared routing rules for product-selection work. Use this file first. It exists to help the agent choose the right path before collecting data or making recommendations. ## Merchant Models Classify the business model first: - `white-label`: generic or lightly customized products, speed and margin first - `brand`: differentiated products, trust and premium first - `distribution`: authorized resale, assortment and channel leverage first - `content-led`: creator or media-driven selling, content efficiency first - `hybrid`: mixed model, choose the dominant constraint first Do not confuse merchant model with sales channel. ## Channels Classify the main selling channel next: - `amazon`: search-led marketplace - `tiktok-shop`: content-led marketplace - `independent-site`: audience and LTV-led storefront - `multi-channel`: compare channel fit explicitly instead of averaging assumptions Treat channel choice as a strategy question, not a formatting detail. ## Question Types Classify the user request before doing any work: - `platform data`: listings, prices, reviews, rankings, creators, comments, shop pages - `social pro