Claude Code Skills vs Commands: Transforming B2B Sales in 2026

I've been building GTM automation systems since my SDR days at Salesforce, and the biggest shift I've seen in 2026 isn't another LLM model—it's how we're finally getting serious about **AI infrastructure**. When Anthropic dropped their 32-page Skills Builder Guide in January, it clarified something the community had been confused about for months: the relationship between **claude code skills vs commands**.

Here's what changed: Claude Code merged slash commands into the skills system. What used to be two separate extensibility patterns—skills you could invoke manually and commands that Claude could trigger autonomously—became a single, unified architecture. If you're still thinking about them as separate systems, you're building on deprecated patterns.

This isn't just a technical detail. For B2B sales teams drowning in RevOps complexity, this merge represents the difference between automation that requires constant maintenance and infrastructure that actually scales. At OneAway, we've rebuilt our entire GTM stack around this architecture, and it's cut our client onboarding automation time from 6 hours to 47 minutes. Here's what we've learned.

What Actually Changed in the Skills/Commands Merge

Before January 2026, Claude Code had two extensibility mechanisms: slash commands (user-invoked shortcuts) and skills (AI-invokable capabilities). The distinction seemed clear until you tried to build production workflows. Commands were great for manual triggers but couldn't be autonomously selected by Claude. Skills could be invoked by the AI but felt heavyweight for simple tasks.

The merge collapsed this distinction. Now skills are the primary extensibility pattern, and they support both invocation methods. You can call a skill with `/skill-name` or let Claude select it autonomously based on context. This is codified in the new `SKILLS.md` specification that replaced the old `commands.json` pattern.

Here's what this looks like in practice: A skill is now a folder containing a `skill.md` file with structured instructions. That same skill can be manually triggered when you need it (`/enrich-lead`) or autonomously invoked when Claude detects relevant context in your conversation. The system determines invocation method based on your project configuration and the skill's `autoInvoke` settings.

Why This Matters for RevOps Automation

Revenue operations teams are drowning in tool sprawl. The average B2B company now uses 37 different sales tools according to Blissfully's 2025 SaaS Trends report. Each tool has its own automation layer, and none of them talk to each other without duct-tape integrations.

The skills architecture solves a critical problem: reusable, composable automation primitives. Instead of building point-to-point integrations between Salesforce, Gong, Outreach, and your data warehouse, you build skills that encapsulate specific GTM workflows. Those skills can be triggered manually by reps, automatically by Claude based on conversation context, or orchestrated by your RevOps automation layer.

At OneAway, we rebuilt our lead enrichment workflow as a skill. Previously, this was a Zapier chain with 14 steps that broke every other week. Now it's a single skill (`/enrich-lead`) that calls our data providers, validates the information, writes to Salesforce, and posts to Slack. When it breaks, we edit one file. When we need to change the logic, we update one prompt.

The New Architecture: Skills as First-Class Citizens

The unified skills system has three components that matter for GTM automation:

1. Skill Definition Files — Your `skills/` directory contains folders, each with a `skill.md` that defines the workflow. This is where you specify what the skill does, when it should be invoked, what data it needs, and how it should format output. For sales workflows, this typically includes CRM field mappings, data validation rules, and output templates.
2. Project Context (CLAUDE.md) — Your root `CLAUDE.md` file tells Claude about your business context—your ICP, deal stages, tech stack, and workflow preferences. This is where you define sales-specific concepts like what constitutes a 'qualified lead' or how to handle deal stage transitions. Skills reference this context to make intelligent decisions.
3. Invocation Layer — Skills can be triggered three ways: manual slash commands (`/skill-name`), autonomous selection by Claude when it detects relevant context, or programmatic invocation via MCP (Model Context Protocol) servers. For GTM automation, you typically use manual for rep-initiated workflows and autonomous for intelligence/alerting.

5 Sales Workflows We've Rebuilt Using the New System

Here are the specific workflows we've moved to the unified skills architecture at OneAway, with before/after performance data:

