AIDive

वीडियो पैक

skill-that-fires kit: Claude Code skill को अपने आप लोड कराइए

9 मिनट पढ़ें

TL;DR और निष्कर्ष

Claude Code की कोई skill तब बिल्कुल सही चल सकती है जब आप उसका नाम टाइप करें, और फिर भी तब कभी लोड न हो जब आप सादे शब्दों में माँगें। Skill लोड करने का फ़ैसला करने से पहले Claude हर skill की एक लाइन पढ़ता है: नाम और description। वह उस लाइन को आपके शब्दों से मिलाता है। अगर लाइन में आपके शब्द नहीं हैं, तो skill चुप रहती है।

हमारे run में, "Generates changelog documents from repository history." description वाली release-notes skill, "what did we ship this week?" request पर 5 में से 0 fresh sessions में लोड हुई। हमने उस एक लाइन को दोबारा लिखा: वह क्या करती है, कब इस्तेमाल होती है और हम कौन-से शब्द टाइप करते हैं। उसी request पर वह फिर 5 में से 5 बार लोड हुई।

निष्कर्ष:

  • Skill उस काम के लिए फ़ायदेमंद है जिसे आप तय output के साथ दोहराते हैं: हफ़्ते के notes, pull request का विवरण, release checklist।
  • एक बार के सवाल के लिए नहीं, और जो नियम हमेशा लागू होना चाहिए उसके लिए यह सही औज़ार नहीं। वह hook का काम है।
  • बेकार पड़ी skills का ढेर महँगा पड़ता है, क्योंकि listing के budget से ऊपर Claude Code descriptions काट देता है, सबसे कम इस्तेमाल हुई से शुरू करके।
  • एक नियम: description उन शब्दों में लिखिए जो आप उस काम को माँगते समय सच में टाइप करते हैं।

नीचे की kit में हमारी skill फ़ाइल पहले और बाद के रूप में, एक description template, fresh-session checklist और वह बीस requests का test है जो हमने इस्तेमाल किया।

docs और मैदान क्या कहते हैं

Skill कहाँ रहती है। Skill एक फ़ोल्डर है जिसमें SKILL.md होती है, या तो हर project के लिए ~/.claude/skills/<skill-name>/ में, या .claude/skills/<skill-name>/ में ताकि आपकी टीम को भी मिले। अलग पड़ी name.md फ़ाइल लोड नहीं होती। s1 s2

Claude description पढ़ता है, body नहीं। नामों और descriptions की सूची हर turn context में रहती है, और body तभी लोड होती है जब skill बुलाई जाए। Docs कहते हैं कि Claude description से ही तय करता है कि skill कब लगानी है। s1

Listing की एक सीमा और एक budget है। Description और when_to_use का टेक्स्ट मिलाकर 1,536 characters पर काटा जाता है। पूरी listing context window के 1% तक सीमित है, और भर जाने पर Claude Code उन skills से शुरू करके descriptions हटाता है जिन्हें आप सबसे कम बुलाते हैं। Docs के अनुसार इससे वे keywords हट जाते हैं जिनकी Claude को आपकी request मिलाने के लिए ज़रूरत है। --debug से debug log में आपको चेतावनी दिखती है। s1

टूटा हुआ header वह जाल है जो सफलता जैसा दिखता है। अगर YAML टूटा है, तो body खाली metadata के साथ लोड होती है, इसलिए /skill-name तब भी चलता है पर Claude आपका description मिला नहीं पाता। --debug से parse error देखिए, या claude plugin validate .claude/skills चलाइए। s1 s2

Badge देखिए। अगर कोई skill /skills में दिखती है पर Claude उसे कभी नहीं बुलाता, तो या तो disable-model-invocation: true सेट है या description आपकी request के ढंग से मेल नहीं खाता। user-only लेबल का मतलब है कि Claude उसे अपने आप trigger नहीं करेगा। s2

अच्छे description में क्या होता है। Anthropic की guide कहती है कि description में skill क्या करती है और कब इस्तेमाल हो, दोनों हों, third person में, और वे मुख्य शब्द हों जो users टाइप करते हैं। वह यह भी बताती है कि Claude इसी से संभावित 100+ में से सही skill चुनता है। s3

