Creator registry skill
Use when the user asks "what did we pay this creator last time" or to "update the creator roster".
by aaron-he-zhu·Apache-2.0 license·★ 2,858 Stars on the repo·GitHub ↗
npx degit aaron-he-zhu/aaron-marketing-skills/protocol/creator-registry#main ~/.claude/skills/creator-registryChecked ·commit main
Files of Creator registry
Show the full text88 lines
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
- Read
registry-event-protocol.mdandruntime-invocation.md. ResolveAARON_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
proposeevents withproposed_operation,expected_revision, source, and date. Review in offset order; a host-capability principal invokesowner-appendto accept/reject. Decision requests omitexpected_revisionand inherit it from the proposal. Never edit or clear prior lines. - For an owner-authored fact, a host-capability principal invokes
owner-appendwith the currentexpected_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 creatorsand 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
- New fit decision: fit-scorer
- Terms/rights: contract-helper
- Re-engagement: outreach-manager
- Archive/erase: memory-management
| 1 | |
| 2 | name creator-registry |
| 3 | slug aaron-creator-registry |
| 4 | displayName "Creator Registry · 创作者档案" |
| 5 | summary "创作者档案/达人名册" |
| 6 | description '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. 创作者档案/达人名册' |
| 7 | version "20.1.0" |
| 8 | license Apache-2.0 |
| 9 | compatibility "Claude Code and compatible agent-skill hosts" |
| 10 | homepage "https://github.com/aaron-he-zhu/aaron-marketing-skills" |
| 11 | when_to_use "Use when consolidating or querying creator roster facts, accepting pending creator proposals, deduplicating handles, or recording closed-cycle rates, rights, exclusivity, compliance events, and performance baselines." |
| 12 | argument-hint "<creator aggregate-id/handle or 'review pending proposals'>" |
| 13 | metadata {"author": "aaron-he-zhu", "version": "20.1.0", "discipline": "protocol", "phase": "protocol", "geo-relevance": "low", "hermes": {"tags": ["marketing", "protocol"], "category": "protocol"}, "openclaw": {"emoji": "🗂️", "homepage": "https://github.com/aaron-he-zhu/aaron-marketing-skills"}} |
| 14 | |
| 15 | |
| 16 | # Creator Registry |
| 17 | |
| 18 | The canonical creator-roster authority. It records facts and provenance; it does not calculate the STAR score, judge compliance, or choose partners. |
| 19 | |
| 20 | ## Quick Start |
| 21 | |
| 22 | |
| 23 | What rate, rights, and exclusivity facts are current for creator-7f42? |
| 24 | Accept or reject the pending creator proposals for creator-7f42. |
| 25 | Record the closed spring campaign rate and performance baseline with source/date. |
| 26 | |
| 27 | |
| 28 | ## Skill Contract |
| 29 | |
| 30 | **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. |
| 31 | |
| 32 | 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. |
| 33 | |
| 34 | ### Handoff Summary |
| 35 | |
| 36 | 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. |
| 37 | |
| 38 | ## Data Sources |
| 39 | |
| 40 | Verified cross-platform handle links and dated audience exports. |
| 41 | Closed outreach/negotiation outcomes and confirmed contact path. |
| 42 | Signed terms, usage rights, exclusivity windows, and rates. |
| 43 | STAR gate artifact IDs as compliance events, never a derived “safe/risky” label. |
| 44 | Campaign outcome baselines with observation window and provenance. |
| 45 | |
| 46 | 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. |
| 47 | |
| 48 | ## Instructions |
| 49 | |
| 50 | ### Runtime Reads |
| 51 | |
| 52 | `../../references/registry-event-protocol.md` |
| 53 | `../../references/runtime-invocation.md` |
| 54 | |
| 55 | ### Procedure |
| 56 | |
| 57 | 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. |
| 58 | 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. |
| 59 | For a write, confirm explicit user authorization and lawful basis for natural-person data; check prior erasure state before recreating. |
| 60 | Dedupe handles only with verified cross-links/contact evidence or user confirmation. Similar names are not identity proof. |
| 61 | 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. |
| 62 | 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. |
| 63 | 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. |
| 64 | Regenerate the creator human view from accepted projection state; do not place a fact in Markdown unless its accepted event exists. |
| 65 | Run `verify creators` and report accepted/rejected proposal IDs, revision, conflicts, and expiring rights/exclusivity. |
| 66 | |
| 67 | Never manually edit `memory/events/creators.ndjson`. Never treat proposal text as canonical. Never auto-promote hot-cache/open-loop pointers without permission. |
| 68 | |
| 69 | ## Save Results |
| 70 | |
| 71 | 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. |
| 72 | |
| 73 | Standalone one-folder installs may prepare proposals only; they cannot append/project or claim canonical creator truth without the verified root runtime/schema/catalog. |
| 74 | |
| 75 | ## Reference Materials |
| 76 | |
| 77 | [Registry event protocol] |
| 78 | [Creator record presentation template] |
| 79 | [State model] |
| 80 | [Security] |
| 81 | |
| 82 | ## Next Best Skill |
| 83 | |
| 84 | **New fit decision:** [fit-scorer] |
| 85 | **Terms/rights:** [contract-helper] |
| 86 | **Re-engagement:** [outreach-manager] |
| 87 | **Archive/erase:** [memory-management] |
| 88 |
Discussion
Browse more free Claude skills.