v4.0.2 to v4.0.2

---

name: Getting Started with Skills

description: Skills wiki intro - mandatory workflows, search tool, brainstorming triggers

when_to_use: when starting any conversation

version: 4.0.2

---

# Getting Started with Skills

## Critical Rules

1. **Use Read tool before announcing skill usage.** The session-start hook does NOT read skills for you. Announcing without calling Read = lying.

2. **Follow mandatory workflows.** Brainstorming before coding. Check for skills before ANY task.

3. **Create TodoWrite todos for checklists.** Mental tracking = steps get skipped. Every time.

## Mandatory Workflow: Before ANY Task

**2. If relevant skill exists, YOU MUST use it:**

- Read ENTIRE file, not just frontmatter

- Announce: "I've read [Skill Name] skill and I'm using it to [purpose]"

- Follow it exactly

**Don't rationalize:**

- "I remember this skill" - Skills evolve. Read the current version.

- "Session-start showed it to me" - That was using-skills/SKILL.md only. Read the actual skill.

**Why:** Skills document proven techniques that save time and prevent mistakes. Not using available skills means repeating solved problems and making known errors.

If a skill for your task exists, you must use it or you will fail at your task.

## Skills with Checklists

If a skill has a checklist, YOU MUST create TodoWrite todos for EACH item.

**Don't:**

- Work through checklist mentally

- Skip creating todos "to save time"

- Batch multiple items into one todo

- Mark complete without doing them

**Why:** Checklists without TodoWrite tracking = steps get skipped. Every time. The overhead of TodoWrite is tiny compared to the cost of missing steps.

**Examples:** skills/testing/test-driven-development/SKILL.md, skills/debugging/systematic-debugging/SKILL.md, skills/meta/writing-skills/SKILL.md

## Announcing Skill Usage

After you've read a skill with Read tool, announce you're using it:

"I've read the [Skill Name] skill and I'm using it to [what you're doing]."

**Examples:**

- "I've read the Brainstorming skill and I'm using it to refine your idea into a design."

- "I've read the Test-Driven Development skill and I'm using it to implement this feature."

- "I've read the Systematic Debugging skill and I'm using it to find the root cause."

**Why:** Transparency helps your human partner understand your process and catch errors early. It also confirms you actually read the skill.

## How to Read a Skill

Every skill has the same structure:

1. **Frontmatter** - `when_to_use` tells you if this skill matches your situation

2. **Overview** - Core principle in 1-2 sentences

3. **Quick Reference** - Scan for your specific pattern

4. **Implementation** - Full details and examples

5. **Supporting files** - Load only when implementing

**Many skills contain rigid rules (TDD, debugging, verification).** Follow them exactly. Don't adapt away the discipline.

**Some skills are flexible patterns (architecture, naming).** Adapt core principles to your context.

The skill itself tells you which type it is.

## Instructions ≠ Permission to Skip Workflows

Your human partner's specific instructions describe WHAT to do, not HOW.

"Add X", "Fix Y" = the goal, NOT permission to skip brainstorming, TDD, or RED-GREEN-REFACTOR.

**Red flags:** "Instruction was specific" • "Seems simple" • "Workflow is overkill"

**Why:** Specific instructions mean clear requirements, which is when workflows matter MOST. Skipping process on "simple" tasks is how simple tasks become complex problems.

## Summary

**Starting any task:**

3. Announce you're using it

4. Follow what it says

**Skill has checklist?** TodoWrite for every item.

**Finding a relevant skill = mandatory to read and use it. Not optional.**