agent-skills - ชุดทักษะวิศวกรรมระดับพร้อมใช้งานจริงสำหรับ AI coding agent

• โอเพนซอร์สที่ Addy Osmani ผู้อำนวยการ AI ของ Google Cloud จัดแพ็ก เวิร์กโฟลว์ระดับวิศวกรอาวุโส ให้อยู่ในรูปทักษะแบบมีโครงสร้าง เพื่อ แก้ปัญหาที่ AI coding agent มักข้ามขั้นตอนสเปก การทดสอบ และการรีวิวความปลอดภัย
• ประกอบด้วย 7 คำสั่งแบบ slash และ 19 ทักษะ ที่ครอบคลุมตลอดทั้งวงจรการพัฒนา (นิยาม→วางแผน→สร้าง→ตรวจสอบ→รีวิว→ปล่อยใช้งาน)
  • /spec กำหนดว่าจะสร้างอะไร: "สเปกก่อนโค้ด"
  • /plan วางแผนวิธีทำ: "แยกเป็นงานย่อยแบบอะตอม"
  • /build พัฒนาแบบค่อยเป็นค่อยไป: "ทำทีละหนึ่ง slice เท่านั้น"
  • /test พิสูจน์ว่าทำงานได้: "การทดสอบคือหลักฐาน"
  • /review ด่านคุณภาพก่อน merge: "ปรับปรุง code health"
  • /code-simplify ทำโค้ดให้ง่ายขึ้น: "ชัดเจนสำคัญกว่าความฉลาดแพรวพราว"
  • /ship ปล่อยขึ้น production: "ยิ่งเร็ว ยิ่งปลอดภัย"
• ทักษะที่เหมาะสมจะถูก เปิดใช้งานอัตโนมัติ ตามสถานการณ์ เช่น ตอนออกแบบ API จะใช้ api-and-interface-design และตอนพัฒนา UI จะใช้ frontend-ui-engineering
• หลักการสำคัญของวัฒนธรรมวิศวกรรมแบบ Google เช่น Hyrum's Law, Beyonce Rule, Chesterton's Fence, Shift Left เป็นต้น ถูกฝังไว้โดยตรงในเวิร์กโฟลว์แต่ละขั้น

รายการทักษะทั้ง 19 รายการ

• Define (ทำให้ชัดว่าจะสร้างอะไร)

  • idea-refine: จัดโครงสร้างการคิดแบบแตกแขนง/บีบให้แคบ เพื่อเปลี่ยนไอเดียลางๆ ให้เป็นข้อเสนอที่เป็นรูปธรรม
  • spec-driven-development: เขียน PRD ที่ครอบคลุมเป้าหมาย คำสั่ง โครงสร้าง สไตล์โค้ด การทดสอบ และขอบเขต ก่อนเริ่มเขียนโค้ด

• Plan (แยกย่อยงาน)

  • planning-and-task-breakdown: แยกสเปกออกเป็นงานย่อยขนาดเล็กที่ตรวจสอบได้ พร้อมเกณฑ์การยอมรับและลำดับการพึ่งพา

• Build (เขียนโค้ด)

  • incremental-implementation: พัฒนา ทดสอบ ตรวจสอบ และ commit แบบ thin vertical slice รองรับการเปลี่ยนแปลงที่เป็นมิตรกับ feature flag และ rollback
  • test-driven-development: ใช้ Red-Green-Refactor, test pyramid (80/15/5), DAMP over DRY และ Beyonce Rule
  • context-engineering: ส่งข้อมูลที่ถูกต้องให้เอเจนต์ในจังหวะที่เหมาะสม (ไฟล์ rules, context packing, การเชื่อม MCP)
  • frontend-ui-engineering: สถาปัตยกรรมคอมโพเนนต์, design system, state management, responsive design, การเข้าถึงตามมาตรฐาน WCAG 2.1 AA
  • api-and-interface-design: ออกแบบแบบ contract-first, Hyrum's Law, One-Version Rule, error semantics, การตรวจสอบความถูกต้องที่ขอบเขตระบบ

• Verify (พิสูจน์การทำงาน)

  • browser-testing-with-devtools: ใช้ข้อมูล runtime แบบเรียลไทม์ผ่าน Chrome DevTools MCP (ตรวจ DOM, console log, network trace, performance profiling)
  • debugging-and-error-recovery: กระบวนการ triage 5 ขั้นตอน (ทำซ้ำให้เกิด→ระบุตำแหน่ง→ย่อขอบเขต→แก้ไข→ป้องกัน) และกฎ stop-the-line

