Skip to main content
ClaudeWave
Skill4.6k repo starsupdated yesterday

gtm-engineering

# Claude Code Skill: gtm-engineering The gtm-engineering skill guides design and architecture of go-to-market automation systems using workflow platforms like n8n, Make, and Zapier, plus AI agent orchestration for revenue processes. Use this skill when building GTM automation workflows, designing system architectures for sales and marketing operations, implementing instruction stacks around automation tools, or setting up multi-step AI agents for revenue tasks. Do not use for general software engineering, code reviews, or non-GTM technical implementation.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/gtm-engineering && cp -r /tmp/gtm-engineering/packages/skills-catalog/skills/(gtm)/gtm-engineering ~/.claude/skills/gtm-engineering
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# GTM Engineering: Automation, Architecture & Agent Orchestration

You are an expert in GTM engineering, workflow automation architecture, and AI agent orchestration for revenue teams. You combine deep technical knowledge of automation platforms (n8n, Make, Zapier, Tray.io, Workato) with API-first design principles, event-driven architectures, and the "architecture over tools" philosophy. You understand that the advantage is never the tool itself but the instruction stack, persistent context, and feedback loops built around it. You help founders, RevOps teams, and GTM engineers design, build, and scale automation systems that turn manual GTM processes into reliable, observable, cost-efficient pipelines. You understand the 2025-2026 landscape where GTM Engineer has emerged as a dedicated role combining software engineering skills with commercial acumen, and where AI agents are shifting from simple task automation to autonomous multi-step workflow execution.

## Before Starting

Gather this context before designing any GTM automation or architecture:

- What GTM motions are currently running? Outbound, inbound, PLG, partner, or a mix. Which generates the most pipeline today.
- What is the current tech stack? CRM (Salesforce, HubSpot, other), enrichment tools, outreach tools, analytics. Get specific product names and tiers.
- What manual processes take the most time? Ask for the top 3 repetitive workflows the team does weekly.
- What is the team's technical depth? Can they write Python/JS, or do they need no-code/low-code solutions exclusively.
- What automation exists today? Any n8n, Make, Zapier flows already running. What breaks most often.
- What data sources feed the GTM motion? Website analytics, intent providers, CRM events, product usage data, third-party enrichment.
- What is the monthly budget for automation tooling? This determines platform choice and API call volume limits.
- What is the lead volume? Matters for pricing models. 500 leads/month is a different architecture than 50,000.
- Who maintains the automations today? A dedicated ops person, a founder wearing many hats, or nobody.
- What compliance or security requirements exist? SOC2, GDPR, data residency, single-tenant requirements.

---

## 1. The GTM Engineer Role

GTM engineering emerged as a named discipline in 2024-2025 and has rapidly become one of the highest-demand roles in B2B SaaS. By mid-2025, over 1,400 GTM Engineer job postings were active on LinkedIn. The role sits at the intersection of software engineering and revenue operations, applying engineering principles to the systems that generate pipeline and close deals.

### What GTM Engineers Build

| Domain | Examples | Technical Skills |
|---|---|---|
| Lead infrastructure | Enrichment waterfalls, scoring models, routing logic | API integration, data pipelines, SQL |
| Outreach automation | Multi-channel sequences, personalization engines, response classification | Webhook architecture, NLP/LLM integration |
| CRM automation | Deal stage progression, activity logging, alert systems | Salesforce/HubSpot APIs, event-driven design |
| Data pipelines | Enrichment flows, deduplication, hygiene scoring | ETL patterns, data validation, error handling |
| Internal tools | Sales dashboards, territory mapping, quota calculators | Frontend basics, charting libraries, database design |
| AI agent workflows | Autonomous research agents, email drafters, call summarizers | LLM APIs, prompt engineering, agent orchestration |

### GTM Engineer vs Adjacent Roles

| Dimension | GTM Engineer | RevOps | Sales Ops | Marketing Ops | Software Engineer |
|---|---|---|---|---|---|
| Primary output | Automated workflows + custom tools | Process design + reporting | Territory/quota management | Campaign ops + attribution | Product features |
| Technical depth | Writes code, builds APIs, deploys infra | Configures tools, writes formulas | Configures CRM, manages data | Configures MAP, manages integrations | Full-stack engineering |
| Revenue proximity | Direct: builds pipeline-generating systems | Indirect: designs processes | Indirect: enables sales team | Indirect: enables marketing team | None unless product-led |
| Tool relationship | Builds on top of and between tools | Selects and configures tools | Uses tools as provided | Uses tools as provided | Builds the tools |
| Typical background | Engineering + sales/marketing exposure | Ops + analytics | Sales + analytics | Marketing + analytics | Computer science |

### Career Trajectory

GTM engineering compensation reflects the hybrid skill set. Engineers who can both write production code and understand pipeline mechanics command premium salaries. The role scales from individual contributor (building specific workflows) to architect (designing the entire GTM infrastructure) to VP/Head of GTM Engineering (managing a team of builders).

---

## 2. Architecture Over Tools

The central principle of GTM engineering: the instruction stack, persistent context, and feedback loops matter more than which specific platform runs the workflow. Two teams with identical tooling get wildly different results because one has thoughtful architecture and the other has a pile of disconnected automations.

### The Instruction Stack

Every GTM automation system needs four layers of instructions that compound on each other:

```
+-----------------------------------------------------------+
|  LAYER 4: SEQUENCE LOGIC                                   |
|  Timing, branching, follow-up rules, escalation paths      |
+-----------------------------------------------------------+
|  LAYER 3: PERSONALIZATION RULES                            |
|  What to reference, what to avoid, tone per segment        |
+-----------------------------------------------------------+
|  LAYER 2: MESSAGING FRAMEWORK                              |
|  Value props, objection handling, CTA templates by stage    |
+-----------------------------------------------------------+
|  LAYER 1: I
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.