50 เคล็ดลับและแนวปฏิบัติที่ดีสำหรับ Claude Code ที่ใช้ได้ทุกวัน

• รวบรวม เคล็ดลับใช้งานจริง 50 ข้อ สำหรับนักพัฒนาที่ใช้ Claude Code อยู่แล้ว โดยสรุปจากเอกสารทางการของ Anthropic, Boris Cherny นักพัฒนา, ประสบการณ์จากชุมชน และประสบการณ์ใช้งานทุกวันตลอด 1 ปี
• ครอบคลุมตั้งแต่คีย์ลัดสำหรับจัดการเซสชัน เช่น alias cc, คำนำหน้า !, การย้อนกลับด้วย Esc ไปจนถึง subagent, agent team และการทำงานแบบขนานด้วย worktree
• รวมวิธีเชิงโครงสร้างเพื่อรักษาคุณภาพและความสม่ำเสมอ เช่น การเขียน CLAUDE.md, ระบบ Hooks, และการจัดการ context window
• นำเสนอแพตเทิร์นเวิร์กโฟลว์หลากหลาย เช่น การใช้เครื่องมือ CLI, การเลือกเซิร์ฟเวอร์ MCP, และ การประมวลผลแบบแบตช์
• ไม่จำเป็นต้องนำไปใช้ครบทั้ง 50 ข้อ โดยแนะนำให้ ค่อย ๆ เริ่มใช้ จากข้อที่สร้างความไม่สะดวกมากที่สุดก่อน

---

1. ตั้งค่า alias cc

• เพิ่ม alias cc='claude --dangerously-skip-permissions' ลงใน ~/.zshrc (หรือ ~/.bashrc) เพื่อให้พิมพ์แค่ cc ก็ เริ่มเซสชัน Claude Code ได้
• เป็นการตั้งค่าที่ ข้ามพรอมป์ต์ขอสิทธิ์ทั้งหมด และชื่อแฟลกก็ถูกตั้งให้ดูน่ากลัวโดยตั้งใจ
• ควรใช้ก็ต่อเมื่อคุณเข้าใจอย่างถ่องแท้ว่า Claude Code สามารถทำอะไรกับ codebase ของคุณได้บ้าง

2. ใช้คำนำหน้า ! เพื่อรันคำสั่ง bash แบบอินไลน์

• หากพิมพ์ !git status หรือ !npm test ระบบจะ รันคำสั่งทันที และเก็บทั้งคำสั่งกับผลลัพธ์ไว้ในคอนเท็กซ์
• Claude สามารถตรวจผลลัพธ์และทำงานต่อได้ — เร็วกว่าการสั่งให้ Claude ไปรันคำสั่งเอง

3. กด Esc เพื่อหยุด, กด Esc+Esc เพื่อย้อนกลับ

• Esc จะหยุด Claude กลางทางโดยไม่ทำคอนเท็กซ์หาย — เปลี่ยนทิศทางได้ทันที
• Esc+Esc (หรือ /rewind) จะเปิดเมนูเลื่อนดู checkpoint ทั้งหมดที่ Claude สร้างไว้ เพื่อกู้คืนโค้ด, บทสนทนา หรือทั้งสองอย่าง
  • มีตัวเลือกการกู้คืน 4 แบบ: โค้ดและบทสนทนา, บทสนทนาอย่างเดียว, โค้ดอย่างเดียว, สรุปหลัง checkpoint
• คุณจึงลองแนวทางที่มั่นใจแค่ 40% ได้ — ถ้าพลาดก็ย้อนกลับได้แบบ ไม่เสียหายเลย
  • แต่ checkpoint ติดตามเฉพาะการแก้ไขไฟล์เท่านั้น การเปลี่ยนแปลงจากคำสั่ง bash (เช่น migration, งานฐานข้อมูล) จะไม่ถูกเก็บไว้
• ใช้ claude --continue เพื่อทำบทสนทนาล่าสุดต่อ หรือใช้ claude --resume เพื่อเปิดตัวเลือกเซสชัน

4. ให้ Claude มีวิธีตรวจสอบงานของตัวเอง

• ใส่ คำสั่งทดสอบ, การตรวจ linter, และผลลัพธ์ที่คาดหวัง ลงในพรอมป์ต์ เพื่อสร้าง feedback loop ให้ Claude จับความผิดพลาดของตัวเองได้
  • ตัวอย่าง: "รีแฟกเตอร์ auth middleware ให้ใช้ JWT หลังแก้เสร็จให้รันชุดทดสอบเดิมทั้งหมด แก้ทุกเคสที่ fail แล้วค่อยถือว่าเสร็จ"
• ตามคำพูดของ Boris Cherny แค่ข้อนี้ก็ช่วยเพิ่ม คุณภาพได้ 2~3 เท่า
• สำหรับการเปลี่ยนแปลง UI ให้ตั้งค่า Playwright MCP server เพื่อให้ Claude เปิดเบราว์เซอร์ โต้ตอบกับหน้าเว็บ และตรวจสอบว่า UI ทำงานตามที่คาดหรือไม่ — ช่วยจับปัญหาที่ unit test พลาดได้

5. ติดตั้งปลั๊กอิน code intelligence ตามภาษา

