Skip to main content
Commands are explicit actions you trigger using slash syntax. They’re perfect for structured, repeatable workflows you want to invoke on demand.

​
What is a command

A command is a markdown file that defines a specific workflow Claude executes when you invoke it: 
commands/
├── call-summary.md
├── pipeline-review.md
└── forecast.md
Invoke with slash syntax: 
/call-summary <paste your notes here>
/pipeline-review Q1
/forecast
Command names are automatically prefixed with the plugin name: /sales:call-summary or simply /call-summary if there’s no naming conflict.

​
Command structure

Every command file includes frontmatter and execution instructions:
call-summary.md
---
description: Process call notes or a transcript — extract action items, draft follow-up email, generate internal summary
argument-hint: "<call notes or transcript>"
---

# /call-summary

Process call notes or a transcript to extract action items, draft follow-up 
communications, and update records.

## Usage

/call-summary <notes or transcript>

Process these call notes: $ARGUMENTS

If a file is referenced: @$1

​
Frontmatter fields

​
description
string
required
What the command does (shown in autocomplete)
​
argument-hint
string
Placeholder text showing expected arguments

​
Arguments and variables

Commands can accept arguments that get passed to Claude:

​
Basic arguments

/call-summary <notes or transcript>
Access with $ARGUMENTS: 
Process these call notes: $ARGUMENTS

​
File references

Commands can reference files with @ syntax: 
/call-summary @meeting-transcript.txt
Access specific files with positional variables: 
If a file is referenced: @$1

/call-summary @transcript.txt
# Claude receives: @$1 (the transcript file)

​
Real example: Call summary command

The sales plugin’s /call-summary command processes call notes:
call-summary.md
---
description: Process call notes or a transcript — extract action items, draft follow-up email, generate internal summary
argument-hint: "<call notes or transcript>"
---

# /call-summary

Process call notes or a transcript to extract action items, draft follow-up 
communications, and update records.

## Usage

/call-summary <notes or transcript>

Process these call notes: $ARGUMENTS

---

## How It Works

┌─────────────────────────────────────────────────────────────────┐
│                      CALL SUMMARY                                │
├─────────────────────────────────────────────────────────────────┤
│  STANDALONE (always works)                                       │
│  ✓ Paste call notes or transcript                               │
│  ✓ Extract key discussion points and decisions                  │
│  ✓ Identify action items with owners and due dates              │
│  ✓ Surface objections, concerns, and open questions             │
│  ✓ Draft customer-facing follow-up email                        │
│  ✓ Generate internal summary for your team                      │
├─────────────────────────────────────────────────────────────────┤
│  SUPERCHARGED (when you connect your tools)                      │
│  + Transcripts: Pull recording automatically                     │
│  + CRM: Update opportunity, log activity, create tasks          │
│  + Email: Send follow-up directly from draft                    │
│  + Calendar: Link to meeting, pull attendee context             │
└─────────────────────────────────────────────────────────────────┘

​
Output sections

The command specifies exactly what to generate: 
## Output

### Internal Summary

## Call Summary: [Company] — [Date]

**Attendees:** [Names and titles]
**Call Type:** [Discovery / Demo / Negotiation / Check-in]

### Key Discussion Points
1. [Topic] — [What was discussed, decisions made]
2. [Topic] — [Summary]

### Action Items
| Owner | Action | Due |
|-------|--------|-----|
| [You] | [Task] | [Date] |
| [Customer] | [Task] | [Date] |

### Customer Follow-Up Email

Subject: [Meeting recap + next steps]

Hi [Name],

Thank you for taking the time to meet today...

​
Real example: Pipeline review command

The /pipeline-review command analyzes deal health:
pipeline-review.md
---
description: Analyze pipeline health — prioritize deals, flag risks, get a weekly action plan
argument-hint: "<segment or rep>"
---

# /pipeline-review

Analyze your pipeline health, prioritize deals, and get actionable 
recommendations for where to focus.

## Usage

/pipeline-review [segment or rep]

Review pipeline for: $ARGUMENTS

​
Multiple input modes

The command supports different ways to provide data: 
## What I Need From You

**Option A: Upload a CSV**
Export your pipeline from your CRM. Helpful fields:
- Deal/Opportunity name
- Account name
- Amount
- Stage
- Close date

