tools-only Skill Gate
When To Activate
Trigger at the START of:
- Any task that will take more than a few minutes
- Any task involving architecture, refactoring, or significant decisions
- Any task where mistakes would be costly
- When user asks for help with a non-trivial problem
- Before writing any significant amount of code
Do NOT trigger for:
- Quick questions or explanations
- Trivial edits (typo fixes, small changes)
- When user explicitly says "just do it" or "skip the process"
Instructions
Step 1: Identify the Task Type
Categorize the incoming task:
Task: [Brief description]
Type: [Planning | Debugging | Implementation | Refactoring | Decision | Review | Other]
Complexity: [Trivial | Standard | Significant | Critical]
If Trivial, skip the gate. Otherwise, proceed.
Step 2: Scan Available Skills
List potentially relevant skills for this task type:
Potentially relevant skills for [task type]:
| Skill | Relevant? | Reason |
|-------|-----------|--------|
| [skill-name] | YES/NO | [One sentence why] |
| [skill-name] | YES/NO | [One sentence why] |
| ... | ... | ... |
Step 3: Activate Relevant Skills
For each YES skill, explicitly activate:
Activating skills:
1. [skill-name] - [what it will help with]
2. [skill-name] - [what it will help with]
Step 4: Proceed with Task
Only NOW begin the actual work, with activated skills guiding the approach.
Skill Categories Reference
Debugging & Problem Solving
- rubber-duck: Structured problem articulation
- zero-in: Scoped codebase searching
- debug-to-fix: Full debug cycle (elixir)
Quality & Verification
- prove-it: Verify outcomes, don't assume
- loose-ends: Check for cruft before committing
- trace-it: Map dependencies before modifying shared code
Code Discipline
- stay-in-lane: Match changes to request, prevent scope creep
- sanity-check: Validate assumptions before building on them
- keep-it-simple: Resist over-engineering
Context & Learning
- dont-be-greedy: Manage context window carefully
- breadcrumbs: Leave notes for future sessions
- learn-from-this: Extract learnings from failures
- skill-forge: Create new skills from discoveries
Safety & Refactoring
- safe-refactor: Refactoring with guardrails (elixir)
- careful-delete: Destruction with ceremony (elixir)
Quick Reference: Task → Skills
NEVER
- Skip evaluation on significant tasks
- Rubber-stamp all skills as "not relevant" without real consideration
- Activate skills you won't actually use (noise)
- Let this become a slow ritual - be brisk and decisive
- Gate trivial tasks (wastes time, annoys user)
ALWAYS
- Evaluate skills at task START, not midway
- Give real YES/NO reasoning, not perfunctory
- Actually follow activated skills' guidance
- Note when a skill SHOULD have been activated but wasn't (feedback loop)
- Be honest about task complexity
Examples
Example 1: Feature Request
User: "Add user authentication to the API"
Task: Add user authentication to API
Type: Implementation
Complexity: Significant
Potentially relevant skills:
| Skill | Relevant? | Reason |
|-------|-----------|--------|
| battle-plan | YES | Significant feature, needs planning |
| pre-mortem | YES | Auth has many failure modes |
| split-decision | YES | Multiple auth approaches exist |
| stay-in-lane | YES | Easy to over-scope auth |
| prove-it | YES | Must verify auth actually works |
| trace-it | NO | Not modifying existing shared code |
| rubber-duck | NO | Requirements seem clear |
Activating skills:
1. battle-plan - Plan before coding
2. pre-mortem - Anticipate auth failure modes (token expiry, etc.)
3. split-decision - JWT vs session vs OAuth decision
4. stay-in-lane - Only what's requested, not full RBAC
5. prove-it - Verify auth works end-to-end
Proceeding with battle-plan first...
Example 2: Bug Fix
User: "The login page is broken, users can't sign in"
Task: Fix broken login
Type: Debugging
Complexity: Standard
Potentially relevant skills:
| Skill | Relevant? | Reason |
|-------|-----------|--------|
| rubber-duck | YES | Need to understand the actual problem |
| zero-in | YES | Need to find where the bug is |
| debug-to-fix | YES | Full debug cycle appropriate |
| prove-it | YES | Must verify fix actually works |
| pre-mortem | NO | Not planning, fixing |
| split-decision | NO | Need to find bug first, not choose approach |
Activating skills:
1. rubber-duck - Clarify expected vs actual behaviour
2. debug-to-fix - Systematic debug cycle
3. prove-it - Verify the fix
Starting with rubber-duck: What exactly happens when users try to sign in?
Example 3: Trivial Task (Skip Gate)
User: "Fix the typo in the README - it says 'teh' instead of 'the'"
Task: Fix typo
Type: Implementation
Complexity: Trivial
[Gate skipped - trivial task]
Fixing typo...
The 80/20 Rule
You don't need to evaluate every skill every time. Focus on:
- The 3-4 most likely relevant skills for this task type
- Any skill that addresses a known weakness (e.g., scope creep → stay-in-lane)
- Quality gates (prove-it, loose-ends) for any code-producing task
Speed matters. Be decisive. The goal is conscious consideration, not bureaucracy.
Why This Skill Exists
Claude has access to powerful skills but often forgets to use them. Not from inability - from not pausing to consider. This gate creates that pause.
The difference between 50% and 80% activation is the difference between skills being occasionally helpful and being reliably transformative.
Gate your work. Activate what matters. Then execute.