Get Shit Done - ระบบเมตาพรอมป์ต์และการพัฒนาที่ขับเคลื่อนด้วยสเปก

 (github.com/gsd-build)
12 คะแนน โดย GN⁺ 2026-03-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นระบบน้ำหนักเบาที่ช่วยทำให้ การพัฒนาที่ขับเคลื่อนด้วยสเปก (SDD) เป็นอัตโนมัติใน Claude Code เป็นต้น เพื่อช่วยให้โปรเจ็กต์เสร็จสมบูรณ์ได้โดยไม่ต้องมีเวิร์กโฟลว์ที่ซับซ้อน
  • ป้องกันปัญหา context rot ซึ่งทำให้คุณภาพของโค้ด AI ลดลง ด้วย context engineering, การจัดโครงสร้างพรอมป์ต์แบบ XML และ การ orchestration แบบ multi-agent
  • ทำให้วงจรการพัฒนาทั้งหมดเป็นอัตโนมัติ ตั้งแต่ กำหนดไอเดีย → วางแผน → ลงมือทำ → ตรวจสอบ ผ่านคำสั่งอย่าง /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase
  • มี atomic Git commit แยกตามหน่วยงานแต่ละชิ้น และการทำงานแบบขนาน (wave execution) เพื่อให้ติดตามย้อนหลังได้และมีประสิทธิภาพ
  • เป็นเครื่องมือที่วิศวกรจาก Amazon, Google, Shopify, Webflow ใช้งาน เพื่อเพิ่มความน่าเชื่อถือและประสิทธิภาพของการพัฒนาด้วย AI

ภาพรวม

  • Get Shit Done (GSD) คือ ระบบเมตาพรอมป์ต์และการจัดการคอนเท็กซ์แบบน้ำหนักเบา ที่ทำงานได้ในสภาพแวดล้อมการพัฒนาด้วย AI หลายแบบ เช่น Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity
  • แก้ปัญหา context rot ที่เกิดขึ้นเมื่อ AI เขียนโค้ดแล้วคุณภาพของบริบทลดลง และสร้างผลลัพธ์ที่สม่ำเสมอบนพื้นฐานของสเปก
  • ใช้งานได้บน Mac, Windows และ Linux ทั้งหมด และติดตั้งได้ด้วยคำสั่ง npx get-shit-done-cc@latest

ที่มาของการสร้าง (Why I Built This)

  • สร้างขึ้นเพื่อแก้ปัญหาที่เครื่องมือสำหรับองค์กรขนาดใหญ่บังคับให้ต้องใช้ขั้นตอนที่ซับซ้อนเกินความจำเป็น
  • GSD ออกแบบตามแนวคิด เก็บความซับซ้อนไว้ในระบบ แต่ทำให้เวิร์กโฟลว์เรียบง่าย
  • ภายในระบบทำงานด้าน context engineering, การจัดรูปแบบพรอมป์ต์แบบ XML, sub-agent orchestration, การจัดการสถานะ
  • ผู้ใช้สามารถทำโปรเจ็กต์ให้เสร็จได้ด้วยคำสั่งที่เรียบง่าย

ฟีเจอร์หลักและเวิร์กโฟลว์ (How It Works)

  • กระบวนการพัฒนาทั้งหมดประกอบด้วย 6 ขั้นตอน

    1. เริ่มต้นโปรเจ็กต์: ถามข้อมูลเกี่ยวกับไอเดีย ข้อจำกัด เทคสแต็ก ฯลฯ แล้วสร้าง PROJECT.md, ROADMAP.md เป็นต้น
    2. ขั้น Discuss: กำหนดรายละเอียดการพัฒนาและสร้าง CONTEXT.md
    3. ขั้น Plan: ทำรีเสิร์ชแบบขนานและวางแผน พร้อมสร้างหน่วยงานในโครงสร้าง XML
    4. ขั้น Execute: ทำงานแบบขนานตาม dependency เป็น wave, commit และตรวจสอบแต่ละงาน
    5. ขั้น Verify: รันทดสอบอัตโนมัติและให้ผู้ใช้ยืนยัน พร้อมสร้างแผนแก้ไขอัตโนมัติเมื่อเกิดความล้มเหลว
    6. ทำซ้ำและปิด milestone: ทำซ้ำแต่ละขั้นตอนแล้วติด release tag

  • Quick Mode ใช้สำหรับจัดการงานเดี่ยวอย่างรวดเร็ว และควบคุมรายละเอียดได้ผ่านแฟลก --discuss, --research, --full

