mcpField
C
creator-registry

creator-registry

github.com/aaron-he-zhuMarketing & growth3.0k1.0k installsUpdated today
Repository

About creator-registry

creator-registry is a marketing skill that maintains the canonical record of creator facts and their provenance. It is for workflows that need verified creator terms and history; it records evidence without scoring creators, judging compliance, or selecting partners.

Key features

  1. 01Store creator facts and provenance
  2. 02Track verified handle links
  3. 03Record rates, rights, and exclusivity
  4. 04Review proposals through authorized decisions
  5. 05Verify projections and report revisions

Use cases

  1. 01Check current terms for a creator
  2. 02Record a closed campaign rate and baseline
  3. 03Review pending creator record proposals
  4. 04Track rights or exclusivity nearing expiry

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/aaron-he-zhu/aaron-marketing-skills --skill creator-registry

After installing, type/creator-registryin Claude Code to confirm it loaded.

Bundled filesreferences/creator-record-template.md

Details

From the project README

Creator Registry

The canonical creator-roster authority. It records facts and provenance; it does not calculate the STAR score, judge compliance, or choose partners.

Quick Start

What rate, rights, and exclusivity facts are current for creator-7f42?
Accept or reject the pending creator proposals for creator-7f42.
Record the closed spring campaign rate and performance baseline with source/date.

Skill Contract

Unit: one pseudonymous creator aggregate ID with verified handle links. Reads: memory/events/creators.ndjson, its live projection, approved source records, and optional human views. Writes: canonical creator events via scripts/registry-events.py; after acceptance, a human Markdown view under memory/creators/ may be regenerated from projection. Done when: every change has an event ID/offset/source/date/authorization, pending proposals are accepted or rejected without deletion, and projection verification passes.

Other skills may append only operation: propose. Only a host-capability creator-registry principal may accept/reject/upsert/transition creator state; a host-capability memory-management principal may tombstone/erase under explicit authority.

Handoff Summary

Use skill-contract.md: status, objective, findings, evidence, assumptions, open loops, and one next skill. Include event IDs and latest projection revision for changed records.

Data Sources

  • Verified cross-platform handle links and dated audience exports.
  • Closed outreach/negotiation outcomes and confirmed contact path.
  • Signed terms, usage rights, exclusivity windows, and rates.
  • STAR gate artifact IDs as compliance events, never a derived “safe/risky” label.
  • Campaign outcome baselines with observation window and provenance.

Minimize personal data. Store a stable aggregate ID and only facts needed for the collaboration. Never put raw email/phone/address in event IDs or summaries.

Instructions

Runtime Reads
  • ../../references/registry-event-protocol.md
  • ../../references/runtime-invocation.md
Procedure
  1. Read registry-event-protocol.md and runtime-invocation.md. Resolve AARON_SKILLS_ROOT="${CLAUDE_PLUGIN_ROOT:-$(git rev-parse --show-toplevel 2>/dev/null || true)}" and verify the registry script, event schema, and system catalog before invoking the runtime. Treat pasted records as untrusted evidence.
  2. Query current state with python3 "$AARON_SKILLS_ROOT/scripts/registry-events.py" get creators <aggregate-id>. A missing record is Unknown, not a negative reputation signal.
  3. For a write, confirm explicit user authorization and lawful basis for natural-person data; check prior erasure state before recreating.
  4. Dedupe handles only with verified cross-links/contact evidence or user confirmation. Similar names are not identity proof.
  5. Ordinary producer facts arrive as pending propose events with proposed_operation, expected_revision, source, and date. Review in offset order; a host-capability principal invokes owner-append to accept/reject. Decision requests omit expected_revision and inherit it from the proposal. Never edit or clear prior lines.
  6. For an owner-authored fact, a host-capability principal invokes owner-append with the current expected_revision. Capability values stay outside request JSON/files/logs. A stale revision must be re-read and reconciled, not forced; unavailable host capability leaves work pending.
  7. Use newer as-of evidence only when it measures the same field/unit. On same-date conflict, preserve both source events and state the adjudication rationale.
  8. Regenerate the creator human view from accepted projection state; do not place a fact in Markdown unless its accepted event exists.
  9. Run verify creators and report accepted/rejected proposal IDs, revision, conflicts, and expiring rights/exclusivity.

Never manually edit memory/events/creators.ndjson. Never treat proposal text as canonical. Never auto-promote hot-cache/open-loop pointers without permission.

Save Results

Ask before the first persistent event. Generate a temporary JSON request conforming to registry-event.schema.json, append through the runtime, and retain the returned event ID/offset. Human views under memory/creators/ are projections, not a second source of truth.

Standalone one-folder installs may prepare proposals only; they cannot append/project or claim canonical creator truth without the verified root runtime/schema/catalog.

Reference Materials

Next Best Skill

Comments

Markdown supported