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.

Handoff Summary

Emit the standard shape from skill-contract.md §Handoff Summary Format.

Instructions

Choose and state one mode before doing work. plan-only runs §§1–9 and does not instantiate §10. tracker-only runs only §10 and requires an existing campaign_id, exact versioned plan_ref plus plan hash, the current locked §8 measurement contract, and its locked non-empty creator scope; if any binding is missing, mismatched, forked, or unverified, return NEEDS_INPUT instead of rebuilding a plan or creating a placeholder tracker. both runs §§1–9 before §10. If creator selection is not yet locked, return the plan plus the exact missing scope/contract inputs and, only when explicitly requested, an inline non-close-eligible partial tracker header; do not invent creator identities or call it execution-ready. In plan-only or both, reuse an explicit upstream/user campaign_id; for a new campaign with none, generate random campaign-<UUIDv4> once and preserve it unchanged. In tracker-only, a missing ID is blocking; never generate or deterministically derive it from a campaign name, date, creator handle, or mutable plan content.

For plan-authoring modes, work the nine steps in order. Each has a fill-in template in references/templates.md — copy the matching block and assemble it in step 9. Replace brackets only with supplied or source-backed values; never invent a number, identity, benchmark, or fact to eliminate a placeholder. Keep an unresolved optional field Unknown, and return NEEDS_INPUT when a required field is absent.

1. Gather campaign requirements — capture campaign_id, brand, value prop, audience, campaign type, timeline, budget, and constraints (template §1).
2. Define objectives — one SMART primary objective plus secondary objectives, with explicit success and failure definitions (template §2).
3. Develop strategy — big idea, strategy statement, audience, key messages, campaign pillars, platform split, and differentiation only from user-approved canon or compatible source-dated evidence; otherwise preserve the decision fields as NEEDS_INPUT rather than defaulting to UGC, promo-code, or another tactic (template §3).
4. Define influencer criteria — tier mix, must-have and preferred selection criteria, exclusions, ideal profile, and relationship types. Use only a user-declared or compatible source-dated follower taxonomy; references/influencer-tiers.md supplies the recording contract, not universal ranges or performance claims (template §4).
5. Plan content requirements — deliverables by platform/format, required elements, creative direction, themes, and the approval chain from supplied decisions and current platform/rights evidence; do not invent a default UGC format, promo mechanic, or content mix (template §5).
6. Create the timeline — key dates, a four-phase week-by-week plan, and a Gantt view (template §6).
7. Allocate budget — break down the supplied total by category, declared follower band, and platform only from user-approved rules or compatible source-dated cost evidence. Add contingency, CPM/CPE, or cost-per-content targets only when their rule/anchor is supplied; otherwise use NEEDS_INPUT and do not invent a percentage or rate (template §7).
8. Establish success metrics — primary KPIs vs source-dated comparators, secondary and conversion metrics, reporting cadence, and a non-canonical pre-execution measurement contract covering the baseline, outcome unit, readback window, attribution basis, decision rule, decision owner, exact campaign/plan version/hash, lock authorization, non-empty creator scope, and structured unique per-creator/deliverable publication checkpoints (template §8). Every external comparator requires an opaque source ref, observation date, and comparable window/cohort; otherwise keep it Unknown/NEEDS_INPUT rather than presenting an “industry average.” A scope or contract change is a new immutable version plus explicit §10 migration; never edit the locked block in place.
9. Compile the plan document — executive summary, the full sections above, and an appendix with risk mitigation (template §9). Return it inline by default; save only after authorization for the exact WARM path.

[Section truncated — full source on GitHub]

Full source on GitHub (appendix / reference sections omitted for length).