• ปลั๊กอิน LSP ให้การวินิจฉัยอัตโนมัติหลังแก้ไฟล์ (เช่น type error, import ที่ไม่ได้ใช้, return type ที่ขาดหาย) — เป็นปลั๊กอินเดี่ยวที่ ส่งผลกระทบสูงที่สุด ที่ติดตั้งได้
• ตัวอย่างคำสั่งติดตั้ง:
  • /plugin install typescript-lsp@claude-plugins-official
  • /plugin install pyright-lsp@claude-plugins-official
  • /plugin install rust-analyzer-lsp@claude-plugins-official
  • /plugin install gopls-lsp@claude-plugins-official
• ปลั๊กอินสำหรับ C#, Java, Kotlin, Swift, PHP, Lua, C/C++ ก็มีให้ใช้ในแท็บ Discover ของ /plugin
• ต้องมีการติดตั้ง language server binary ของภาษานั้นไว้ในระบบด้วย (ถ้าไม่มี ปลั๊กอินจะแจ้งเตือน)

6. ใช้ gh CLI และเรียนรู้เครื่องมือ CLI ทุกตัว

• ใช้ gh CLI จัดการ PR, issue และคอมเมนต์ได้โดยไม่ต้องมี MCP server แยก — เครื่องมือ CLI ใช้คอนเท็กซ์ได้มีประสิทธิภาพกว่า MCP server (ไม่ต้องโหลด tool schema เข้า context window)
• แนวคิดเดียวกันนี้ใช้ได้กับเครื่องมือ CLI มาตรฐานอย่าง jq, curl เป็นต้น
• ถ้า Claude ไม่รู้จักเครื่องมือใด ก็ให้อ่านผลลัพธ์ --help เพื่อทำความเข้าใจไวยากรณ์แล้วรันคำสั่งได้เอง — เช่น: "เรียนรู้จาก sentry-cli --help แล้วช่วยหา error ล่าสุดใน production ให้หน่อย"
• ใช้ได้แม้กับเครื่องมือ CLI ภายในองค์กรที่เฉพาะทางมาก

7. ใส่ "ultrathink" สำหรับการให้เหตุผลที่ซับซ้อน

• คีย์เวิร์ด "ultrathink" จะตั้ง effort เป็นระดับสูง และเปิดใช้ adaptive reasoning บน Opus 4.6
• เหมาะกับสถานการณ์ที่ Claude ต้องคิดให้รอบคอบก่อนลงมือ เช่น การตัดสินใจด้านสถาปัตยกรรม, การดีบักยาก ๆ, หรือการให้เหตุผลหลายขั้นตอน
• ตั้งค่าเป็นค่าถาวรได้ด้วย /effort — แต่สำหรับงานง่ายควรใช้ effort ต่ำเพื่อให้เร็วและประหยัดกว่า
• ไม่จำเป็นต้องเสีย thinking token กับการเปลี่ยนชื่อตัวแปร — ปรับ effort ให้เหมาะกับปัญหา

8. ขยายความรู้แบบออนดีมานด์ด้วยสกิล

• สกิล คือไฟล์ Markdown ที่ใช้ขยายความรู้ของ Claude โดยต่างจาก CLAUDE.md ตรงที่จะ โหลดเฉพาะในงานที่เกี่ยวข้อง ช่วยให้คอนเท็กซ์เบา
• สร้างได้ใน .claude/skills/ หรือจะติดตั้งสกิลสำเร็จรูปที่ปลั๊กอิน bundle มาให้ก็ได้ (ดูได้จาก /plugin)
• เหมาะกับความรู้เฉพาะโดเมนที่ Claude ต้องใช้เป็นครั้งคราวแต่ไม่จำเป็นต้องใช้ตลอด เช่น กฎของ API, ขั้นตอน deploy, หรือแพตเทิร์นการเขียนโค้ด

9. ควบคุม Claude Code จากโทรศัพท์

• เริ่มเซสชันด้วย claude remote-control แล้วเชื่อมต่อผ่าน claude.ai/code หรือแอป Claude บน iOS/Android
• เซสชันจะรันอยู่บนเครื่องโลคัลของคุณ ส่วนโทรศัพท์หรือเบราว์เซอร์เป็นแค่ช่องทางเชื่อมต่อ — ส่งข้อความ, อนุมัติการเรียกใช้เครื่องมือ, และติดตามความคืบหน้าได้
• หากใช้ alias cc จาก tip #1 ก็ไม่ต้องคอยอนุมัติเพิ่ม ทำให้การควบคุมระยะไกลลื่นไหลขึ้น — เริ่มงานแล้วลุกไปทำอย่างอื่นได้ จากนั้น ค่อยกลับมาดูตอน Claude ทำเสร็จหรือเมื่อมีสถานการณ์ไม่คาดคิดเท่านั้น

10. ขยาย context window เป็น 1M โทเค็น

• ทั้ง Sonnet 4.6 และ Opus 4.6 รองรับ context window ขนาด 1M โทเค็น
• ในแพ็กเกจ Max, Team และ Enterprise นั้น Opus จะถูกอัปเกรดเป็น 1M context โดยอัตโนมัติ
• สลับโมเดลระหว่างเซสชันได้ด้วย /model opus[1m] หรือ /model sonnet[1m]
• หากกังวลเรื่องคุณภาพเมื่อใช้คอนเท็กซ์ขนาดใหญ่ ให้ค่อย ๆ ทดสอบเพิ่มจาก 500k ก่อน
• ใช้ CLAUDE_CODE_AUTO_COMPACT_WINDOW และ CLAUDE_AUTOCOMPACT_PCT_OVERRIDE เพื่อควบคุม จังหวะที่ทริกเกอร์การ compact

