สารบัญ oh-my-hermes ทั้ง 119 skills, แผนที่เต็มของทีม AI ข้ามคืน

โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026

บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจากเอกสาร Workflow Reference ทั้งหมด 919 กิโลไบต์ของโปรเจกต์ ซึ่งผมแยกวิเคราะห์ทีละ skill ด้วยสคริปต์จริง

บทความก่อนหน้าผมเขียนรีวิวโปรเจกต์ oh-my-hermes ในภาพกว้าง (อ่าน README ฉบับเต็มของโปรเจกต์ [2]) และมีคนถามต่อมาว่า ข้างในมีอะไรซ่อนอยู่จริงๆ คำตอบสั้นคือมีมากเกินจะเล่าจบในหนึ่งบท ผมจึงกลับไปไล่อ่านเอกสาร workflow ทั้งไฟล์ (ยาว 919 กิโลไบต์ แปลว่าราวๆ เจ็ดแสนตัวอักษร) แล้วเขียนสคริปต์แยกทุก skill ออกมาเป็นข้อมูลโครงสร้างนับจริง

ผลลัพธ์คือบทความนี้: สารบัญเต็มของ skills ที่ติดตั้งได้จริง 119 ตัว จาก 41 หมวด พร้อมคำอธิบายว่าแต่ละตัวทำอะไร เรียงตามกลุ่มงานที่มนุษย์ใช้จริง บทความยาวกว่าปกติโดยเจตนา เพราะนี่คือสิ่งที่ผู้ใช้จริงต้องการ: เห็นปุ่มทั้งหมดก่อนตัดสินใจว่าจะกดตัวไหน

ก่อนอ่าน: วิธีอ่านสารบัญนี้

สามสิ่งที่ควรรู้ก่อนไล่ดู

หนึ่ง เครื่องหมายต่อไปนี้คือสถานะติดตั้งจริงจากเอกสาร: ✓ คือติดตั้งแล้วเรียกใช้ผ่านแชตได้เลย ช่องว่างคือใช้ภายในระบบเท่านั้น ทั้ง 119 ตัวในสารบัญนี้คือกลุ่มแรกทั้งหมด

สอง ทุก skill ระบุบทบาท (role) ที่ Hermes จะสวมระหว่างทำงาน จากเก้าบทบาทที่นิยามไว้ในเอกสาร Roles [3]: guide (นำทาง), researcher (นักวิจัย), planner (นักวางแผน), operator (ผู้ปฏิบัติ), memory-keeper (ภารโรงความจำ), handoff-guide (ผู้ส่งต่อ), builder (ผู้สร้าง), tracker (ผู้ติดตาม), reviewer (ผู้ตรวจ)

สาม โครงสร้างของระบบไม่ได้เรียงตามตัวอักษร แต่เป็นเส้นทางงานจริง: ทำความเข้าใจโจทย์ ค้นคว้า วางแผน ลงมือ ตรวจสอบ บำรุงรักษา ผมจัดตามเส้นทางนี้เพื่อให้ผู้อ่านเห็นว่าแต่ละช่วงมีเครื่องมืออะไรรองรับ

ภาพรวมก่อนลงรายละเอียด สิบหมวดใหญ่สุดของระบบเรียงตามจำนวน skills:

หมวด	จำนวน	หน้าที่หลัก
operations	13	งานบริหาร การเงิน HR สนับสนุนลูกค้า
planning	11	วางแผน แตกปัญหา รีวิวแผน
research	10	ค้นคว้ามีแหล่งอ้างอิง
review	7	ตรวจโค้ด ความปลอดภัย กฎหมาย
materials	7	ผลิตสไลด์เอกสารรายงาน
operator	7	คำสั่งบริหารระบบเอง
verification	5	ด่านตรวจผ่านจริง
observability	5	เฝ้าดูสถานะและประสิทธิภาพ
optimization	5	จับจุดช้าและแพง
hermes-setup	4	ตั้งค่าโมเดลและเครื่องมือ