Claude skills को undertrigger करने की ओर झुकता है। Anthropic का skill-creator कहता है "currently Claude has a tendency to 'undertrigger' skills" और थोड़ा "pushy" description सुझाता है। s18 उसका trigger test 20 queries इस्तेमाल करता है, should-trigger और should-not-trigger का मेल, जिनमें near misses सबसे कीमती हैं। Loop उन्हें 60% train और 40% held-out test में बाँटता है, हर query 3 बार चलाता है, और सबसे अच्छे test score वाला description रखता है। s4 Eval script हर query claude -p से चलाती है और जाँचती है कि skill इस्तेमाल हुई या नहीं। s19

Activation keyword matching जैसा बर्ताव करता है। असली binary पर, एक third-party test (22 prompts, Sonnet 4.5) ने दो runs में baseline 55% और 50% मापा, और forced-evaluation hook के साथ 100%। जिस prompt में साफ़ token था वह लगभग 100% बार activate हुआ, जबकि अप्रत्यक्ष शब्दों में लगभग 0%। लेखक का निष्कर्ष: semantic matching से ज़्यादा keyword matching जैसा। यह एक blog है, पुराना model और अलग repo, इसलिए इसे सहारा देने वाला प्रमाण मानिए, नियम नहीं। s5

Description trigger है, सार नहीं। नौ असली skills के एक audit ने यही नतीजा निकाला: जो description ठोस स्थितियाँ गिनाता है वह उससे बेहतर है जो बताता है कि skill क्या है। s8

उलटी विफलता भी होती है। एक developer ने देखा कि skill गलत कामों पर trigger हो रही है, उसने trigger evals लिखे, description को "Load when..." के रूप में दोबारा लिखा, और ध्यान दिलाया कि रखने लायक skill आम तौर पर उस विफलता से पैदा होती है जिसे दो बार देखना आप सह नहीं सकते। s11

और लोग भी इससे टकराए हैं। Issue "Claude Code not aware of skills in .claude/skills" पर 75 reactions हैं और 2026-10-17 को भी खुला था। Thread के workarounds में CLAUDE.md का संकेत और एक hook शामिल हैं। s7

जहाँ hook skill से बेहतर है। 778 upvotes वाले thread के एक शीर्ष जवाब के अनुसार skill "basically just a prompt you save for later" है जिसे Claude इस्तेमाल करने का फ़ैसला करता है या आप slash command से बुलाते हैं, और hook तब है जब skills बहुत ढीली हों और आपको निश्चितता चाहिए। s9 एक और thread चेताता है कि याद दिलाने वाले nudges लंबे session में फीके पड़ सकते हैं। s10

Kit

Skill पहले और बाद। सिर्फ़ description की लाइन अलग है, body एक जैसी है।

release-notes.before.SKILL.md

---
name: release-notes
description: Generates changelog documents from repository history.
---

# Release notes

1. Find the range: commits since last Monday (`git log --since="last monday" --no-merges --pretty="%h %s"`).
2. Drop `chore` and `docs` commits.
3. Group what is left by the conventional-commit scope (router, css, jsx, serve-static...), fixes and features apart.
4. Write one line per change, in plain English, present tense, no commit hashes, with the PR number at the end.
5. Output a markdown block titled "Release notes, week of <date>", with a two-line summary on top.

release-notes.before.SKILL.md on GitHub

release-notes.after.SKILL.md

---
name: release-notes
description: Writes this week's release notes from git log, grouped by scope (router, css, jsx). Use when the user asks what we shipped, what changed this week, for release notes, a changelog, or a summary of recent commits.
---

# Release notes

1. Find the range: commits since last Monday (`git log --since="last monday" --no-merges --pretty="%h %s"`).
2. Drop `chore` and `docs` commits.
3. Group what is left by the conventional-commit scope (router, css, jsx, serve-static...), fixes and features apart.
4. Write one line per change, in plain English, present tense, no commit hashes, with the PR number at the end.
5. Output a markdown block titled "Release notes, week of <date>", with a two-line summary on top.

release-notes.after.SKILL.md on GitHub

Description template, हमारे असली description के साथ एक हल किए उदाहरण के रूप में।

description-template.md

# Skill description template

The description is the one line Claude reads before it decides to load your skill. Write it for the moment you ask, not for the file.

## Template

```
<Verb in third person> <what the skill produces>, <how it is shaped>. Use when the user asks <phrase 1>, <phrase 2>, <phrase 3>, or <phrase 4>.
```

