について
このClaudeスキルは、マーケティングおよびクリエイターエコノミー製品を構築するための必須ドメイン知識を提供し、アーキテクトやPMが主要既存企業に対する素朴な仕様策定を回避できるようにします。コンテンツスケジューリング、分析、収益化、スポンサーシップCRMという4つの主要製品領域について、必要な語彙、ビジネスルール、エンティティモデルを提供します。仕様書作成時に本スキルを活用することでドメインを正確にモデル化でき、特に戦略的機会としてスポンサーシップCRMに焦点を当てることが特筆されます。
クイックインストール
Claude Code
推奨npx 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-creatorこのコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします
ドキュメント
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.
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.
関連スキル
このスキルは、Content Collections(Markdown/MDXファイルを型安全なデータコレクションに変換するTypeScriptファーストのツール)の本番環境でテストされた設定を提供します。Zodバリデーションによる型安全性を実現し、ブログ、ドキュメントサイト、コンテンツ重視のVite + Reactアプリケーション構築時にご利用ください。Viteプラグインの設定、MDXコンパイルから、デプロイ最適化、スキーマバリデーションまで、すべてを網羅しています。
このスキルは、開発者がPolymarket予測市場プラットフォームを活用したアプリケーション構築を可能にします。API統合による取引や市場データの取得に加え、WebSocketを介したリアルタイムデータストリーミングにより、ライブ取引や市場活動を監視できます。取引戦略の実装や、ライブ市場更新を処理するツールの作成にご利用ください。
このスキルは、開発者がコマンド、ファイル、LSP操作など25種類以上のイベントタイプにフックするOpenCodeプラグインを作成することを支援します。JavaScript/TypeScriptモジュール向けに、プラグイン構造、イベントAPI仕様、および実装パターンを提供します。カスタムイベント駆動ロジックでOpenCode AIアシスタントのライフサイクルをインターセプト、監視、または拡張する必要がある場合にご利用ください。
SGLangは、高性能なLLMサービングフレームワークであり、RadixAttentionプレフィックスキャッシュを活用したJSON、正規表現、エージェントワークフロー向けの高速で構造化された生成を特長とします。特にプレフィックスが繰り返されるタスクにおいて、大幅に高速な推論を実現し、複雑な構造化出力やマルチターン対話に最適です。制約付きデコードが必要な場合や、広範なプレフィックス共有を伴うアプリケーションを構築する場合は、vLLMなどの代替案ではなくSGLangを選択してください。
