creator-registry

Original：🇺🇸 English

Translated

Use when the user asks "what did we pay this creator last time" or to "update the creator roster"; curates creator identity, rate, rights, exclusivity, compliance-event, and performance facts through the append-only creators event stream. Not for scoring fit — use fit-scorer; not for reviewing content — use creator-content-auditor. 创作者档案/达人名册

2installs

Sourceaaron-he-zhu/aaron-marketing-skills

Added on2026-08-13

NPX Install

npx skill4agent add aaron-he-zhu/aaron-marketing-skills creator-registry

SKILL.md Content

View Translation Comparison →

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

text

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

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.
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.
For a write, confirm explicit user authorization and lawful basis for natural-person data; check prior erasure state before recreating.
Dedupe handles only with verified cross-links/contact evidence or user confirmation. Similar names are not identity proof.
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.
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.
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.
Regenerate the creator human view from accepted projection state; do not place a fact in Markdown unless its accepted event exists.
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

Registry event protocol
Creator record presentation template
State model
Security

Next Best Skill

New fit decision: fit-scorer
Terms/rights: contract-helper
Re-engagement: outreach-manager
Archive/erase: memory-management