campaign-planner

Campaign Planner

Designs an influencer campaign from strategy to execution plan — an actionable blueprint that ties business objectives to creative execution.

Scope edge — product launches: this skill owns the creator lane of a launch. The launch itself — tier/type decision, launch calendar, press motion, community launch day, readiness gate — belongs to the launch discipline (launch-tier-planner and siblings), which hands this skill the creator-channel sub-plan aligned to the launch-registry date and stage. "Launch a product with creators" starts here; "launch a product" starts there.

Quick Start

Create an influencer campaign plan for [product launch]

Plan an influencer campaign for [brand] with [budget] targeting [audience] during [timeframe]

Skill Contract

• Reads: requested mode (plan-only | tracker-only | both); brand, product, audience, campaign type, budget, timeline, and constraints for plan authoring; and, for execution-ready tracking, an existing campaign_id, exact versioned campaign-plan reference/hash, locked §8 measurement contract, and locked non-empty creator scope. If memory-management is active, prior audience profiles and past-campaign benchmarks load from the hot cache.
• Writes: the campaign plan inline by default. With exact save authorization, write it to memory/influencer/campaign-planner/YYYY-MM-DD-<topic>.md. For execution tracking, emit separate JSON artifacts that validate against the shared five-kind control schema (evidence observations, the locked measurement contract, action intents/receipts only for an actual executor action, and the Cycle Retro), then let the controller bind their exact refs/hashes to the selected run ancestry. The Markdown/YAML tracker in references/templates.md §10 is a deterministic read-only Influencer compatibility view, marked authoritative: false; its domain blocks are not themselves schema-valid control artifacts, and editing them never changes runtime state. Standalone hosts without the validator may save a semantic-only compatibility snapshot after exact WARM authorization, but it must be marked NOT_VERIFIED and cannot claim single-head, receipt, persistence, or close enforcement. Reuse an explicit upstream/user campaign_id; in a plan-authoring mode, generate one random campaign-<UUIDv4> if none exists and preserve it through the lineage. tracker-only never invents a missing ID, plan, contract, scope, or checkpoint. Every row preserves a stable opaque creator_ref; every saved live_post_ref is qualified-resolver-backed and opaque. Raw names, handles, URLs, shortcodes, provider IDs, and hidden locator maps remain transient.
• Promotes: only with separate exact authorization, promote approved campaign name, objective, budget, go-live date, and KPI targets to memory/hot-cache.md; never promote tracker stages or payment state. After a creator row is closed, another exact authorization is required for each registry proposal containing evidence-backed actual rate, signed rights window/expiry, or measured performance baseline; only creator-registry can make those facts canonical. Forecast targets, stage, next_action, due_at, and payment_status remain WARM working state.
• Done when:
  • The selected mode is explicit: plan-only completes §§1–9, tracker-only completes only §10 from its required existing inputs, and both completes §§1–9 before §10.
  • In a plan-authoring mode, objectives, strategy, influencer mix, deliverables, timeline, budget allocation, contingency, and KPIs are concrete only where the user supplied them or a compatible source-dated planning anchor supports them. Every unsupported required choice stays NEEDS_INPUT; the skill never fills it from a repository default. The §8 measurement design is execution-locked only when its campaign/plan binding, immutable plan hash/version, authorization, non-empty creator scope, and unique per-creator/deliverable checkpoints are present; otherwise report the exact lock inputs as NEEDS_INPUT/DONE_WITH_CONCERNS and do not create a close-eligible tracker.
  • If tracking was requested, each creator has validated source artifacts and one deterministic non-authoritative projection block with stage, next action, due date, rights expiry, evidence references, and external-payment handoff state. The projection carries its source artifact refs/digests and current head; it is never hand-edited as the state source.
  • Each tracker creator uses one stable opaque creator_ref; every identity resolution, publication, terminal-checkpoint resolution, creator close, campaign close, migration, and late event has an immutable ref plus exact campaign/creator scope and a single non-forked current head where applicable.
  • Every saved live_post_ref is opaque and qualified-resolver-backed. External actions require current exact authority and matching intent/receipt artifacts; a prior save, plan, gate, path, capability, or projection never grants authority. Raw post locators and reusable blanket approvals never enter the artifact set or projection.
  • A tracked live post has a receipt per required checkpoint, and each checkpoint's latest explicitly unsuperseded receipt controls the close gate; a mismatch, unknown disclosure, or changed/removed post is evidence for review, never silently treated as approved.
  • A closed creator row points to its unique current close-receipt head. A closed campaign points to the unique current campaign-close head, proves exact equality with the locked non-empty creator scope, and passes the strict gates in template §10; neither closed value is treated as a synonym for success.
  • A material late event is appended without rewriting prior receipts. A reference correction appends fresh close receipts when corrected gates still pass; a failed gate cannot receive a passing receipt, and manual reopen is reserved for new campaign-owned work under template §10's stage/action baseline.
  • A plan-authoring result names brief generation and open approvals. A tracker-only result instead names the evidence/action owner implied by the current stage, or stops as chain-complete when nothing remains; it never routes backward to brief generation by default.
• Primary next skill: in plan-only/both, brief-generator; in tracker-only, use the stage-specific handoff in Next Best Skill or stop when complete.