---
name: using-gmd
description: >-
  Use at the start of every conversation -- establishes how to find and use
  skills, requiring Skill tool invocation before ANY response including
  clarifying questions
type: behavioral
trigger-patterns:
  - session start
  - any task
  - tool selection
discipline: flexible
category: meta
tags:
  - discovery
  - skill-invocation
  - meta
---

# Using GMD Skills

<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific task, skip this skill.
</SUBAGENT-STOP>

<EXTREMELY-IMPORTANT>
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.
</EXTREMELY-IMPORTANT>

## Instruction Priority

GMD skills override default system prompt behavior, but **user instructions always take precedence**:

1. **User's explicit instructions** (CLAUDE.md, direct requests) -- highest priority
2. **GMD skills** -- override default system behavior where they conflict
3. **Default system prompt** -- lowest priority

If CLAUDE.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.

## How to Access Skills

**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you -- follow it directly. Never use the Read tool on skill files.

Skills are auto-discovered from installed plugins. The discovery hook indexes all available skills at session start, filtering by the current agent's `skill-scope` for efficiency.

## Invocation Pattern

GMD ships skills under the `gmd` plugin namespace. Slash-invocation
surfaces (Claude Code `/` autocomplete) list every GMD skill as
`/gmd:<name>`, matching the slash-command pattern (`/gmd:plan-phase`,
`/gmd:add-phase`, etc.).

The pattern:

| Surface | Example |
|---------|---------|
| Slash command | `/gmd:plan-phase 17` |
| Slash skill | `/gmd:add-directive` |
| Skill tool (programmatic) | `Skill(name: "add-directive")` -- no namespace prefix when invoked via the Skill tool; the namespace is a slash-surface concern only |

Note: when invoking a skill programmatically via the Claude Code `Skill`
tool, use the bare slug (e.g., `add-directive`, not `gmd:add-directive`).
The `gmd:` prefix is the slash-autocomplete display form, not the
underlying skill identifier.

## Using Skills

### The Rule

**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.

```dot
digraph skill_flow {
    "User message received" [shape=doublecircle];
    "Might any skill apply?" [shape=diamond];
    "Invoke Skill tool" [shape=box];
    "Announce: 'Using [skill] to [purpose]'" [shape=box];
    "Has checklist?" [shape=diamond];
    "Follow skill exactly" [shape=box];
    "Respond (including clarifications)" [shape=doublecircle];

    "User message received" -> "Might any skill apply?";
    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
    "Has checklist?" -> "Follow skill exactly" [label="no"];
    "Has checklist?" -> "Follow skill exactly" [label="yes, track items"];
    "Follow skill exactly" -> "Respond (including clarifications)";
}
```

### Rigid Skill Rule

When invoking any skill with `discipline: rigid`, you MUST ALSO invoke the `rationalization-prevention` skill. This is non-negotiable.

Rigid skills enforce strict behavioral contracts. The rationalization-prevention skill provides the immune system that keeps you honest. Loading a rigid skill without its defense layer is like running antivirus without updating definitions.

**Examples of rigid skills:** test-driven-development, verification-before-completion

### Skill Priority

When multiple skills could apply, use this order:

1. **Process skills first** (debugging, verification) -- these determine HOW to approach the task
2. **Implementation skills second** (frontend-design, domain-specific) -- these guide execution

"Build X" -> process skills first, then implementation skills.
"Fix this bug" -> debugging first, then domain-specific skills.

### Skill Types

**Rigid** (TDD, verification): Follow exactly. Don't adapt away discipline.

**Flexible** (patterns, meta): Adapt principles to context.

The skill itself tells you which type it is via the `discipline` field.

## Red Flags

These thoughts mean STOP -- you're rationalizing:

| Thought | Reality |
|---------|---------|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know what that means" | Knowing the concept does not equal using the skill. Invoke it. |

## User Instructions

Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.
