ინჟინერია28 პაკეტი
- code-mentor
- code-vuln-audit
- repo-audit
მოდელი კოდს წერს. ვარგა თუ არა — ამას ის არ წყვეტს.
atlas-orchestrator Claude Code‑ის, Codex‑ის და OpenCode‑ის პლაგინი არის: ყოველ ცვლილებას ერთ state machine‑ში ატარებს და ექვსი ლინზით ამოწმებს. ვერდიქტს სუფთა ფუნქცია ითვლის, არა მოდელი, და ადამიანური კარიბჭის გარეშე შენს კოდს არაფერი ეხება.
დავალება add parse_duration, the inverse of format_seconds
6 ლინზა5 გავლილი1 მონიშნული
- DOES-IT-RUNruncheckგავლილი
- CODE-QUALITYquality.lint_deliverableგავლილი
- SECURITYsemgrep sastგავლილი
- TEST-ADEQUACYadvisoryგავლილი
- REQUIREMENTS-COVERAGE7 criteriaგავლილი
- CORRECTNESScriticმონიშნული
verdict.merge -> verdict.gate
0 CRITICAL 0 HIGH 4 MEDIUM 2 LOWpass 0‑ზე კარიბჭე გაიარა: ბლოკავს მხოლოდ CRITICAL და HIGH
REFINE 1/2
სისწორის ან უსაფრთხოების ნებისმიერ სიმძიმის ხარვეზი refine pass‑ს მაინც იწვევს: ამ სიმძიმეს მოდელი ანიჭებს.
Pass 0‑ზე ცვლილებამ კარიბჭე უკვე გაიარა. ბაგი მაინც იძულებით refine pass‑მა იპოვა.
int() ყველა მათგანს იღებს, ამიტომ parse‑ის დროს გამონაკლისი არ გაჩნდა.
ნამდვილი გაშვება, 2026 წლის 12 სექტემბერი (იხ. პლაგინის README, „Proven live“).
claude plugin marketplace add null0xxx/atlas-orchestrator claude plugin install atlas-orchestrator@atlas-orchestrator ამ ორს Claude Code CLI სჭირდება; Python 3.11 ან უფრო ახალი კი ყველა host‑ს
როგორ ითვლება ვერდიქტი
კოდის აგენტი, რომელიც საკუთარ ნამუშევარს აფასებს, მას დასრულებულად ჩათვლის. atlas-orchestrator ამ ხმას ყველა მოდელს ართმევს, მათ შორის იმასაც, რომელმაც diff‑ი დაწერა.
მტკიცებულებებს პროგრამები აგროვებს
build‑ი ეშვება, diff‑ი ლინტერით მოწმდება, კრიტერიუმები ცვლილებას ედარება, ნახსენები ფაილების არსებობა მოწმდება, შეცვლილი კოდი სინტაქსურად მოწმდება, ფარგლებზე კი SAST სკანირება ეშვება. თითოეულს ბლოკირება დამოუკიდებლად შეუძლია, მოდელის ჩართვამდე.
runcheck,quality.lint_deliverable,reqcoverage,pathcheck,astlens,syntaxlens,semgrep sastDOES-IT-RUN
სრულად დეტერმინისტული
შენი შემოწმების ბრძანება მეხსიერების ზღვრითა და მკაცრ ვადით სრულდება, ყველა შეცვლილი ფაილი კი სინტაქსურად მოწმდება. მოდელი არ მონაწილეობს.
დეტერმინისტული საფუძველი
runcheck + astlens + syntaxlensTEST-ADEQUACY
დეტერმინისტული, სარეკომენდაციო
ტესტები ნამდვილად დაემატა და გაიშვა? მწვანე build‑ი, რომლის ტესტებიდან არც ერთი არ გაიშვა, მწვანე არ არის.
დეტერმინისტული საფუძველი
quality.lint_deliverableREQUIREMENTS-COVERAGE
დეტერმინისტული, სარეკომენდაციო
ყოველ გაყინული კრიტერიუმი რეალურ diff‑ის მიმართ მოწმდება, და ცვლილება, რომელიც შენს დასახელებულ ფაილებს გასცდა, ხარვეზი არის.
დეტერმინისტული საფუძველი
reqcoverage.coverage
სამი კრიტიკოსი, ერთმანეთისგან იზოლირებული
თითოეული კრიტიკოსი ზუსტად ოთხ რამეს იღებს: გაყინულ მოთხოვნას და კრიტერიუმებს, ცვლილების diff‑ს, რუბრიკის თავის ერთ ლინზას და დეტერმინისტულ მტკიცებულებების მისთვის საჭირო ნაწილს. სხვას არაფერს. ეს იზოლაცია სხვის დასკვნაზე მიყოლას გამორიცხავს: კრიტიკოსი ვერ დაეთანხმება დასკვნას, რომელიც მას არ უჩვენეს.
correctness-critic,code-quality-critic,security-criticCORRECTNESS
კრიტიკოსის მსჯელობა
აკეთებს თუ არა ცვლილება მოთხოვნილს, იმ მონაცემებზე, რომლებსაც შეხვდება? სასაზღვრო შემთხვევები, შეცდომის გზები, ერთით აცდენა, ტესტები, რომლებიც მოთხოვნას არ ფარავენ.
დეტერმინისტული საფუძველი
runcheckCODE-QUALITY
კრიტიკოსის მსჯელობა
ემთხვევა თუ არა რეპოზიტორიის არსებულ კონვენციებს? სტრუქტურა, სახელდება, მკვდარი კოდი და დარჩენილი debug token‑ები.
დეტერმინისტული საფუძველი
quality.lint_deliverableSECURITY
კრიტიკოსის მსჯელობა
ინექციები, სახიფათო sink‑ები, საიდუმლოები, ნდობის საზღვრები.
semgrep‑ის სკანირება დამოუკიდებლად ბლოკავს; ის fail-open არის, დაsemgrep‑ის არარსებობას ლინზა აღნიშნავს.დეტერმინისტული საფუძველი
semgrep sast
ვერდიქტს სუფთა ფუნქცია აბრუნებს
კრიტიკოსების ანგარიშებს და დეტერმინისტულ ხარვეზებს
verdict.mergeერთ ფორმატში მოყავს,verdict.gateკი ერთ შედეგში აერთებს. ორივე სუფთა არის: იგივე შემავალ მონაცემებზე ყოველთვის იგივე პასუხი. ორკესტრატორი მონაცემებს ამზადებს და შედეგს კითხულობს. ხმის უფლება მას არ აქვს.verdict.mergeverdict.gateverdict.final_status
შენი ნებართვის გარეშე არაფერი ხდება
სამი კარიბჭე, ზუსტად იმ სამ ადგილას, სადაც ადამიანის გადაწყვეტილება შედეგს ნამდვილად ცვლის.
INIT
ამოწმებს საკუთარ წინაპირობებს და ეძებს შეწყვეტილ გაშვებას, რომ ის გააგრძელოს. თუ იმპორტის იზოლაცია ხელმისაწვდომი არ არის, გაშვება აქვე წყდება, რათა დაუცველად არ გაგრძელდეს.
INTENT_
CAPTURED ყინავს დავალების პაკეტს: შენს მოთხოვნას სიტყვასიტყვით, მიღების კრიტერიუმებს მიმდევრობით, ცვლილების ფარგლებს, შემოწმების ბრძანებას და საწყის წერტილს. შემდეგ ეტაპებზე ამათ შეცვლა აღარ შეიძლება.
- ადამიანური კარიბჭე: დაზუსტება, სანამ სურათი არ დაიდება
CLARIFYპირობითი
გადაწყვეტილებების ხის საუბარი, რაუნდებად, ყოველ კითხვასთან რეკომენდებული პასუხით, ledger‑ში ჩაწერილი და გასაგრძელებელი; ის, რაც რეპოზიტორიაში წაკითხვით დგინდება, თვითონ დგინდება. ირთვება მხოლოდ მაშინ, როცა აუცილებელი ველი აკლია ან ფარგლები ნამდვილად ბუნდოვანი არის; ნათელი ამოცანა მას გამოტოვებს.
TRIAGED
განსაზღვრავს სამუშაოს ტიპს (ხარვეზის გასწორება, ახალი ფუნქცია, რეფაქტორინგი ან ტესტი) და ადასტურებს, რომ სამიზნე კოდის პროექტი არის. ეს მხოლოდ აღრიცხვა არის: მოდელი აქ არაფერს წყვეტს.
- ადამიანური კარიბჭე: გეგმის დამტკიცება, ერთ ბაიტის ჩაწერამდე
GROUNDED
scout‑ი, რომელსაც მხოლოდ კითხვის უფლება აქვს, ათვალიერებს რეპოზიტორიას და აბრუნებს ამ დავალებისთვის მნიშვნელოვან ფაქტებს, კონვენციებსა და წინააღმდეგობებს. ფაილებს ის არ ცვლის; მის ანგარიშს ორკესტრატორი ინახავს.
CODED
coder‑ი ცვლილებას დამტკიცებულ ფარგლებში ახორციელებს და დაბრუნებამდე თვითონ ამოწმებს. მისი საკუთარი დასკვნა სისტემისთვის მხოლოდ ერთ-ერთი მტკიცებულება არის, არასდროს საბოლოო.
VERIFIED
ეშვება ექვსივე ლინზის გადამოწმება: ჯერ დეტერმინისტული შემოწმებები, შემდეგ სამი იზოლირებული კრიტიკოსი, ბოლოს სუფთა ფუნქცია, რომელიც ყველაფერს ერთ ვერდიქტში აერთებს.
REFINEპირობითიმაქსიმუმ 2
ნებისმიერი ხარვეზი, რომელიც ბლოკავს, ასევე სისწორის ან უსაფრთხოების ნებისმიერი სიმძიმის ხარვეზი ახალ გავლას ითხოვს. ასეთი გავლების ზღვარი ორი არის, ამიტომ ციკლი აუცილებლად სრულდება.
- ადამიანური კარიბჭე: ბოლოს, შედეგის მიღება ან უარყოფა
OUTPUT
ერთადერთი ადგილი, სადაც გაშვება სრულდება. მიიღებ სტატუსით მონიშნულ შედეგს და თავად წყვეტ, რა უყო მას.
ინტერაქტიულ გაშვება ყოველ კარიბჭეზე ჩერდება და შენს პასუხს ელოდება.
დაზუსტება, სანამ სურათი არ დაიდება
თუ აუცილებელი ველი აკლია ან ფარგლები ნამდვილად ბუნდოვანი არის, გაშვება არ გამოიცნობს — გესაუბრება: გადაწყვეტილებების ხე, რაუნდებად დასმული კითხვებით, თითოეულთან რეკომენდებული პასუხით. სრულდება მხოლოდ მაშინ, როცა საერთო სურათს თავად დაადასტურებ, ნათელი ამოცანა კი ამ საუბარს საერთოდ გამოტოვებს. იგივე საუბარი ცალკე skill‑ადაც არის:
grill-me.გეგმის დამტკიცება, ერთ ბაიტის ჩაწერამდე
ხედავ, რომელი ფაილები შეიცვლება, რა მიდგომით, და ზუსტად რომელი ბრძანება შეამოწმებს შედეგს, როცა კოდი ჯერ ხელუხლებელი არის. დაამტკიცე, შეასწორე ან გააუქმე.
ბოლოს, შედეგის მიღება ან უარყოფა
გაშვება ჩერდება, სტატუსით მონიშნულ შედეგს წარადგენს და გკითხავს, რა უყო მას.
ამ საიტზე atlas‑ის ოთხივე ჩაწერილი გაშვება ერთხელ შეჩერდა CLARIFY‑ზე, ავტორის პასუხის მოლოდინში.
არაინტერაქტიულ გაშვებაზე პატიოსნად პასუხის გამცემი არავინ არის, ამიტომ არაფერს ეკითხება: ცვლილება იზოლირებულ ტოტსა და worktree‑ში რჩება, შენს კოდს არაფერი ეხება. იმდენად ბუნდოვანი ამოცანა, რომ გაგრძელება პატიოსანი არ იქნება, იქვე მთავრდება UNVERIFIED ნიშნით, და არა გამოცნობით.
ყოველ გადასვლა დისკზე, .atlas/<run_id>/ ჟურნალში, იწერება, ამიტომ გაშვება კონტექსტის შეკუმშვას გაუძლებს, და /atlas-orchestrator:atlas-resume მას ბოლო ჩაწერილ ეტაპიდან გააგრძელებს.
როცა გაშვება აქტიური არის, telemetry.sh ყოველ ინსტრუმენტის და subagent‑ის მოვლენაზე ამ გაშვების hooks.jsonl‑ში ერთ ხაზს ამატებს: PostToolUse, PostToolUseFailure, SubagentStart, SubagentStop. კონტექსტის ცოცხალი გრაფი ყოველ წაკითხვისას ჟურნალიდან ხელახლა ითვლება.
დიდი ცვლილებები, და რა იცავს გაშვებას
/atlas-orchestrator:atlas-weave დიდ ცვლილებას ისეთ ნაწილებზე ყოფს, რომლებიც ერთსა და იმავე ფაილს არ ეხება, და ერთდროულად მაქსიმუმ 3 გაშვებას ატარებს. შეერთების შემდეგ ყოველ ნაწილის ტესტები, რომლებიც საწყის ვერსიაზე მწვანე იყო, საერთო ხეზე ხელახლა ეშვება: ასე ჩანს ცვლილება, რომელიც ცალკე გადის, ერთად კი ჩავარდება. თუ სამუშაო ნამდვილად არ იყოფა, ის ზუსტად ისე მუშაობს, როგორც ერთი გაშვება.
ერთი გარსი გარე ტექსტისთვის ყველა ტექსტი, რომელიც მოდელმა თვითონ არ დაწერა, მაგრამ ხედავს (skill‑ის შიგთავსი, ინსტრუმენტის output‑ი, ჩავარდნილ build‑ის stderr), მონაცემად მოინიშნება, ამიტომ coder‑ის მიზანს, ფარგლებს ან სამიზნეს ვერ შეცვლის.
მხოლოდ წინ მიმავალი rollback ავარიისას მდგრადი reset‑ი, რომელიც მხოლოდ იზოლირებულ worktree‑ში ირთვება და შენს ნამდვილ კოდს არასდროს ეხება.
116 skill‑ის პაკეტი და სელექტორი, რომელიც სწორს ირჩევს
ფინანსები19 პაკეტი
- financial-ratio-toolkit
- discounted-cashflow-model
- equity-research-report
რჩეული18 პაკეტი
- find-skills
- fast-browser-use
- docx
პროდუქტიულობა17 პაკეტი
- grilling
- gantt-planner
- structured-minutes
შემოქმედება15 პაკეტი
- keynote-composer
- x-thread-crafter
- photo-magazine
მარკეტინგი11 პაკეტი
- seo-content-writer
- campaign-plan
- competitor-analysis
აკადემიური8 პაკეტი
- cv-tailor
- anki-card-maker
- scholarly-writing-refiner
GROUNDED ეტაპზე სელექტორი რეესტრს შენს გაყინულ მოთხოვნას ადარებს: პირველი შედეგი coder‑ის აქტიურ skill‑ად იქცევა, კრიტიკოსები მას არ ხედავენ, შენ კი შერჩევას pin, exclude, boost და categories ველებით მართავ.
116 გაზომილი რიცხვი არის: რეესტრი 116 პაკეტს ასახელებს, მათი manifest კი 661 ფაილს და 153 SKILL.md ჩანაწერს ფლობს — თითო პაკეტზე ერთს, დამატებით GitLab‑ის ჩადგმული 37 skill‑ი. Claude Code დისკზე 119 skill‑ს ითვლის: ამ პაკეტებს და ორკესტრატორის 3 skill‑ს; Codex და OpenCode თითოეული 156 native სახელს აღმოაჩენს — 151 გენერირებულს და 5 საკუთარს. თითოეულ host‑ზე გადამოწმებული აღმოჩენა არის: ჩადებულ პაკეტს host ავტომატურად ირთავს თუ არა, დადასტურებული არ არის; ორკესტრატორის skill‑ების პირდაპირ გამოძახება კი დადასტურებული არის.
როგორ გადამოწმდა თითოეული host‑ის კატალოგიიხსნება ახალ ჩანართში
რა დაიჭირა სინამდვილეში
კლიენტების ლოგოები და benchmark‑ების მტკიცებები არ არის: ამ პროექტს ისინი არ აქვს და არ გამოიგონებს. ქვემოთ მისი საკუთარი ჩაწერილი მტკიცებულებები არის, და ჟურნალებს თავად წაიკითხავ.
atlas‑ის აუდიტი ამ საიტზე
4‑დან 3 atlas‑ის გაშვება ამ საიტზე UNVERIFIED სტატუსით დასრულდა.
ორჯერ, საიტის build‑ის საკუთარ კოდის HIGH სიმძიმის ხარვეზებზე. ერთხელ, CRITICAL შეცდომაზე, რომელიც atlas‑მა საკუთარ გაშვების ჟურნალში იპოვა.
| გაშვება | თარიღი | დავალება | refine pass‑ები | შედეგი | CORR | CQ | SEC | TEST | RUN | REQ | ჯამი |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 48fb111e.1 | საიტის შექმნა | 2 | UNVERIFIED | 4 | 7 | 5 | 2 | 1 | 0 | 19 | |
| 48fb111e.2 | პირველ გაშვების დარჩენილ ხარვეზების გასწორება | 2 | UNVERIFIED | 3 | 7 | 5 | 1 | 0 | 0 | 16 | |
| 48fb111e | ახალი ფერები და „ადრე/შემდეგ“ დემონსტრაცია | 2 | UNVERIFIEDსნოსკა 2 | 12 | 6 | 0 | 1 | 1 | 0 | 20 | |
| a4f86c28 | ფერების გაშვების დარჩენილ ხარვეზების გასწორება | 1 | OK | 2 | 6 | 0 | 3 | 0 | 1 | 12 |
- ჟურნალი გაშვების მხოლოდ ბოლო გავლას ინახავს, რადგან ყოველ გავლა წინას გადაწერს. ამიტომ ამ ცხრილის ყოველ რიცხვი მინიმუმი არის, არა ჯამი. ტექსტზე დაბრუნება
48fb111eგაშვების 20 ხარვეზიდან ორკესტრატორმა coder‑ს 11 არ გადასცა: 10CRITICALpathcheckხარვეზი, რომელიც პლაგინის საკუთარ რეპოზიტორიის ნამდვილ გზებს ამ საიტის root‑ის მიმართ ამოწმობდა, და ფარგლებს გარეთ 1HIGHხარვეზი impeccable პლაგინის hook‑ის cache‑ზე, ფაილზე, რომელსაც coder‑ი არ წერდა. კარიბჭე სუფთა ფუნქცია არის და გადაუცემელის შესახებ არაფერი იცის, ამიტომUNVERIFIEDდააბრუნა. ხარვეზებიდან, რომლებიც ბლოკავს, ამ სიაში მხოლოდ ჟურნალისstale-verdictარ მოხვდა. ტექსტზე დაბრუნება
ყოველ ლინზის ერთი ნამდვილი ხარვეზი
ყოველ ლინზის ხარვეზის წაკითხვა
ქართულ გვერდზე screen reader‑ი ლინზის მდგომარეობას (გავლილი ან მონიშნული) ინგლისურ სიტყვით, ენის მონიშნვის გარეშე აცხადობდა.
stylesheet‑ი და დიზაინის დოკუმენტი ორივე ამბობდა, რომ საიტზე ფერადი შარავანდი არსად არის, მთავარ ღილაკზე hover‑ისას კი თეთრ ნათება ჩნდობდა.
ყოველ build‑ი output‑ის დირექტორიაში symlink‑ებს წაშლობდა, ისეთებსაც, რომლებიც manifest‑ში არასდროს ჩაიწერა; სერვერზე, სადაც version control‑ი არ არის, სერტიფიკატის განახლების link‑ი შეიძლება ისე წაიშლოდა, რომ აღდგენა შეუძლებელი იქნებოდა. ხარვეზი რისკს აღწერს, ჩაწერილ წაშლას არა. გასწორდა: link‑ი ახლა მხოლოდ მაშინ წაიშლება, როცა manifest‑ში ჩაწერილი არის; ამ საიტის კოდში შემოწმდა 2026 წლის 13 სექტემბერს.
„მხოლოდ Python 3‑ის სტანდარტული ბიბლიოთეკა“ ყოველ მოდულზე სწორი იყო, მაგრამ, თუ ეს ოდესმე შეიცვლოდა, არც ერთი ტესტი არ ჩავარდოდა.
ჟურნალში ეტაპების ისეთი წყვილი ჩაიწერა, რომელსაც state machine‑ი არ უშვებს, ამიტომ გაშვების საკუთარ ჩანაწერზე დაყრდნობა შეუძლებელი იყო.
დამტკიცებული გეგმა ჩრდილებში ისეთ ფერს უშვობდა, რომელსაც გამოქვეყნებული ტესტი უარყოფდა, და გეგმიდან ეს გადახვევა არსად ჩაიწერა.
39 ხარვეზი skill‑ების საკუთარ სისტემის შექმნისას
რეესტრი, სელექტორი და skill‑ების პაკეტების ჩადება: თითოეულმა სრული ციკლი გაიარა. პლაგინის README‑ის „Proven live“ ნაწილის თანახმად, ორ გაშვებაზე სისტემამ 39 ნამდვილი ხარვეზი დაიჭირა, მათ შორის კრიტიკული zip-slip: მავნე skill‑ი frontmatter‑ის name ველის საშუალებით ექსტრაქტორის საქაღალდიდან გარეთ ფაილს ჩაწერდა. ეს გასწორდა, სანამ რამე გამოვიდოდა: სახელის მკაცრ ვალიდაციით, კოლიზიების შემოწმებით, გზისა და symlink‑ის დაცვით და მავნე შემავალ მონაცემების ტესტების მატრიცით.
ეს პროექტის საკუთარი ჩანაწერები არის, არა მესამე მხარის benchmark‑ები.
რას არ აკეთებს
გადამოწმების ხელსაწყო, რომელიც თავის შესაძლებლობებს აზვიადებს, ზუსტად ის არის, რაც ეს პროექტი არ უნდა იყოს. ეს პროექტის მიერ დასახელებული შეზღუდვები არის, შერბილების გარეშე.
შინაარსობრივად მცდარი დაყოფა გადაწყვეტილი არ არის
კარიბჭეები ხარვეზებს და ტესტებით ხილვად რეგრესიებს იჭერს, მაგრამ ვერ დაიჭერს დაყოფას, რომელიც ლოგიკურად გამოიყურება და შინაარსობრივად მცდარი არის. რისკი შემცირებული არის (ერთ გაშვებამდე დაბრუნება, კავშირების შემოწმება, „ნაკერების“ კრიტიკოსები, კრიტერიუმების შენახვა), მაგრამ ცხადად გადაწყვეტილი არ არის.
დიფერენციალი სწორი არის, მაგრამ არა სრული
ორ ცვლილების ურთიერთქმედება, რომელსაც არც ერთი ტესტი არ ფარავს, შეიძლება მაინც მწვანედ შეერთდეს.
მსჯელობის ლინზებზე მოდელი სჯის
დეტერმინისტული საფუძველი ბლოკავს ყველაფერს, რაც მექანიკურად აღმოჩნდება. დახვეწილი ბაგი, რომელიც ერთი შეხედვით ადეკვატულ ტესტის უკან იმალება, დასახელებული სუსტი წერტილი რჩება, არა გადაწყვეტილი პრობლემა.
ჩადებული skill‑ები მესამე მხარის შიგთავსი არის
მათი მთლიანობა ჰეშებით დამაგრებული არის და მოდელს ცხადად, გარე ტექსტის გარსში მიეწოდება, მაგრამ ეს მათი ავტორების ინსტრუქციები არის, რომლებიც შენი სახელით სრულდება. მგრძნობიარე გარემოში, skill‑ის payload სკრიპტებზე დაყრდნობამდე, მის საქაღალდეს გადაათვალიერე.
გამტარობა შეგნებულად მცირე არის
ინტეგრაციის ეტაპი თანმიმდევრული „ვიწრო ყელი“ არის, ამიტომ ერთ გაშვებაზე სასარგებლო პარალელიზმი დაახლოებით თორმეტიდან თექვსმეტ კვანძამდე არის, არა ასობით. ეს დიზაინი არის: ხარისხი რაოდენობის ნაცვლად.
დაყენება
ორი ბრძანება Claude Code‑ზე, ან ერთი ინსტალატორი სამივე host‑ისთვის. შემდეგ ერთი ნამდვილი დავალება.
მოთხოვნები
Claude Code CLI და CPython 3.11 ან უფრო ახალი, python3‑ად. ზღვარი მკაცრი არის: იზოლაცია, რომელიც არასანდო რეპოზიტორიას კარიბჭის მოდულების ჩანაცვლებას არ ანებავს, 3.11‑მდე არ არსებობდა, ამიტომ ძველ ვერსიაზე ყოველი გაშვება პირველ ნაბიჯზე წყდება, რათა დაუცველად არ გაგრძელდეს. რამდენიმე LTS დისტრიბუცია ჯერ 3.10‑ს აწვდის, ამიტომ დაყენებამდე შეამოწმე.
python3 -Vდაამატე marketplace‑ი
claude plugin marketplace add null0xxx/atlas-orchestrator დააყენე პლაგინი
claude plugin install atlas-orchestrator@atlas-orchestrator შეამოწმე, ჩაიტვირთა თუ არა
/atlas-orchestrator:atlas ping შემდეგ მიეცი ნამდვილი დავალება
საილუსტრაციო დავალება
/atlas-orchestrator:atlas fix the off-by-one in pagination verify_cmd: pytest -q success: page 2 returns rows 11-20 scope: api/ pagination.py verify_cmd:- ბრძანება, რომელიც წარმატებით უნდა სრულდეს
success:- მიღების კრიტერიუმები, ადამიანურ ენაზე
scope:- ფაილები, რომლებსაც atlas‑ს შეცვლა შეუძლია; მათ გარეთ ცვლილება ხარვეზი არის და ბლოკავს
სამივე ველი არასავალდებულო არის: გამოტოვებულ ველს
CLARIFY‑ზე გკითხავენ.
სამი ბრძანება: /atlas-orchestrator:atlas ერთ ცვლილებისთვის, /atlas-orchestrator:atlas-weave, როცა სამუშაო ნამდვილად რამდენიმე ცვლილება არის, და /atlas-orchestrator:atlas-resume შეწყვეტილ გაშვების გასაგრძელებლად.
რას ამატებს Claude Code‑ს
აგენტები, skill‑ები და hook‑ები, რომლებსაც ამატებს
- აგენტები
- 7
context-scout,elite-coder,correctness-critic,code-quality-critic,security-critic,integration-critic,planner - Skill‑ები
- ორკესტრატორის 3 skill‑ი და 116 ჩადებული skill‑ის პაკეტი
- Hook‑ები
init-env.shSessionStartsession-resume.shSessionStarttelemetry.shPostToolUse,PostToolUseFailure,SubagentStart,SubagentStop
hook‑ების manifest‑ი მხოლოდ fail-open, observe-only ან pointer-only hook‑ებს არეგისტრირებს.
ერთი ინსტალატორი სამივე host‑ისთვის
როგორ დააყენო ან განაახლო სამივე ერთად
რეპოზიტორიის ლოკალური ასლიდან ერთი მმართველი Claude Code‑ს, Codex‑ს და OpenCode‑ს ერთად აყენებს ან განაახლებს: plan მხოლოდ კითხვადი წინასწარი ხედვა არის, apply აყენებს ან განაახლებს, rollback კი წინა რევიზიას აბრუნებს.
python3 scripts/atlasctl.py plan python3 scripts/atlasctl.py apply python3 scripts/atlasctl.py rollback დაყენებისას მოდელს არ მიმართავს, საკუთარ ასლს ~/.local/share/atlas-orchestrator/current‑ში ფლობს, და დაუმუშავებელ ასლზე ან უცნობ ფაილზე უარს ამბობს. --channel development origin/main‑ს მიჰყვება, --ref გამოქვეყნებულ რევიზიას იღებს, --repo სხვა რეპოზიტორიას ან ლოკალურ ასლს, --hosts კი დაყენებას შენ მიერ დასახელებულ host‑ებამდე ავიწროებს; ნაგულისხმევად სამივე არის.
განახლების შემდეგ Claude Code ან OpenCode ხელახლა გაუშვი, Codex‑ში კი ახალი thread გახსენი.
ორივე ვერსია შვიდ როლის კონტრაქტს, ხუთ საკუთარ skill‑ს და 116 პაკეტის გენერირებულ კატალოგს ატარებს, იმავე scripts/ ბირთვზე, უცვლელად:
Codex‑ზე
როგორ მუშაობს Codex‑ზე
ეს ვერსია runtimes/codex/‑ში არის და უკვე არსებულ ChatGPT‑ის ავტორიზაციას იყენებს, საკუთარი API‑ს გასაღებების გარეშე.
Codex‑ის exec ყოველ როლს მხოლოდ კითხვის უფლებით ტოვებს, გარდა coder‑ისა — ერთადერთისა, ვინც განსახილველ კოდს წერს — და უფლებების გაზრდა შვილობილ პროცესს არ შეუძლია. მომხმარებლის exec‑ის წესები, ჩადგმული აგენტები, პლაგინები და hook‑ები გამორთული არის, პროექტის MCP სერვერები კი ცალკე მითითებით, რადგან დისტანციური ჩაწერა ფაილურ სისტემაზე დადებულ შეზღუდვას გვერდს აუვლიდა.
დამახინჯებული JSON, კრიტიკოსის დარღვეული კონტრაქტი, დაკარგული საბოლოო პასუხი, დროის ამოწურვა და პროცესის ჩავარდნა — ყველა დახურვით სრულდება. თუ არჩეული მოდელი ხელმისაწვდომი არ არის, გაშვება ჩერდება და სუსტზე არ გადადის, ხოლო medium‑ზე დაბალ მსჯელობას გამშვები არ იღებს.
პაკეტში ჩადებული პროფილი
gpt-5.6-solhighelite-coder,planner,correctness-critic,security-critic,integration-criticgpt-5.6-terramediumcontext-scoutgpt-5.6-terrahighcode-quality-critic
ეს საწყისი კონფიგურაცია არის და არა რანჟირება: პროექტი თვითონ ამბობს, რომ როლებს შორის ხარისხი და ხარჯი გაზომილი არ არის. სესიის მოდელს, საიდანაც უშვებ, შენ ირჩევ და არა ეს პროფილი.
OpenCode‑ზე
როგორ დააყენო OpenCode‑ზე
ეს ვერსია runtimes/opencode/‑ში არის, და დაყენებულ როლების და skill‑ების ფაილებს OpenCode თვითონ აღმოაჩენს.
OpenCode როლების და skill‑ების ფაილებს ~/.config/opencode/agent/ და ~/.config/opencode/skills/ დირექტორიებიდან კითხულობს. ზემოთ აღწერილი ინსტალატორი მათ თვითონ ათავსებს იქ; რეპოზიტორიის ლოკალური ასლიდან symlink‑ებს ხელითაც შექმნი, როლების ფაილებზე და skill‑ების დირექტორიებზე, ისე, როგორც ამ ვერსიის README ამბობს.
როლების ფაილებში მოდელი მითითებული არ არის, რადგან OpenCode რომელიმე provider‑ზე მიბმული არ არის: რომელი მოდელი რომელ როლს ასრულებს, შენს სისტემაზე, პლაგინის გარეთ, თავად განსაზღვრავ.
ერთი დამცველი hook‑ი, რომელიც თავად ჩართავ
რას ამოწმებს, და როგორ ჩართე
guard-destructive.sh პლაგინის ერთადერთი hook‑ი არის, რომელსაც ინსტრუმენტის გამოძახების ბლოკირება შეუძლია: Bash‑ის ბრძანებებს გაშვებამდე denylist‑ით ამოწმებს. ნაგულისხმევად ჩართული არ არის, რადგან PreToolUse hook‑ი, რომელიც ბლოკავს, პლაგინის დაყენების შემდეგ Claude Code‑ის ყოველ სესიას ეხება; ის განზრახ best-effort და fail-open არის.
ჩასართავად hooks/hooks.json‑ში მისთვის PreToolUse ჩანაწერი დაამატე; ზუსტ ჩანაწერს hook‑ის საკუთარ header‑ი აჩვენებს.
ჩართვამდე ეს გაითვალისწინე: პლაგინის საკუთარ უსაფრთხოების აუდიტმა აღმოაჩინა, რომ ის ზოგ ჩვეულებრივ შედგენილ ბრძანებასაც ბლოკავს, მაგალითად rm -rf ./build && ls /‑ს. 4.8.1‑ის guard‑ი ამ ბრძანებას ახლაც ბლოკავს, და გასწორება არც ერთ რელიზში ჩაწერილი არ არის.
Headless და CI
ბრძანება, და რა წაიკითხე მის გაშვებამდე
ერთჯერადი, არაინტერაქტიული გაშვება. რადგან დამტკიცებაზე პასუხის გამცემი არავინ არის, გაშვება იზოლირებულ ტოტსა და worktree‑ში რჩება და შედეგს ისე წარადგენს, რომ შეერთების გადაწყვეტილება ადამიანმა მიიღოს.
კოპირებამდე ყურადღებით წაიკითხე, რას აკეთებს ფლაგი: bypassPermissions Claude Code‑ში ყველა ნებართვის შეკითხვას გამორთავს, არა მხოლოდ მათ, რომლებსაც atlas ამატებს. გაუშვი ერთჯერად კონტეინერში ან CI‑ზე, რომელსაც თავად აკონტროლებ, არასდროს საკუთარ კომპიუტერზე.
claude --permission-mode bypassPermissions -p "/atlas-orchestrator:atlas <change> verify_cmd: <cmd> success: <criteria> scope: <paths>" თავად atlas-orchestrator‑ის განვითარება
თუ პლაგინის შეცვლა გინდა, არა მხოლოდ გამოყენება, რეპოზიტორიიდან დაიწყე: მის README‑ში ახსნილი არის, როგორ ჩატვირთე ის ლოკალურ ასლიდან.