vertical-creator
Acerca de
Esta Habilidad Claude proporciona conocimiento esencial del dominio para construir productos de marketing y de la economía de creadores, asegurando que arquitectos y PMs eviten especificaciones ingenuas frente a los principales actores del mercado. Suministra el vocabulario necesario, las reglas de negocio y los modelos de entidad para cuatro áreas clave de producto: programación de contenido, analíticas, monetización y CRM de patrocinios. Úsela durante la redacción de especificaciones para modelar correctamente el dominio, con un enfoque destacado en el CRM de patrocinios como una oportunidad estratégica.
Instalación rápida
Claude Code
Recomendadonpx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/vertical-creatorCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
Vertical: marketing & creator — undercut the take-rate, own the white space
Creators monetize an audience across channels they don't control. Their economics are dominated by take-rate (the platform's cut) and by brand sponsorships that most creators still manage in spreadsheets. Two of the four products here (scheduling, analytics) sit in red oceans owned by entrenched incumbents; one (sponsorship-crm) sits in genuine white space. Spec against that asymmetry — don't lead with the commodity.
1. Domain vocabulary
- CPM (cost per mille) — ad/sponsor price per 1,000 impressions. The supply side.
- RPM (revenue per mille) — revenue the creator actually earns per 1,000 views/opens, net of platform cut. RPM < CPM; the gap is fees and unfilled inventory.
- Sponsorship / brand deal — a brand pays a creator to promote a product. The unit of white-space revenue here.
- Fee model — how a deal pays: flat fee (fixed $ per deliverable), affiliate (% of referred sales), or CPA (cost-per-action — $ per signup/install). A single deal can mix them (flat + affiliate).
- Deliverables — the concrete asset(s) owed: posts, stories, dedicated email, video integration (a segment inside a longer video), etc. Each has a channel and a due date.
- Usage rights — whether/how long the brand may reuse the creator's content (e.g. "whitelisting" to run as paid ads). Priced separately; easy to give away by accident.
- Media kit — the creator's sales one-pager: audience size, demographics, engagement, past brands.
- Rate card — the creator's published prices per deliverable type. The negotiation anchor.
- Audience demographics — geo, age, gender split — what a brand buys against.
- Engagement rate — interactions ÷ reach/followers. The quality signal brands price on.
- Take rate (platform cut) — the % a monetization platform skims (Substack ~10%, Patreon 8–12%). The single biggest competitive lever in this vertical.
- MRR — monthly recurring revenue from memberships/subscriptions; the membership KPI.
- UTM — campaign tracking params on a link; the raw input to attribution.
- Cross-channel attribution — crediting a conversion/revenue back to the right channel and post across platforms with different IDs. Hard, and the analytics moat.
2. Non-obvious domain rules
- Scheduling and analytics are RED OCEANS — do not lead there. Buffer, Hootsuite, and Later own cross-channel scheduling; every analytics vendor re-skins channel dashboards. Building "yet another scheduler" is a commodity play with no wedge. These two only earn their place as the connective tissue of a suite, never as the entry point.
- Sponsorship management is WHITE SPACE — this is the real wedge. Most creators track brand sponsors, deals, and deliverables in spreadsheets. There is no entrenched category leader. A purpose-built sponsorship CRM is the one product here with a defensible reason to exist on day one.
- Monetization platforms take 8–12% — undercut on take-rate. The competitive lever is not features, it's the cut. If the incumbent takes 10% and you take 3%, that is the pitch. Take-rate must be a first-class, configurable design decision, not an afterthought.
- Each social channel has a different API and content shape. A "post" is not one thing: an X post, an IG story, a YouTube integration, and an email all differ in format, limits, metrics, and auth. Normalize at the model layer; never assume one channel's shape.
- Brand deals carry deliverables + usage rights + payment milestones. A deal is not a line item — it's a small project: multiple deliverables across channels, usage-rights terms, and staged payments (e.g. 50% on signing, 50% on go-live). Model all three.
3. What a naive build gets wrong
- Building yet another scheduler — treating content-scheduler as the hero product. It's a commodity in a red ocean; shipped standalone it competes head-on with Buffer and loses.
- sponsorship-crm as a generic CRM — modeling a "deal" as a contact + amount + stage misses the domain. It needs deliverables, rate card, usage rights, fee model, and payment milestones — a generic pipeline CRM captures none of these.
- Analytics that just re-skins one channel — pulling YouTube Studio numbers into a prettier chart adds nothing. The only defensible analytics is normalized cross-channel with attribution, not a single-channel mirror.
- Monetization that ignores take-rate as the lever — copying Substack's feature set at Substack's 10% cut. If take-rate isn't the design center, there's no reason to switch.
4. Must-model entities
Spec these explicitly; they recur across the four products. Build them [[migration-ready-schema]] (stable external IDs, soft-delete, audit timestamps) because creators arrive mid-stream from spreadsheets and incumbents and import open deals + members.
- Sponsor — the brand: contact(s), past deals, status. Distinct from the Deal.
- Deal — the unit of sponsorship revenue: stage (prospect → negotiating → signed → delivering → paid), fee model (flat / affiliate / CPA, possibly mixed), deliverables (each with channel + due date + status), usage rights (scope + duration), and payment milestones (amount + trigger + paid state). This is the white-space product — model it richly.
- MediaKit / RateCard — audience stats + demographics + engagement (media kit) and per-deliverable prices (rate card). The sales surface; feeds the Deal negotiation.
- ScheduledPost — one logical post with per-channel variants (content, format, limits, asset refs differ per channel), schedule time, and publish status per channel. Never a single body string shared across channels.
- ChannelMetric — a normalized cross-channel metric row (channel, post ref, metric type, value, period) so analytics can sum/compare across platforms with different native IDs.
- Membership / Paywall tier — name, price, interval, take-rate, entitlements, member count; the unit of recurring (MRR) monetization.
5. Per-product notes (wedge vs incumbent + the one thing to nail)
- sponsorship-crm (crm) — THE WEDGE. White space. Creators do this in spreadsheets; no category leader. Must nail: the Deal as a project, not a contact — deliverables + rate card + usage rights + fee model + payment milestones, with a stage machine. A generic CRM is a non-answer. See [[vertical-onboarding]]: first activation = first sponsor + deal imported off the spreadsheet.
- monetization (content) — wedge: undercut take-rate. Paywalls, memberships, tips at 3% vs incumbents' 8–12%. Must nail: take-rate as a first-class, configurable design center and MRR tracking; consent for member comms defers to [[lifecycle-messaging]].
- content-scheduler (content) — commodity, red ocean. Only worth building as the publishing layer of the suite, never standalone. Must nail: per-channel post variants (one calendar, N channel shapes) — that's the only non-commodity part.
- analytics (dashboard) — commodity unless cross-channel. A single-channel re-skin is worthless. Must nail: normalized cross-channel metrics + attribution; ingestion of each channel's API is a [[connector-builder]] job, not bespoke glue.
6. Compliance (light)
Keep this proportionate — defer money-movement and message-sending specifics to the relevant engineer/skill.
- FTC disclosure — sponsored content must be clearly disclosed (
#ad/ "sponsored" / paid-partnership label). If the product publishes brand deals, surface and enforce the disclosure as part of the deliverable, not an optional toggle. - 1099 for creator income — creators (and their sponsors/affiliates) generate reportable income; if the product touches payouts, track payee tax info for 1099-NEC/1099-K (US). Note it; don't build a tax engine into a CRM.
- Email/SMS consent for membership comms — member announcements and lifecycle sends need consent (CAN-SPAM/TCPA, double opt-in, suppression). Defer the deliverability + consent posture entirely to [[lifecycle-messaging]].
- Platform ToS for cross-posting — each channel's terms govern API auth, automation, and re-posting. Cross-channel publishing must respect per-platform rate limits and automation rules; don't assume one channel's allowances apply to all.
Output
When applied, contribute a Domain model note to the architecture doc capturing: the products in scope and which are commodity vs wedge (sponsorship-crm = white space), the must-model entities above that this product owns, the take-rate decision if monetization is in scope, the Deal shape (deliverables + usage rights + fee model + payment milestones) if sponsorship-crm is in scope, and the per-channel variant + normalized cross-channel contract if scheduler/analytics is in scope.
Repositorio GitHub
Frequently asked questions
What is the vertical-creator skill?
vertical-creator is a Claude Skill by avelikiy. Skills package instructions and resources that Claude loads on demand, so Claude can perform vertical-creator-related tasks without extra prompting.
How do I install vertical-creator?
Use the install commands on this page: add vertical-creator to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does vertical-creator belong to?
vertical-creator is in the Meta category, tagged ai, design and data.
Is vertical-creator free to use?
Yes. vertical-creator is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.
Habilidades relacionadas
Esta habilidad proporciona una configuración probada en producción para Content Collections, una herramienta centrada en TypeScript que transforma archivos Markdown/MDX en colecciones de datos con tipado seguro mediante validación Zod. Úsala al construir blogs, sitios de documentación o aplicaciones Vite + React con mucho contenido para garantizar seguridad de tipos y validación automática de contenido. Abarca todo, desde la configuración del plugin de Vite y compilación MDX hasta la optimización de despliegue y validación de esquemas.
Esta habilidad permite a los desarrolladores crear aplicaciones con la plataforma de mercados de predicción Polymarket, incluyendo la integración de API para operaciones y datos de mercado. También proporciona transmisión de datos en tiempo real a través de WebSocket para monitorear operaciones en vivo y actividad del mercado. Úsela para implementar estrategias de trading o crear herramientas que procesen actualizaciones de mercado en tiempo real.
Esta habilidad ayuda a los desarrolladores a crear complementos de OpenCode que se conectan a más de 25 tipos de eventos, como comandos, archivos y operaciones LSP. Proporciona la estructura del complemento, las especificaciones de la API de eventos y los patrones de implementación para módulos en JavaScript/TypeScript. Úsala cuando necesites interceptar, monitorear o extender el ciclo de vida del asistente de IA de OpenCode con lógica personalizada basada en eventos.
SGLang es un framework de alto rendimiento para el servicio de LLM que se especializa en generación rápida y estructurada para JSON, expresiones regulares y flujos de trabajo de agentes utilizando su caché de prefijos RadixAttention. Ofrece una inferencia significativamente más rápida, especialmente para tareas con prefijos repetidos, lo que lo hace ideal para salidas complejas y estructuradas, y conversaciones multiturno. Elige SGLang sobre alternativas como vLLM cuando necesites decodificación restringida o estés construyendo aplicaciones con uso extensivo de prefijos compartidos.