Three parts, in this order:

1. What it does. Third person ("Writes", never "I can" or "You can use this"). Name the output.
2. When to use it. Start with "Use when the user asks".
3. Your words. The exact phrases you or your team type, copied from your own history, not synonyms you invented.

Put the key use case first. The description and `when_to_use` are cut together at 1,536 characters in the skill listing.

## Worked example (the real one from our run)

Before, a summary of the skill:

```
Generates changelog documents from repository history.
```

After, what + when + the words we type:

```
Writes this week's release notes from git log, grouped by scope (router, css, jsx). Use when the user asks what we shipped, what changed this week, for release notes, a changelog, or a summary of recent commits.
```

What changed:

- What: "Writes this week's release notes from git log, grouped by scope".
- When: "Use when the user asks ...".
- Your words: "what we shipped", "what changed this week", "release notes", "a changelog", "a summary of recent commits".

## Fill-in sheet

- Skill name:
- The prompt I keep retyping (copy it from your history):
- The output I want from it:
- Verb + output (what it does):
- Four phrases I really type (when):
- Phrases that sound close but are a different job (for your near misses):

## Check before you save

- Third person, no "I" and no "you".
- At least three phrases you really type.
- Under 1,536 characters in total.
- Not so wide that it matches a neighbour job. Add the near misses to your trigger test.

description-template.md on GitHub

Fresh-session checklist।

trigger-checklist.md

# Fresh-session trigger checklist

A skill that runs by name can still be invisible to a plain request. Test it the way a teammate will use it.

## Test in a fresh session

1. Open a new session. A skill already used stays in the conversation, so a test in the same session proves nothing.
2. Ask for the task in your own words, without the skill's name. Example: "what did we ship this week?"
3. Watch for the Skill tool call before Claude touches anything else. If Claude runs the commands itself and writes its own summary, the skill was skipped.
4. Repeat in several fresh sessions. A handful of runs is a demo, not a statistic.

## If it was skipped, read why before you edit

1. `/skills`: is it listed, is it switched on, is there a `user-only` badge? A `user-only` badge means Claude will not trigger it on its own.
2. Ask "What skills are available?" and check your skill is in the answer.
3. `claude --debug`, then search the log for the skills line (how many loaded) and for a "Skill listing over budget" warning. Over budget means some descriptions are cut, the least invoked first.
4. `claude plugin validate .claude/skills`: a malformed header still lets `/name` work but leaves Claude with empty metadata to match against.
5. Check the file is `.claude/skills/<name>/SKILL.md`, not a loose `<name>.md`, and that the header starts on the first line.

## Fix, then prove it

1. Rewrite the description with `description-template.md`.
2. Fresh session, same plain request, several runs: does the Skill call come first now?
3. Baseline: set the skill to `"off"` in `skillOverrides` (saved to `.claude/settings.local.json` from `/skills`), ask again, then switch it back on.

## Hold it

1. Write twenty requests: ten that should load the skill, ten near misses (`evals.json` is our set).
2. Run each in its own fresh session and note whether the skill loaded (`trigger_test.py`, `tally.py`).
3. Re-run the list every time you change the description.
4. For a skill that must never miss: call it by name, or add a UserPromptSubmit hook (`hook.json`).

trigger-checklist.md on GitHub

बीस requests का test set: दस requests जो skill को लोड करें, दस near misses जो न करें। Queries को अपने repo के हिसाब से बदलिए।

evals.json

[
  {"query": "what did we ship this week?", "should_trigger": true},
  {"query": "can you put together the release notes for this week", "should_trigger": true},
  {"query": "what changed in the repo since monday", "should_trigger": true},
  {"query": "write the changelog for the commits we merged this week", "should_trigger": true},
  {"query": "I need a summary of this week's commits for the team update on friday", "should_trigger": true},
  {"query": "draft the weekly notes of what got fixed, grouped by area", "should_trigger": true},
  {"query": "list what landed this week, router and css changes apart", "should_trigger": true},
  {"query": "give me something to post in the team channel about this week's fixes", "should_trigger": true},
  {"query": "recap the work merged since last monday", "should_trigger": true},
  {"query": "what's new in hono this week? short version for the release post", "should_trigger": true},
  {"query": "explain what commit 08807ce1 changes in the trie router", "should_trigger": false},
  {"query": "the jsx tests are failing on cloneElement, can you fix them", "should_trigger": false},
  {"query": "write a commit message for my staged changes", "should_trigger": false},
  {"query": "who wrote most of the serve-static code?", "should_trigger": false},
  {"query": "add a CHANGELOG entry format section to CONTRIBUTING.md", "should_trigger": false},
  {"query": "show me the diff between main and my branch", "should_trigger": false},
  {"query": "bump the version in package.json to the next patch", "should_trigger": false},
  {"query": "why does the css helper minify url() like that?", "should_trigger": false},
  {"query": "squash my last three commits into one", "should_trigger": false},
  {"query": "review this PR for breaking changes before I merge it", "should_trigger": false}
]