1. Lead Enrichment & Qualification — Before: 8-step Zapier workflow pulling from Clearbit, Apollo, and LinkedIn. Broke 2-3x/month. After: Single `/enrich` skill that orchestrates all data sources. Went from 6min average enrichment time to 43 seconds. More importantly, maintenance dropped from 4 hours/month to ~20 minutes.
2. Account Research Compilation — Before: SDRs manually pulled data from 6 different sources (news, tech stack, hiring, funding, intent signals) into a Google Doc template. Took 35-45 minutes per account. After: `/research-account` skill that autonomously gathers everything and outputs in our standardized format. Now takes 3 minutes. SDR capacity increased by 27%.
3. Deal Room Creation — Before: AEs manually created Notion pages with stakeholder maps, competitive intel, ROI calculations, and proposal templates. Inconsistent formatting made handoffs to CS painful. After: `/create-deal-room` skill that scaffolds everything with data from Salesforce and Gong. Handoff errors dropped 68%.
4. Conversation Intelligence Summaries — Before: Post-call summaries from Gong were decent but generic. Reps rewrote them to match our qualification framework. After: Skill that autonomously processes call transcripts against our MEDDPICC framework, extracts specific data points, and writes to Salesforce. Reps review rather than rewrite. Saves 12 minutes per call.
5. Pipeline Health Alerting — Before: Weekly pipeline reviews where managers manually identified at-risk deals. Reactive. After: Autonomous skill that continuously monitors deal activity, scores risk based on our historical win/loss patterns, and alerts in Slack with specific recommended actions. Catch at-risk deals 8 days earlier on average.

How to Migrate Your Existing Commands to Skills

If you built custom commands in 2025, here's the migration path we used across 17 client implementations:

1. Audit your current commands.json file — List every custom command you've built. For each one, document: what it does, how often it's used (check your logs), whether it needs autonomous invocation, and what data dependencies it has. We found that 40% of commands we'd built were rarely used and could be deprecated.
2. Create your skills/ directory structure — Follow the new convention: `skills/skill-name/skill.md`. Each skill gets its own folder. This seems verbose but enables skill-specific assets (templates, examples, test cases) that make complex workflows maintainable. For GTM teams, organize by workflow category: enrichment, research, deal-management, intelligence.
3. Convert command prompts to skill.md format — The new format is more structured. Include: Purpose (what business problem this solves), Input requirements (what data you need), Process steps (the actual workflow logic), Output format (structured data schema), and Invocation settings (manual, autonomous, or both). This structure makes skills much easier to debug when they break.
4. Test both invocation methods — Verify your skill works via `/skill-name` manual trigger AND can be autonomously selected when relevant. For sales workflows, autonomous invocation requires clear context patterns in your CLAUDE.md. Example: our deal-risk skill autonomously triggers when Claude sees 'pipeline review' or 'forecast' in conversation context.
5. Update your CLAUDE.md with business context — Skills are only as smart as the context you provide. Document your ICP, sales process, qualification framework, tech stack, and data schema. This is where you teach Claude what 'qualified' means for your business. We maintain a 380-line CLAUDE.md that makes our skills incredibly accurate for our specific GTM motion.
6. Deprecate old commands gradually — Don't delete your commands.json immediately. Keep both systems running for 2-3 weeks while your team adapts. Monitor usage logs to verify skills are being adopted. Once usage drops below 5% for legacy commands, remove them. We found a 2-week parallel run eliminated adoption friction.

Building Sales Marketing Alignment with Shared Skills

The unified skills architecture creates something we've never had before: shared automation infrastructure across GTM functions. Previously, sales had their sequences in Outreach, marketing had their workflows in HubSpot, and RevOps built brittle sync jobs to keep everything aligned.

Now we build shared skills libraries. A `/research-account` skill works identically whether called by an SDR during prospecting or by marketing during ABM campaign planning. A `/calculate-fit-score` skill uses the same logic for inbound lead scoring and outbound target account selection. The skill definition becomes the source of truth for 'how we do this workflow.'