11. ใช้ Plan Mode เมื่อยังไม่แน่ใจแนวทาง

• Plan Mode เหมาะกับการแก้หลายไฟล์ โค้ดที่ไม่คุ้นเคย หรือการตัดสินใจเชิงสถาปัตยกรรม — ยอมเสียเวลาสองสามนาทีล่วงหน้าเพื่อกันไม่ให้ Claude ใช้เวลา 20 นาทีแก้ปัญหาผิดจุด
• ข้ามได้สำหรับงานที่เล็กและขอบเขตชัดเจน — ถ้าอธิบาย diff ได้ในประโยคเดียว ก็ลงมือได้เลย
• กด Shift+Tab เพื่อสลับระหว่างโหมดสิทธิ์ Normal, Auto-Accept และ Plan ได้ (โดยไม่ต้องออกจากบทสนทนา)

12. รัน /clear ระหว่างงานที่ไม่เกี่ยวกัน

• พรอมป์ต์ที่คมชัดในเซสชันสะอาด ดีกว่าเซสชัน 3 ชั่วโมงที่รก — ถ้าเป็นคนละงานให้เริ่มด้วย /clear
• มันอาจรู้สึกเหมือนทิ้งความคืบหน้า แต่คอนเท็กซ์ที่สะสมไว้สามารถกลบคำสั่งปัจจุบันจนทำให้ รู้สึกว่าเสียผลลัพธ์ไป 30 นาที
• การใช้เวลา 5 วินาทีกับ /clear และเขียนพรอมป์ต์เริ่มต้นที่โฟกัสชัดเจนคุ้มค่ากว่ามาก

13. อย่าตีความบั๊กเอง ให้แปะข้อมูลดิบไปเลย

• ถ้าคุณอธิบายบั๊กเป็นคำพูด Claude จะต้องเดา แก้ แล้ววนซ้ำอย่างช้า ๆ
• ให้แปะ error log, ผลลัพธ์ CI, หรือเธรด Slack ลงไปตรง ๆ แล้วบอกว่า "fix" จากนั้น Claude จะอ่านล็อกระบบกระจายและไล่หาจุดที่มีปัญหา
• การตีความของมนุษย์คือการเพิ่ม ชั้นนามธรรม ที่ทำให้รายละเอียดซึ่งจำเป็นต่อการหาสาเหตุรากของปัญหาอย่างแม่นยำหายไป
• ใช้ได้กับ CI เช่นกัน — แค่บอกว่า "Go fix the failing CI tests" แล้วแปะผลลัพธ์ CI หรือส่ง URL/หมายเลข PR พร้อมขอให้แก้ checks ที่ล้มเหลว
• สามารถ pipe เอาผลลัพธ์จากเทอร์มินัลเข้าไปได้โดยตรง:
  • cat error.log | claude "explain this error and suggest a fix"
  • npm test 2>&1 | claude "fix the failing tests"

14. ถามเรื่องข้างเคียงแบบรวดเร็วด้วย /btw

• /btw จะเปิดโอเวอร์เลย์ที่ ไม่ถูกบันทึกลงในประวัติการสนทนา เพื่อให้ถามคำถามสั้น ๆ ได้อย่างรวดเร็ว
• ใช้เพื่อขอคำอธิบายเพิ่มเติมเกี่ยวกับเซสชันปัจจุบัน เช่น "ทำไมถึงเลือกแนวทางนี้?" หรือ "trade-off เมื่อเทียบกับตัวเลือกอื่นคืออะไร?"
• คำตอบจะแสดงในโอเวอร์เลย์ที่ปิดได้ ทำให้ คอนเท็กซ์หลักยังคงเบา

15. รัน branch แบบขนานที่แยกจากกันด้วย --worktree

• claude --worktree feature-auth จะสร้าง สำเนางานที่แยกออกมา และ branch ใหม่ — Claude จะจัดการการตั้งค่าและการเก็บกวาด git worktree ให้อัตโนมัติ
• ทีม Claude Code มองว่านี่เป็นหนึ่งใน ตัวปลดล็อกประสิทธิภาพการทำงานที่ใหญ่ที่สุด
• สามารถ spin up worktree 3–5 ชุดเพื่อรัน Claude session ที่เป็นอิสระต่อกันแบบขนานได้ (ปกติใช้ 2–3 ชุด)
• แต่ละ worktree มีเซสชัน, branch และ สถานะไฟล์ระบบ ของตัวเอง
• ข้อจำกัดของ local worktree คือทรัพยากรเครื่อง — dev server หลายตัว, build และ Claude session จะแข่งกันใช้ CPU
  • Builder.io แก้ภาระบนเครื่องโดยวางแต่ละเอเจนต์ไว้ใน cloud container แยกกัน

16. บันทึกพรอมป์ต์ชั่วคราวด้วย Ctrl+S