evals.json on GitHub

वह script जो हर request को उसके अपने fresh claude -p session में चलाती है और गिनती है कि Skill tool बुलाया गया या नहीं।

trigger_test.py

"""Twenty-prompt trigger test for one skill, the method skill-creator describes, run on the real skill folder.
For each query: a fresh `claude -p` in the repo; the run counts as loaded if the Skill tool is called with the skill's name
before the run ends (stopped early as soon as it is). Usage:
  python3 trigger_test.py <repo> <skill-name> <SKILL.md to install> <evals.json> <out.json> [workers]"""
import json, os, shutil, subprocess, sys
from concurrent.futures import ThreadPoolExecutor

repo, name, skill_md, evals_path, out = sys.argv[1:6]
workers = int(sys.argv[6]) if len(sys.argv) > 6 else 4
dest = os.path.join(repo, '.claude', 'skills', name)
os.makedirs(dest, exist_ok=True)
shutil.copy(skill_md, os.path.join(dest, 'SKILL.md'))
evals = json.load(open(evals_path))
allowed = ['Bash(rtk git log *)', 'Bash(git log *)', 'Bash(git show *)', 'Bash(date *)', 'Skill', 'Read']

def run(item):
    cmd = ['claude', '-p', item['query'], '--output-format', 'stream-json', '--verbose', '--allowedTools', *allowed]
    p = subprocess.Popen(cmd, cwd=repo, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL, text=True)
    loaded = False
    try:
        for line in p.stdout:
            try:
                d = json.loads(line)
            except ValueError:
                continue
            if d.get('type') == 'assistant':
                for c in d['message'].get('content', []):
                    if c.get('type') == 'tool_use' and c['name'] == 'Skill' and name in json.dumps(c.get('input', {})):
                        loaded = True
            if loaded or d.get('type') == 'result':
                break
    finally:
        if p.poll() is None:
            p.kill()
    return {**item, 'loaded': loaded, 'pass': loaded == item['should_trigger']}

with ThreadPoolExecutor(workers) as ex:
    results = list(ex.map(run, evals))
should = [r for r in results if r['should_trigger']]
shouldnt = [r for r in results if not r['should_trigger']]
summary = {'loaded_when_it_should': sum(r['loaded'] for r in should), 'of_should': len(should),
           'loaded_when_it_should_not': sum(r['loaded'] for r in shouldnt), 'of_should_not': len(shouldnt),
           'passed': sum(r['pass'] for r in results), 'total': len(results)}
json.dump({'skill': name, 'skill_md': skill_md, 'summary': summary, 'results': results}, open(out, 'w'), indent=2)
for r in results:
    print(f"[{'PASS' if r['pass'] else 'FAIL'}] {'loaded ' if r['loaded'] else 'skipped'} expected={'load' if r['should_trigger'] else 'skip'}: {r['query']}")
print(json.dumps(summary))

trigger_test.py on GitHub

claude -p --output-format stream-json runs के एक फ़ोल्डर के लिए एक छोटा tally।

tally.py

"""Count whether a `claude -p --output-format stream-json` run loaded a given skill. Usage: python3 tally.py <skill> run1.jsonl [run2.jsonl ...]"""
import json, sys
skill, files = sys.argv[1], sys.argv[2:]
fired = 0
for f in files:
    hit = False
    for line in open(f):
        try:
            d = json.loads(line)
        except ValueError:
            continue
        if d.get('type') == 'assistant':
            for c in d['message'].get('content', []):
                if c.get('type') == 'tool_use' and c['name'] == 'Skill' and skill in json.dumps(c.get('input', {})):
                    hit = True
    fired += hit
    print(f"{f}: {'loaded' if hit else 'skipped'}")