• Review (ด่านคุณภาพก่อนรวมโค้ด)

  • code-review-and-quality: รีวิว 5 แกน, ขนาดการเปลี่ยนแปลง (~100 บรรทัด), ป้ายกำกับระดับความรุนแรง (Nit/Optional/FYI), เกณฑ์ความเร็วในการรีวิว
  • code-simplification: ใช้ Chesterton's Fence, Rule of 500 และลดความซับซ้อนโดยยังคงพฤติกรรมเดิมอย่างแม่นยำ
  • security-and-hardening: ป้องกัน OWASP Top 10, แพตเทิร์นการยืนยันตัวตน, การจัดการ secret, การตรวจสอบ dependency, ระบบขอบเขต 3 ชั้น
  • performance-optimization: แนวทางวัดผลก่อนเสมอ, เป้าหมาย Core Web Vitals, เวิร์กโฟลว์ profiling, การวิเคราะห์ bundle

• Ship (ปล่อยใช้งาน)

  • git-workflow-and-versioning: trunk-based development, atomic commit, ขนาดการเปลี่ยนแปลง (~100 บรรทัด), แพตเทิร์น commit-as-savepoint
  • ci-cd-and-automation: Shift Left, Faster is Safer, feature flag, pipeline ของ quality gate
  • deprecation-and-migration: แนวคิด code-as-debt, วิธีเลิกใช้แบบบังคับ/แบบแนะนำ, การลบ zombie code
  • documentation-and-adrs: Architecture Decision Records, เอกสาร API, เกณฑ์การทำเอกสารแบบอินไลน์ (บันทึกว่า 'ทำไม')
  • shipping-and-launch: เช็กลิสต์ก่อนเปิดตัว, วงจรชีวิตของ feature flag, gradual rollout, ขั้นตอน rollback, การตั้งค่า monitoring

Persona ของเอเจนต์

• เตรียม persona ผู้เชี่ยวชาญไว้ล่วงหน้า 3 แบบสำหรับการรีวิวแบบเจาะจง
  • code-reviewer: มุมมองของวิศวกร staff ระดับอาวุโส พร้อมรีวิวโค้ด 5 แกนด้วยเกณฑ์ "ถึงระดับที่ staff engineer จะอนุมัติหรือไม่?"
  • test-engineer: มุมมองของผู้เชี่ยวชาญ QA, กลยุทธ์การทดสอบ, การวิเคราะห์ coverage, แพตเทิร์น Prove-It
  • security-auditor: มุมมองของวิศวกรความปลอดภัย, การตรวจหาช่องโหว่, threat modeling, การประเมินตาม OWASP

เช็กลิสต์อ้างอิง

• เอกสารอ้างอิงแบบรวดเร็ว 4 รายการที่ทักษะจะเรียกใช้เมื่อจำเป็น
  • testing-patterns.md: โครงสร้างการทดสอบ, การตั้งชื่อ, mocking, ตัวอย่าง React/API/E2E, anti-pattern
  • security-checklist.md: เช็กก่อน commit, การยืนยันตัวตน, การตรวจสอบ input, header, CORS, OWASP Top 10
  • performance-checklist.md: เป้าหมาย Core Web Vitals, เช็กลิสต์ฝั่ง frontend/backend, คำสั่งสำหรับการวัดผล
  • accessibility-checklist.md: การนำทางด้วยคีย์บอร์ด, screen reader, การออกแบบเชิงภาพ, ARIA, เครื่องมือทดสอบ

หลักการออกแบบทักษะ