This solves the alignment problem that's plagued B2B GTM teams forever. When sales and marketing use different definitions of 'qualified,' you get finger-pointing and missed revenue. When they share skills that encode agreed-upon workflows, alignment is enforced by infrastructure.

We've seen this play out across client implementations: A Series B SaaS company we worked with had 27% of their SQLs rejected by sales because marketing and sales used different qualification criteria. We built a shared `/qualify-lead` skill that encoded their agreed-upon framework. SQL rejection rate dropped to 8% in the first quarter after deployment. Both teams now call the same skill, so they can't drift apart.

Revenue Intelligence That Doesn't Break

Revenue intelligence tools promised to make our deals more predictable. Instead, they became another data source to manually check. The problem: they operated in isolation, generating insights that never made it into actual workflows.

Skills architecture changes this by making intelligence actionable by default. You build intelligence as skills that both analyze data AND trigger actions. A deal risk skill doesn't just flag at-risk opportunities—it suggests specific plays, drafts outreach, and creates tasks in Salesforce.

Here's a specific example: We built a `/analyze-deal-momentum` skill that examines engagement patterns, stakeholder coverage, and timeline alignment. It runs autonomously every Monday morning. When it detects momentum loss, it doesn't just alert the AE—it drafts a re-engagement email based on the most recent conversation, suggests a competitive angle based on the prospect's tech stack, and creates a task with a due date.

This is where the autonomous invocation capability becomes critical. The skill monitors Salesforce continuously and triggers when it detects specific patterns (14+ days since last touchpoint + no champion meeting scheduled + close date within 45 days = high risk). The AE gets a Slack message with a draft action plan, not just a dashboard they have to check.

Token efficiency matters here. Previously, we'd stuff entire deal histories into context windows for analysis. Expensive and slow. Now skills can reference project memory (CLAUDE.md) for business rules and only pull relevant deal data. Our deal momentum skill went from $0.34 per analysis to $0.08, making it economical to run continuously rather than on-demand.

3 Mistakes That Will Break Your GTM Automation

We've now deployed skills-based automation across 17 B2B GTM stacks. Here are the mistakes that consistently cause problems:

1. Building skills that are too granular — Teams coming from API-first thinking try to build atomic skills for every tiny action (read account, write field, send message). This creates coordination overhead. Instead, build skills at the workflow level. A `/enrich-lead` skill should orchestrate all enrichment steps, not just call a single API. We aim for skills that represent complete user intent, not implementation details.
2. Not documenting failure modes — Skills will encounter API errors, missing data, and edge cases. If you don't explicitly document how to handle these in your skill.md, Claude will hallucinate error handling. This causes silent failures that corrupt your CRM. Every skill should have a 'Failure Handling' section specifying: what errors to expect, how to handle each one, whether to retry or alert, and what to log. This reduced our error rate by 73%.
3. Ignoring project context (CLAUDE.md) — Teams build skills with all logic embedded in the skill.md file. This makes sense initially but becomes unmaintainable as you scale. Business rules should live in CLAUDE.md: your ICP definition, qualification framework, data schemas, and workflow preferences. Skills should reference this context, not duplicate it. When you change your ICP, you update CLAUDE.md once, not 14 different skills.

What to Measure When You Deploy Skills

GTM automation often fails because teams don't instrument it properly. You deploy a workflow, it seems to work, then six months later you realize it's been silently producing garbage. Here's what to actually measure:

