Claude Code Commands vs Skills: 2026 GTM Automation Guide

I spent six months as an SDR at Salesforce copying the same prospecting sequences into our sales engagement platform. Every account required the same research playbook, the same qualification criteria, the same handoff notes. When I moved to AWS, I did it again. Different CRM, same manual repetition.

Fast forward to 2026, and I'm watching GTM teams make the same mistake with Claude Code—manually typing instructions for account research, signal analysis, and outreach generation when they should be building reusable automation systems. The confusion? Understanding claude code commands vs skills and how the unified architecture actually works.

Here's what changed in 2026: skills and slash commands merged into a single extensibility system. If you're still thinking of them as separate features, you're building on deprecated patterns. This guide breaks down the actual architecture, when to use commands versus skills versus agents, and how we're using this at my agency to automate 80% of our intent data workflows.

The 2026 Unified Architecture: What Actually Changed

The old mental model was wrong. Pre-2026, developers thought about slash commands as built-in shortcuts and skills as custom extensions. That separation never really existed in the codebase—it was just how Anthropic documented the features.

In 2026, Claude Code formalized what was always true: skills ARE the slash command system. Every `/command` you execute—whether built-in or custom—runs through the same skill execution engine. The folder at `~/.claude/skills/` isn't a separate feature; it's the extensibility layer for the entire command architecture.

This matters for GTM engineering because it changes how you build automation. Instead of choosing between 'should I make this a command or a skill,' you're actually choosing between user-invoked workflows (slash commands) and agent-invoked capabilities (agent skills).

The practical difference: A slash command skill waits for `/trigger` input from a human. An agent skill can be autonomously called by Claude during its reasoning process. Both use the same `SKILL.md` file structure, same folder architecture, same execution context.

Commands vs Skills: The Real Distinction

Agent skills (autonomous capabilities) shine when the task is a component of a larger workflow, not the workflow itself. These are the building blocks agents combine during reasoning.

In our GTM stack, agent skills handle data transformation, validation, formatting—tasks where consistency matters more than judgment. The agent decides when to invoke them based on context, not manual triggering.

• enrich_contact_data — Agent skill that normalizes contact records from multiple sources (Apollo, ZoomInfo, Clearbit) into our standard schema. Called automatically during account research.
• score_buying_signals — Applies our ICP scoring model to intent data. Agent uses this within broader prioritization logic.
• format_crm_notes — Structures unstructured research into Salesforce field mappings. Invoked as final step of research workflows.
• validate_email_syntax — Checks deliverability before sequence building. Agent calls this without asking.

Decision Framework: Which to Build When

The third column is critical. I see teams building skills for things that belong in `CLAUDE.md` project files. Project instructions are not skills. If you want Claude to always format code in a specific style, that's a project configuration. If you want Claude to generate code in response to a specific command, that's a skill.

Here's a real example that clarifies the boundary: We have a `CLAUDE.md` file in our GTM automation repo that says 'always structure Salesforce API calls with error handling and retry logic.' That's a project instruction—applies universally, no trigger needed.

We also have a `/sync-to-sfdc` slash command skill that packages research outputs and pushes them to Salesforce. That's a discrete workflow triggered on-demand after research is complete and reviewed.

And we have an agent skill `validate_sfdc_fields` that checks data against our CRM schema before syncing. The agent invokes this autonomously within the `/sync-to-sfdc` workflow—no human trigger, no manual invocation.

GTM Use Cases: Signal-Based Selling Automation

This architecture reduces account research time from 45 minutes to 6 minutes while maintaining quality. The key: automation handles data gathering and formatting (agent skills), humans handle judgment and customization (slash commands).

The mistake I see teams make is trying to automate steps 3-5. Those require context about your GTM strategy, competitive positioning, and account-specific nuance. A fully autonomous agent will generate generic outreach. A slash command with rich context from prior steps generates campaigns that convert at 3.2x our previous benchmark.

1. Step 1: Signal Detection (Automated) — MCP server monitors intent data sources (6sense, Bombora, G2, LinkedIn). When multiple signals converge (tech stack change + funding + job openings), triggers alert.
2. Step 2: Initial Enrichment (Agent Skill) — Agent automatically enriches company data—headcount, tech stack, recent news, org chart. Uses agent skills for data normalization and validation. No human intervention needed.
3. Step 3: Account Prioritization (Slash Command) — Human SDR/AE runs `/prioritize-account [domain]` command. This skill analyzes enriched data against ICP criteria, scores account fit, identifies best entry points. Output requires human review.
4. Step 4: Research Deep Dive (Slash Command) — If prioritization score >75, SDR runs `/research-account [domain] [persona]`. This generates personalized talking points, competitive positioning, technical use cases. Context-heavy, needs human judgment.
5. Step 5: Sequence Generation (Slash Command) — `/build-sequence [account_id] [campaign_type]` creates multi-touch outreach. Uses agent skills internally for formatting and CRM field mapping, but workflow is human-triggered.
6. Step 6: CRM Sync (Agent Skill) — After human approves, agent skills handle data transformation and Salesforce sync. Fully automated final mile.

