Use when the user asks to "plan an influencer campaign", "build a campaign blueprint", "track or close a creator campaign", or "record a late campaign correction"; produces the plan and, when requested, a non-canonical evidence tracker with scoped identity, publication, reconciliation, close, and reopen receipts. Not for individual creator briefs — use brief-generator; not for overall product launches without creators — use launch-tier-planner; not for sending, publishing, amplifying, or paying — use the owning execution workflow. 达人营销策划/种草方案/活动追踪与关账
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Use when the user asks to "plan an influencer campaign", "build a campaign blueprint", "track or close a creator campaign", or "record a late campaign correction"; produces the plan and, when requested, a non-canonical evidence tracker with scoped identity, publication, reconciliation, close, and reopen receipts. Not for individual creator briefs — use brief-generator; not for overall product launches without creators — use launch-tier-planner; not for sending, publishing, amplifying, or paying — use the owning execution workflow. 达人营销策划/种草方案/活动追踪与关账
Use when planning a new influencer campaign, launching a product with influencer support, building seasonal or always-on creator programs, or maintaining an existing creator-campaign tracker: recording verified publication checkpoints, deriving exception queues, reconciling payment/measurement evidence, closing creators or the campaign, and handling late evidence or manual reopen. Planning does not write briefs or execute outreach; tracking does not publish, amplify, pay, or mutate external systems.
argument-hint
<brand or product> [budget] [platform] [timeframe]
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 ; in a plan-authoring mode, generate one random if none exists and preserve it through the lineage. never invents a missing ID, plan, contract, scope, or checkpoint. Every row preserves a stable opaque ; every saved is qualified-resolver-backed and opaque. Raw names, handles, URLs, shortcodes, provider IDs, and hidden locator maps remain transient.
campaign_id
campaign-<UUIDv4>
tracker-only
creator_ref
live_post_ref
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.
This family is Tier 1: every skill works with no live integrations. Supplied brand, audience, budget, and timeline support a plan skeleton, but do not determine messaging, platform/tier mix, content format, promo mechanics, contingency, rate, or KPI targets. Those choices require user direction or compatible source-dated planning evidence; otherwise retain NEEDS_INPUT.
Optional connectors that strengthen the plan when available:
~~influencer database — size the influencer mix and validate tier follower ranges.
~~social platform analytics — set platform-specific reach and engagement benchmarks.
~~CRM — align conversion targets and attribution with existing pipeline data.
~~analytics — pull past-campaign actuals for realistic KPI and budget-efficiency targets.
See CONNECTORS.md for the free/keyless data recipe per category. Without a connector, ask the user for the missing inputs and proceed only with fields supported by user-provided evidence; return a useful skeleton plus NEEDS_INPUT for the rest.
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.
Gather campaign requirements — capture campaign_id, brand, value prop, audience, campaign type, timeline, budget, and constraints (template §1).
Define objectives — one SMART primary objective plus secondary objectives, with explicit success and failure definitions (template §2).
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).
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).
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).
Create the timeline — key dates, a four-phase week-by-week plan, and a Gantt view (template §6).
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).
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.
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.
For tracker-only or both, read references/templates.md §10 for the Influencer domain fields and compatibility view. On Governed hosts, validate the source control artifacts first and generate the tracker as a read-only projection; never accept a tracker edit as an append, migration, stage/evidence/pointer change, reopen, or close. Creator rows must equal the locked scope and keep the active block at exactly eight fields; identity and close pointers stay adjacent. Identity and state heads must be resolvable, same-scope, unique, and non-forked. Any scope/contract/identity/checkpoint/verification/receipt/close/late-event gap shows PARTIAL CHECKPOINT COVERAGE — NOT CLOSE-ELIGIBLE; elapsed time never advances state. On semantic-only hosts, return the same view inline or save a NOT_VERIFIED compatibility snapshot after exact path-scoped authorization. payment_status records external readiness/evidence only and never sends money.
Each publication checkpoint gets an immutable, same-campaign/creator/checkpoint domain publication_receipt under fresh host authorization for the append-publication-receipt view update and a single-head supersession chain. This YAML block maps to shared evidence-observation; it is not an action-receipt and does not prove that this skill published anything. A real publish needs a separate exact action-intent before the executor and matching action-receipt after it. live_post_ref is only a qualified-resolver-backed opaque ref; raw URLs/slugs/provider IDs stay transient, and unresolved input remains unknown. verified disclosure/version match requires the exact observation, frozen approved asset/auditor, and evidence refs. Missing, mismatched, cross-scope, or forked evidence blocks close and routes the asset to creator-content-auditor; never infer approval or mutation.
A creator closes only when each applicable checkpoint has one controlling verified publication receipt or evidence-backed terminal non-applicability resolution and every §10 gate passes. A fresh atomic close-creator authorization must name its receipt append, row/evidence changes, and pointer update; campaign close needs a separate equivalently scoped close-campaign authorization and an exact creator→current-close mapping. Any fork blocks both branches. Corrections preserve history, re-evaluate gates, and append newly authorized close heads only when warranted; a reference-only correction does not manually reopen work.
Late rights/post/attribution/payment/data evidence uses the campaign-bound §10 late_event_note under a fresh append-late-event authorization. Any accompanying stage/action/evidence/pointer mutation must be named in that atomic authorization or separately approved. supersede-artifact binds the exact old and replacement refs of the same scope and meaning. manual-reopen is only for new campaign-owned work; otherwise append the correction and, if gates pass, fresh close heads. Preserve history and never auto-reopen or invent a reopened stage.
When the user asks what needs attention, generate the template §10 exception queue from the validated source artifacts (or a clearly labeled semantic-only compatibility snapshot) using an explicit as_of time and user-selected rights horizon. It is a read-only projection—no cron, polling, automatic stage change, projection write-back, or external mutation.
Example
User: "Create a campaign plan for a new sustainable sneaker launch targeting Gen Z on TikTok and Instagram with a $50K budget"
Output: A plan skeleton preserving the supplied audience, platforms, and $50K total. Sustainability claims/message canon, creator mix, content format, promo/attribution mechanic, rates, contingency, KPI targets, and exact dates remain NEEDS_INPUT until the user supplies them or compatible source-dated anchors. No micro-heavy, UGC, promo-code, or percentage default is inferred. (Fuller walkthrough in references/templates.md.)
Reference Materials
references/templates.md — fill-in templates for all nine planning steps, the optional lightweight WARM tracker, the worked example, and success tips.
references/influencer-tiers.md — declaration contract for user/source-dated partner models and follower bands; it supplies no universal range or performance claim.
Tracker-only, publication/approval blocker: creator-content-auditor — verify the cited live post against the frozen approved asset; this does not authorize an edit or amplification.
Tracker-only, readback/reconciliation due: performance-analyzer — produce the dated §8 readback artifact; final reporting may package that artifact only after the evidence exists.
Tracker-only, open operational item: hand off only to the named owner/skill required by the current next_action; do not route back to briefing for a late-stage row. If every close gate passes and no action remains, stop and report chain-complete.
Termination note: keep a visited-set of skills invoked this session. If the applicable next skill has already run this session, stop and report the chain complete rather than re-invoking. Do not chain deeper than 3 hops from the originating request.
