Skills รีวิวโค้ด

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

ทักษะแบบอ่านอย่างเดียวสำหรับ Rigor Analyze / Rigor Audit สำหรับคลังวิจัยการเรียนรู้เชิงลึก ใช้เมื่อผู้ใช้ต้องการอ่านและทำความเข้าใจคลัง ตรวจสอบโครงสร้างโมเดลและจุดเริ่มต้นการฝึกหรือการอนุมาน ทบทวนการกำหนดค่าและจุดแทรก หรือระบุรูปแบบการใช้งานที่น่าสงสัยโดยไม่ต้องแก้ไขโค้ดหรือรันงานหนัก ห้ามใช้สำหรับการรันคำสั่งแบบแอคทีฟ การปรับโครงสร้างโค้ดในวงกว้าง การปรับโค้ดแบบคาดเดา หรือการแก้ไขบั๊กอัตโนมัติ

สร้างโค้ด Angular และให้คำแนะนำด้านสถาปัตยกรรม เรียกใช้เมื่อสร้างโปรเจกต์ คอมโพเนนต์ หรือเซอร์วิส หรือสำหรับแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับรีแอคทีฟ (signals, linkedSignal, resource), ฟอร์ม, dependency injection, routing, SSR, การเข้าถึง (ARIA), แอนิเมชัน, การจัดสไตล์ (component styles, Tailwind CSS), การทดสอบ หรือเครื่องมือ CLI

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