• ถ้ากำลังเขียนพรอมป์ต์ยาว ๆ แล้วต้องการคำตอบด่วนก่อน ให้กด Ctrl+S เพื่อ stash ฉบับร่างไว้
• หลังส่งคำถามด่วนแล้ว พรอมป์ต์ที่ stash ไว้จะถูก กู้กลับอัตโนมัติ

17. สลับงานที่ใช้เวลานานไปเบื้องหลังด้วย Ctrl+B

• เมื่อ Claude เริ่มคำสั่ง bash ที่ใช้เวลานาน (test suite, build, migration) ให้กด Ctrl+B เพื่อย้ายไปทำงานเบื้องหลัง
• Claude จะทำงานต่อไปและผู้ใช้ก็ยังสนทนาได้ — เมื่อโปรเซสเสร็จจะมีการแสดงผลลัพธ์

18. เพิ่ม statusline แบบสด

• statusline คือ shell script ที่รันหลังแต่ละรอบของ Claude เพื่อแสดงไดเรกทอรีปัจจุบัน, git branch และ การใช้คอนเท็กซ์แบบเข้ารหัสสี ที่ด้านล่างของเทอร์มินัล
• ตั้งค่าได้รวดเร็วด้วยคำสั่ง /statusline — ระบบจะถามว่าต้องการแสดงอะไรแล้วสร้างสคริปต์ให้โดยอัตโนมัติ

19. ใช้ subagent เพื่อให้คอนเท็กซ์หลักสะอาด

• หากบอกว่า "ใช้ subagent เพื่อหาว่า payment flow จัดการธุรกรรมที่ล้มเหลวอย่างไร" ก็จะมี Claude instance แยกต่างหาก อ่านไฟล์และวิเคราะห์ในหน้าต่างคอนเท็กซ์อิสระ จากนั้นรายงานสรุปแบบกระชับกลับมา
• การสืบค้นเชิงลึกอาจ กินหน้าต่างคอนเท็กซ์ไปครึ่งหนึ่ง ดังนั้นใช้ subagent เพื่อแยกต้นทุนนี้ออกจากเซสชันหลัก
• ประเภทที่มีมาในตัว: Explore (Haiku, สำหรับค้นหาไฟล์อย่างรวดเร็ว), Plan (การวิเคราะห์แบบอ่านอย่างเดียว)

20. ทีมเอเจนต์สำหรับประสานงานหลายเซสชัน

• เป็นฟีเจอร์ทดลองแต่ทรงพลัง — เปิดใช้งานได้โดยเพิ่ม CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS ลงในการตั้งค่าหรือตัวแปรสภาพแวดล้อม
• สั่งได้ว่า "สร้างทีมเอเจนต์ 3 คนเพื่อรีแฟกเตอร์โมดูลเหล่านี้แบบขนาน"
• หัวหน้าทีม จะกระจายงานให้สมาชิก โดยแต่ละคนมีหน้าต่างคอนเท็กซ์อิสระและ รายการงานที่ใช้ร่วมกัน พร้อมทั้งส่งข้อความหากันโดยตรงได้
• แนะนำให้เริ่มที่สมาชิกทีม 3–5 คน และ งาน 5–6 งานต่อคน
• ควรหลีกเลี่ยงการมอบหมายงานที่แก้ไฟล์เดียวกัน เพราะมี ปัญหาการเขียนทับกัน — เริ่มจากงานวิจัยและรีวิวก่อน แล้วค่อยขยายไปสู่การทำ implementation แบบขนาน

21. เพิ่มคำสั่งให้เก็บข้อมูลไว้ตอน compaction

• ตอนทำ context compaction (อัตโนมัติหรือผ่าน /compact) สามารถ ระบุสิ่งที่ต้องการเก็บไว้ ได้ เช่น /compact focus on the API changes and the list of modified files
• สามารถเพิ่มคำสั่งถาวรไว้ใน CLAUDE.md ได้ด้วย เช่น "เวลาทำ compaction ให้ เก็บรายการไฟล์ที่แก้ทั้งหมดและสถานะการทดสอบปัจจุบัน ไว้"

22. รันการตรวจสอบซ้ำ ๆ ด้วย /loop

• ใช้ /loop 5m check if the deploy succeeded and report back เพื่อ ตั้งเวลาพรอมป์ต์แบบวนซ้ำในเบื้องหลัง
• ช่วงเวลาระบุได้หรือไม่ก็ได้ (ค่าเริ่มต้น 10 นาที) รองรับหน่วย s, m, h, d
• สามารถวนคำสั่งอื่นได้เช่นกัน เช่น /loop 20m /review-pr 1234
• งานมีผล ภายในขอบเขตของเซสชันและหมดอายุหลัง 3 วัน — ลูปที่ถูกลืมจะไม่รันตลอดไป
• ใช้สำหรับมอนิเตอร์ deploy, เฝ้าดู CI pipeline และ polling บริการภายนอก

23. เขียนพรอมป์ต์ที่มีบริบทมากขึ้นด้วยการป้อนเสียง

