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

IF A SKILL APPLIES TO YOUR TASK, YOU MUST USE IT.

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

Using Skills

The Rule

Check for skills BEFORE ANY RESPONSE. This includes clarifying questions. Even 1% chance means invoke the Skill tool first.

Development Workflow Skills

These skills form a pipeline. Each phase produces a dated artifact and references the next step:

Skill	When to Use
/define	New feature request, bug report, or requirement to break down
/architect	Requirements exist, need technical design
/implement	Design exists, ready to build
/qa	Implementation complete, need adversarial testing
/refactor	Code quality pass after implementation

You don't always need all phases. Start at whichever phase makes sense.

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.
"This doesn't need a formal skill"	If a skill exists, use it.
"The skill is overkill"	Simple things become complex. Use it.
"I'll just do this one thing first"	Check BEFORE doing anything.

Skill Priority

When multiple skills could apply:

1. Process skills first (define, architect) — determine HOW to approach
2. Implementation skills second (implement, qa, refactor) — guide execution

Skill Types

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

Flexible (patterns): Adapt principles to context.

The skill itself tells you which.

User Instructions

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