หมวดเล็กที่เหลืออีก 31 หมวด มีหนึ่งถึงสาม skills แต่ละหมวด รวมเป็นความสามารถเฉพาะทางที่ต่อกันเป็นระบบเดียว

ถ้าให้อุปมา: บทก่อนหน้าพาคุณดูบริษัทจากภายนอก บทนี้พาเดินลิสต์พนักงานทั้งบริษัททีละแผนก ตั้งแต่ฝ่ายรับโทรศัพท์ไปจนถึงฝ่ายตรวจสอบภายใน

ช่วงที่ 1: ทำความเข้าใจก่อนเริ่ม (clarification + context)

สอง skills ที่ออกแบบมาเพื่อกันงานพังตั้งแต่ยังไม่เริ่ม

✓ deep-interview ถามทีละข้อจนรู้ว่าคุณต้องการอะไรแน่ ไม่เดา ไม่สมมติเอง ถ้าคุณเคยเจอเอเจนต์ที่รับคำสั่งกว้างๆ แล้ววิ่งไปทิศลอยๆ จนจบงานผิด นี่คือยาแก้โรคนั้นโดยตรง

✓ context จัดแนวศัพท์ของโปรเจกต์ให้ตรงกันก่อนเริ่มงาน ค้นว่าคำแต่ละคำใน repo นี้หมายถึงอะไรจริง บันทึกคำที่ยืนยันแล้ว และแก้คำที่ใช้คลาดเคลื่อน งานเทคนิคจำนวนมากพังเพราะคนสองฝั่งเรียกของชื่อเดียวกันคนละความหมาย

ช่วงที่ 2: ฝ่ายวิจัยและค้นคว้า (research, 10 skills)

หัวใจของกลุ่มนี้คือความจริงเรื่องแหล่งข้อมูล: ทุกงานต้องมีแหล่งอ้างอิงจับต้องได้

✓ research เครื่องยนต์วิจัยเชิงลึก ศึกษาจากโค้ดโอเพนซอร์สจริงเพื่อยืนพื้นฐานให้สเปกและการตัดสินใจ

✓ web-research รอบค้นเว็บครั้งเดียวที่ต้องมี citation ตอบคำถามข้อเท็จจริงปัจจุบันให้จบ

✓ source-finder เตรียมบัญชีแหล่งข้อมูลเป้าหมายพร้อมสถานะการเข้าถึงก่อนลงมือดาวน์โหลด คล้ายรายชื่อพยานก่อนสืบคดี

✓ research-brief เปลี่ยนคำถามเชิงธุรกิจ (ตลาด คู่แข่ง ราคา ลูกค้า) ให้เป็นบรีฟที่นำไปตัดสินใจได้

✓ research-department สิ่งที่น่าสนใจสุดของกลุ่ม: ประสานงานวิจัยแบบแผนกจริง มี Scout (หาของ) Analyst (วิเคราะห์) และ Briefer (เขียนสรุป) ทำงานต่อกันเป็นสายพาน

✓ paper-learning อธิบาย paper วิจัยหรือ PDF ตามระดับความเข้าใจที่คุณเลือก (ผมใช้วิธีเดียวกันนี้ในการรีวิว paper ทั้งสามบทที่เขียนไปเมื่อวาน)

✓ jit-learn เลือกหัวข้อที่คุ้มค่าที่สุดให้เรียนตอนนี้พอดีกับปัญหาที่เจอ ค้นคว้าอย่างน่าเชื่อถือ แล้วยืนยันก่อนเริ่ม

✓ autoresearch-goal งานวิจัยเชิงเป้าหมายที่วิ่งยาวได้

✓ best-practice-research ค้นแนวปฏิบัติที่ดีจากเอกสารทางการต้นน้ำเท่านั้น จำกัดขอบเขตชัด

✓ product-docs เอกสารผลิตภัณฑ์ที่อ้างแหล่งปัจจุบันเสมอ

ช่วงที่ 3: วางแผนแบบมืออาชีพ (planning, 11 skills)

กลุ่มใหญ่สุดอันดับสองของระบบ เพราะเอกสารของโปรเจกต์ยึดหลักว่าแผนที่ผ่านการรีวิวคือของกั้นระหว่างงานเสร็จกับงานพัง [1]