• ใช้ /voice เพื่อเปิด push to talk แล้วกดปุ่ม Space และพูด ระบบจะถอดเสียงแบบเรียลไทม์และแทรกลงในพรอมป์ต์
• สามารถผสมการพูดกับการพิมพ์ในข้อความเดียวกันได้
• พรอมป์ต์ด้วยเสียงมักมี คอนเท็กซ์มากกว่า การพิมพ์ตามธรรมชาติ — อธิบายภูมิหลัง, ข้อจำกัด และสิ่งที่ต้องการได้โดยไม่ต้องเสียแรงพิมพ์
• ต้องมีบัญชี Claude.ai (ไม่ใช่ API key)
• ใน ~/.claude/keybindings.json สามารถ rebind ปุ่ม push to talk เป็น meta+k เป็นต้น เพื่อข้ามช่วงวอร์มอัปของ hold-detection ได้

24. ถ้าแก้ปัญหาเดิมมา 2 ครั้งแล้วยังไม่หาย ให้เริ่มใหม่

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

25. ระบุให้ Claude ดูไฟล์ไหนอย่างชัดเจน

• อ้างอิงไฟล์โดยตรงด้วย คำนำหน้า @ เช่น @src/auth/middleware.ts has the session handling
• คำนำหน้า @ จะถูกตีความเป็น path ของไฟล์โดยอัตโนมัติ ทำให้ Claude ระบุตำแหน่งที่ถูกต้องได้ทันที
• แม้ Claude จะ grep/ค้นหาเองได้ แต่กระบวนการจำกัดตัวเลือกและระบุไฟล์ที่ถูกต้องนั้น ใช้ทั้งโทเค็นและคอนเท็กซ์ — ถ้าระบุไฟล์ตั้งแต่แรกก็ข้ามขั้นตอนทั้งหมดนี้ได้

26. สำรวจโค้ดที่ไม่คุ้นเคยด้วยพรอมป์ต์กำกวม

• "ในไฟล์นี้คุณจะปรับปรุงอะไรบ้าง?" เป็น พรอมป์ต์สำหรับการสำรวจ ที่ยอดเยี่ยม — ไม่ใช่ทุกพรอมป์ต์ต้องเฉพาะเจาะจง
• เมื่ออยากได้มุมมองใหม่ต่อโค้ดเดิม คำถามที่กำกวมจะเปิดพื้นที่ให้ Claude ค้นพบสิ่งที่คาดไม่ถึง
• ใช้ได้ดีตอน onboarding เข้าสู่ repo ที่ไม่คุ้นเคย — Claude จะชี้ให้เห็นแพตเทิร์น, ความไม่สอดคล้อง และโอกาสในการปรับปรุงที่อาจพลาดไปในการอ่านรอบแรก

27. แก้ไขแผนด้วย Ctrl+G

• เมื่อ Claude เสนอแผนขึ้นมา สามารถกด Ctrl+G เพื่อเปิดและแก้ไขโดยตรงใน text editor
• สามารถเพิ่มข้อจำกัด, ลบขั้นตอน หรือเปลี่ยนแนวทางได้ก่อนที่ Claude จะเขียนโค้ดแม้แต่บรรทัดเดียว
• ถ้าแผนโดยรวมถูกต้องอยู่แล้วแต่ อยากปรับแค่บางขั้นตอน ก็ไม่จำเป็นต้องอธิบายทั้งหมดใหม่อีกครั้ง

28. หลังรัน /init ให้ตัดผลลัพธ์ออกครึ่งหนึ่ง

• CLAUDE.md คือไฟล์ Markdown ใน root ของโปรเจกต์ ที่ให้ คำสั่งถาวร แก่ Claude เช่น คำสั่ง build, มาตรฐานการเขียนโค้ด, การตัดสินใจด้านสถาปัตยกรรม และธรรมเนียมของ repo
• Claude จะอ่านไฟล์นี้ตอนเริ่มแต่ละเซสชัน
• ใช้ /init เพื่อสร้าง ฉบับร่างเบื้องต้น จากโครงสร้างโปรเจกต์ — ระบบจะตรวจจับคำสั่ง build, สคริปต์ทดสอบ และ layout ของไดเรกทอรีโดยอัตโนมัติ
• ผลลัพธ์มักจะพองเกินไป — ลบบรรทัดที่อธิบายเหตุผลของการมีอยู่ไม่ได้ และเพิ่มสิ่งที่ขาดไป

29. ทดสอบทุกบรรทัดใน CLAUDE.md ด้วย litmus test

• สำหรับทุกบรรทัดใน CLAUDE.md ให้ถามว่า "ถ้าไม่มีบรรทัดนี้ Claude จะทำพลาดไหม?"
• คำสั่งที่ Claude ทำถูกอยู่แล้วคือ noise — บรรทัดที่ไม่จำเป็นจะทำให้บรรทัดสำคัญถูกเจือจาง
• มีขีดจำกัดราว 150–200 คำสั่ง ก่อนที่อัตราการปฏิบัติตามจะลดลง โดย system prompt ใช้ไปแล้วประมาณ 50 คำสั่ง

30. หลัง Claude พลาด ให้บอกว่า "อัปเดต CLAUDE.md เพื่อไม่ให้ความผิดพลาดนี้เกิดซ้ำ"