Building Skills for Account Prioritization

Section 1: Purpose and Context—Define what this skill does and why it exists. This isn't just documentation; Claude uses this during execution to stay on-track. We include our ICP definition, scoring criteria, and output requirements.

Section 2: Input Parameters—What data does the skill need? For account prioritization, we require company domain (mandatory), industry vertical (optional), and known intent signals (optional). The skill handles missing data gracefully by using agent skills to fetch it.

Section 3: Execution Logic—Step-by-step process. This is where the slash command vs agent skill distinction shows up. Our prioritization command invokes several agent skills (enrich_company, score_technographics, identify_champions) but the overall workflow is user-triggered.

Section 4: Output Format—Critical for downstream automation. We specify exact JSON schema for CRM sync, required fields, and conditional logic for different account tiers.

The power of this approach: we've run this skill 847 times in the last 90 days (yes, I track metrics on our automation). Consistency is 94% compared to manual research variance of 60-70%. SDRs get the same quality analysis whether they're targeting a Series A SaaS company or a Fortune 500 enterprise.

Integration Patterns: MCP and Intent Data Sources

The integration pattern: skills call MCP servers, MCP servers call external APIs. This abstraction means you can swap data providers without rewriting skills. When we migrated from Bombora to 6sense for intent data, zero skills required updates—only the MCP server configuration changed.

For teams building this stack, start with read-only MCP servers. Get comfortable with data retrieval before enabling write operations to your CRM. We ran read-only for 6 weeks, validating output quality, before allowing automated Salesforce updates. That caution prevented 3 potential data corruption incidents.

• Salesforce MCP Server — Read/write access to our CRM. Skills query account history, opportunity stages, contact engagement. Also handles data sync from research workflows.
• 6sense Intent API MCP — Pulls account-level buying signals—keyword research, content consumption, competitor page views. Our prioritization skills weight 6sense data at 35% of total account score.
• Clearbit MCP Server — Company and contact enrichment. Agent skills use this for data normalization—turning messy LinkedIn profiles into structured CRM records.
• Apollo.io MCP — Contact discovery and validation. When building sequences, skills query Apollo for verified email addresses and mobile numbers.
• G2 Review MCP — Competitive intelligence. Skills analyze what accounts say about competitors in G2 reviews, extract pain points, identify switching triggers.

Performance and Context Management

This tiered approach reduced average skill execution time from 47 seconds to 12 seconds and eliminated timeout errors. The trade-off: skills need conditional logic to request additional context tiers when analysis requires it.

Another optimization: agent skills should be stateless. Don't load project context or conversation history in skills meant for data transformation. Our `format_crm_notes` agent skill used to reference the full chat history to 'understand context'—this added 5,000 tokens per invocation. We refactored to only accept explicit input parameters, cutting token usage by 85%.

For slash command skills where human review happens, we optimize differently. These skills produce markdown reports, comparison tables, decision frameworks—human-readable outputs that justify the larger context windows. A 25,000 token execution is acceptable if it saves an SDR 40 minutes of manual research.

• Tier 1: Metadata Only — Company name, domain, industry, employee count, known tech stack. ~500 tokens. Loaded for every account.
• Tier 2: Recent Activity — Last 90 days of CRM activity, recent intent signals, current opportunities. ~3,000 tokens. Loaded if Tier 1 indicates active account.
• Tier 3: Complete History — Full relationship history, all stakeholders, every touchpoint. ~15,000+ tokens. Only loaded for strategic/enterprise accounts where depth matters.

Team Deployment and Version Control

``` gtm-automation-skills/ ├── skills/ │ ├── research-account/ │ │ └── SKILL.md │ ├── prioritize-account/ │ │ └── SKILL.md │ ├── build-sequence/ │ │ └── SKILL.md │ └── … ├── agent-skills/ │ ├── enrich_contact/ │ │ └── SKILL.md │ ├── score_signals/ │ │ └── SKILL.md │ └── … ├── mcp-configs/ │ ├── salesforce.json │ ├── 6sense.json │ └── … ├── tests/ │ └── skill-tests.md └── README.md ```