We need to translate the given English text into Thai. The text describes a decision guide for delegating to caveman-style subagents. It mentions specific names: cavecrew-investigator, cavecrew-builder, cavecrew-reviewer, and cavecrew. These names should be preserved as is. Also preserve "Explore" (capitalized) and the trigger phrases. The translation should be natural Thai, keeping technical terms like "subagent", "tool-result", "context", "inline", "diff review", etc. The instruction says to preserve URLs, numbers, technical terms. No extra commentary. Just output the translation. Let me translate paragraph by paragraph. First sentence: "Decision guide for delegating to caveman-style subagents." -> "คู่มือการตัดสินใจสำหรับการมอบหมายงานให้กับซับเอเจนต์สไตล์ถ้ำมนุษย์" (caveman-style might be "สไตล์ถ้ำมนุษย์" but careful: "caveman" is a term, but we preserve "caveman-style" as is? The

เครื่องมือสร้างข้อความคอมมิตที่บีบอัดอย่างยิ่ง ลดความรกในข้อความคอมมิตขณะคงเจตนาและเหตุผลไว้ รูปแบบ Conventional Commits หัวข้อไม่เกิน 50 ตัวอักษร เนื้อหาเฉพาะเมื่อ "เหตุผล" ไม่ชัดเจน ใช้เมื่อผู้ใช้พูดว่า "write a commit", "commit message", "generate commit", "/commit" หรือเรียก /caveman-commit ทำงานอัตโนมัติเมื่อมีการจัดเตรียมการเปลี่ยนแปลง

ความคิดเห็นรีวิวโค้ดแบบบีบอัดสูง ลดสัญญาณรบกวนจากฟีดแบ็ก PR ขณะคงสัญญาณที่นำไปปฏิบัติได้ไว้ แต่ละความคิดเห็นคือหนึ่งบรรทัด: ตำแหน่ง ปัญหา วิธีแก้ไข ใช้เมื่อผู้ใช้พูดว่า "review this PR", "code review", "review the diff", "/review" หรือเรียกใช้ /caveman-review ทำงานอัตโนมัติเมื่อรีวิว pull requests

ตรวจสอบความแตกต่างของโค้ด PR คิวของ issue ความพร้อมในการเผยแพร่ คอมมิต การพุช การเผยแพร่ และการตรวจสอบโครงการ ใช้เมื่อผู้ใช้ขอให้ตรวจสอบ/ดูโค้ด/ก่อนรวม/ดู issue/PR/release/push หรือเพื่อดำเนินการตามแผนที่อนุมัติ โดยมีประตูความปลอดภัยสำหรับ worktree ที่สกปรกและไม่ได้ติดตาม ไม่ใช่สำหรับการสำรวจแนวคิด การดีบักสาเหตุที่แท้จริง หรือการตรวจสอบร้อยแก้ว

เปรียบเทียบการนำไปใช้งานของ pull request กับบริบทของสเปกใน spec_context.md และป้อนความไม่สอดคล้องที่มีนัยสำคัญเข้าไปใน review.json ใช้ในระหว่างการตรวจสอบ PR เมื่อได้รับการอนุมัติหรือมีบริบทของสเปกของ repository พร้อมใช้งาน

ตรวจสอบการเปลี่ยนแปลงตั้งแต่จุดคงที่ (commit, branch, tag, หรือ merge-base) ตามสองแกน — มาตรฐาน (โค้ดเป็นไปตามมาตรฐานการเขียนโค้ดที่บันทึกไว้ใน repo นี้หรือไม่) และสเปก (โค้ดตรงกับสิ่งที่ issue/PRD ต้นทางกำหนดไว้หรือไม่) ดำเนินการตรวจสอบทั้งสองแบบใน sub-agents แบบขนานและรายงานผลเคียงข้างกัน ใช้เมื่อผู้ใช้ต้องการตรวจสอบ branch, PR, การเปลี่ยนแปลงที่กำลังดำเนินการ หรือขอให้ "ตรวจสอบตั้งแต่ X

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

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

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

มาตรฐานการตั้งชื่อสาขา การตั้งชื่อ worktree และข้อความ commit ตามรูปแบบ Conventional Commits v1.0.0 สำหรับโปรเจกต์บน GitHub และ GitLab ใช้เมื่อสร้างสาขา ตั้งชื่อ worktree เขียน commit สร้างข้อความ commit ตรวจสอบรูปแบบสาขา หรือตั้งค่าระบบอัตโนมัติสำหรับ changelog ใช้เมื่อโปรเจกต์ของคุณต้องการประวัติ git ที่สอดคล้องกัน การเผยแพร่แบบ SemVer การสร้าง changelog ที่สามารถแยกวิเคราะห์ได้ หรือการปิด issue อัตโนมัติ เรียกใช้เมื่อผู้ใช้ถามถึงวิธีการตั้งชื่อ worktree สร้าง git worktree หรือ...

สร้าง pull request ใน warp repository สำหรับ branch ปัจจุบัน ใช้เมื่อผู้ใช้พูดถึงการเปิด PR, การสร้าง pull request, การส่งการเปลี่ยนแปลงเพื่อตรวจสอบ หรือการเตรียมโค้ดสำหรับ merge

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

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

วนซ้ำการวินิจฉัยสำหรับบั๊กที่ซับซ้อนและการถดถอยของประสิทธิภาพ ใช้เมื่อผู้ใช้พูดว่า "วินิจฉัย"/"ดีบักสิ่งนี้" หรือรายงานว่ามีบางอย่างเสีย/เกิดข้อผิดพลาด/ล้มเหลว/ช้า

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

Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant modules, adapt a backbone, add LoRA or adapter layers, replace a head, or stitch together meaningful low-risk migration ideas with rollback-aware records in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted...

แนะนำการพัฒนาเซิร์ฟเวอร์แบ็กเอนด์ Fastify Node.js และ REST API โดยใช้ TypeScript หรือ JavaScript ใช้เมื่อสร้าง กำหนดค่า หรือดีบักแอปพลิเคชัน Fastify รวมถึงการกำหนดเส้นทาง การใช้งานปลั๊กอิน การตั้งค่าการตรวจสอบ JSON Schema การจัดการข้อผิดพลาด การเพิ่มประสิทธิภาพ การจัดการการยืนยันตัวตน การกำหนดค่า CORS และส่วนหัวความปลอดภัย การเชื่อมต่อฐานข้อมูล การทำงานกับ WebSockets และการปรับใช้สู่ระบบผลิต ครอบคลุมวงจรการร้องขอ Fastify ทั้งหมด (hooks,...

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

แก้ไขข้อผิดพลาดในการคอมไพล์ ปัญหาการตรวจสอบโค้ด และความล้มเหลวในการทดสอบในโค้ดเบส Rust ของ warp ครอบคลุมการตรวจสอบก่อนส่งโค้ด ข้อผิดพลาดเฉพาะ WASM และการรันการทดสอบเฉพาะ ใช้เมื่อผู้ใช้พบข้อผิดพลาดในการ build ความล้มเหลวของ clippy หรือ fmt ความล้มเหลวในการทดสอบ หรือจำเป็นต้องรันหรือตีความการตรวจสอบก่อนส่งโค้ดก่อนทำ PR

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

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

การวัดประสิทธิภาพ การทำโปรไฟล์ และการวัดสมรรถนะของ Golang ใช้เมื่อเขียน รัน หรือเปรียบเทียบเบนช์มาร์กของ Go การทำโปรไฟล์เส้นทางที่ใช้ทรัพยากรมากด้วย pprof การตีความโปรไฟล์ CPU/หน่วยความจำ/เทรซ การวิเคราะห์ผลลัพธ์ด้วย benchstat การตั้งค่าการตรวจจับการถดถอยของเบนช์มาร์กใน CI หรือการตรวจสอบประสิทธิภาพในระบบผลิตด้วยเมตริกรันไทม์ของ Prometheus นอกจากนี้ยังใช้เมื่อนักพัฒนาต้องการการวิเคราะห์เชิงลึกเกี่ยวกับตัวบ่งชี้ประสิทธิภาพเฉพาะ — ทักษะนี้ให้ระเบียบวิธีการวัด ในขณะที่...

Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).

รูปแบบการทำงานพร้อมกันของ Golang ใช้เมื่อเขียนหรือตรวจสอบโค้ด Go ที่ทำงานพร้อมกันซึ่งเกี่ยวข้องกับ goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools หรือ fan-out/fan-in pipelines นอกจากนี้ยังทำงานเมื่อตรวจพบ goroutine leaks, race conditions, ปัญหาการเป็นเจ้าของ channel หรือจำเป็นต้องเลือกระหว่าง channels และ mutexes

คู่มือครอบคลุมสำหรับการฉีดการพึ่งพา (DI) ใน Golang ครอบคลุมถึงเหตุผลที่ DI มีความสำคัญ (ความสามารถในการทดสอบ การเชื่อมต่อแบบหลวม การแยกความรับผิดชอบ การจัดการวงจรชีวิต) การฉีดผ่านคอนสตรัคเตอร์แบบแมนนวล และการเปรียบเทียบไลบรารี DI (google/wire, uber-go/dig, uber-go/fx, samber/do) ใช้ทักษะนี้เมื่อออกแบบสถาปัตยกรรมบริการ ตั้งค่าการฉีดการพึ่งพา ปรับโครงสร้างโค้ดที่เชื่อมต่อแน่นหนา จัดการซิงเกิลตันหรือโรงงานบริการ หรือเมื่อผู้ใช้ถามเกี่ยวกับการควบคุมกลับด้าน บริการ...

รูปแบบการออกแบบ Go ที่เป็นธรรมชาติ — ตัวเลือกเชิงฟังก์ชัน, คอนสตรัคเตอร์, การไหลของข้อผิดพลาดและการเรียงลำดับ, การจัดการทรัพยากรและวงจรชีวิต, การปิดระบบอย่างนุ่มนวล, ความยืดหยุ่น, สถาปัตยกรรม, การฉีด dependencies, การจัดการข้อมูล, การสตรีม และอื่นๆ ใช้เมื่อเลือกอย่างชัดเจนระหว่างรูปแบบสถาปัตยกรรม, การใช้ตัวเลือกเชิงฟังก์ชัน, การออกแบบ API ของคอนสตรัคเตอร์, การตั้งค่าการปิดระบบอย่างนุ่มนวล, การใช้รูปแบบความยืดหยุ่น, หรือการถามว่ารูปแบบ Go ที่เป็นธรรมชาติใดเหมาะกับปัญหาเฉพาะ