เทคโนโลยีหลัก (Why It Works)

  • Context engineering: จัดการบริบทของทั้งโปรเจ็กต์ในระดับไฟล์ (PROJECT.md, REQUIREMENTS.md, STATE.md เป็นต้น)
  • การจัดรูปแบบพรอมป์ต์แบบ XML: กำหนดแต่ละงานให้ชัดเจนและรวมขั้นตอนการตรวจสอบไว้ด้วย
  • Multi-agent orchestration: รันเอเจนต์เฉพาะทางแบบขนานตามขั้นตอนรีเสิร์ช วางแผน ลงมือทำ และตรวจสอบ
  • Atomic Git commit: commit แยกตามหน่วยงานแต่ละชิ้น เพื่อให้ง่ายต่อการติดตามและกู้คืน
  • การออกแบบแบบโมดูลาร์: เพิ่ม แทรก หรือแก้ไขขั้นตอนได้อย่างอิสระ ทำให้บริหารโปรเจ็กต์ได้ยืดหยุ่น

ชุดคำสั่ง (Commands)

  • เวิร์กโฟลว์หลัก: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • รองรับการออกแบบ UI: /gsd:ui-phase, /gsd:ui-review
  • วิเคราะห์โค้ดเบส: /gsd:map-codebase
  • จัดการโปรเจ็กต์: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • ยูทิลิตี: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note เป็นต้น

การตั้งค่าและการกำหนดค่า (Configuration)

  • ควบคุม โหมด, การแบ่งขั้นตอนอย่างละเอียด, โปรไฟล์โมเดล, เวิร์กโฟลว์เอเจนต์, การทำงานแบบขนาน, กลยุทธ์การแตก Git branch ได้จากไฟล์ตั้งค่า .planning/config.json
  • โปรไฟล์โมเดลเลือกได้ระหว่าง quality, balanced, budget, inherit
  • ปรับสมดุลคุณภาพและความเร็วได้ด้วยท็อกเกิลอย่าง workflow.research, workflow.plan_check, workflow.verifier

ความปลอดภัยและการแก้ปัญหา (Security & Troubleshooting)

  • ไฟล์สำคัญอย่าง .env, secrets/, *.pem, *.key ควรถูกเพิ่มเข้า deny list ของ Claude Code เพื่อบล็อกการเข้าถึง
  • หากหลังติดตั้งแล้วคำสั่งไม่ถูกจดจำ แนะนำให้รีสตาร์ตรันไทม์หรือติดตั้งใหม่
  • ในสภาพแวดล้อม Docker สามารถแก้ปัญหาเส้นทางได้ด้วยการตั้งค่า CLAUDE_CONFIG_DIR
  • สามารถลบองค์ประกอบทั้งหมดได้ด้วยออปชัน --uninstall