print(f"{skill}: loaded in {fired} of {len(files)} runs")

tally.py on GitHub

ज़रूर चलने का fallback: UserPromptSubmit hook जो skill का नाम बताता है।

hook.json

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo 'If the user asks about release notes, a changelog or what shipped this week, use the release-notes skill.'"
          }
        ]
      }
    ]
  }
}

hook.json on GitHub

सोमवार को यह कीजिए

  • वह prompt लिख लीजिए जो पिछले हफ़्ते आपने सबसे ज़्यादा बार दोबारा टाइप किया, और उससे चाहा गया ठीक-ठीक output भी।
  • नाम, description और एक छोटी क्रमांकित body के साथ .claude/skills/<name>/SKILL.md बनाइए।
  • उसे पहले नाम से test कीजिए, फिर fresh session खोलकर नाम बताए बिना सादे शब्दों में काम माँगिए।
  • अगर skip हो, तो कुछ भी बदलने से पहले /skills, claude --debug और claude plugin validate .claude/skills पढ़िए।
  • description-template.md से description दोबारा लिखिए: वह क्या करती है, कब, और आप कौन-से शब्द टाइप करते हैं।
  • कई fresh sessions में दोबारा test कीजिए, फिर एक बार skillOverrides में skill को "off" करके और एक बार वापस on करके।
  • अपनी बीस requests लिखिए, उन्हें trigger_test.py से चलाइए, और description बदलने पर हर बार दोबारा चलाइए।
  • जिस skill को कभी चूकना नहीं है, उसके लिए तय कीजिए: नाम से बुलाइए, या hook जोड़िए।

हमने क्या मापा

ये open-source Hono repo (s20) के एक scratch clone पर छोटे demo runs हैं, Claude Code 2.1.294 के साथ और request "what did we ship this week?" पर, सोमवार 2026-10-12 से अब तक के 8 non-merge conventional commits पर। ये benchmark नहीं हैं। आपका model, आपकी skills और आपका repo आँकड़ों को बदल देंगे।

Test Description नतीजा
सादी request, 5 fresh sessions सार: "Generates changelog documents from repository history." 5 में से 0 में लोड हुई
सादी request, 5 fresh sessions दोबारा लिखा: क्या करती है + कब + हमारे शब्द 5 में से 5 में लोड हुई
नाम से बुलाया (/release-notes) सार 2 में से 2 में चली
skillOverrides off, फिर on दोबारा लिखा Off: skip हुई। On: लोड हुई
बीस requests का test, rewrite से पहले सार should-load में से 10 में से 4 लोड हुईं, near misses में 10 में से 0, 20 में से 14 पास
बीस requests का test, rewrite के बाद दोबारा लिखा should-load 10 में से 10, near misses 10 में से 0, 20 में से 20 पास
Hook और पुराना description सार 1 में से 1 में लोड हुई

Rewrite से पहले, जो 4 requests लोड हुईं वे वही थीं जिनमें "release notes", "changelog", "notes" या "release" था: यानी keyword असर साफ़ दिखता हुआ। Rewrite के बाद चौड़े description ने एक भी near miss अंदर नहीं खींचा।

जो चेतावनी हमें मिली, और उसकी ईमानदार व्याख्या। --debug के साथ हमारे setup ने छापा: "Skill listing over budget: 296 skills, 144833 chars > 30000 budget"। हमारे setup में बहुत ज़्यादा skills हैं, इसलिए descriptions कटते हैं। फिर भी हमारी project skill लोड हुई ("Loaded 43 unique skills", जिनमें एक project skill थी), और पुराना description कटौती से बच गया: बीस requests के test में "changelog" वाली request, एक ऐसा शब्द जो सिर्फ़ description में है, उसने skill लोड की। हमने साबित नहीं किया कि budget आम तौर पर नई skill के साथ कैसा बर्ताव करता है। अगर आपके पास बहुत skills हैं, तो जाँच खुद चलाइए। हमारे setup पर /skills ने 277 skills गिनाईं, और release-notes project skill के रूप में दिखी, on थी, और उस पर user-only badge नहीं था।

औज़ार के बारे में एक चेतावनी: Anthropic की eval script ने हमारे version पर skill देखी ही नहीं, इसलिए हमने वही requests kit की छोटी script से चलाईं। तरीका वही है, हर request के लिए एक fresh claude -p session।

