Files
gh-cskiro-claudex/skills/meta/skill-creator/patterns/mode-based.md
2025-11-29 18:16:40 +08:00

2.3 KiB

Mode-Based Skill Pattern

Use this pattern when your skill has multiple distinct operating modes based on user intent.

When to Use

  • Skill performs fundamentally different operations based on context
  • Each mode has its own workflow and outputs
  • User intent determines which mode to activate
  • Examples: git-worktree-setup (single/batch/cleanup/list modes)

Structure

Quick Decision Matrix

Create a clear mapping of user requests to modes:

User Request                → Mode          → Action
───────────────────────────────────────────────────────────
"trigger phrase 1"          → Mode 1        → High-level action
"trigger phrase 2"          → Mode 2        → High-level action
"trigger phrase 3"          → Mode 3        → High-level action

Mode Detection Logic

Provide clear logic for mode selection:

// Mode 1: [Name]
if (userMentions("keyword1", "keyword2")) {
  return "mode1-name";
}

// Mode 2: [Name]
if (userMentions("keyword3", "keyword4")) {
  return "mode2-name";
}

// Ambiguous - ask user
return askForClarification();

Separate Mode Documentation

For complex skills, create separate files for each mode:

skill-name/
├── SKILL.md                 # Overview and mode detection
├── modes/
│   ├── mode1-name.md       # Detailed workflow for mode 1
│   ├── mode2-name.md       # Detailed workflow for mode 2
│   └── mode3-name.md       # Detailed workflow for mode 3

Example: Git Worktree Setup

Modes:

  1. Single Worktree - Create one worktree
  2. Batch Worktrees - Create multiple worktrees
  3. Cleanup - Remove worktrees
  4. List/Manage - Show worktree status

Detection Logic:

  • "create worktree for X" → Single mode
  • "create worktrees for A, B, C" → Batch mode
  • "remove worktree" → Cleanup mode
  • "list worktrees" → List mode

Best Practices

  1. Clear Mode Boundaries: Each mode should be distinct and non-overlapping
  2. Explicit Detection: Provide clear rules for mode selection
  3. Clarification Path: Always have a fallback to ask user when ambiguous
  4. Mode Independence: Each mode should work standalone
  5. Shared Prerequisites: Extract common validation to reduce duplication