CLAUDE.md, Skills, Hooks თუ Subagents: რა სად უნდა ჩავდოთ

ერთი საუბარი, როგორც ჩანს, გარდაუვალია, როგორც კი გუნდი agentic კოდინგ-ხელსაწყოს აითვისებს: „CLAUDE.md-ში ხომ ჩავწერე — რატომ გააკეთა მაინც ის?” ჩვეულებრივი პასუხია, რომ ფაილი ზედმეტად გაგრძელდა და მას აღარავინ კითხულობს. შეიძლება ეს მართალიც იყოს, მაგრამ ნამდვილ პრობლემას ვერ ხსნის.

ნამდვილი პრობლემა ისაა, რომ ხელსაწყო steering-ის რამდენიმე განსხვავებულ გზას გაძლევთ და ისინი ურთიერთშემცვლელი არ არის. memory ფაილი, skill, hook და subagent ერთმანეთისგან განსხვავდება იმით, როდის იტვირთება, რამდენი კონტექსტი უჯდება, გადარჩება თუ არა compaction-ს და — ყველაზე მნიშვნელოვანი — არის თუ არა ეს რჩევა თუ გარანტია. ინსტრუქცია არასწორ ადგილას რომ ჩაგიდიათ, ის ან იგნორირდება, ან ყოველ ტურნზე წვავს კონტექსტს, ან გრძელი სესიის შუაში წყნარად ქრება.

Anthropic-მა ცოტა ხნის წინ სწორედ ამაზე გამოაქვეყნა მოკლე და მკვრივი სტატია: Steering Claude Code: skills, hooks, rules, subagents and more. ეს პოსტი ჩემი, როგორც ინჟინრის, სინთეზია მისი და CLAUDE.md-ზე, hooks-ზე, skills-სა და subagents-ზე დაკავშირებული სტატიებისა — ჩემივე მოსაზრებებით იმაზე, სად იმსახურებს თითოეული მექანიზმი ადგილს. ეს არის თანმხლები პოსტი AI-native SDLC-ისა, რომელიც მთელ მიწოდების ციკლს უყურებს ზემოდან; აქ კი თვით harness-ს ვუახლოვდებით.

ერთი კითხვა, რომელიც ყველაფერს ალაგებს

კითხვა, რომელსაც ნებისმიერ მითითებას დავუსვამდი:

ეს არის ცოდნა, პროცედურა, გარანტია თუ ცალკე სამუშაო?

• ცოდნა — ფაქტები, რომლებიც აგენტს უმეტესად სჭირდება: build-ის ბრძანებები, დირექტორიების სტრუქტურა, სახელდების კონვენციები. ეს memory ფაილია.
• პროცედურა — მრავალნაბიჯიანი „როგორ ვაკეთებთ X-ს”, რომელიც ხანდახან მნიშვნელოვანია: release checklist, მიგრაციის რეცეპტი, უსაფრთხოების რევიუ. ეს skill-ია.
• გარანტია — რაღაც, რაც აუცილებლად უნდა მოხდეს (ან არასოდეს უნდა მოხდეს) იმისგან დამოუკიდებლად, რას გადაწყვეტს მოდელი: ფორმატირება, დაცულ ბილიკებზე ჩაწერის დაბლოკვა, დასრულებაზე უარი, სანამ ტესტები ეცემა. ეს hook-ია (პლუს permissions).
• ცალკე სამუშაო — სამუშაო, რომლის შუალედური არეულობა მთავარ საუბარში არ გჭირდებათ: ორმოცი ფაილის წაკითხვა ერთ კითხვაზე პასუხისთვის, მიუკერძოებელი რევიუ, ლოგების ანალიზი. ეს subagent-ია.

steering-ის შეცდომების უმეტესობა ამ ოთხს შორის კატეგორიული შეცდომებია. განვიხილოთ სათითაოდ.

CLAUDE.md: ყოველთვის ჩართული რუკა

პროექტის memory ფაილი იტვირთება ყოველი სესიის დასაწყისში და იქვე რჩება. ეს არის მისი ძალაც და ფასიც. ყველაფერი, რაც მასშია, ყოველ ტურნზე კონკურენციას უწევს ყურადღებას, იმ ტურნებზეც, სადაც არარელევანტურია.