✓ plan วางแผนแบบมีโครงสร้างก่อนลงมือเสมอ

✓ ralplan วางแผนแบบประชามติพร้อมด่านตรวจ (review gates) ทุกขั้น

✓ adversarial-consensus เปิดมุมมองอิสระหลายฝั่งโจมตีข้อเสนอ แล้วกลั่นสิ่งที่รอดมาเป็นชุดให้ตัววางแผนตัวอื่นใช้ต่อ (ผมเคยเรียกมันว่าจ้างผู้เชี่ยวชาญหลายฝ่ายมาถกแทนเชื่อมุมเดียว)

✓ curriculum-design เปลี่ยนเป้าหมายการเรียนเป็นหลักสูตรที่สอนได้จริง พร้อมแผนวัดผล

✓ product-brief เปลี่ยนหลักฐานผลิตภัณฑ์เป็น PRD และกรอบจัดลำดับ

✓ strategy-brief ตัดสินใจระหว่างทางเลือก: ข้อแลกเปลี่ยน ข้อเสนอแนะ และบันทึกการตัดสินใจที่ลงมือทำได้

✓ codebase-onboarding สร้างแผนที่ repo เส้นทางอ่าน อภิศัพท์ และแผนความเสี่ยงสำหรับคนใหม่

✓ codebase-uml เปลี่ยน repository ทั้งทั้งหมดให้เป็นภาพสถาปัตยกรรม PlantUML หนึ่งหน้าที่อ่านระดับ interface ได้

✓ codegraph-refresh รีเฟรชความเข้าใจโค้ดเบสให้เป็นปัจจุบัน

✓ backend เตรียมสัญญา server, API และชั้นข้อมูล พร้อมขอบเขต auth และ error

✓ rust วางแผนงานภาษา Rust ด้วยวินัย ownership, error และ API โดยเฉพาะ

ช่วงที่ 4: ลงมือสร้าง (execution + delivery)

✓ ultrawork แบ่งแผนที่ตกลงแล้วเป็นเลนขนานที่ไม่ซ้อนกัน ทุกเลนมีเกณฑ์ผ่าน คำสั่งตรวจ และเจ้าของ กันสองเลนแก้ไฟล์เดียวกันจนตีกัน

✓ maestro เตรียมส่งต่องานให้เอเจนต์เขียนโค้ดที่คุณเลือกไว้ (เช่น Claude Code หรือ Codex) โดยเรียบเรียง prompt จาก skill ที่ตัวนั้นติดตั้งไว้จริง ไม่ใช่เดาว่ามันทำอะไรได้

✓ loop วงจร: สัมภาษณ์โจทย์ วางแผน ค้นคว้า สร้าง รีวิว แล้ววนซ้ำจนผ่านด่านจริง ไม่ใช่ผ่านแบบบอกตัวเองว่าผ่าน

✓ idea-to-deploy จากไอเดียแอบถึงการปล่อยใช้จริง: ตัดสินใจ ส่งต่องาน ตรวจสอบ แล้วส่งมอบ

✓ llm-app-dev เตรียมส่งต่องานสร้างฟีเจอร์ที่ขับเคลื่อนด้วย LLM พร้อมสัญญาที่ชัด

✓ frontend งาน UI ที่ขับเคลื่อนด้วย design system ทั้งเว็บและ terminal

✓ frontend-refactor รีแฟกเตอร์ UI โดยพฤติกรรมต้องคงเดิม ดูผลลัพธ์เต็มก่อนแตะทุกครั้ง

ช่วงที่ 5: ตรวจสอบและล้างข้อมอง (review + verification + maintenance)

ส่วนที่โปรเจกต์นี้หนักแน่นที่สุด และเป็นเหตุผลที่มันเติบโตเร็ว