• เมื่อ Claude ทำพลาด ให้สั่งว่า "update the CLAUDE.md file so this doesn't happen again"
• Claude จะเขียนกฎของตัวเอง และ ปฏิบัติตามโดยอัตโนมัติ ตั้งแต่เซสชันถัดไป
• เมื่อเวลาผ่านไป CLAUDE.md จะพัฒนาเป็น เอกสารมีชีวิตที่ก่อตัวจากความผิดพลาดจริง
• เพื่อป้องกันการเติบโตไม่สิ้นสุด ให้ใช้อ้างอิง @imports (tip #32) ไปยังไฟล์แยกต่างหาก เช่น @docs/solutions.md — ทำให้ CLAUDE.md เบาไว้และให้ Claude อ่านรายละเอียดเมื่อจำเป็น

31. ใช้กฎแบบมีเงื่อนไขด้วย .claude/rules/

• วางไฟล์ Markdown ไว้ใน .claude/rules/ เพื่อ จัดระเบียบคำสั่งตามหัวข้อ — โดยค่าเริ่มต้น ไฟล์กฎทั้งหมดจะถูกโหลดเมื่อเริ่มเซสชัน
• ใช้ frontmatter paths เพื่อ เปิดใช้งานแบบมีเงื่อนไขให้โหลดเฉพาะกับแพตเทิร์นไฟล์ที่กำหนด ได้:
  • ตัวอย่าง: หากตั้งค่า paths: ["**/*.ts"] กฎ TypeScript จะถูกโหลดก็ต่อเมื่อ Claude อ่านไฟล์ .ts เท่านั้น
• รักษา CLAUDE.md หลักให้กระชับ — Claude จะไม่อ่านกฎของภาษาที่ไม่ได้กำลังทำงานอยู่

32. ทำให้ CLAUDE.md เบาอยู่เสมอด้วย @imports

• อ้างอิงเอกสารอย่าง @docs/git-instructions.md — ใช้ @README.md, @package.json, @~/.claude/my-project-instructions.md ได้เช่นกัน
• Claude จะ อ่านไฟล์เมื่อจำเป็นเท่านั้น — ทำหน้าที่เป็น "เพิ่มบริบทเมื่อจำเป็น" โดยไม่ทำให้ CLAUDE.md ที่ถูกโหลดทุกเซสชันเทอะทะเกินไป

33. ตั้งค่า allowlist ของคำสั่งที่ปลอดภัยด้วย /permissions

• เลิกกดอนุมัติ npm run lint เป็นครั้งที่หลายร้อย — ใช้ /permissions เพื่อ เพิ่มคำสั่งที่เชื่อถือได้เข้า allowlist
• คำสั่งที่ไม่อยู่ในรายการจะยังคงแสดงพรอมป์ต์อยู่

34. ใช้ /sandbox เพื่อให้ Claude ทำงานได้อย่างอิสระมากขึ้น

• เปิดใช้ การแยกระดับ OS ด้วย /sandbox — จำกัดการเขียนไว้ที่ไดเรกทอรีโปรเจกต์ และอนุญาตคำขอเครือข่ายเฉพาะโดเมนที่ได้รับอนุมัติ
• บน macOS ใช้ Seatbelt, บน Linux ใช้ bubblewrap และข้อจำกัดจะมีผลกับทุก subprocess ที่ Claude สร้าง
• ในโหมด auto-allow คำสั่งภายใน sandbox จะ รันได้โดยไม่ต้องมีพรอมป์ต์ขอสิทธิ์ — เกือบอัตโนมัติเต็มรูปแบบแต่ยังมีราวกันตก
• สำหรับงานแบบไม่มีผู้ดูแล (เช่น การย้ายระบบข้ามคืน หรือการรีแฟกเตอร์เชิงทดลอง) ให้รัน Claude ภายใน Docker container เพื่อให้แยกขาดสมบูรณ์และย้อนกลับได้ง่าย

35. สร้าง custom subagent สำหรับงานที่ทำซ้ำ

• ต่างจาก subagent แบบเฉพาะหน้าตาม tip #19, custom subagent จะถูก ตั้งค่าไว้ล่วงหน้าและบันทึก ใน .claude/agents/
  • ตัวอย่าง: เอเจนต์ security reviewer ที่ใช้ Opus + เครื่องมือแบบอ่านอย่างเดียว, เอเจนต์ค้นหาแบบเร็วของ Haiku
• สำรวจและสร้างได้ด้วย /agents
• สามารถตั้งค่าเอเจนต์ให้มีระบบไฟล์แยกอิสระได้ด้วย isolation: worktree

36. เลือก MCP server ให้เข้ากับสแตกของคุณ

• MCP server ที่เหมาะสำหรับเริ่มต้น: Playwright (ทดสอบเบราว์เซอร์และตรวจสอบ UI), PostgreSQL/MySQL (คิวรีสคีมาโดยตรง), Slack (รายงานบั๊กและบริบทของเธรด), Figma (เวิร์กโฟลว์จากดีไซน์สู่โค้ด)
• Claude Code รองรับ dynamic tool loading — Claude จะโหลด definition ของ server เฉพาะเมื่อจำเป็นเท่านั้น

37. ตั้งค่าสไตล์ของเอาต์พุต

• เลือกสไตล์ที่ต้องการได้ใน /config — ตัวเลือกในตัวมี: Explanatory (ละเอียด เป็นขั้นตอน), Concise (กระชับ เน้นการลงมือทำ), Technical (แม่นยำ เป็นมิตรกับศัพท์เฉพาะ)
• สามารถสร้างไฟล์ custom output style ของตัวเองได้ใน ~/.claude/output-styles/

38. CLAUDE.md คือข้อเสนอแนะ ส่วน Hooks คือข้อบังคับ

• CLAUDE.md มีลักษณะเป็นคำแนะนำ — Claude ทำตามประมาณ 80%
• Hooks มีลักษณะเป็นตัวกำหนดตายตัว — ทำงาน 100%
• สิ่งที่ต้องรันทุกครั้งโดยไม่มีข้อยกเว้น (เช่น formatting, linting, security check) ควร ตั้งเป็น Hook
• ถ้าเป็นเพียงแนวทางที่อยากให้ Claude คำนึงถึง ใช้ CLAUDE.md ก็เพียงพอ

39. ใช้ PostToolUse Hook เพื่อฟอร์แมตอัตโนมัติ

• เพิ่ม PostToolUse Hook ใน .claude/settings.json เพื่อให้ formatter รันอัตโนมัติ ทุกครั้งที่ Claude แก้ไขไฟล์
  • ลงทะเบียน npx prettier --write "$CLAUDE_FILE_PATH" 2>/dev/null || true กับ matcher Edit|Write
• ใช้ || true เพื่อ ไม่ให้ Hook ที่ล้มเหลวบล็อก Claude
• สามารถ chain npx eslint --fix เป็นรายการ Hook ลำดับที่สองได้
• หาก editor เปิดไฟล์เดียวกันอยู่ ควรปิด format-on-save — มีรายงานว่าการบันทึกจาก editor อาจ ทำให้ prompt cache ใช้ไม่ได้ และให้ Hook เป็นผู้จัดการเรื่อง formatting แทน

40. ใช้ PreToolUse Hook เพื่อบล็อกคำสั่งทำลายล้าง

• บล็อกแพตเทิร์นอย่าง rm -rf, drop table, truncate ด้วย PreToolUse Hook — Claude จะไม่แม้แต่พยายามรัน
• Hook จะ ทำงานก่อน ที่ Claude จะเรียกใช้เครื่องมือ จึงช่วยกันคำสั่งทำลายล้างไว้ล่วงหน้า
• เพิ่มใน .claude/settings.json, ตั้งค่าแบบอินเทอร์แอ็กทีฟด้วย /hooks, หรือสั่ง Claude ว่า "เพิ่ม PreToolUse Hook ที่บล็อกคำสั่ง rm -rf, drop table, truncate"

41. ใช้ Hook เพื่อรักษาบริบทสำคัญไว้ตอน compaction

• ในเซสชันที่ยาว เมื่อมีการ compact บริบท Claude อาจ สูญเสียบริบทของสิ่งที่กำลังทำอยู่
• Notification Hook ที่มี matcher compact จะ inject บริบทสำคัญกลับเข้าไปอัตโนมัติ ทุกครั้งที่มีการ compact
• สั่ง Claude ว่า "ตั้ง Notification Hook ที่คอยเตือนงานปัจจุบัน, ไฟล์ที่แก้ไข, และข้อจำกัดต่าง ๆ หลัง compaction"
• สิ่งที่เหมาะจะ re-inject ได้แก่: คำอธิบายงานปัจจุบัน, รายการไฟล์ที่แก้ไข, ข้อจำกัดตายตัว ("อย่าแก้ไฟล์ migration")
• มีประโยชน์มากที่สุดใน เซสชันหลายชั่วโมง ที่ Claude ดำดิ่งอยู่กับฟีเจอร์ลึก ๆ และไม่ควรทำบริบทหลุด

42. Authentication, การชำระเงิน, และ data mutation ต้องตรวจด้วยมือเสมอ

• authentication flow, payment logic, data mutation, งาน DB แบบทำลายล้าง — ไม่ว่าโค้ดส่วนอื่นจะดูดีแค่ไหน ก็ต้องให้มนุษย์ตรวจเสมอ
• authentication scope ที่ผิด, payment webhook ที่ตั้งค่าผิด, migration ที่ลบคอลัมน์แบบเงียบ ๆ ล้วน ทำให้สูญเสียผู้ใช้ ต้นทุน และความเชื่อมั่น
• ไม่ว่าการทดสอบอัตโนมัติจะมากแค่ไหน ก็จับปัญหาเหล่านี้ได้ไม่ครบทั้งหมด

43. ใช้ /branch เพื่อลองแนวทางอื่นโดยไม่เสียเส้นทางปัจจุบัน

• ใช้ /branch (หรือ /fork) เพื่อ สร้างสำเนาของบทสนทนาจากจุดปัจจุบัน
• ลองทำรีแฟกเตอร์เสี่ยง ๆ บน branch — ถ้าสำเร็จก็เก็บไว้ ถ้าล้มเหลว บทสนทนาต้นฉบับก็ยังปลอดภัย
• ต่างจาก rewind (tip #3) ตรงที่ ทั้งสองเส้นทางยังคงอยู่พร้อมกัน

44. หากสเปกฟีเจอร์ยังไม่สมบูรณ์ ให้ Claude สัมภาษณ์คุณ

• เมื่อคุณรู้ว่าอยากสร้างอะไร แต่ยังขาด รายละเอียดทั้งหมดที่ Claude ต้องใช้เพื่อสร้างได้ดี ให้ Claude เป็นฝ่ายถาม
  • "ฉันอยากสร้าง [คำอธิบายสั้น ๆ] ใช้เครื่องมือ AskUserQuestion เพื่อสัมภาษณ์ฉันอย่างละเอียด ถามเรื่องการทำงานทางเทคนิค, edge case, ข้อกังวล, และ trade-off อย่าถามคำถามพื้น ๆ สัมภาษณ์ไปจนกว่าจะครอบคลุมทั้งหมด แล้วจึง เขียนสเปกที่สมบูรณ์ลงใน SPEC.md"
• เมื่อสเปกเสร็จแล้ว ให้เริ่ม ลงมือ implement ในเซสชันใหม่ด้วยบริบทที่สะอาดและสเปกที่ครบถ้วน

45. ให้ Claude หนึ่งตัวเขียน อีกตัวรีวิว

• ให้ Claude ตัวแรก implement ฟีเจอร์ แล้วให้ Claude ตัวที่สอง รีวิวด้วยบริบทใหม่เหมือน staff engineer
• ผู้รีวิวไม่รู้ทางลัดที่ใช้ระหว่าง implement มาก่อน จึง ตั้งคำถามได้กับทุกส่วน
• แนวคิดเดียวกันนี้ใช้กับ TDD ได้: เซสชัน A เขียนเทสต์, เซสชัน B เขียนโค้ดให้ผ่าน

46. ทำ PR review แบบโต้ตอบ

• แทนที่จะขอ PR review แบบ one-shot (ซึ่งก็ทำได้แน่นอน) ให้เปิด PR ในเซสชันแล้วคุยกันแบบ โต้ตอบ
  • "อธิบายการเปลี่ยนแปลงที่เสี่ยงที่สุดใน PR นี้"
  • "ถ้าสิ่งนี้รันพร้อมกันจะมีอะไรพังบ้าง?"
  • "การจัดการ error สอดคล้องกับส่วนอื่นของ codebase หรือไม่?"
• การรีวิวแบบโต้ตอบจับปัญหาได้มากกว่า — เพราะสามารถ ขุดลึกลงไปในจุดสำคัญ ได้
• รีวิวแบบ one-shot มักชี้เรื่องหยุมหยิมด้านสไตล์ และ พลาดปัญหาเชิงสถาปัตยกรรมได้ง่าย

47. ตั้งชื่อและสีให้เซสชัน

• ใช้ /rename auth-refactor เพื่อ แสดงป้ายชื่อบน prompt bar
• ใช้ /color red หรือ /color blue เพื่อ ตั้งค่าสีของ prompt bar
  • สีที่ใช้ได้: red, blue, green, yellow, purple, orange, pink, cyan
• หากรัน 2–3 เซสชันคู่ขนานกัน การใช้เวลา 5 วินาทีเพื่อตั้งชื่อและสีจะช่วย ป้องกันการพิมพ์ผิดเทอร์มินัล

48. เล่นเสียงเมื่อ Claude ทำงานเสร็จ

• ใช้ Stop Hook เพื่อเล่นเสียงของระบบเมื่อ Claude ตอบเสร็จ
• เริ่มงานแล้วสลับไปทำอย่างอื่น จากนั้นให้ แจ้งเตือนด้วยเสียง ping เมื่อเสร็จ
• ตัวอย่าง: ลงทะเบียน /usr/bin/afplay /System/Library/Sounds/Glass.aiff เป็น Stop Hook ใน .claude/settings.json

49. กระจายงานแบตช์ด้วย claude -p

• ใช้ โหมดไม่โต้ตอบ เพื่อวนลูปรายการไฟล์แล้วประมวลผล — จำกัดขอบเขตงานที่ Claude ทำได้ต่อไฟล์ด้วย --allowedTools
• ใช้ & เพื่อ รันแบบขนาน ให้ได้ปริมาณงานสูงสุด:
  • for file in $(cat files-to-migrate.txt); do claude -p "Migrate $file from class components to hooks" --allowedTools "Edit,Bash(git commit *)" & done; wait
• เหมาะกับการแปลงฟอร์แมตไฟล์, อัปเดต import ทั้งโค้ดเบส, และ งานย้ายแบบทำซ้ำ ที่แต่ละไฟล์เป็นอิสระต่อกัน

50. ปรับแต่งคำกริยาของสปินเนอร์ (เพิ่มความสนุก)

• ระหว่างที่ Claude กำลังคิด จะแสดง คำกริยาของสปินเนอร์ ในเทอร์มินัล เช่น "Flibbertigibbeting...", "Flummoxing..."
• สามารถเปลี่ยนเป็นข้อความที่ต้องการได้ — สั่ง Claude ว่า:
  • "Replace my spinner verbs in user settings with these: Hallucinating responsibly, Pretending to think, Confidently guessing, Blaming the context window"
• ไม่จำเป็นต้องให้รายการเอง — แค่ บอกบรรยากาศที่ต้องการ เช่น "Replace my spinner verbs with Harry Potter spells" แล้ว Claude จะสร้างรายการให้
• เป็นการปรับแต่งเล็ก ๆ ที่ทำให้ช่วงเวลารอดูน่าสนุกขึ้น

[roxie]

ตั้งแต่ข้อ 1 ก็สนุกมากแล้ว