आगे बढ़िए

उलटी समस्या भी ठीक कीजिए। जो description बहुत ज़्यादा चीज़ों से मेल खाता है, उससे skill वहाँ भी चल पड़ती है जहाँ नहीं चलनी चाहिए। इसीलिए test set का आधा हिस्सा near misses है। वे शब्द जोड़िए जो आप सच में इस्तेमाल करते हैं, वे सारे नहीं जो आपको सूझें। s11

Optimizer को rewrite सुझाने दीजिए। Skill-creator का loop नए descriptions सुझाता है और held-out test score से सबसे अच्छा रखता है, ताकि आपकी tune की हुई queries पर overfit न हो। Eval set के रूप में अपनी बीस requests इस्तेमाल कीजिए। s4

ठोस test prompt इस्तेमाल कीजिए। Skill-creator ध्यान दिलाता है कि Claude skills तभी देखता है जब काम वह आसानी से खुद नहीं कर सकता, इसलिए एक-कदम की मामूली request पूरे मेल के बावजूद skill trigger न करे, यह हो सकता है। s4

सादे hook से आगे जाइए। ऊपर के third-party test ने पाया कि forced-evaluation hook, जो Claude से हर skill पर हाँ या ना कहलवाकर फिर activate कराता है, 100% तक पहुँचा जहाँ passive याद दिलाने वाला नहीं पहुँचा, और native type: "prompt" hook बिना hook जैसा बर्ताव करता रहा। हमारा hook सादा संस्करण है, और यह एक demo run है। s5 रिपोर्टें कहती हैं कि hook के nudges लंबे session में फीके पड़ सकते हैं। s10

Body छोटी रखिए। ऊपर के audit में, टूटी हुई इकलौती skill 1,002 लाइन की थी और हर जगह MANDATORY लिखा था, जबकि स्वस्थ skills छोटी थीं। s8

हमने क्या छोड़ा। हमने plugin skills और plugin eval graders को कवर नहीं किया, जो सिर्फ़ plugin लेखकों के काम के हैं, और न यह कि महीनों में skill की तुलना सादे model से कैसे करें। कुछ लोग यह भी बताते हैं कि कमज़ोर models के लिए लिखी skills बोझ बन सकती हैं, इसलिए उन्हें बीच-बीच में दोबारा test कीजिए। इसे हमने नहीं मापा।

FAQ

/release-notes क्यों चलता है पर सादे शब्द क्यों नहीं? नाम टाइप करना मिलान को दरकिनार कर देता है। सादे शब्दों में Claude के पास मिलाने को सिर्फ़ नाम और description की एक लाइन होती है, इसलिए जो सार आपकी request से कोई शब्द साझा नहीं करता वह skip हो जाता है। s1

Skill बदलने के बाद क्या Claude Code को restart करना पड़ता है? नहीं। Claude Code ~/.claude/skills/ या .claude/skills/ के अंदर जोड़ी या बदली हुई skill को मौजूदा session में उठा लेता है। अगर आप कोई ऐसा शीर्ष-स्तर का skills directory बनाएँ जो session शुरू होते समय था ही नहीं, तो /reload-skills चलाइए। s1

Description कितना लंबा हो सकता है? Listing में description और when_to_use मिलाकर 1,536 characters पर कटते हैं, इसलिए मुख्य उपयोग सबसे पहले रखिए। Anthropic की platform guide अलग से Claude Code के बाहर अपलोड की गई skills के लिए description को 1,024 characters पर सीमित करती है। s1 s3

क्या fix पर भरोसा करने के लिए पाँच fresh sessions काफ़ी हैं? नहीं। वे दिशा दिखाते हैं। हमारा नतीजा एक repo पर एक demo है, इसीलिए kit बीस requests के test पर खत्म होती है जिसे आप description बदलने पर हर बार दोबारा चला सकते हैं।

Skill की जगह hook कब इस्तेमाल करूँ? जब कोई नियम हर बार लागू होना चाहिए, सिर्फ़ तब नहीं जब Claude को मेल दिख जाए। Hook हर message में एक लाइन जोड़ता है, इसलिए उसे उन गिनी-चुनी skills के लिए रखिए जिन्हें चलना ही है। s9

फ़ाइलें