ฝ่ายตรวจ (review, 7 skills): ✓ code-review (รีวิวแบบหาบั๊กก่อน มีหลักฐานประกอบ), ✓ security-safety-review (ตรวจ prompt, เครื่องมือ, ความลับ, dependency, การกระทำทำลายล้าง), ✓ production-audit (ประเมินความพร้อมปล่อยใช้จริงทั้ง deploy, rollback), ✓ legal-compliance-review (ผิดพลาดทางสัญญาก่อนตัดสินใจกฎหมาย), ✓ localization-review (พร้อมสำหรับแต่ละภาษาและวัฒนธรรม), ✓ failure-signal-audit (หา error ที่ถูกกลืน, fallback อันตราย), ✓ ask (ปรึกษาที่ปรึกษาภายนอกเมื่อตั้งค่าไว้)

ฝ่ายตรวจสอบ (verification, 5 skills): ✓ verification-gate (นิยามและบันทึกด่าน build, lint, typecheck, test, security), ✓ ultraqa (QA แบบคิดว่าโจมตีแล้วแก้เป็นวงจร), ✓ build-failure-triage (จัดหมวด build พังทุกชนิดแล้วชี้ทางแก้), ✓ native-debugging (ดีบั๊ก binary แบบตั้งสมมติฐาน), quality-evidence-loop (เตรียมฉาก QA และมาตรฐานหลักฐาน)

ฝ่ายบำรุงรักษา (maintenance, 3 skills): ✓ ai-slop-cleaner (ลบขยะที่ AI สร้าง โค้ดตาย ส่วนซ้ำ โดยพฤติกรรมต้องเหมือนเดิม), ✓ tech-debt-audit (หนี้เทคนิคจัดเรียงตามความรุนแรงต่อแรงที่ต้องใช้แก้), ✓ workspace-audit (แผนที่ repo, skill, prompt, plugin, MCP, hook, config ทั้งเครื่อง)

ช่วงที่ 6: วัดผลและเพิ่มประสิทธิภาพ (optimization + observability)

✓ ultraperf หาว่าระบบช้า รั่ว หรือแพงตรงไหนจริงข้าม runtime, memory แล้วแก้ทีละจุดร้อน

✓ model-optimization เมื่อโมเดลออกรุ่นใหม่ ช่วยตัดสินใจว่าคุ้มจะย้ายไหม ด้วยตารางตัดสินใน

✓ inference-serving เลือก engine และ quantization สำหรับการเสิร์ฟโมเดลจากตารางเปรียบเทียบ

✓ performance-goal ปรับปรุงประสิทธิภาพแบบตั้งเป้าวัดผลได้

✓ run-efficiency รายงานประสิทธิภาพการรันจากข้อมูลจริงที่มองเห็น ไม่เดา

ฝ่ายสังเกตการณ์ (observability, 5 skills): ✓ context-budget-review (วางแผนงบ token และค่าใช้จ่าย), ✓ ops-observability-card (บอร์ดคำสั่งสำหรับผู้ดูแล), ✓ harness-session-inventory (ทำให้ session ของ Codex, Claude Code, Hermes ฯลฯ อยู่ในรูปแบบเดียวกันเพื่อเทียบ), ✓ achievements (เหรียญตราจาก badge จริง), ✓ run-efficiency

สอง skills พิเศษที่ผมชอบที่สุดในโปรเจกต์ทั้งหมด:

✓ instinct-ledger เปลี่ยนบทเรียนที่เจอซ้ำๆ ให้เป็นสัญชาตญาณ atomic ที่มีคะแนนความมั่นใจ แยกขอบเขตการเลื่อนระดับชัดเจน นี่คือวิธีทำให้ AI เก็บประสบการณ์แบบผู้เชี่ยวชาญมนุษย์

✓ workflow-learning จัดหมวดและรีวิวเส้นทาง self-improvement ของระบบเองเป็นสารบัญ

ช่วงที่ 7: ความจำและความรู้ (memory + knowledge)

✓ memory-new จับความจำโปรเจกต์หนึ่งเรื่องต่อครั้ง ผ่านการตัดสินใจจำ ปฏิเสธ หรือเลื่อนอย่างชัดเจน ไม่ใช่เก็บมั่ว