ชุมชนและไลเซนส์

  • รองรับ community port สำหรับ OpenCode, Gemini CLI และ Codex
  • เผยแพร่ภายใต้ MIT License
  • “Claude Code is powerful. GSD makes it reliable.” — เครื่องมือที่ช่วยเพิ่มความน่าเชื่อถือให้ Claude Code

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-19
ความคิดเห็นจาก Hacker News

  • เมื่อก่อนฉันใช้ Plan mode กับ Superpowers ควบคู่กัน แต่สุดท้ายรู้สึกว่าแค่ Plan mode ก็เพียงพอแล้ว
    เฟรมเวิร์กแบบนี้เหมาะกับงาน fire-and-forget ที่ต้องทำรีเสิร์ช แต่ก็รู้สึกว่าเปลืองโทเคนมากกว่า 10 เท่า
    คุณภาพของผลลัพธ์ก็ไม่ได้ต่างกันมาก จนชนลิมิต Max plan บ่อย ๆ

    • ฉันเอาฟังก์ชัน brainstorm·design·implementation planning ของ Superpowers มาต่อเข้ากับเลเยอร์ implementation ที่อิง Ralph
      พอวางแผน implementation เสร็จ มันจะทำต่ออัตโนมัติโดยไม่ถามอินพุตจากฉัน และต้องรันอยู่ใน Docker sandbox
      เป็นเพราะการตั้งค่าสิทธิ์ที่อันตราย แต่ยังไงฉันก็คิดว่าแบบนั้นปลอดภัยกว่า
      ตอนนี้มันทำงานได้ดีและช่วยเพิ่มประสิทธิภาพมาก แต่ก็ดูเหมือนยังเป็นแค่ช่วงกลางของการเดินทาง
    • ฉันกลับกันเลย ย้ายจาก Plan mode ไปใช้ Superpowers
      พอเห็นประกาศเวอร์ชันล่าสุดก็เลยลองใช้อีกครั้ง แล้วพบว่า cross-check และ self-review มีหลายชั้น ทำให้ผลลัพธ์เสถียรกว่า
      จะทำเองแบบแมนนวลก็ได้ แต่ Superpowers ทำขั้นตอนนั้นให้อัตโนมัติ เลยสะดวกกว่ามาก
    • ฉันทดสอบงานเดียวกันด้วย GSD และ Plan Mode โดย Plan Mode ใช้เวลาแค่ 20 นาทีถึงขั้น implementation พื้นฐาน ส่วน GSD ใช้เวลาหลายชั่วโมง
      GSD เขียนโค้ดโดยคำนึงถึงบริบทของทั้งโปรเจกต์ ส่วน Plan Mode ทำแค่เท่าที่จำเป็นในระดับ MVP
      ข้อดีข้อเสียชัดเจนมาก ขึ้นอยู่กับ workflow และขนาดของงาน
    • ช่วงหลัง Plan mode ของ GitHub Copilot แปลกไปตั้งแต่เพิ่ม plan memory
      เอาต์พุตยาวขึ้นแต่รายละเอียดกลับคลุมเครือกว่าเดิม
      มีแต่ขั้นอย่าง “design”, “figure out” เพิ่มขึ้น และข้ามไป implementation ทันทีโดยไม่ถามคำถามต่อ
    • ฉันก็เจอคล้ายกัน ใช้หมดทั้ง ค่า Claude subscription และ API credit ของหนึ่งสัปดาห์ เพื่อแลกกับโค้ดราว 500 บรรทัด
      บางทีก็ไปแก้เทสต์มั่ว ๆ หรือให้ผลลัพธ์ที่ไม่เกี่ยวข้อง
      สุดท้ายฉันต้อง ไกด์แบบแมนนวล เองจนทำ MVP เสร็จ ซึ่งมีประสิทธิภาพกว่ามาก

  • ช่วงนี้มี meta framework แบบนี้เยอะเกินไป แต่แทบไม่เห็นตัวไหนพิสูจน์ได้ว่าช่วยเพิ่ม productivity จริง
    ส่วนใหญ่เป็นแค่การเปลืองโทเคนและทำให้ context window สกปรก
    สุดท้ายวิธีที่ดีที่สุดยังคงเป็นทำให้เรียบง่าย ให้ข้อมูลเท่าที่จำเป็น แล้ววนลูป Plan → Code → Verify

    • ในบทความของ Apenwarr “The AI Developer’s Descent Into Madness” มีการเสียดสีสถานการณ์ที่ “เอเจนต์สร้างเฟรมเวิร์กของตัวเอง”
    • ฉันทำ มินิเฟรมเวิร์ก ของตัวเองที่จับ Claude กับ Codex มาทำงานร่วมกัน
      เวลาที่ Codex จับความผิดพลาดที่ Claude ทำไว้ได้ ก็ยิ่งทำให้รู้สึกว่าไม่ควรฝากทุกอย่างไว้กับเอเจนต์ตัวเดียว
    • ฉันใช้แนวทาง ออกแบบสเปกแบบภาพ
      ออกแบบ flow ของหน้าจอแอปเป็นภาพ แล้ว export เป็น markdown ที่มีโครงสร้าง เพื่อให้ LLM เข้าใจบริบทเป็นรายหน้าจอ
      วิธีนี้ช่วยจับ สถานะที่ตกหล่นหรือ flow ของข้อผิดพลาด ได้ล่วงหน้าดีกว่าสเปกแบบข้อความ
    • สุดท้าย meta framework พวกนี้ก็เป็นแค่เครื่องมือปรับแต่งเฉพาะตัวแบบ .vimrc หรือ .emacs.d
      คนที่สร้างขึ้นมาอาจใช้ประโยชน์ได้ แต่คนอื่นมักรู้สึกว่าไม่ค่อยมีประโยชน์

  • ฉันมองว่าระบบ Spec-Driven ถูกกำหนดให้ล้มเหลวอยู่แล้ว
    สเปกที่เขียนเป็นภาษาอังกฤษเชื่อมโยงกับโค้ดและพฤติกรรมจริงไม่ได้
    ที่จริงปัญหานี้ถูกแก้ไปแล้วด้วย automated testing
    พฤติกรรมของระบบควรถูก encode เป็นเทสต์ที่รันได้จริง
    ตอนที่ LLM สร้าง implementation ก็ควรเขียนเทสต์ก่อน และตรวจความสอดคล้องด้วย mutation testing
    ฉันสรุปเรื่องนี้ไว้ในบทความนี้ และตัวอย่างบน GitHub

    • สเปกภาษาธรรมชาติอาจขยายต่อได้ยาก แต่ถ้าสร้าง formal spec จากมันก็ยังพอมีความเป็นไปได้
      สุดท้ายมันก็ต้องถูกแสดงออกมาในรูปแบบโค้ดอยู่ดี
    • เคยมีบทความชื่อประมาณ “A sufficiently detailed spec is code” เหมือนกัน แต่ฉันทำผลลัพธ์ของ OpenAI ให้ซ้ำไม่ได้
      ดูลิงก์ ได้
    • Spec Driven Development ชื่ออาจคล้าย TDD แต่แนวคิดตรงกันข้ามเลย
    • การมองว่าเทสต์เป็นแค่ผลลัพธ์ปลายทางของสเปกนั้นเป็น ตรรกะที่ผิด
      สเปกครอบคลุมขอบเขตที่กว้างกว่าเทสต์มาก
      หลายครั้ง LLM ก็ไม่สนใจเทสต์หรือแก้มันตามอำเภอใจด้วย

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

    • ไม่จำเป็นต้องคอยบำรุงรักษาก็ได้
      ในยุค AI แค่ แบ่งปันแรงบันดาลใจและไอเดีย ก็มีคุณค่ามากพอแล้ว

  • ฉันลองใช้ GSD ในทีมแฮกกาธอน แล้วมันใช้เวลาทำความเข้าใจ codebase นานเกินไป แถม กินโทเคน หนักมาก
    ระหว่างสร้าง agent transcript ก็มีข้อผิดพลาดบ่อยด้วย
    สำหรับการทำฟีเจอร์เล็ก ๆ ไม่กี่อย่าง มันเป็นเครื่องมือที่เกินจำเป็น
    บทเรียนที่ได้มีง่าย ๆ คือ — เขียนสเปกให้ดี + วน Plan mode มีประสิทธิภาพกว่ามาก

  • ฉันอึดอัดกับข้อจำกัดด้านดีไซน์ของ Beads เลยทำเครื่องมือคล้ายกันขึ้นมาเอง
    เวอร์ชันของฉันใช้ SQLite เป็นฐาน และเพิ่มฟังก์ชันซิงก์สองทางกับ GitHub
    หัวใจสำคัญคือคุยกับโมเดลก่อนเพื่อสร้าง ไฟล์สเปกที่ชัดเจน
    พอมีไฟล์แล้ว โมเดลจะไม่ลืม และยิ่งรายละเอียดเยอะ คุณภาพของเอาต์พุตก็ยิ่งดี
    ฉันใช้ Claude ทำต้นแบบของไอเดียที่คิดมานานได้ และผลออกมาดีกว่าที่คาดไว้มาก

    • ถ้าจะเรียกว่าเป็น “ซอสลับ” ก็คงเกินไปหน่อย เพราะ RPI(research-plan-implement) เป็นแนวคิดที่อยู่ในเอกสารทางการอยู่แล้ว
      โมเดลก็ยังเป็น ระบบเชิงความน่าจะเป็น เลยไม่มีทางมีความจำที่สมบูรณ์ได้
      การเล่าเหมือนค้นพบเคล็ดลับใหม่จึงดูเวอร์เกินจริง

  • ฉันเคยใช้ Superpowers และ GSD รอบนี้ก็ดูคล้ายกัน เลยอยากรู้ว่าเทียบกันแล้วเป็นยังไง

    • ฉันเคยใช้ทั้งคู่ และ GSD ซับซ้อนเกินไป แถมช้า
      Quick mode ทำให้จุดประสงค์ดั้งเดิมหายไป ส่วน Superpowers อยู่ตรงกลางได้ค่อนข้างดี
    • prompt ที่มีโครงสร้างช่วยได้จริง
      ถ้าเอาเฟรมเวิร์กแบบนี้ใส่ไว้ใน repository แล้วให้ AI ปรับปรุงตัวเฟรมเวิร์กเอง มันก็มีประโยชน์กับงานเชิงสร้างสรรค์เหมือนกัน
      แต่โครงสร้างแบบนี้น่าจะเป็นแค่การแฮ็กชั่วคราว พอโมเดลเรียนรู้ได้ดีพอ มันก็คงหายไปเองตามธรรมชาติ
    • Superpowers เขียนโค้ดทั้งหมดตั้งแต่ขั้นวางแผน แล้วให้ sub-agent คัดลอกไปตรง ๆ ทำให้ไม่มีประสิทธิภาพ
      GSD แก้ปัญหานี้ได้ แต่ก็ มีขั้นตอนเยอะเกินไป จนช้า
    • ฉันทดสอบ Superpowers ตอนย้ายบล็อกจาก Hugo ไป Astro
      สเปกที่ Superpowers สร้างละเอียดก็จริง แต่ยังขาดบางฟังก์ชันไป เช่น RSS และ analytics ขณะที่สเปกการทำงานร่วมกันที่เสนอ parallel migration มีความยืดหยุ่นมากกว่า
      สุดท้ายฉันให้ Claude เปรียบเทียบและรวมสองสเปกจนเป็นฉบับสมบูรณ์
      ดูการเปรียบเทียบแบบละเอียด ได้
    • ฉันไม่แน่ใจว่าจำเป็นต้องมี CLI wrapper ด้วยหรือเปล่า
      แค่ Claude skills ก็น่าจะทำได้เพียงพอแล้ว

  • ฉันใช้ GSD อย่างจริงจังมา 3 เดือน และมัน สมบูรณ์กว่าที่เคยใช้มาอย่าง speckit มาก
    มันจัดการงานซับซ้อนได้อัตโนมัติถึง 95%
    อีก 5% ที่เหลือฉันปิดงานด้วยการทดสอบแบบแมนนวล
    ฉันถึงขั้นออก ผลิตภัณฑ์ SaaS (whiteboar.it) ได้ด้วยมัน
    โมเดลเองก็ดีขึ้นด้วย แต่ ประสิทธิภาพการทำงานที่เพิ่มขึ้น นั้นชัดเจนจริง

    • ฉันก็มีประสบการณ์คล้ายกัน
      เพราะเสียดายค่าสมาชิก FreshBooks ฉันเลยใช้ GSD ทำ แอป macOS Swift ขึ้นมาเอง
      ตั้งแต่การดึงข้อมูลใบเสร็จอัตโนมัติไปจนถึงการแยกหมวดหมู่ ก็ทำด้วย Anthropic API
      เริ่มจากเว็บแอป แต่พอเพิ่มฟีเจอร์อย่างการเชื่อมต่อกล้อง ก็พัฒนาจนกลายเป็นเดสก์ท็อปแอปเต็มตัว
      GSD ช่วยให้ฉันทำแอปบัญชีส่วนตัวจนเสร็จได้

  • ท้ายที่สุด เครื่องมือที่ต้องการจริง ๆ คือ เครื่องมือที่ช่วยประหยัดโทเคน
    แต่ตอนนี้ยังไม่มีอะไรแบบนั้น
    แม้แต่ Claude Code เองก็ยังใช้โทเคนมากเกินไปในโปรเจกต์ขนาดใหญ่

  • ชื่อของ “ชุดไฟล์ Markdown” นี้มัน ชวนขนลุก เกินไป

    • ถ้าเอาไว้ใต้โฟลเดอร์ “Languages” อาจจะดูดีกว่านี้
    • แต่ยังไงก็ยังดีกว่า “gstack” ไม่ใช่เหรอ?