Back to Details

skill-gate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill Gate

Skill Gate

<purpose> 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. </purpose>
<purpose> 技能若未被激活则毫无用处。研究表明，被动可用的技能激活率约为50%（如同抛硬币碰运气），而强制评估可将激活率提升至80-84%。本技能就是一道“闸门”：在技能被明确评估并激活相关技能前，任何重要工作都不得启动。 </purpose>

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

步骤1：确定任务类型

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.
对传入的任务进行分类：
Task: [简要描述]
Type: [规划 | 调试 | 实现 | 重构 | 决策 | 评审 | 其他]
Complexity: [琐碎 | 标准 | 重要 | 关键]
如果是琐碎任务，跳过闸门。否则继续下一步。

Step 2: Scan Available Skills

步骤2：扫描可用技能

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] |
| ... | ... | ... |
列出与该任务类型潜在相关的技能：
Potentially relevant skills for [task type]:

| Skill | Relevant? | Reason |
|-------|-----------|--------|
| [skill-name] | YES/NO | [一句话理由] |
| [skill-name] | YES/NO | [一句话理由] |
| ... | ... | ... |

Step 3: Activate Relevant Skills

步骤3：激活相关技能

For each YES skill, explicitly activate:
Activating skills:
1. [skill-name] - [what it will help with]
2. [skill-name] - [what it will help with]
对每个标记为YES的技能进行明确激活：
Activating skills:
1. [skill-name] - [该技能的作用]
2. [skill-name] - [该技能的作用]

Step 4: Proceed with Task

步骤4：执行任务

Only NOW begin the actual work, with activated skills guiding the approach.
只有在完成上述步骤后，才能开始实际工作，以激活的技能指导执行方法。

Skill Categories Reference

技能分类参考

<skill-categories> **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)
</skill-categories>
<skill-categories> **规划与风险** - battle-plan: 针对重要任务的完整规划流程 - pre-mortem: 在启动前预判失败模式 - you-sure: 在执行破坏性操作前暂停 - split-decision: 针对决策的多选项分析
调试与问题解决
  • rubber-duck: 结构化问题阐述
  • zero-in: 限定范围的代码库搜索
  • debug-to-fix: 完整调试周期（elixir）
质量与验证
  • prove-it: 验证结果，而非假设
  • loose-ends: 提交前检查冗余内容
  • trace-it: 修改共享代码前映射依赖关系
代码规范
  • stay-in-lane: 确保改动符合需求，防止范围蔓延
  • sanity-check: 在构建前验证假设
  • keep-it-simple: 避免过度设计
上下文与学习
  • dont-be-greedy: 谨慎管理上下文窗口
  • breadcrumbs: 为后续会话留下笔记
  • learn-from-this: 从失败中提取经验
  • skill-forge: 从发现中创建新技能
安全与重构
  • safe-refactor: 带防护机制的重构（elixir）
  • careful-delete: 带规范流程的删除操作（elixir）
</skill-categories>

Quick Reference: Task → Skills

快速参考：任务→技能

<quick-reference> | 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 | </quick-reference>
<quick-reference> | 任务类型 | 需考虑的技能 | |-----------|----------------------| | 调试 | rubber-duck, zero-in, debug-to-fix, prove-it | | 新功能开发 | battle-plan, pre-mortem, stay-in-lane, prove-it | | 重构 | trace-it, safe-refactor, pre-mortem, loose-ends | | 架构决策 | split-decision, pre-mortem, sanity-check | | 删除/移除操作 | careful-delete, you-sure, trace-it | | 代码评审 | prove-it, loose-ends, sanity-check | | 代码库探索 | zero-in, dont-be-greedy, breadcrumbs | | 失败后复盘 | learn-from-this, retrospective, skill-forge | </quick-reference>

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
  • 在任务启动时评估技能，而非中途
  • 给出真实的YES/NO理由，而非敷衍
  • 切实遵循已激活技能的指导
  • 记录本应激活但未激活的技能（形成反馈循环）
  • 如实评估任务复杂度

Examples

示例

Example 1: Feature Request

示例1：功能请求

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...
用户：“为API添加用户认证功能”
Task: Add user authentication to API
Type: Implementation
Complexity: Significant

Potentially relevant skills:

| Skill | Relevant? | Reason |
|-------|-----------|--------|
| battle-plan | YES | 重要功能，需要规划 |
| pre-mortem | YES | 认证功能存在多种失败模式 |
| split-decision | YES | 存在多种认证实现方案 |
| stay-in-lane | YES | 容易出现功能范围蔓延 |
| prove-it | YES | 必须验证认证功能是否正常工作 |
| trace-it | NO | 无需修改现有共享代码 |
| rubber-duck | NO | 需求看起来清晰明确 |

Activating skills:
1. battle-plan - 编码前先规划
2. pre-mortem - 预判认证功能的失败模式（如令牌过期等）
3. split-decision - 决策采用JWT、会话还是OAuth方案
4. stay-in-lane - 仅实现需求内容，不添加完整RBAC
5. prove-it - 端到端验证认证功能

先执行battle-plan...

Example 2: Bug Fix

示例2：Bug修复

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?
用户：“登录页面坏了，用户无法登录”
Task: Fix broken login
Type: Debugging
Complexity: Standard

Potentially relevant skills:

| Skill | Relevant? | Reason |
|-------|-----------|--------|
| rubber-duck | YES | 需要明确实际问题 |
| zero-in | YES | 需要定位Bug位置 |
| debug-to-fix | YES | 适合采用完整调试周期 |
| prove-it | YES | 必须验证修复是否有效 |
| pre-mortem | NO | 不是规划，是修复问题 |
| split-decision | NO | 先找Bug，无需选择方案 |

Activating skills:
1. rubber-duck - 明确预期行为与实际行为的差异
2. debug-to-fix - 系统化调试流程
3. prove-it - 验证修复效果

先执行rubber-duck：用户尝试登录时具体发生了什么？

Example 3: Trivial Task (Skip Gate)

示例3：琐碎任务（跳过闸门）

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...
用户：“修复README里的拼写错误——把'teh'改成'the'”
Task: Fix typo
Type: Implementation
Complexity: Trivial

[Gate skipped - trivial task]

正在修复拼写错误...

The 80/20 Rule

80/20法则

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.
无需每次评估所有技能。重点关注：
  1. 与当前任务类型最相关的3-4个技能
  2. 针对已知短板的技能（如范围蔓延→stay-in-lane）
  3. 任何代码生成任务的质量闸门（prove-it、loose-ends）
速度很重要。要果断。目标是有意识的思考，而非官僚主义流程。

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.
Claude拥有强大的技能，但常常忘记使用。并非因为能力不足——而是因为没有停下来思考。这个闸门就是为了创造这个思考的停顿。
50%和80%激活率的区别，就是技能偶尔有用和持续带来变革性价值的区别。
为你的工作设闸。激活重要的技能。然后执行。