✓ memory-sync รีวิวข้ออ้างในความจำ (USER.md, MEMORY.md) เตรียมการปรับเทียบ โดยไม่แตะความจำภายในของ Hermes โดยเด็ดขาด

✓ decision-recall ดึงมติที่เคยถูกปฏิเสธกลับมาดูได้โดยไม่ยกให้เป็นความจำที่อนุมัติแล้ว

✓ rules-distill กลั่นหลักการที่เกิดซ้ำจาก skills, prompts, รีวิว ให้เป็นกฎที่ใช้ซ้ำได้

✓ wiki พิมพ์แบบสารานุกรมโปรเจกต์พร้อมเชื่อมคลังความรู้ภายนอกได้

ช่วงที่ 8: ฝ่ายธุรกิจที่คนลืมว่ามี (business + ops)

สิ่งที่ทำให้ OMH ต่างจากเครื่องมือโค้ดล้วนคือมันออกแบบให้ใช้ในบริษัทจริง ตามแผนที่ use-case ที่โปรเจกต์ประกาศไว้เอง [4]

ฝ่ายปฏิบัติการ (operations, 13 skills ใหญ่สุดของระบบ): ✓ finance-analysis (บรีฟการเงินตัดสินใจได้), ✓ people-ops (สรรหาและทรัพยากรบุคคล), ✓ ops-review (สถานะ ความเสี่ยง สิ่งกีดขวาง), ✓ operating-rhythm (นาทีประชุม sprint retro และมติ), ✓ meeting-brief (วาระและบันทึกประชุม), ✓ feedback-triage (จัดกลุ่มเสียงลูกค้า), ✓ support-operations (เปลี่ยนตั๋วปัญหาเป็นคำตอบที่ชัด), ✓ sales-development (พัฒนายอดขายแบบค้นหาคุณสมบัติลูกค้าก่อน)

✓ cto-loop ผมขอยกให้เป็น skill เดี่ยวที่แปลกใหม่ที่สุด: ทำงานในบทบาท CTO ครบวงจรตั้งแต่ roadmap, PM, ตัดสินใจทางเทคนิค, ความเสี่ยง, ส่งมอบ จนถึงติดตามผล

ฝ่ายผลิตชิ้นงาน (materials, 7 skills): ✓ materials-package (สไลด์ PDF สเปรดชีตเอกสาร), ✓ report-package (รายงานผู้บริหาร), ✓ deliverable-package (ติดตามไฟล์ส่งมอบทุกชนิด), ✓ img-summary (การ์ดภาพสรุปจากงานหรือ PR), ✓ design-orchestration, ✓ design-quality-gate, ✓ award-bar-score (ให้คะแนนเว็บด้วยเกณฑ์รางวัลดีไซน์จริง)

ช่วงที่ 9: ชั้นความปลอดภัยที่ห่อทุกอย่าง (operators + นโยบาย)

ส่วนที่แสดงวัฒนธรรมของโปรเจกต์ชัดที่สุด: ทุกการกระทำที่เสี่ยงมีเลเยอร์นโยบายครอบอยู่

✓ browser-operator เพิ่มด่านยืนยันก่อน login หรือกรอกฟอร์มบนเว็บ พร้อมบันทึกทุกจังหวะ

✓ command-operator ตรวจ cwd, environment และความปลอดภัยก่อนรันคำสั่ง terminal ทุกครั้ง

✓ workspace-file-operator กำหนดขอบเขต path และด่านกันการกระทำทำลายล้างไฟล์

✓ connector-operator อีเมล Slack Discord Notion Linear Jira CRM ผ่านตัวเชื่อมภายนอก พร้อมด่านตรวจ

✓ voice-operator คำสั่งพูดสั้นๆ แบบมือถือ เปลี่ยนเป็นการถามให้ชัด วางแผน หรือยืนยัน

✓ media-input-operator ไฟล์ที่ผู้ใช้ส่งมา (เสียง วิดีโอ YouTube ภาพหน้าจอ OCR) ต้องผ่านขอบเขตที่ชัดก่อนประมวลผล