იქ უნდა იყოს ის, რაც კომპეტენტურ ახალ თანამშრომელს პირველ დღეს დასჭირდება და რაზეც სხვაგვარად განმეორებით იკითხავდა: როგორ ავაშენოთ და გავტესტოთ, სად რა დევს, კონვენციები, რომლებიც კოდიდან აშკარა არ არის, და პროექტისთვის სპეციფიკური ხაფანგები. CLAUDE.md-ის სტატია კარგად ჩამოაყალიბებს: ყოველი ხაზი იმიტომ უნდა არსებობდეს, რომ რეალურ პრობლემას გადაჭრა, რომელსაც ნამდვილად გადააწყდით, და არა ჰიპოთეტურს. steering-ის სტატია კონკრეტულ ჭერს გვაძლევს: root ფაილი 200 ხაზზე ნაკლები იყოს, მას მფლობელი ჰყავდეს და მასში ცვლილებებს კოდივით აქცევდნენ რევიუს.

კარგი root ფაილი ლაკონიურ onboarding ჩანაწერს ჰგავს:

# CLAUDE.md

## Commands
- `npm run dev` — local server on :4321
- `npm run check` — lint + types + i18n parity. Must pass before commit.

## Layout
- App lives in `src/`, not the repo root. Content in `src/src/content/`.

## Conventions
- Every new UI string goes into all four locale files.
- Never construct canonical URLs from the request URL.

რაც ადვილად გამოგრჩებათ:

• ქვედირექტორიების ფაილები ზარმაცია. ქვედირექტორიაში მდებარე CLAUDE.md იტვირთება მხოლოდ მაშინ, როცა აგენტი ამ დირექტორიიდან ფაილს კითხულობს. ამიტომ ის იაფია — და ამიტომვე შეიძლება compaction-ის შემდეგ გაქრეს, სანამ ამ დირექტორიას ხელახლა არ შეეხებიან. monorepo-ში სწორედ ასე იღებს თითოეული გუნდი საკუთარ კონვენციებს ისე, რომ სხვების სესიებს არ ამძიმებს.
• პირადი პრეფერენციები პროექტის ფაილში არ გვხვდება. თქვენი სასურველი commit-ტონი ან რედაქტორის ახირებები თქვენს მომხმარებლის დონის ფაილში უნდა იყოს. პროექტის ფაილი ამ კოდბაზისთვის სპეციფიკური გუნდური კონვენციებისთვისაა.
• საიდუმლოები — არასოდეს. ის სისტემური პრომპტის ნაწილი ხდება; მიიჩნიეთ პოტენციურად საჯაროდ.

Rules: CLAUDE.md scope-ით

.claude/rules/-ში მდებარე წესების ფაილები ხიდია „ყოველთვის ჩატვირთულსა” და „ჩატვირთულს, როცა რელევანტურია” შორის. scope-ის გარეშე წესი უბრალოდ დამატებით CLAUDE.md-ს ჰგავს. დაამატეთ paths ველი და ის მხოლოდ მაშინ იტვირთება, როცა აგენტი შესაბამის ფაილებს ეხება:

---
paths:
  - "src/api/**"
---
All API handlers validate input with Zod before any processing.

ეს სწორი ადგილია cross-cutting შეზღუდვებისთვის, რომლებიც კოდბაზის ნაწილზე ვრცელდება — API handlers, მიგრაციები, გენერირებული კლიენტები — და სხვაგან ხმაური იქნებოდა. path-სპეციფიკური წესი path scope-ის გარეშე ერთ-ერთი ყველაზე იაფად გამოსასწორებელი ანტი-პატერნია.

Skills: პროცედურები მოთხოვნისას