• Invocation frequency by skill — Which skills get used and how often? Low usage means the skill isn't valuable or isn't discoverable. We maintain a dashboard showing invocations per skill per week. If a skill drops below 5 invocations/week, we either improve it or deprecate it. This prevents skill sprawl.
• Manual vs autonomous trigger ratio — For skills that support both invocation methods, track the ratio. If a skill is set to autonomous but everyone manually triggers it, your context detection isn't working. If it's mostly autonomous but has low adoption, maybe reps don't trust it yet. The ratio tells you if you've built the right interface.
• Time saved per invocation — Measure baseline task completion time (how long did this take manually) vs skill completion time. Our `/research-account` skill saves 37 minutes on average. That's 37 minutes number of invocations hourly SDR cost = measurable ROI. Without this number, you're guessing about value.
• Error rate and error types — What percentage of skill executions fail, and why? API timeout? Missing data? Malformed output? Track errors by type so you can prioritize fixes. Our target is <2% error rate for production skills. Above that and adoption suffers because reps lose trust.
• Output quality scores — For skills that generate content (research summaries, emails, deal analyses), sample outputs weekly and rate them against your quality rubric. We have AEs score `/deal-room` outputs on a 1-5 scale. If scores drop below 4.2, we investigate prompt drift or context degradation.
• Downstream impact metrics — This is where it matters. Does your enrichment skill actually improve qualification accuracy? Does your deal risk skill reduce slipped deals? Connect skill usage to business outcomes. Our `/qualify-lead` skill increased meeting show rate from 54% to 67% because we're better at selecting qualified prospects.

Future-Proofing Your Go-to-Market Operations

The skills architecture isn't just about what you can build today—it's about building automation that won't need to be rewritten in 12 months. Here's how we're thinking about durability:

Abstractions over implementations. Your skills should define workflows in business terms, not technical terms. Instead of 'call Clearbit API, parse JSON, map to SFDC fields,' write 'enrich account with firmographic data using our standard schema.' This makes skills resilient to underlying API changes. When Clearbit changes their response format or you switch to a different provider, you update the implementation layer, not every skill.

Composable primitives. Build small, focused skills that can be combined. We have a `/find-champion` skill that identifies likely champions in an account. It's called by our `/build-account-plan` skill, our `/draft-outreach` skill, and our `/analyze-deal-health` skill. When we improve champion identification logic, all dependent workflows improve automatically.

Version control as a first principle. Your skills directory should be a git repository. Every change gets reviewed. Every deployment gets tagged. This sounds obvious but most teams treat AI automation differently from code. Don't. Treat your skills library like production software because it is. We've rolled back skills changes three times in the past quarter when we detected quality regressions.

The really interesting long-term play: skills as your GTM knowledge base. Your skills library becomes the codified representation of how your company goes to market. New hires don't just read your sales playbook—they see the actual executable workflows. When you iterate your GTM motion, you update skills, and the changes propagate everywhere. Your go-to-market operations become versionable, testable, and deployable infrastructure.

Frequently Asked Questions

Key Takeaways

• Claude merged commands into skills in January 2026, creating a unified system where skills support both manual (`/skill-name`) and autonomous invocation. If you're still building separate commands, you're working with deprecated patterns.
• Skills enable RevOps automation that actually scales by creating reusable workflow primitives. Build once at the workflow level, invoke manually or autonomously, maintain in one place instead of across brittle point-to-point integrations.
• Shared skills libraries solve GTM alignment problems by giving sales and marketing the same executable workflows. When both teams use `/qualify-lead` that encodes agreed-upon criteria, they can't drift apart.
• Separate business rules (CLAUDE.md) from workflow logic (skills) to make automation maintainable. When your ICP changes, update context once, not 14 different skills. This is the difference between automation that lasts 6 months vs 18+ months.
• Instrument your skills like production software: track invocation frequency, error rates, time saved, and downstream business impact. Without measurement, you're guessing about value and won't catch quality regressions until it's too late.
• Build skills at the workflow level, not the API level. A skill should represent complete user intent (research an account, qualify a lead, assess deal risk), not atomic technical actions. This makes workflows usable by reps and maintainable by RevOps.
• The long-term play is skills as executable GTM knowledge. Your skills library becomes the versioned, testable, deployable representation of how your company goes to market. This fundamentally changes how GTM teams capture and scale institutional knowledge.

Related Reading

• The average B2B company now uses **37 different sales tools**