Writing Slash Commands

Writing Slash Commands

Overview

Writing slash commands IS Test-Driven Development applied to command documentation.

You write test cases (arguments to test), watch them fail (wrong logic), fix the logic, watch tests pass, and refactor.

Core principle: If you didn't watch the slash command execute with the SlashCommand tool, you don't know if the logic works.

REQUIRED BACKGROUND: You MUST understand writing-skills skill before using this. This skill adapts TDD methodology to slash commands.

TDD Mapping for Slash Commands

The Iron Law

NO SLASH COMMAND WITHOUT TESTING WITH SlashCommand TOOL FIRST

Mental simulation ≠ actual testing. The SlashCommand tool is the ONLY way to verify logic.

When to Use

Create slash command:

• Test with SlashCommand tool for each argument combination
• Watch it fail/succeed for each input
• Fix logic until all tests pass

Edit existing slash command:

• Test current behavior (RED - document what's wrong)
• Fix logic (GREEN - make tests pass)
• Test edge cases (REFACTOR - handle new scenarios)

Common Failures (From Baseline Testing)

Failure 1: Inverted Conditional Logic

Baseline behavior:

# With NO argument
Output: "Creating commit for $1 branch" ❌
Expected: "Warning: No feature branch provided"

# With argument "my-feature"
Output: "Warning: No feature branch provided" ❌
Expected: "Creating commit for my-feature branch"

Root cause: IF/ELSE conditions backwards, not tested

Solution: Test BOTH branches with SlashCommand tool

Failure 2: Untested Variable Substitution

Baseline behavior:

• Output shows literal "$1" instead of argument value

Root cause: Assumed $N substitution works without testing

Solution: Verify variables substitute correctly in output

Failure 3: Unverified Path References

Baseline behavior:

• Command references git-and-github/create-git-commit skill
• Actual path: .claude/skills/create-git-commit/SKILL.md

Root cause: Trust mental model of paths without verification

Solution: Verify all referenced paths exist before deploying

Testing Workflow (RED-GREEN-REFACTOR)

RED: Document Current Behavior

Use subagent with SlashCommand tool to test:

Task: Test the slash command at [path] with these arguments:
1. No arguments
2. One argument: "test-value"
3. Multiple arguments: "arg1" "arg2"

Document EXACT output for each test.

GREEN: Fix Logic to Pass Tests

Fix the slash command logic based on RED phase findings.

REFACTOR: Test Edge Cases

Add tests for:

• Empty strings
• Special characters
• Missing vs empty arguments
• Extra unexpected arguments

Required Tests Before Deploying

For every slash command, test:

• No arguments (if optional)
• One argument (if single arg expected)
• All arguments (if multiple args expected)
• Each conditional branch (test IF and ELSE separately)
• Variable substitution (verify $1, $2, etc. show actual values)
• Referenced paths (verify skills/files exist)

Common Rationalizations

Red Flags - STOP and Test

• Writing conditional logic without testing both branches
• Assuming variable substitution works
• Referencing paths without verifying
• "This is simple, no need to test"
• Deploying without using SlashCommand tool

All of these mean: Stop. Test with SlashCommand tool.

Slash Command Testing Checklist

Before deploying ANY slash command:

• Used subagent with SlashCommand tool to test
• Tested with NO arguments (documented behavior)
• Tested WITH arguments (documented behavior)
• Tested EACH conditional branch (IF, ELSE, ELSE IF)
• Verified variable substitution ($1, $2) works correctly
• Verified all referenced paths/skills exist
• Fixed any bugs found during testing
• Re-tested after fixes to confirm resolution

The Bottom Line

Mental simulation found ZERO bugs. SlashCommand tool testing found FOUR bugs.

Test with SlashCommand tool. Every time. No exceptions.