skill არის საქაღალდე, რომლის root-ში მდებარეობს SKILL.md — სახელი, აღწერა და ინსტრუქციების ტანი — და სურვილისამებრ სკრიპტები, შაბლონები და საცნობარო ფაილები. მთავარი მექანიზმია progressive disclosure: კონტექსტში წინასწარ მხოლოდ სახელი და აღწერა დევს; ტანი იტვირთება skill-ის გამოძახებისას (slash-ბრძანებით ან იმიტომ, რომ აგენტმა აღწერა ამოცანას შეუსაბამა), ხოლო მიბმული ფაილები — მხოლოდ თუ ინსტრუქციები მათზე მიუთითებს. skills-ის ამხსნელი მეტამონაცემების ფასს დაახლოებით 100 ტოკენად თითო skill-ზე ასახელებს, სრულ ინსტრუქციებს კი 5k ტოკენზე ნაკლებად — ამიტომ შეიძლება ბევრი skill იყოს ხელმისაწვდომი ისე, რომ ფანჯარა არ გადაიტვირთოს.

---
name: release-checklist
description: Use when preparing a release or tagging a version. Bumps
  the version, updates CHANGELOG, runs the full check suite, drafts notes.
---
1. Confirm the working tree is clean and on main.
2. Run `npm run check`; stop and report on any failure.
3. ...

ამ ფაილში ორი რამ არის ყველაფერზე მნიშვნელოვანი:

• აღწერა არის ტრიგერი. ეს ერთადერთი ნაწილია, რომელსაც აგენტი ხედავს, სანამ გადაწყვეტს skill-ის ჩატვირთვას. დაწერეთ როგორც „რას აკეთებს და როდის გამოიყენება”, იმ სიტყვებით, რასაც ადამიანები რეალურად წერენ. ბუნდოვანი აღწერა ნიშნავს, რომ skill ან არასოდეს ირთვება, ან ყველაფერზე ირთვება.
• ტანი პროცედურაა და არა ესე. ნუმერირებული ნაბიჯები, მკაფიო გაჩერების პირობები, მითითებები სკრიპტებზე ყველაფრისთვის, რაც დეტერმინირებულია. თუ რომელიმე ნაბიჯი „გაუშვი ზუსტად ეს ბრძანება”-ა, ბრძანება ჩადეთ სკრიპტში, რომელსაც skill გამოიძახებს, და ნუ ენდობით, რომ მოდელი მას თავად აღადგენს.

steering-ის სტატიის ევრისტიკა ის არის, რომელსაც ყველაზე ხშირად ვიყენებ: თუ CLAUDE.md-ში 30-ხაზიან პროცედურას პოულობთ, ეს skill-ია, რომელიც ჯერ არ ამოუღიათ. ის ყოველ ტურნზე სრულ კონტექსტურ ქირას იხდის იმისთვის, რომ რამდენიმე ტურნზე იყოს სასარგებლო.

skills connectors-ებთანაც კომბინირდება: MCP აგენტს გაძლევთ წვდომას თქვენს issue tracker-ზე; skill კი ეუბნება, როგორ ახარისხებს თქვენი გუნდი.

Hooks: ერთადერთი, რაც ნამდვილად გარანტირებულია

აი ხაზი, რომელსაც მთელ თემაში ხაზს გავუსვამდი. ყველაფერი ზემოთ — CLAUDE.md, rules, skills — რჩევითია. მოდელი მას კითხულობს და, ჩვეულებრივ, მისდევს. „ჩვეულებრივ” კონვენციებისთვის კარგია. ის არ არის კარგი „არასოდეს ჩაწერო migrations/-ში დამტკიცების გარეშე” ან „ყოველთვის გაუშვი ფორმატერი”-სთვის.

hooks ბუნებით განსხვავებულია. ესენი settings-ში რეგისტრირებული handler-ებია, რომლებიც lifecycle მოვლენებზე ირთვება — ხელსაწყოს გაშვებამდე, მის შემდეგ, სესიის დაწყებისას, როცა აგენტი ცდილობს გაჩერებას, compaction-მდე და ა.შ. Command, HTTP და MCP-tool hooks დეტერმინირებულად სრულდება: მოდელის განსჯა არ მონაწილეობს. PreToolUse hook, რომელიც კოდ 2-ით გამოდის, ბლოკავს tool-გამოძახებას, ხოლო მისი stderr უკან მიეწოდება, რათა აგენტმა გაიგოს, რატომ.

მინიმალური „დაფორმატე ყოველი რედაქტირების შემდეგ” hook .claude/settings.json-ში:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/format.sh" }
        ]
      }
    ]
  }
}

