creator-meta

name

creator-meta

description

Creator-agnostic operating-system substrate. The abstract layer model + decision tree + brand-discipline framework that any creator can inherit and specialize. Use when designing a new creator's repo structure, asking 'what layer does X belong to?', booting a new creator's Claude Code config, or reasoning about the creator-tooling stack independent of any specific creator. Trigger phrases: creator meta, creator system map, creator OS, what layer does X go in, creator layer model, generalize for creators, bootable creator skill.

Creator Meta

The portable substrate behind every creator-specific operating system. Defines the 6-layer model, the "where does X go?" decision tree, and the brand-discipline framework — abstractly, with placeholders, so any creator can inherit and specialize.

creator-meta is to creator operating systems what arcanea-meta is to Arcanea or frankx-meta is to FrankX: the self-describing layer that makes the system bootable.

When to use this skill

• Designing a new creator's Claude Code project structure (any creator, not just Frank)
• Asking "where should this live?" in any creator-tooling context
• Booting a fresh creator project with the proven layer model
• Comparing two creator setups for drift or convention divergence
• Generalizing a project-scope skill (like frankx-meta) into a portable plugin
• Reasoning about creator-tooling architecture independent of specific paths or brand

When NOT to use this skill

• When you have a specific creator-meta child available (e.g., frankx-meta) — use that instead, it has concrete paths
• For domain work (writing code, content, music) — use the domain-specific skill
• For ACOS-internal questions — use acos-meta instead

The 6-layer model (abstract)

L0  RAW INTAKE          {creator}/intake/                    inbound, unprocessed
L1  SECOND BRAIN        {creator}/docs/                      long-form prose
L2  COMMAND CENTER      {creator}/.claude/                   skills, commands, agents, hooks
L3  OPERATIONAL DATA    {creator}/{data,content,lib,scripts}/   typed records, MDX, code
L4  PUBLIC FACE         {creator}/{app,site,public}/         what the world sees
L5  SUBSTRATE           sibling repos                        open-source frameworks for forking

The walk: when you have a new artifact, walk top-to-bottom. Stop at the first layer that fits. If two fit, you're misreading the artifact — re-read and re-walk.

Concrete instances

Creator	Project skill	Repo	Specializations
Frank Riemer	frankx-meta	~/frankx/	L1=docs/, L4=app/, brand-walls Arcanean mythology, dual-repo deploy
(scaffold)	<name>-meta	~/<name>/	Custom paths, custom brand, custom substrate repos

This skill is the parent. Each child specializes paths, voice, and substrate boundaries while preserving the layer-model contract.

The 5 meta-rules (creator-agnostic)

1. Layer before content

Before adding anything, decide which layer it belongs to. Skip-the-tree shortcuts cause sprawl.

2. Canonical wins

When two copies of the same data exist, the canonical (per the project's canonical-locations.md) is truth. Drift gets reconciled, never silently edited in both places.

3. Brand boundary is a wall, not a guideline

Each creator brand stays in its repo. Substrate brands (open-source frameworks) keep their own voice in their own repos but adopt the consuming creator's voice when surfaced. Brand walls are tested by automated grep on every PR.

4. Substrate is its own repo

L5 systems (open-source frameworks) live in their own GitHub repos with their own license and brand. The creator's main repo references them but never contains their source.

5. Production sync is human-gated

No tool ever auto-syncs from dev → production. Humans review diffs.

The decision tree (abstract)

Q1: Is it inbound and unprocessed (chat, dump, voice memo, screenshot)?
    → L0 — drop in {creator}/intake/

Q2: Is it long-form prose that informs decisions?
    → L1 — {creator}/docs/{topic-or-date-folder}/

Q3: Is it Claude harness tooling (skill / command / agent / hook)?
    → L2 — global if reusable, project if creator-specific

Q4: Is it typed data, MDX content, library code, or build script?
    → L3 — {creator}/{data,content,lib,scripts}/

Q5: Does it ship as a page / component / static asset?
    → L4 — {creator}/{app,site,public}/

Q6: Is it a foundational framework for others to fork?
    → L5 — new sibling repo with MIT, dedicated brand, own SKILL.md

Full decision-tree depth: references/decision-tree.md.

How to specialize (boot a new creator)

1. Create skill folder:    ~/<creator>/.claude/skills/<creator>-meta/
2. Copy skeleton:          cp -r ~/.claude/skills/creator-meta/_template/ ./
3. Specialize SKILL.md:
   - Replace {creator} placeholders with concrete paths
   - Define your brand voice + lexicon walls
   - List your sibling substrate repos (Tier 2)
4. Create references/canonical-locations.md with your real paths
5. Create references/ecosystem-inventory.md with your shipped systems
6. Create references/brand-discipline.md with your voice rules
7. Test: invoke trigger phrase "where does X go" — verify activation

A _template/ example is bundled in references/template-creator-meta.md.

Composition with ACOS

creator-meta is what ACOS v11's compose.extends declares. ACOS plugin manifest (~/agentic-creator-os/.claude-plugin/plugin.json) inherits this substrate. Any creator who installs ACOS automatically gets the layer model + decision tree, then specializes via their own <creator>-meta project skill.

ACOS v11 plugin
   └── compose.extends = ["creator-meta"]
        └── creator-meta (this skill, global)
             └── inherited & specialized by <creator>-meta (project)

What this skill does NOT specify

• Specific paths (those are creator-specific)
• Specific brand voice (that's per-creator)
• Specific substrate repos (those are per-creator)
• Specific tooling versions (those are per-creator)
• Specific publishing targets (those are per-creator)

If a question requires those answers, drop down to the creator's project skill (e.g., frankx-meta).

Anti-patterns

• Adding creator-specific names to this skill — defeats the abstraction
• Defining substrate repos in the abstract — substrates are per-creator
• Making this skill mandatory — it's a base class, not a runtime requirement
• Forking this skill instead of inheriting — duplication causes drift; specialize via a child skill
• Skipping the decision tree — that's the load-bearing piece

Related skills

• acos-meta — describes ACOS v11 specifically (the plugin that composes on this substrate)
• arcanea-meta — the same pattern applied to Arcanea (mythology + tooling)
• frankx-meta — the FrankX-specific child of this skill
• superpowers:writing-skills — how to write a new skill following this pattern

References

• references/decision-tree.md — full Q1-Q6 walk with edge cases (abstract)
• references/template-creator-meta.md — paste-able template for booting a new creator
• references/brand-discipline-framework.md — voice-rule framework (creator-agnostic)
• references/composition-with-acos.md — how creator-meta plugs into ACOS v11