---

name: using-harness description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

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.

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.

In other environments: Check your platform's documentation for how skills are loaded.

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.

On every user message:

1. Could ANY skill apply? (even 1% chance)

   • No → Respond normally
   • Yes → Continue

2. Invoke Skill tool

3. Announce: "Using [skill] to [purpose]"

4. Has checklist?

   • Yes → Create TodoWrite item per checklist item
   • No → Continue

5. Follow skill exactly

Red Flags

These thoughts mean STOP—you're rationalizing:

Skill Priority

When multiple skills could apply, use this order:

1. Process skills first (brainstorming, debugging) - these determine HOW to approach the task
2. Implementation skills second (frontend-design, mcp-builder) - these guide execution

"Let's build X" → brainstorming first, then implementation skills. "Fix this bug" → debugging first, then domain-specific skills.

Skill Types

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

Flexible (patterns): Adapt principles to context.

The skill itself tells you which.

Asking Questions

When presenting choices to users, use AskUserQuestion instead of plain text:

• Reduces cognitive burden - users click instead of typing
• Clarifies options - descriptions explain trade-offs
• Always has escape hatch - "Other" allows custom input

Use for: Architecture choices, tool selection, approach decisions, any question with 2-4 clear options.

Don't use for: Simple yes/no, permission requests ("Should I commit?"), or open-ended questions.

Deferring Items

When something is out of scope or deferred, log it immediately:

• Game projects: .artifacts/GDD.md (Game Design Document)
• Non-game projects: .artifacts/ROADMAP.md

Create the file if it doesn't exist. Append deferred items under a "## Future Considerations" or "## Backlog" section with brief context about why it was deferred and what it would involve.

This ensures good ideas aren't lost when scope is trimmed.

User Instructions

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