Slash command skills live in `/skills`, agent skills in `/agent-skills`. This separation makes permissions management easier—we give junior SDRs access to commands but restrict who can modify agent skills that handle CRM writes.

Version control for skills is different than code. There's no compilation, no unit tests (yet). Our testing process: example-based validation. Each skill has a companion test file with 5-10 example scenarios and expected outputs. Before merging skill updates, we manually run test cases and verify results.

For deployment, we use a simple shell script that symlinks the repo to `~/.claude/skills/` and sets up MCP server configurations. New team members run one command, authenticate to MCP servers, and have the full GTM automation stack operational in under 10 minutes.

The biggest team deployment challenge: prompt drift. Team members modify skills locally for one-off use cases, forget to commit changes, and create inconsistent versions across machines. We've implemented a weekly 'skill sync' process—automated script that checks for uncommitted changes and alerts in Slack. Reduced drift incidents by 90%.

Real Examples from Production GTM Workflows

Let's close with actual skills we run daily. These aren't sanitized examples—they're production code with real performance metrics.

Example 1: `/trigger-research` - Signal-Based Account Research

This slash command fires when our intent monitoring system detects buying signals. Takes company domain and signal type as inputs, orchestrates 4 agent skills, produces prioritized research brief.

Input: Company domain, signal type (funding/hiring/tech_change/competitor_eval)

Agent skills invoked: enrich_company, analyze_tech_stack, score_buying_intent, identify_stakeholders

Output: Markdown report with account fit score, recommended entry strategy, personalized talking points, and next actions

Performance: Average execution 18 seconds, 12,500 tokens consumed, used 347 times last month

Impact: Replaced 30-40 minutes of manual research per account. SDR adoption: 100% (it's now mandatory workflow)

Example 2: `validate_contact_data` - Agent Skill for Data Quality

This agent skill runs autonomously during sequence building. Validates contact records against multiple data sources, flags discrepancies, normalizes formatting.

Inputs: Contact object (JSON with email, name, title, company)

External calls: Apollo verification API, email validation service, LinkedIn profile check

Output: Validated contact object + confidence score + data quality flags

Performance: 3.2 seconds average, 800 tokens, invoked 1,200+ times weekly

Impact: Reduced bounce rates on sequences from 18% to 4.2%. Prevented sending to 156 invalid contacts last month.

Example 3: `/competitive-intel` - Slash Command for Battlecard Generation

When deals enter 'Evaluation' stage with known competitors, AEs run this to generate custom battlecards. Pulls G2 reviews, analyzes competitor positioning, suggests differentiators.

Input: Opportunity ID, known competitors (optional)

Data sources: G2 MCP server, competitive intelligence database, win/loss analysis records

Output: Structured battlecard with feature comparison, customer proof points, objection handling, pricing positioning

Performance: 35 seconds average (acceptable for monthly use), 28,000 tokens

Impact: AEs report 40% reduction in eval cycle time for competitive deals. Win rate increased from 31% to 47% when battlecards used.

What makes these production-ready versus prototype: error handling, graceful degradation, and output validation. Each skill has fallback logic when MCP servers are unavailable, validates input parameters before execution, and structures outputs for downstream automation.

Frequently Asked Questions

Key Takeaways

• Skills and slash commands are now unified—the distinction is user-invoked workflows (slash commands) vs agent-invoked capabilities (agent skills), not separate technical systems.
• Build slash command skills for GTM workflows requiring human judgment (account prioritization, sequence generation, competitive research). Build agent skills for deterministic tasks (data validation, formatting, enrichment).
• MCP servers separate data access from workflow logic—connect to intent data sources, CRMs, and enrichment APIs through MCP, then build skills that orchestrate these data sources.
• Context window optimization is critical at scale—implement tiered data loading, keep agent skills stateless, and monitor token consumption to prevent timeouts and degraded performance.
• Signal-based selling requires hybrid automation—use agent skills for data gathering and formatting (automated), slash commands for research and customization (human-in-the-loop). This combination reduced our account research time by 87% while improving quality.
• Version control and team deployment prevent skill drift—store skills in Git, use symlinks for deployment, implement testing with example scenarios, and audit for uncommitted local changes.
• Production-ready skills include error handling and graceful degradation—validate inputs, implement fallbacks for MCP server failures, structure outputs for downstream automation, and test edge cases before team-wide deployment.

Related Reading

• The Role Replacing Your SDR Team