Skills Addyosmani

ตรวจสอบและปรับปรุงการเข้าถึงเว็บตามแนวทาง WCAG 2.2 ใช้เมื่อถูกขอให้ "ปรับปรุงการเข้าถึง", "ตรวจสอบ a11y", "ปฏิบัติตาม WCAG", "รองรับโปรแกรมอ่านหน้าจอ", "การนำทางด้วยแป้นพิมพ์" หรือ "ทำให้เข้าถึงได้

แนะนำการออกแบบ API และอินเทอร์เฟซที่เสถียร ใช้เมื่อออกแบบ API ขอบเขตโมดูล หรืออินเทอร์เฟซสาธารณะใดๆ ใช้เมื่อสร้าง REST หรือ GraphQL endpoints กำหนดสัญญาประเภทระหว่างโมดูล หรือสร้างขอบเขตระหว่างฟรอนต์เอนด์และแบ็กเอนด์

ใช้แนวปฏิบัติที่ดีที่สุดในการพัฒนาเว็บสมัยใหม่เพื่อความปลอดภัย ความเข้ากันได้ และคุณภาพของโค้ด ใช้เมื่อถูกขอให้ "ใช้แนวปฏิบัติที่ดีที่สุด" "ตรวจสอบความปลอดภัย" "ปรับปรุงโค้ดให้ทันสมัย" "ตรวจสอบคุณภาพโค้ด" หรือ "ตรวจสอบช่องโหว่

ทดสอบในเบราว์เซอร์จริงผ่าน Chrome DevTools MCP ใช้เมื่อสร้างหรือดีบักสิ่งที่ทำงานในเบราว์เซอร์ ใช้เมื่อต้องการตรวจสอบ DOM จับข้อผิดพลาดคอนโซล วิเคราะห์คำขอเครือข่าย ประเมินประสิทธิภาพ หรือยืนยันผลลัพธ์ภาพด้วยข้อมูลรันไทม์จริง ต้องกำหนดค่าเซิร์ฟเวอร์ chrome-devtools MCP

ทำให้การตั้งค่าไปป์ไลน์ CI/CD เป็นอัตโนมัติ ใช้เมื่อตั้งค่าหรือปรับเปลี่ยนไปป์ไลน์การสร้างและการปรับใช้ ใช้เมื่อคุณต้องการทำให้เกตคุณภาพเป็นอัตโนมัติ กำหนดค่าตัวรันทดสอบใน CI หรือสร้างกลยุทธ์การปรับใช้

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

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

ปรับแต่งการตั้งค่าบริบทของเอเจนต์ให้เหมาะสม ใช้เมื่อเริ่มเซสชันใหม่ เมื่อคุณภาพผลลัพธ์ของเอเจนต์ลดลง เมื่อสลับระหว่างงาน หรือเมื่อคุณต้องการกำหนดค่าไฟล์กฎและบริบทสำหรับโปรเจกต์

ปรับปรุง Core Web Vitals (LCP, INP, CLS) เพื่อประสบการณ์หน้าเว็บที่ดีขึ้นและการจัดอันดับในการค้นหา ใช้เมื่อถูกขอให้ "ปรับปรุง Core Web Vitals", "แก้ไข LCP", "ลด CLS", "ปรับแต่ง INP", "ปรับปรุงประสบการณ์หน้าเว็บ" หรือ "แก้ไขการเลื่อนเค้าโครง

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

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

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

กำหนดให้ทุกการตัดสินใจที่ไม่ใช่เรื่องเล็กน้อยต้องผ่านการตรวจสอบเชิงโต้แย้งในบริบทใหม่ก่อนที่จะยืนยัน ใช้เมื่อความถูกต้องสำคัญกว่าความเร็ว เมื่อทำงานกับโค้ดที่ไม่คุ้นเคย เมื่อมีความเสี่ยงสูง (ระบบผลิต, ตรรกะที่อ่อนไหวต่อความปลอดภัย, การดำเนินการที่ไม่สามารถย้อนกลับ) หรือเมื่อใดก็ตามที่การตรวจสอบผลลัพธ์ที่มั่นใจในตอนนี้จะถูกกว่าการดีบักในภายหลัง

สร้าง UI ที่มีคุณภาพระดับโปรดักชัน เข้าถึงได้ และตอบสนองต่อผู้ใช้ ใช้เมื่อสร้างหรือปรับเปลี่ยนอินเทอร์เฟซและหน้าเว็บ สร้างคอมโพเนนต์ จัดวางเลย์เอาต์ ตรงตามข้อกำหนดการเข้าถึง WCAG จัดการสถานะ หรือเมื่อผลลัพธ์ต้องดูและให้ความรู้สึกเหมือนของจริงมากกว่าที่สร้างโดย AI

จัดโครงสร้างแนวทางการทำงานกับ git ใช้เมื่อมีการเปลี่ยนแปลงโค้ดใดๆ ใช้เมื่อ commit, branching, แก้ไข conflict หรือเมื่อต้องการจัดระเบียบงานในหลายสตรีมคู่ขนาน ใช้เมื่อตัด release, เลือกการเพิ่ม semantic version, tagging หรือเขียน changelog