სკრიპტი stdin-იდან კითხულობს tool input-ს JSON-ად, იღებს ფაილის ბილიკს და უშვებს თქვენს ფორმატერს. ფორმატირება აღარ არის რაღაც, რაც აგენტს შეიძლება დაავიწყდეს; ის უბრალოდ ხდება.

steering-ის სტატია წესს მკაფიოდ აყალიბებს: ინსტრუქცია guardrail არ არის. თუ თქვენი CLAUDE.md ამბობს „ყოველთვის გააკეთე Y X-ის შემდეგ”, ეს hook-ია. თუ ამბობს „არასოდეს გააკეთო Z”, ეს hook-ია ან permission წესი — ხოლო ორგანიზაციის მასშტაბის პოლიტიკისთვის — managed settings, რომლებსაც ცალკეული მომხმარებლები ლოკალურად ვერ გადაფარავენ.

hooks-ის გზამკვლევიდან რამდენიმე გაფრთხილება, რომლებსაც არადაშვებად მივიჩნევდი:

• Hooks თქვენი მომხმარებლის უფლებებით სრულდება. ეს თვითნებური shell-ია. გადახედეთ მათ როგორც production კოდს, ცვლადები ბრჭყალებში ჩასვით, გამოიყენეთ სკრიპტების აბსოლუტური ბილიკები და გაასუფთავეთ ის, რაც stdin-ზე შემოდის.
• Matchers რეგისტრზე მგრძნობიარეა. bash არ დაემთხვევა Bash ხელსაწყოს. ეს ისეთი ბაგია, რომლის გამოც guardrail წყნარად უბრალოდ არ არსებობს.
• ყველა hook არ არის დეტერმინირებული. Prompt- და agent-ტიპის hooks მოდელის განსჯას იყენებს. სასარგებლოა, მაგრამ enforcement-ში ნუ აურევთ.
• დაიწყეთ ერთით. გზამკვლევი ფორმატერს გვთავაზობს: დაბალი რისკი, მყისიერი სარგებელი.

Subagents: ცალკე კონტექსტი ცალკე სამუშაოსთვის

subagent არის იზოლირებული აგენტის ინსტანცია საკუთარი კონტექსტური ფანჯრით, საკუთარი სისტემური პრომპტითა და საკუთარი tool permissions-ით. ის იწყება თქვენი საუბრის ისტორიის გარეშე, აკეთებს სამუშაოს და აბრუნებს მხოლოდ საბოლოო შეტყობინებას. ეს იზოლაცია არის მთელი აზრი.

Custom subagents ცხოვრობს .claude/agents/-ში (პროექტი) ან ~/.claude/agents/-ში (პირადი), როგორც Markdown frontmatter-ით:

---
name: security-reviewer
description: Reviews a diff for security issues before commit. Use after
  implementation, before opening a PR.
tools: Read, Grep, Glob
---
You are a security reviewer. You do not edit files. Report findings
by severity with file and line, and say explicitly if you found none.

დააკვირდით, რა აკეთებს მთავარ საქმეს: მხოლოდ-წაკითხვადი tool-სია (ის ვერ „დაგეხმარებათ” გამოსწორებით) და აღწერა, რომელიც ამბობს, როდის უნდა დელეგირება, რადგან სწორედ ეს აღწერა განაპირობებს ავტომატურ დელეგირებას.

subagents-ის სტატია გვთავაზობს ცერის წესს, რომელიც ჩემთვის ნამდვილად სასარგებლოა: თუ ამოცანა ათი ან მეტი ფაილის შესწავლას ნიშნავს, ან გაქვთ სამი ან მეტი დამოუკიდებელი სამუშაო ნაწილი, ეს დელეგირების ძლიერი სიგნალია. სხვა ძლიერი შემთხვევებია ახალი თვალსაზრისი (reviewer, რომელსაც თქვენი debugging-ის გვერდითი გზები არ უნახავს) და ვერიფიკაცია commit-მდე.