**Option B: Paste your deals**
Acme Corp - $50K - Negotiation - closes Jan 31 - last activity Jan 20
TechStart - $25K - Demo scheduled - closes Feb 15 - no activity in 3 weeks

**Option C: Describe your pipeline**
"I have 12 deals. Two big ones in negotiation..."

​
Structured analysis

Commands can include scoring frameworks: 
## Pipeline Health Score: [X/100]

| Dimension | Score | Issue |
|-----------|-------|-------|
| **Stage Progression** | [X]/25 | [X] deals stuck in same stage 30+ days |
| **Activity Recency** | [X]/25 | [X] deals with no activity in 14+ days |
| **Close Date Accuracy** | [X]/25 | [X] deals with close date in past |
| **Contact Coverage** | [X]/25 | [X] deals single-threaded |

​
Commands vs skills

Choose the right approach for your workflow:

Commands

Use when:
  • You want explicit invocation
  • Workflow is structured and repeatable
  • You need to pass specific arguments
  • You prefer slash-command syntax
Example: /call-summary <transcript>

Skills

Use when:
  • Should activate from conversation
  • Involves judgment and adaptation
  • Can be described different ways
  • No special syntax needed
Example: “Prep me for my call with Acme”
Many workflows have both: a skill for automatic activation and a command for explicit invocation.

​
Connector integration

Commands can leverage MCP connectors: 
## If Connectors Available

**Transcripts connected (e.g. Gong, Fireflies):**
- I'll search for the call automatically
- Pull the full transcript
- Extract key moments flagged by the platform

**CRM connected:**
- I'll offer to update the opportunity stage
- Log the call as an activity
- Create tasks for action items
- Update next steps field

**Email connected:**
- I'll offer to create a draft in your inbox
- Or send directly if you approve
See Connectors for more on tool integration.

​
Style and formatting guidelines

Many commands generate customer-facing content and include style rules: 
## Email Style Guidelines

When drafting customer-facing emails:

1. **Be concise but informative** — Get to the point quickly
2. **No markdown formatting** — Don't use asterisks, bold, or other markdown syntax
3. **Use simple structure** — Short paragraphs, line breaks between sections
4. **Keep it scannable** — Use plain dashes or numbers for lists

**Good:**
Here's what we discussed:
- Quote for 20 seats at $480/seat/year
- W9 and supplier onboarding docs
- Point of contact for the contract

**Bad:**
**What You Need from Us:**
- Quote for 20 seats at $480/seat/year

​
Tips and best practices

Commands often include usage tips: 
## Tips

1. **More detail = better output** — Even rough notes help
2. **Name the attendees** — Helps me structure the summary and assign action items
3. **Flag what matters** — If something was important, tell me: "The big thing was..."
4. **Tell me the deal stage** — Helps me tailor the follow-up tone and next steps

​
Customizing commands

Commands can include customization sections: 
## Company Configuration [CUSTOMIZE]

### Email Signature
[Your preferred signature]

### CRM Fields to Update
- Next steps: [Yes/No]
- Stage: [Auto-update based on call/Manual only]
- Activity log: [Yes/No]

### Follow-up Timing
- Default: Send follow-up within 2 hours
- After hours: Draft and review in morning

​
Command discoverability

Users can discover commands through:
  1. Autocomplete — Type / to see all available commands
  2. Help text — The description field appears in suggestions
  3. Plugin docs — Commands are documented in your plugin’s README
Write clear, concise descriptions. They’re shown in the autocomplete UI.

​
Best practices

Each command should do one thing well. Don’t combine multiple unrelated workflows.
Include multiple examples of how to invoke the command with different argument types.
Give Claude an exact template to follow. This ensures consistency across executions.
Let users provide data via arguments, file references, or manual upload. Be flexible.
Design commands to work without connectors. Tool integrations should enhance, not enable.
If generating customer-facing content, specify tone, formatting, and what to avoid.

​
Next steps

Skills

Learn about automatic skill activation

Connectors

Connect commands to your tools

Build a plugin

Create your own commands

Examples

See more command implementations

Build docs developers (and LLMs) love

Get started for freeTalk to us