skill-gate

name	skill-gate
description	| Use when this capability is needed.

Skill Gate

Skills don't help if they're not activated. Research shows passive skill availability leads to ~50% activation (coin flip). Forced evaluation achieves 80-84% activation. This skill is the gate: no significant work begins until skills have been explicitly evaluated and relevant ones activated.

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

**Planning & Risk** - battle-plan: Complete planning ritual for significant tasks - pre-mortem: Anticipate failure modes before starting - you-sure: Pause before destructive actions - split-decision: Multi-option analysis for decisions

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

| Task Type | Consider These Skills | |-----------|----------------------| | Debugging | rubber-duck, zero-in, debug-to-fix, prove-it | | New Feature | battle-plan, pre-mortem, stay-in-lane, prove-it | | Refactoring | trace-it, safe-refactor, pre-mortem, loose-ends | | Architecture Decision | split-decision, pre-mortem, sanity-check | | Deleting/Removing | careful-delete, you-sure, trace-it | | Code Review | prove-it, loose-ends, sanity-check | | Exploring Codebase | zero-in, dont-be-greedy, breadcrumbs | | After Failure | learn-from-this, retrospective, skill-forge |

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:

1. The 3-4 most likely relevant skills for this task type
2. Any skill that addresses a known weakness (e.g., scope creep → stay-in-lane)
3. 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.

---

Converted and distributed by TomeVault — claim your Tome and manage your conversions.