ასევე სასარგებლოა იმის ცოდნა, როდის არა: თანმიმდევრული სამუშაო, სადაც თითოეულ ნაბიჯს წინა ნაბიჯის სრული გამოსავალი სჭირდება, ერთი ფაილის პარალელური რედაქტირება, პატარა ამოცანები, სადაც დელეგირების overhead სარგებელს აჭარბებს, და აგენტები, რომლებსაც ერთმანეთთან საუბარი სჭირდებათ. თითოეული subagent საკუთარ ტოკენებს წვავს — fan-out-ის ტოკენების ეკონომიკა რეალურია.

steering-ის სტატიის განსხვავება skill-სა და subagent-ს შორის ყველაზე გასაგებია, რაც მინახავს: გამოიყენეთ subagent, როცა შუალედური შედეგები თქვენს საუბარს გადატვირთავდა; გამოიყენეთ skill, როცა გინდათ ყოველი ნაბიჯის დანახვა და წარმართვა.

გადაწყვეტილების ცხრილი

აი, ყველაფერი ერთ ეკრანზე. loading და compaction სვეტები steering-ის სტატიიდანაა; „გამოიყენეთ რისთვის” სვეტი ჩემი შეკუმშვაა.

მექანიზმი	იტვირთება	Compaction-ის შემდეგ	რჩევითი თუ აღსრულებადი	გამოიყენეთ რისთვის
Root CLAUDE.md	სესიის დასაწყისში	ხელახლა იკითხება	რჩევითი	ბრძანებები, სტრუქტურა, პირველი დღის კონვენციები
ქვედირექტორიის CLAUDE.md	როცა ამ დირექტორიას კითხულობენ	იკარგება, სანამ ხელახლა არ შეეხებიან	რჩევითი	პაკეტის ან გუნდის დონის კონვენციები
Path-scoped rule	როცა შესაბამის ფაილებს ეხებიან	ხელახლა ინექტირდება	რჩევითი	კოდბაზის ნაწილის შეზღუდვები
Skill	აღწერა დასაწყისში, ტანი გამოძახებისას	ხელახლა ინექტირდება საერთო ბიუჯეტში	რჩევითი	პროცედურები, რომლებიც ხანდახან გამოიყენება
Subagent	აღწერა დასაწყისში, ტანი გამოძახებისას	უბრუნდება მხოლოდ summary	რჩევითი (tools აღსრულებადია)	იზოლირებული, ხმაურიანი ან პარალელური გვერდითი სამუშაოები
Hook	lifecycle მოვლენებზე	გვერდს უვლის compaction-ს	აღსრულებადი (command/HTTP/MCP ტიპები)	აუცილებლად-უნდა-მოხდეს და არასოდეს-არ-უნდა-მოხდეს
Permissions / managed settings	ყოველთვის	n/a	აღსრულებადი	მკაცრი საზღვრები, ორგანიზაციის მასშტაბის პოლიტიკა

steering-ის სტატია ასევე ფარავს output styles-ს და სისტემურ პრომპტში დამატებას. მე ორივეს იშვიათ ხელსაწყოდ ჩავთვლიდი: custom output style ცვლის სტანდარტულ software-engineering ინსტრუქციებს, თუ მათ ცალსახად არ შეინარჩუნებთ, ხოლო დამატებული ინსტრუქციების დაცვა მცირდება, რაც მეტს დააგროვებთ. თუ კოდინგ-კონვენციის პრობლემის გამოსასწორებლად მათკენ ხელი მიგიწვდებათ, თითქმის ყოველთვის უკეთესი ადგილი ზემოთ ჩამოთვლილი მექანიზმებიდან რომელიმეა.

ყველაზე გავრცელებული ანტი-პატერნები

მათი უმეტესობა ერთი და იგივე შეცდომაა — კატეგორიული შეცდომა — სხვადასხვა ტანსაცმელში.

