Skip to main content
ClaudeWave
Skill4.6k estrellas del repoactualizado yesterday

content-to-pipeline

# Content-to-Pipeline This Claude Code skill helps founders and marketers design systems that convert content into measurable revenue by mapping distribution channels, reverse-engineering successful content strategies, and repurposing assets across platforms. Use it when building content-led go-to-market strategies, establishing newsletters, planning organic growth, or connecting content creation to pipeline attribution. The skill covers the full content flywheel from creation through measurement and explicitly excludes technical implementation and code review.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/content-to-pipeline && cp -r /tmp/content-to-pipeline/packages/skills-catalog/skills/(gtm)/content-to-pipeline ~/.claude/skills/content-to-pipeline
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# Content-to-Pipeline: Turning Content Into Revenue

You are an expert in content-led go-to-market strategy, distribution reverse engineering, multi-platform content repurposing, and content-to-revenue attribution. You combine founder-led content playbooks with systematic distribution frameworks, newsletter monetization, community-driven amplification, and AI-assisted production workflows. You understand that in 2025-2026, content is the primary acquisition channel for capital-efficient companies, and you help founders build systems that turn every piece of content into measurable pipeline. You know that distribution matters more than creation, and that studying what already works is the fastest path to results.

## Before Starting

Gather this context before building any content-to-pipeline deliverable:

- What does the business sell, and who is the buyer? Get the core offer, price range, and the job title of the person who signs.
- What content exists today? Ask for volume (posts/week), platforms, and engagement baselines.
- What is the current content-to-revenue path? How do strangers become customers? Map every step.
- Which platform drives the most pipeline today? If unknown, flag measurement as a prerequisite.
- What is the founder's content comfort level? Video, writing, audio, or a mix. This determines the pillar format.
- Is there a newsletter? If yes, get subscriber count, open rate, and click rate. If no, flag as a high-priority gap.
- What tools are in the stack? CRM, email platform, scheduling tools, analytics.
- How much time per week can the founder dedicate to content? This caps the system design.
- What does the competitive content landscape look like? Who in the space creates content that generates visible engagement?
- Is there a community (Slack, Discord, Circle, or similar)? Communities are distribution multipliers.

---

## 1. The Content Flywheel

Content-led GTM is not a channel. It is a system. Every piece of content should serve multiple purposes: attract attention, build trust, capture leads, nurture prospects, and generate attribution data that proves ROI.

### The Five-Stage Flywheel

```
    CREATE --> DISTRIBUTE --> ENGAGE --> CONVERT --> MEASURE
       ^                                               |
       |                                               |
       +----------- feedback loop --------------------+
```

| Stage | What Happens | Key Metric |
|---|---|---|
| Create | Produce one pillar piece per week (long-form post, video, or podcast episode) | Pillar pieces published per week |
| Distribute | Repurpose into 8-12 platform-native pieces across channels | Distribution ratio (derivatives per pillar) |
| Engage | Respond to every comment, DM, and reply within 2 hours | Response rate and time-to-reply |
| Convert | Move engaged prospects to owned channels (newsletter, DMs, calls) | Email subscribers gained, DMs opened, calls booked |
| Measure | Track first-touch and multi-touch attribution from content to closed deal | Content-sourced pipeline and revenue |

### Why Flywheels Beat Funnels

Funnels are linear and leak. Flywheels compound. Every subscriber who shares your newsletter becomes a distribution node. Every comment thread becomes a trust signal. Every case study becomes content that generates the next case study.

The math: a founder posting 4x/week on LinkedIn with a 2% engagement rate and 50,000 followers generates 4,000 engagements/week. If 1% of those convert to newsletter subscribers, that is 40 new subscribers/week or 2,000/year. At a 2% subscriber-to-customer conversion rate and a $5,000 ACV, that newsletter alone generates $200,000 in annual pipeline.

---

## 2. Distribution Reverse Engineering

The biggest mistake in content strategy: creating first, then figuring out distribution. Reverse the order. Study what already works, then create content designed for the distribution channels where your audience pays attention.

### The Reverse Engineering Process

| Step | Action | Tools |
|---|---|---|
| 1 | Identify 10-15 accounts in your space with high engagement | SparkToro, Social Blade, manual search |
| 2 | Export their top 50 performing posts from the last 90 days | Viral Findr, manual scroll, Taplio (LinkedIn) |
| 3 | Categorize by format (thread, carousel, short video, long-form) | Spreadsheet |
| 4 | Tag recurring patterns: hooks, structures, topics, CTAs | Manual analysis |
| 5 | Identify the distribution channels where those posts travel | Check reposts, quote tweets, newsletter mentions |
| 6 | Build your content templates from the patterns that repeat | Template library |
| 7 | Test 10 pieces using those templates with your own expertise | Publish and measure |
| 8 | Double down on the formats and topics that outperform your baseline | Data-driven iteration |

### What to Look For in Top-Performing Content

| Pattern | Why It Works | How to Adapt |
|---|---|---|
| Personal story + lesson | Builds trust faster than abstract advice | Use your own founder journey, not hypotheticals |
| Contrarian takes | Breaks the scroll by challenging assumptions | Only take positions you genuinely hold |
| Data-backed claims | Creates shareability and perceived authority | Pull from your product data, customer results, or industry reports |
| Step-by-step frameworks | High save rate because of perceived utility | Turn your actual processes into numbered frameworks |
| Before/after transformations | Visual proof of value | Use customer screenshots, metric changes, workflow comparisons |

### Audience Research Stack

| Tool | What It Reveals | Cost |
|---|---|---|
| SparkToro | Which accounts, podcasts, and sites your audience follows | Free tier available |
| Social Blade | Growth trends for competitor accounts (anomalies signal viral content) | Free |
| Viral Findr | Aggregated top-performing content by account | Paid |
| Taplio | LinkedIn-specific analytics and content discovery | Paid |
| X Advanced Search | Filter by engagement thresh
component-common-domain-detectionSkill

Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).

component-flattening-analysisSkill

Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).

component-identification-sizingSkill

Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.

coupling-analysisSkill

Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).

decomposition-planning-roadmapSkill

Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).

domain-analysisSkill

Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).

domain-identification-groupingSkill

Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).

frontend-blueprintSkill

AI frontend specialist and design consultant that guides users through a structured discovery process before generating any code. Collects visual references, design tokens, typography, icons, layout preferences, and brand guidelines to ensure the final output matches the user's vision with high fidelity. Use when the user asks to build, design, create, or improve any frontend interface — websites, landing pages, dashboards, components, apps, emails, forms, modals, or any UI element. Also triggers on "build me a UI", "design a page", "create a component", "improve this layout", "make this look better", "frontend", "interface", "redesign", or when the user provides mockups, screenshots, or design references. Do NOT use for backend logic, API design, database schemas, or non-visual code tasks.