✓ live-info-operator ข้อมูลสดต้องระบุแหล่ง ความสด หน่วย และคุณภาพแหล่ง

✓ data-analysis วิเคราะห์ข้อมูลพร้อมสอบที่มา คำกล่าวอ้างเชิงเหตุผล และด่านกันการมองเห็นสิ่งที่ไม่มี

ช่วงที่ 10: เครื่องมือบริหารตัว Hermes เอง (setup + meta)

✓ model-setup วินิจฉัยการตั้งค่าโมเดลแต่ละบทบาท เชื่อม provider ให้ถูกต้อง

✓ doctor ตรวจสุขภาพการติดตั้ง oh-my-hermes ทั้งชุด

✓ capability-toggle เปิดปิดความสามารถรายกลุ่มให้เหมาะกับเครื่องคุณ ไม่ต้องติดทั้งหมด

✓ skill-scout ค้นก่อนสร้างเสมอ: รายงานว่ามี skill ที่ต้องการอยู่แล้วไหม ในเครื่อง ตลาด GitHub หรือเว็บ พร้อมความเสี่ยงและทางเลือก

✓ skill-health แดชบอร์ดสุขภาพ skill ทั้งพอร์ต: ตัวไหนเก่า ตัวไหนควรเกษียณ

✓ running-work-board แสดงว่าตอนนี้มีงานกี่ชิ้นกำลังวิ่งบน runtime ไหน โมเดลอะไร

✓ agent-board กระดานงานสำหรับหลาย Hermes profile ทำงานพร้อมกัน

✓ meta-router และ ✓ oh-my-hermes (ตัวหลัก) หนึ่งคู่ที่ตัดสินว่าคำขอของคุณควรไปหา skill ไหน ด้วยกฎที่เข้มงวดกว่าปกติ: ถ้าไม่แน่ใจ ให้ถามกลับ อย่าเดาเอาเอง

สามข้อสังเกตจากการไล่ทั้ง 119 ตัวจริง

ข้อแรก ระบบนี้ออกแบบเป็นบริษัท ไม่ใช่กล่องเครื่องมือ

เมื่อไล่ครบทุกตัว รูปแบบที่โผล่ซ้ำๆ คือโครงสร้างองค์กรจริง: มีฝ่ายรับโจทย์ (interview, context), ฝ่ายวิจัย (research 10 ตัว), ฝ่ายวางแผน (planning 11), ฝ่ายผลิต (execution), ฝ่ายตรวจ (review + verification 12), ฝ่ายประกันคุณภาพ (qa), ฝ่ายบำรุงรักษา (maintenance), ฝ่ายธุรกิจ (operations 13), ไปจนถึงฝ่ายกฎหมายและ compliance ที่หลายทีมเทคโนโลยีตัวจริงยังไม่มี นี่ไม่ใช่ความบังเอิญ แต่เป็นการออกแบบตามบทบาทเก้าตัวที่ประกาศไว้ตั้งแต่ต้น

ข้อสอง ความลึกซ้อนของการตรวจสอบเกินคาด

นับเฉพาะ skills ที่หน้าที่คือการตรวจ ตรวจสอบ หรือกันความเสี่ยง รวมแล้วเกิน 20 ตัวจาก 119 (code-review, security, production, legal, localization, failure-signal, verification-gate, ultraqa, build-triage, native-debugging, workspace-audit, reliability, accessibility, visual-qa และบรรดา operator อีกแปดตัว) คิดเป็นเกือบหนึ่งในห้าของระบบทั้งหมด โปรเจกต์ที่อุทิศพื้นที่มากขนาดนี้ให้การกันความผิดพลาด บอกได้ว่าทีมเคยเจอความเจ็บปวดจริงแล้วออกแบบระบบมาแก้

ข้อสาม ความซื่อสัตย์ถูกฝังอยู่ในคำอธิบายทุกตัว