1. „არასოდეს” წესები პროზაში. „არასოდეს დაარედაქტირო გენერირებული ფაილები” CLAUDE.md-ში იმედია. PreToolUse hook გენერირებულ ბილიკზე ფაქტია.
2. რომანის სიგრძის CLAUDE.md. პროცედურები, ისტორია, დასაბუთება და ყველა ოდესმე ნასწავლი გაკვეთილი, ყველაფერი ყოველ ტურნზე ჩატვირთული. პროცედურები გაიტანეთ skills-ში, path-სპეციფიკური ნაწილები — scoped rules-ში და წაშალეთ ყველაფერი, რაც აღარ ასწორებს რეალურ პრობლემას.
3. Scope-ის გარეშე rules. წესი მონაცემთა ბაზის მიგრაციებზე, რომელიც იტვირთება, სანამ ვინმე CSS-ს ასწორებს.
4. Subagent ყველაფრისთვის. subagents-ის სტატია პირდაპირ ამბობს, რომ ზედმეტად ბევრი custom აგენტი ავტომატურ დელეგირებას ნაკლებად სანდოს ხდის; გუნდების უმეტესობას რამდენიმე კარგად შემოსაზღვრული საკმარისი აქვს.
5. ბუნდოვანი დელეგირება. „შეისწავლე კოდბაზა” ამოცანა არ არის. „იპოვე X-ის ყველა გამოძახების ადგილი, ჩამოწერე ფაილი და ხაზი, არ დაარედაქტირო” — არის.
6. Skills ბუნდოვანი აღწერებით. თუ აღწერა არ ამბობს, როდის, აგენტი ვერ წყვეტს, ჩატვირთოს თუ არა.
7. პირადი პრეფერენციები გუნდურ ფაილში. ახლა ყველას სესია ერთი ადამიანის გემოვნებას ატარებს.
8. ავტომატიზაცია, სანამ პატერნი ნათელია. hooks-ისა და აგენტების წერა workflow-სთვის, რომელიც ჯერ არავის გაუკეთებია ხელით სამჯერ. დაიწყეთ საუბრით; დააკოდეთ მაშინ, როცა იცით, რას აკოდებთ.

სად ვიქნებოდი ფრთხილად

• ეს პროდუქტის სპეციფიკაა და ის მოძრაობს. ფაილების სახელები, მოვლენების სახელები, frontmatter ველები და ტოკენების ციფრები აქ Anthropic-ის სტატიებიდანაა დაწერის მომენტისთვის და შეიცვლება. პატერნი — ყოველთვის ჩართული memory, scoped rules, მოთხოვნისას პროცედურები, დეტერმინირებული hooks, იზოლირებული workers — გამძლე ნაწილია. სხვა ხელსაწყოებს საკუთარი ანალოგები აქვთ (AGENTS.md ფაილი, რედაქტორისთვის სპეციფიკური rule-ფაილები და ა.შ.); მე კატეგორიებს შევადარებდი და არ ვივარაუდებდი, რომ სემანტიკა ერთი-ერთზე ემთხვევა.
• რჩევითი უსარგებლო არ არის. „Skills ურჩევენ, hooks ახორციელებენ” შეიძლება ზედმეტად ისწავლოს როგორც „მხოლოდ hooks არის მნიშვნელოვანი”. რაც აგენტს თქვენს კოდბაზაზე კარგს ხდის, უმეტესად ცოდნა და პროცედურაა, რომელიც მხოლოდ რჩევითი შეიძლება იყოს. Hooks არის სარეზერვო დაცვა და არა სტრატეგია.
• Hooks არის კოდი თქვენი უფლებებით. ცუდად დაწერილი hook ახალი თავდასხმის ზედაპირია, ხოლო თანაგუნდელის დამატებული hook-კონფიგურაცია კოდია, რომლის გაშვებასაც აპირებთ. რევიუ შესაბამისად ჩაატარეთ.
• თქვენი harness რეგრესირებს. CLAUDE.md-ის, skill-ის ან hook-ის ყოველი ცვლილება აგენტის ქცევას ცვლის. რეალურ ამოცანებზე evals-ის რაიმე ფორმის გარეშე თქვენ ვიბით ახალისებთ. და ეს ყველაფერი მაინც context engineering-ია — მექანიზმები უბრალოდ განსხვავებული პასუხებია კითხვაზე, როდის ხედავს მოდელი რას.

როგორ დავნერგავდი

რომ გუნდი ნულიდან მეწყობა, ამ თანმიმდევრობით:

1. ჯერ CLAUDE.md. გაუშვით /init, შემდეგ მკაცრად შეკვეცეთ: ბრძანებები, სტრუქტურა, არაცხადი კონვენციები. დანიშნეთ მფლობელი. სამუშაო წესი: როცა აგენტი ერთსა და იმავე შეცდომას ორჯერ უშვებს, დაამატეთ შესწორება — ერთი ხაზი.
2. ერთი hook. PostToolUse ფორმატერი. შემდეგ PreToolUse ბლოკი ბილიკებზე, რომლებსაც ადამიანის გარეშე არასოდეს უნდა შეეხონ. CLAUDE.md-ის ყოველი „არასოდეს” წინადადება აქციეთ hook-ად ან permission-ად.
3. შემოსაზღვრეთ ნაწილობრივი. path-სპეციფიკური კონვენციები გადაიტანეთ paths-იან rules-ში, ხოლო პაკეტის დონის კონვენციები — ქვედირექტორიების ფაილებში.
4. ამოიღეთ პირველი skills. მოძებნეთ პროცედურები, რომლებსაც განუწყვეტლივ აკოპირებთ ან რომლებიც CLAUDE.md-ს ბერავს — release, მიგრაცია, PR-ის აღწერა. დაწერეთ მკაცრი აღწერები. ორი-სამი კარგი skill ოცზე უკეთესია, რომლებიც სპეკულატიურია.
5. დაამატეთ ორი-სამი subagent. მხოლოდ-წაკითხვადი მკვლევარი, მხოლოდ-წაკითხვადი reviewer, შესაძლოა verifier, რომელიც აპს უშვებს და გასწორების გარეშე აცნობებს. გამოიყენეთ ისინი საუბრით, სანამ ავტომატურ დელეგირებას დაეყრდნობით.
6. დაფუთავეთ და მართეთ. როცა setup სტაბილურია, დააფუთავეთ skills, აგენტები და hooks plugin-ში, რათა გუნდს ერთი ვერსია ჰქონდეს, ხოლო აუცილებლად-დასაცავი პოლიტიკა გადაიტანეთ managed settings-ში.

კარიერული კუთხე

აქ ჩუმად ახალი უნარი იკვეთება: harness-ის დიზაინი. ეს არ არის პრომპტების წერა. ეს უფრო platform engineering-ს ჰგავს — გადაწყვეტა, რომელი ცოდნა არის გარემოში, რომელი — მოთხოვნისას, რომელი აღსრულებადი და რომელი იზოლაციაში სრულდება, და შემდეგ ამ კონფიგურაციის რევიუ, ვერსიონირება და ტესტირება ნებისმიერი სხვა კოდივით. ადამიანები, რომლებიც ამაში კარგდებიან, ყველას აგენტურ სესიებს აუმჯობესებენ, და რადგან უნარი კატეგორიებს ეხება და არა სინტაქსს, ის გადადის ნებისმიერ შემდეგ ხელსაწყოზე.

უფრო ღრმად

თუ გსურთ ამის პრაქტიკა რეალურ კოდბაზაზე, Claude Code Mastery ფარავს ყოველდღიურ ციკლს და steering-ის სრულ ინსტრუმენტარიუმს — memory ფაილები, skills, hooks და subagents — პრაქტიკულად. AI-Native SDLC ამ harness-ს მართულ მიწოდების სასიცოცხლო ციკლში ათავსებს, თვით აგენტის კონფიგურაციაზე evals-ით. ამ ყველაფრის უკეთ მუშაობისთვის საჭირო upstream დისციპლინისთვის იხილეთ Spec-Driven Development Foundations და OpenSpec Mastery. ხოლო თუ გსურთ იგივე primitives-ით საკუთარი აგენტების აშენება, შემდეგი ნაბიჯია Claude Agent SDK.

---

წყაროები: Anthropic, Steering Claude Code: skills, hooks, rules, subagents and more; Using CLAUDE.md files; How to configure hooks; Skills explained; The complete guide to building skills for Claude; Subagents in Claude Code. ეს პოსტი დამოუკიდებელი კომენტარია; პროდუქტის დეტალები გამოქვეყნების შემდეგ შეიძლება შეცვლილიყო, ამიტომ გადაამოწმეთ ორიგინალები. დაკავშირებული ამ სერიაში: AI-native SDLC, context engineering, evals, Claude Code in production.