• เป็นกระบวนการ ไม่ใช่ร้อยแก้ว: ทักษะคือเวิร์กโฟลว์ที่เอเจนต์ต้องทำตาม มีทั้งขั้นตอน จุดตรวจสอบ และเกณฑ์จบงาน ไม่ใช่เอกสารอ้างอิง
• ป้องกันการหาเหตุผลเข้าข้างตัวเอง: ทุกทักษะฝังข้ออ้างที่เอเจนต์มักใช้เพื่อข้ามขั้นตอน ("เดี๋ยวค่อยเพิ่มเทสต์ทีหลัง") พร้อมตรรกะโต้แย้งไว้แล้ว
• การตรวจสอบต่อรองไม่ได้: ทุกทักษะจบด้วยข้อกำหนดด้านหลักฐาน (เทสต์ผ่าน, ผลลัพธ์การ build, ข้อมูล runtime) โดยคำว่า "น่าจะใช้ได้" ยังไม่เพียงพอ
• เปิดเผยแบบค่อยเป็นค่อยไป: SKILL.md คือจุดเริ่มต้น และจะโหลดเอกสารอ้างอิงเสริมเมื่อจำเป็นเท่านั้น เพื่อประหยัด ปริมาณการใช้โทเค็น

วิธีติดตั้ง (เครื่องมือที่รองรับ)

• Claude Code (แนะนำ): /plugin marketplace add addyosmani/agent-skills แล้วตามด้วย /plugin install agent-skills@addy-agent-skills
  • สำหรับพัฒนาในเครื่อง: git clone แล้วใช้ claude --plugin-dir /path/to/agent-skills
• Cursor: คัดลอก SKILL.md ใดก็ได้ไปไว้ใน .cursor/rules/ หรืออ้างอิงทั้งไดเรกทอรี skills/
• Gemini CLI: gemini skills install https://github.com/addyosmani/agent-skills.git
• Windsurf: เพิ่มเนื้อหาของทักษะลงในค่าตั้งค่า rules ของ Windsurf
• GitHub Copilot: ใช้นิยามเอเจนต์ใน agents/ เป็น persona ของ Copilot และใช้เนื้อหาทักษะใน .github/copilot-instructions.md
• Codex และเอเจนต์อื่นๆ: เนื่องจากทักษะเป็น Markdown ทั่วไป จึง เข้ากันได้กับเอเจนต์ทุกตัว ที่รองรับ system prompt หรือไฟล์ instruction

[xguru]

ช่วงนี้ดูเหมือนการเปิดเผยชุดสกิลของตัวเองกำลังกลายเป็นกระแส

ยังไงก็เป็นไฟล์ Markdown อยู่แล้ว เลยไม่จำเป็นต้องนำทั้งหมดมาใช้ตามต้นฉบับ
ยิ่งมีมากก็ยิ่งเพิ่มการใช้โทเคนเท่านั้น
บอกเอเจนต์ของเราว่า "ช่วยวิเคราะห์อันนี้แล้วดึงมาเฉพาะที่จำเป็น" จะดีกว่า

แล้วก็ค่อยๆ สร้างฮาร์เนสของตัวเองขึ้นมาแบบนั้น

[thestackai]

ใช่ครับ ผมคิดว่านี่เป็นวิธีที่ดีที่สุดในการรับมือกับโอเพนซอร์สที่หลั่งไหลเข้ามา

[yangeok]

ดูเหมือนจะเป็นแบบ speckit นะ

[blacksocks]

มีคำสั่งลงมาภายในบริษัทให้ลองพัฒนาโดยอาศัยแค่ vibe coding ก็เลยลองปรับใช้โน่นนี่ดูครับ แต่พอลองทำจริงแล้วก็พบว่าทักษะการพัฒนาที่ยอดเยี่ยมไม่ได้รับประกันคุณภาพที่สูงเสมอไปนัก..
กลับกลายเป็นว่าความสามารถในการตรวจทานและทำความเข้าใจโค้ดที่ AI สร้างขึ้นต่างหากที่เป็นหัวใจสำคัญ ยิ่งเครื่องมือดีขึ้นเท่าไร ก็ยิ่งเป็นความย้อนแย้งที่ว่า “พลังในการอ่านและตัดสิน” สำคัญมากขึ้นเท่านั้น

[ragingwind]

หัวหน้าทีม Chrome ของ Google, Addy Osmani -> ย้ายไปรับตำแหน่ง Director, Google Cloud AI

[xguru]

โอ๊ะ ย้ายไปตอนไหนเนี่ย ผมเข้าใจแบบนั้นมาตลอดเลย ตอนนี้แก้ไขไว้แล้วครับ

[ragingwind]

ตอนนี้คนที่ผมรู้จักในทีม Chrome ก็เหลือแค่ Paul Kinlan (หัวหน้า DevRel ของ Chrome) คนเดียวแล้วจริงๆ เวลาผ่านไปไวมาก