ผมนับคำที่ปรากฏในคำอธิบาย skills: คำว่า prepare (เตรียม) โผล่หกสิบกว่าครั้ง observed (ที่เห็นจริง) ยี่สิบกว่าครั้ง ขณะที่คำอ้างสิทธิ์แบบ guarantee หรือ execute ในความหมายลับๆ แทบไม่มี สิ่งนี้สอดคล้องกับหลัก evidence-bound ที่เขียนไว้ในบทก่อน: ระบบพูดถึงสิ่งที่มันเตรียมได้ สิ่งที่มันเห็น และสิ่งที่ผ่านการตรวจ เท่านั้น

สรุปมุมมองของผม

การไล่อ่านทั้ง 119 skills ทำให้ผมเข้าใจว่าทำไมโปรเจกต์อายุสามเดือนถึงได้ 1,400 ดาว: มันตอบคำถามที่ผู้ใช้เอเจนต์จริงเจอทุกวัน คือเอเจนต์ควรทำงานแบบมีระเบียบแค่ไหนและใครคุม คำตอบของ OMH คือเอาวินัยของบริษัทซอฟต์แวร์ทั้งบริษัทมาฝังเป็น config ที่สลับเปิดปิดได้

สำหรับคนไทยที่กำลังเริ่มใช้เอเจนต์ในงานจริง ผมแนะนำอย่าเพิ่งติดตั้งทั้ง 119 ตัว ใช้ capability-toggle เปิดเป็นสามกลุ่มพื้นฐานก่อน: deep-interview (กันโจทย์เพี้ยน), plan (กันงานไร้ทิศทาง) และ verification-gate (กันงานส่งที่ยังไม่ผ่าน) เมื่อใช้จนคุ้นแล้วค่อยขยายตามปัญหาจริงที่เจอ เพราะเครื่องมือที่ดีที่สุดคือเครื่องมือที่คุณรู้ว่ามันทำอะไรจริง

คำถามชวนคุย: จากสารบัญทั้งหมดนี้ มีตัวไหนที่คุณอยากได้ในทีมของตัวเองที่สุดเป็นตัวแรก และตัวไหนที่คุณมองว่าเกินจำเป็นไป คอมเมนต์แลกเปลี่ยนกันได้ครับ

ถ้าชอบบทความแนวเจาะลึกโปรเจกต์โอเพนซอร์สแบบอ่านเอกสารทั้งเล่ม ติดตาม Nokka ได้ที่ dev.to/sarantoon

📚 อ่านคู่กัน: บทก่อนหน้าที่รีวิวภาพรวม oh-my-hermes (1,400 ดาวใน 3 เดือน, routing 9 หมวด, evidence-bound delivery) และบทวิเคราะห์ paper "Agentic Software" เรื่องวิชาใหม่หลังยุคโค้ด สามบทประกอบเป็นภาพเดียว: ทฤษฎี ผู้ใช้จริง และสารบัญเต็ม

แหล่งอ้างอิง

[1] rlaope. "Workflow Reference" (เอกสารสร้างอัตโนมัติจากแคตตาล็อก skills ทั้งหมด, 919KB). GitHub. 2026. https://github.com/rlaope/oh-my-hermes/blob/main/docs/WORKFLOWS.md

[2] rlaope. "oh-my-hermes" (README ฉบับเต็ม). GitHub. 2026. https://github.com/rlaope/oh-my-hermes

[3] rlaope. "Roles" (เอกสารบทบาททั้งเก้าของระบบ). GitHub. 2026. https://github.com/rlaope/oh-my-hermes/blob/main/docs/ROLES.md

[4] rlaope. "Application Cases" (แผนที่ use-case G1-G10). GitHub. 2026. https://github.com/rlaope/oh-my-hermes/blob/main/docs/APPLICATION_CASES.md

---

บทความนี้แยกวิเคราะห์ skills จริงจากเอกสาร Workflow Reference ทั้งไฟล์ (919,352 ไบต์) ด้วยสคริปต์ที่นับและจัดหมวดอัตโนมัติ: 119 skills ติดตั้งได้ จาก 41 หมวด ทุกคำอธิบายตรงกับเอกสารต้นฉบับ ข้อมูล ณ 5 กันยายน 2026 Nokka