ปรับแต่งแนวคิดดิบให้เป็นแนวคิดที่คมชัดและนำไปปฏิบัติได้ ผ่านการคิดแบบกระจายและรวมศูนย์อย่างมีโครงสร้าง ใช้เมื่อแนวคิดยังคลุมเครือ เมื่อต้องการทดสอบสมมติฐานก่อนตัดสินใจดำเนินการ หรือเมื่อต้องการขยายทางเลือกก่อนจะสรุปที่แนวคิดเดียว เริ่มทำงานเมื่อมีคำว่า "ideate", "refine this idea" หรือ "stress-test my plan

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

ดึงสิ่งที่ผู้ใช้ต้องการจริงๆ แทนที่จะเป็นสิ่งที่พวกเขาคิดว่าควรต้องการ โดยใช้การสัมภาษณ์ทีละคำถามจนกว่าจะมั่นใจประมาณ 95% เกี่ยวกับเจตนาที่แท้จริง ใช้เมื่อคำขอไม่ชัดเจน ("สร้าง X ให้ฉัน" โดยไม่มี "เพื่อใคร" หรือ "ทำไมตอนนี้") เมื่อผู้ใช้เรียกใช้โดยตรง ("สัมภาษณ์ฉัน", "ซักถามฉัน", "เราแน่ใจไหม?", "ทดสอบความคิดของฉัน") หรือเมื่อคุณพบว่าตัวเองกำลังเติมเต็มข้อกำหนดที่ไม่ชัดเจนอย่างเงียบๆ ก่อนที่จะมีแผน ข้อกำหนด หรือโค้ดใดๆ

ทำให้โค้ดมีเครื่องมือวัดเพื่อให้พฤติกรรมในระบบผลิตสามารถมองเห็นและวินิจฉัยได้ ใช้เมื่อต้องการเพิ่มการบันทึกข้อมูล การวัดค่า การติดตาม หรือการแจ้งเตือน ใช้เมื่อส่งมอบฟีเจอร์ใดๆ ที่ทำงานในระบบผลิตและต้องการหลักฐานว่ามันทำงานได้ ใช้เมื่อมีรายงานปัญหาจากระบบผลิตแต่ไม่สามารถบอกได้ว่าเกิดอะไรขึ้นจากข้อมูลที่มีอยู่

ปรับปรุงประสิทธิภาพเว็บให้โหลดเร็วขึ้นและประสบการณ์ผู้ใช้ดีขึ้น ใช้เมื่อถูกขอให้ "ทำให้เว็บไซต์เร็วขึ้น", "ปรับปรุงประสิทธิภาพ", "ลดเวลาโหลด", "แก้ไขการโหลดช้า", "ปรับปรุงความเร็วหน้าเว็บ" หรือ "ตรวจสอบประสิทธิภาพ

ปรับแต่งประสิทธิภาพของแอปพลิเคชันในส่วน frontend, backend, คำสั่ง query และฐานข้อมูล ใช้เมื่อมีข้อกำหนดด้านประสิทธิภาพ เมื่อสงสัยว่าประสิทธิภาพลดลง เมื่อต้องการปรับปรุง Core Web Vitals หรือเวลาโหลด เมื่อต้องแก้ไขรูปแบบคำสั่ง query แบบ N+1 หรือเมื่อการทำ profiling เผยให้เห็นจุดคอขวด

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

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

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

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

ยึดทุกการตัดสินใจในการพัฒนาจากเอกสารทางการ ใช้เมื่อต้องการโค้ดที่เชื่อถือได้ มีการอ้างอิงแหล่งที่มา และปราศจากรูปแบบที่ล้าสมัย ใช้เมื่อสร้างงานด้วยเฟรมเวิร์กหรือไลบรารีใดๆ ที่ความถูกต้องแม่นยำเป็นสิ่งสำคัญ

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

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

ค้นหาและเรียกใช้ทักษะของเอเจนต์ ใช้เมื่อเริ่มเซสชันหรือเมื่อคุณต้องการค้นหาว่าทักษะใดที่เกี่ยวข้องกับงานปัจจุบัน นี่คือทักษะหลักที่ควบคุมวิธีการค้นหาและเรียกใช้ทักษะอื่นๆ ทั้งหมด

การตรวจสอบคุณภาพเว็บอย่างครอบคลุม ครอบคลุมประสิทธิภาพ การเข้าถึง SEO และแนวทางปฏิบัติที่ดีที่สุด ใช้เมื่อถูกขอให้ "ตรวจสอบเว็บไซต์ของฉัน" "ตรวจสอบคุณภาพเว็บ" "รัน Lighthouse audit" "ตรวจสอบคุณภาพหน้าเว็บ" หรือ "ปรับปรุงเว็บไซต์ของฉัน