golive-skill คือ Agent Skill หรือชุดคำสั่งเสริมสำหรับผู้ช่วย AI ที่เปิดให้ใช้งานฟรีแบบโอเพนซอร์ส ช่วยนำเว็บแอปพลิเคชันที่ AI เขียนขึ้นไปรันเป็นเว็บจริงบนบัญชีของเราเอง โดยจัดการเชื่อมต่อให้ครบวงจรในที่เดียว ตั้งแต่โฮสติ้ง ฐานข้อมูล โดเมน ระบบส่งอีเมล ไปจนถึงระบบรับชำระเงิน

ปัญหาคลาสสิกของคนที่ใช้ AI ช่วยเขียนโปรแกรมคือ แม้ Coding Agent อย่าง Claude Code หรือ Codex จะช่วยเขียนโค้ดจนรันบนเครื่องของเราได้ในเวลาไม่กี่นาที แต่พอจะเปิดให้คนภายนอกเข้ามาใช้งานจริง มักจะติดแหง็ก เพราะต้องไปเปิดบัญชีบริการต่างๆ ตั้งค่าระบบ และผูก API key กับผู้ให้บริการอีกสารพัดเจ้า

golive-skill เข้ามารับหน้าที่จัดการขั้นตอนเหล่านี้ต่อ โดยไม่ได้นำแอปขึ้นระบบหรือ deploy แบบรวดเดียวจบ แต่ใช้วิธีทำงานอย่างรัดกุม 5 ขั้นตอน ตั้งแต่ detect เพื่อตรวจสอบ, plan เพื่อวางแผน, approve เพื่อขออนุมัติ, apply เพื่อลงมือทำ ไปจนถึง verify เพื่อตรวจผลลัพธ์ ที่สำคัญคือ ระบบจะไม่เข้าไปแก้ไขหรือเปลี่ยนแปลงข้อมูลใดๆ ในบัญชีจริงของเรา จนกว่าเราจะตรวจสอบและอนุมัติแผนงาน

ตัวโปรเจกต์บน GitHub ประกอบด้วยสองส่วนหลักที่ทำงานร่วมกัน ส่วนแรกคือตัวสกิลที่ Coding Agent จะโหลดเข้าไปใช้งาน และส่วนที่สองคือ Node CLI ที่ไม่ต้องติดตั้งแพ็กเกจอื่นเพิ่มเติม โดย Agent จะเป็นฝ่ายเรียกใช้งานเองเมื่อถึงขั้นตอนที่ต้องลงมือ ทั้งหมดนี้เผยแพร่เป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT

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

กว่าจะเป็นเว็บที่รับเงินได้ ต้องเชื่อมต่อกี่บัญชี

การสร้างเว็บที่เปิดให้คนทั่วไปเข้ามาสมัครสมาชิกและชำระเงินได้ ต้องอาศัยบริการหลายส่วนประกอบกัน ซึ่งแต่ละส่วนก็มี Provider หรือผู้ให้บริการภายนอกและบัญชีแยกจากกันอย่างชัดเจน โดยในเวอร์ชันปัจจุบัน golive-skill ผ่านการทดสอบใช้งานร่วมกับบัญชีจริงมาแล้ว ดังนี้

บริการเหล่านี้ไม่ได้ทำงานแยกกันอย่างอิสระ เมื่อสร้างฐานข้อมูลเสร็จเรียบร้อย ค่าเชื่อมต่อทั้งหมดต้องส่งไปตั้งค่าไว้ที่ฝั่ง Hosting ในรูปของตัวแปรสำหรับตั้งค่าระบบอย่าง Environment Variable ให้ครบถ้วนเพื่อให้แอปทำงานได้ ซึ่ง golive จะช่วยจัดการส่งต่อค่าเหล่านี้ให้ทั้งหมด และผ่านการทดสอบใช้งานจริงแล้วเช่นกัน

สำหรับระบบชำระเงิน เวอร์ชันนี้ยืนยันผลแล้วเฉพาะในโหมดทดสอบหรือ Test mode ของ Stripe เท่านั้น คือทดลองชำระเงินด้วยบัตรทดสอบ แล้วตรวจสอบว่าแอปได้รับข้อความแจ้งเตือนอัตโนมัติผ่านระบบ Webhook จาก Stripe พร้อมตรวจยืนยันลายเซ็นดิจิทัลว่าส่งมาจาก Stripe จริง ส่วนการรับเงินจริง การทำเรื่องคืนเงิน และระบบเก็บเงินแบบสมาชิกรายเดือน ยังรอการทดสอบอยู่

golive ทำงาน 5 ขั้นตอน และหยุดรอเราอนุมัติเสมอ

ลองนึกภาพว่าเรามีแอปที่ใช้ Supabase เป็นฐานข้อมูลอยู่แล้ว และเราสั่งให้ Agent ใช้ golive พาแอปนี้ขึ้นเว็บ โดยระบุว่าให้ใช้ทรัพยากรสำหรับทดสอบไปก่อน (เช่น สร้างโปรเจกต์หรือฐานข้อมูลชั่วคราวที่ลองเสร็จแล้วลบทิ้งได้) การทำงานจะแบ่งออกเป็น 5 ขั้นตอนดังนี้

detect: ตรวจสอบสิ่งที่แอปมีอยู่แล้ว

Agent จะเริ่มจากการสแกนโค้ดในโปรเจกต์ เมื่อพบว่าแอปเขียนมาเพื่อใช้ Supabase อยู่แล้ว ก็จะยึดค่านั้นไว้ตามเดิม แล้วถามเฉพาะส่วนที่ยังขาดอยู่ ในตัวอย่างนี้คือถามว่าต้องการนำเว็บไปวางไว้ที่ Hosting ไหน โดยมีตัวเลือกเป็น Vercel, Netlify หรือจะระบุชื่อผู้ให้บริการอื่นเองก็ได้ จากนั้นจะถามต่อว่าจะใช้โปรเจกต์ Supabase ที่มีอยู่แล้ว หรือต้องการให้สร้างโปรเจกต์ใหม่สำหรับทดสอบ

ก่อนจะเริ่มขั้นตอนถัดไป Agent จะให้เราเปิด Terminal ขึ้นมาอีกหน้าต่าง แล้วรันคำสั่ง vercel login และ supabase login ด้วยตัวเอง เพราะขั้นตอนการสมัครบัญชี การล็อกอินผ่านเบราว์เซอร์ การยืนยันตัวตน และการกดยืนยันชำระเงิน เป็นหน้าที่ที่เจ้าของบัญชีต้องทำเองเพื่อความปลอดภัย

plan: วางแผนและแสดงรายการทั้งหมดก่อนลงมือ

Agent จะสรุปแผนการทำงานทั้งหมดมาให้เราตรวจสอบ ตั้งแต่การสร้างโปรเจกต์เว็บทดสอบใน Team ของ Vercel ที่เราเลือก, การสร้างฐานข้อมูลใน Organization ของ Supabase ที่เรากำหนด, การนำค่า Environment Variables ที่แอปจำเป็นต้องใช้ทั้งหมดไปใส่ไว้ให้ครบ จนถึงขั้นตอนการสั่ง deploy

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

approve: ไม่แตะต้องบัญชีจริงจนกว่าเราจะอนุมัติ

Agent จะหยุดรอคำอนุมัติจากเราเสมอ และก่อนที่เราจะกดยืนยัน จะไม่มีอะไรเปลี่ยนแปลงในบัญชีจริงเลย นอกจากนี้ สำหรับการทำงานที่มีความเสี่ยงสูง 3 ด้าน ระบบยังบังคับให้ต้องระบุ flag เพิ่มอีกชั้น ได้แก่ การแก้ไขค่า DNS ต้องระบุ --confirm-dns, การทำงานที่เกี่ยวข้องกับเงินจริงต้องระบุ --confirm-live, และการสั่งลบระบบต้องระบุ --confirm-destroy

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

apply: ดำเนินการตามแผนด้วยบัญชีของเรา

เมื่อเรากดอนุมัติ Agent จะลงมือดำเนินการตามแผนนั้นโดยใช้สิทธิ์การล็อกอินของเราเอง ซึ่งในตัวอย่างนี้คือการสร้างโปรเจกต์ สร้างฐานข้อมูล ส่งค่าเชื่อมต่อไปยังฝั่ง Hosting และ deploy จนได้ URL ของเว็บไซต์จริงกลับมาให้เรา

verify: ตรวจสอบผลลัพธ์ รายงานชัดเจนว่าอะไรผ่านและอะไรยังไม่รู้ผล

ในขั้นตอนนี้ golive จะตรวจสอบเฉพาะสิ่งที่ตรวจวัดได้จริงในเชิงระบบ แล้วสรุปรายงานออกมาโดยแบ่งสถานะเป็น pass, fail, warning และ skipped พร้อมแนบรายการที่ผู้พัฒนาต้องไปจัดการต่อเอง สิ่งที่ระบบตรวจสอบได้ ได้แก่ สิทธิ์การเข้าถึงบัญชี, ชื่อของ Environment Variables ที่ต้องมี, การเชื่อมต่อไปยังฐานข้อมูล และ URL ที่ผู้ให้บริการยืนยันว่า deploy สำเร็จแล้ว

นอกจากนี้ ระบบยังช่วยสแกนหา API key ที่อาจหลุดไปอยู่ในโค้ด JavaScript ฝั่งหน้าเว็บหรือ Frontend เพราะจุดนี้ใครเปิดเว็บดูก็จะเห็นรหัสได้ทันที เหมือนกับปัญหาที่เคยเตือนไว้ในบทความเรื่อง API key ที่หลุดเพราะ AI ใส่ไว้ในโค้ด

สิ่งที่ต้องระวังคือ การ deploy สำเร็จไม่ได้แปลว่าตัวแอปจะทำงานได้ถูกต้องสมบูรณ์เสมอไป เพราะชื่อ Environment Variable อาจมีครบแต่ค่าที่ใส่ไว้ข้างในอาจผิด, โดเมนอีเมลที่ขึ้นสถานะว่ายืนยันแล้วก็ไม่ได้แปลว่าอีเมลจะส่งถึงกล่องจดหมายจริง และผลที่ขึ้นว่า skipped ก็ไม่ได้แปลว่าทำงานผ่าน เมื่อจบกระบวนการ Agent จึงส่ง URL รายงานผล และรายการที่ระบบยังตรวจวัดไม่ได้มาให้ เพื่อให้เราเข้าไปทดสอบระบบสมัครสมาชิกและระบบบันทึกข้อมูลของแอปด้วยตัวเองต่อไป

ตัวอย่างกรณีนี้มีบันทึกอยู่ใน issue บน GitHub ของโปรเจกต์จริง เช่น บริการ Resend อาจรายงานว่าโดเมนสำหรับส่งอีเมลผ่านการยืนยันแล้ว ทั้งที่ค่า DNS record ยังไม่ได้อัปเดตไปยัง Nameserver ทำให้ผลตรวจ email-verified ของ golive แสดงสถานะว่าผ่าน แต่ในความเป็นจริง อีเมลที่ส่งออกจากโดเมนยังยืนยันตัวตนผู้ส่งไม่ได้

บัญชีเป็นของเรา และ API key ก็เก็บอยู่ในเครื่องเรา

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

นอกจากนี้ golive ยังออกแบบมาไม่ให้ API key หลุดเข้าไปในหน้าต่างแชทเลย บริการไหนที่มีระบบล็อกอินที่ golive รองรับอยู่แล้ว ตัวระบบจะนำ session การล็อกอินนั้นมาใช้งานต่อทันที แต่ถ้าบริการไหนจำเป็นต้องกรอก key บน macOS จะมีหน้าต่างป๊อปอัปแบบซ่อนตัวอักษรเด้งขึ้นมาให้กรอก พร้อมระบุชัดเจนว่าขอข้อมูลไปทำอะไรและจะนำไปบันทึกไว้ที่ไหน ส่วนบนระบบปฏิบัติการอื่น ตัวระบบจะเปิดโปรแกรม Editor ภายในเครื่องขึ้นมาให้กรอกแทน

ข้อมูลที่กรอกจะบันทึกลงในไฟล์ ~/.config/golive/credentials บนเครื่องของเราโดยตรง ไม่ปรากฏในประวัติการแชทและไม่แสดงในผลลัพธ์ของคำสั่ง อย่างไรก็ตาม สิ่งที่ควรทราบคือไฟล์นี้จัดเก็บข้อมูลเป็นข้อความธรรมดาที่ไม่ได้เข้ารหัส มีเพียงการตั้งค่าจำกัดสิทธิ์การอ่านไฟล์เอาไว้เท่านั้น

เมื่อเว็บขึ้นระบบแล้ว golive ยังมีอีก 3 คำสั่งที่ใช้ต่อได้

golive status ใช้ตรวจสอบว่ามีค่าใดเปลี่ยนแปลงไปจากเดิมหรือไม่ โดยจะนำค่าที่เคยบันทึกไว้ตอนตั้งค่าระบบ มาเปรียบเทียบกับค่าจริงที่อ่านได้จาก Provider ณ ปัจจุบัน ครอบคลุมตั้งแต่ค่า DNS record ที่เคยตั้งไว้ ไปจนถึงชื่อ Environment Variables ที่ส่งไป คำสั่งนี้ทำหน้าที่แค่อ่านข้อมูลเท่านั้น ไม่เข้าไปแก้ไขระบบเอง และจะทำงานเฉพาะเวลาที่เราสั่งรันเท่านั้น ไม่ได้คอยมอนิเตอร์ระบบให้อยู่ตลอดเวลา

golive handoff --write ใช้สร้างเอกสารส่งมอบระบบชื่อ GOLIVE_HANDOVER.md เพื่อสรุปข้อมูลว่าใช้บริการของเจ้าไหนบ้าง ล็อกอินผ่านช่องทางใด สร้าง Resource อะไรไว้พร้อมหลักฐาน มีขั้นตอนใดที่ต้องทำต่อเอง งานใดที่ต้องทำซ้ำเป็นรอบๆ และมีวิธีลบระบบอย่างไร โดยข้อมูลแต่ละรายการจะระบุสถานะชัดเจนว่าเป็น verified, recorded, not verifiable หรือ unknown ไฟล์นี้ไม่มีข้อมูลลับอย่าง Secret บันทึกอยู่เลย แต่เนื้อหายังระบุถึง Resource ส่วนตัวของเรา จึงควรอ่านตรวจทานก่อนนำไปส่งต่อให้ผู้อื่น

golive teardown ใช้สั่งลบระบบ โดยจะวางแผนการลบมาให้เราอนุมัติก่อนเสมอ และจะเลือกลบเฉพาะ Resource ที่ golive ยืนยันได้ว่าตนเองเป็นผู้สร้างขึ้นเท่านั้น โดยต้องใส่ flag --confirm-destroy ควบคู่กันจึงจะเริ่มลบจริง และหลังจากลบแล้ว ระบบจะอ่านค่า DNS ของโดเมนซ้ำเพื่อยืนยันว่าลบ record ออกไปแล้วจริงๆ อย่างไรก็ตาม มีบางอย่างที่ golive จะไม่ลบให้ นั่นคือโปรเจกต์บน Supabase หรือ Neon รวมถึงโดเมนส่งอีเมลบน Resend ซึ่งถ้าเราไม่เข้าไปลบด้วยตัวเองในหน้า Dashboard ของบริการเหล่านั้น ทรัพยากรเหล่านี้ก็จะยังค้างอยู่ในบัญชีต่อไป

ควรเลือกคู่ Provider ที่ผ่านการทดสอบจริงแล้วเป็นหลัก

ปัจจุบัน golive-skill ยังอยู่ในช่วงพัฒนาขั้นต้นหรือ Early Alpha (เวอร์ชัน 0.1.0-alpha.3) คำว่า "ผ่านการทดสอบจริงแล้ว" ในตารางข้างต้น หมายถึงคู่ Provider ที่ทีมพัฒนานำไปรันด้วยกันบนบัญชีจริง ทั้งสร้างและลบทิ้งเรียบร้อยแล้ว ไม่ได้แปลว่าจับคู่บริการแบบไหนก็จะได้ผลที่เสถียรเท่ากันทั้งหมด

ถ้าแอปของคุณใช้ Supabase อยู่แล้ว คู่ที่ผ่านการทดสอบจริงมาอย่างละเอียดคือ Vercel กับ Supabase ซึ่งครอบคลุมตั้งแต่การสร้างโปรเจกต์, การผูก Environment Variables, การ deploy ไปจนถึงการทดสอบว่าผู้ใช้ที่ล็อกอินแล้วสามารถจัดการข้อมูลและเห็นเฉพาะข้อมูลตามสิทธิ์ของตนเองได้จริง สำหรับใครที่ยังไม่ได้เลือกฐานข้อมูล คู่ระหว่าง Netlify กับ Neon ก็เป็นอีกทางเลือกที่ผ่านการทดสอบจริงแล้วเช่นกัน แต่ถ้าเป็นการจับคู่ข้ามค่าย เช่น Netlify กับ Supabase ในตอนนี้ยังทดสอบเพียงแค่ในระบบจำลองเท่านั้น ยังไม่มีผลการรันจริงมารับรองเทียบเท่ากับสองคู่หลัก

ถ้าเลือกใช้ Provider นอกเหนือจากรายการที่รองรับ golive จะพาทำผ่านขั้นตอนแนะนำทีละขั้นแบบ Guided flow คือตรวจสอบก่อนว่าบริการนั้นมีช่องทางให้เรียกใช้ได้หรือไม่ ทั้ง CLI, MCP หรือ official API ถ้ายังไม่พอก็จะแนะนำให้เราเข้าไปตั้งค่าต่อบน Dashboard ของบริการนั้นด้วยตัวเอง โดยขั้นตอนการวางแผนและการขออนุมัติยังคงมีอยู่ครบถ้วน แต่จะเป็นการช่วยอำนวยความสะดวกเท่าที่ทำได้ ไม่รับประกันว่าจะเสร็จสมบูรณ์หรือตรวจสอบผลได้ละเอียดเท่ากับ Provider ที่รองรับในตัว ถ้าติดขัดตรงไหน ระบบจะแจ้งเตือนว่าติดปัญหาอะไรและแนะนำขั้นตอนต่อไปให้ ซึ่งสามารถเข้าไปดูรายละเอียดระดับการรองรับของแต่ละบริการได้ที่หน้า Provider scope

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

วิธีติดตั้ง golive-skill และการเริ่มสั่งงานครั้งแรก

ก่อนเริ่มต้นใช้งาน เครื่องของคุณต้องมี Node.js เวอร์ชัน 20 ขึ้นไป, npm/npx และ Git ให้พร้อม ส่วน Agent ที่ใช้ต้องรองรับการโหลดสกิลและสั่งรันคำสั่งภายนอกได้ ซึ่งปัจจุบันผ่านการทดสอบและยืนยันการติดตั้งร่วมกับ Claude Code และ Codex แล้ว (Agent ตัวอื่นๆ ยังไม่ได้ทดสอบ)

การติดตั้งผ่าน Skills CLI ทำได้ด้วยคำสั่งเดียวจากโฟลเดอร์ใดก็ได้ และติดตั้งครั้งเดียวจะใช้งานได้กับทุกโปรเจกต์:

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global

ระหว่างติดตั้ง ระบบจะแสดงหน้าต่างให้เลือก Agent โดยใช้ปุ่มลูกศรเลื่อน กด Spacebar เพื่อเลือก แล้วกด Enter เพื่อยืนยัน (หน้าต่างนี้กำลังรอให้เรากดเลือก ไม่ได้ค้าง)

ถ้าต้องการติดตั้งสกิลไว้ใช้งานเฉพาะในโปรเจกต์ปัจจุบัน ให้เปิดโฟลเดอร์ของโปรเจกต์นั้น แล้วรันคำสั่งเดิมโดยตัด --global ออก

นอกจากนี้ ยังมีอีกวิธีคือติดตั้งผ่าน แพ็กเกจ golive บน npm โดยตรง ซึ่งวิธีนี้ไม่จำเป็นต้องผ่าน Git หรือ Skills CLI:

npx golive@alpha install --agent claude

ถ้าใช้งาน Codex ให้เปลี่ยนจาก --agent claude เป็น --agent codex โดยคำสั่งนี้จะติดตั้งลงในโปรเจกต์ที่เปิดอยู่ แต่ถ้าต้องการให้ใช้งานได้กับทุกโปรเจกต์ ให้ใส่ --global ต่อท้ายคำสั่งได้เช่นกัน

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

เมื่อติดตั้งเรียบร้อยแล้ว ให้เปิดโปรเจกต์แอปของคุณใน Agent (ถ้ายังมองไม่เห็นสกิล golive ให้ลองรีโหลดสกิลหรือเปิดเซสชันใหม่) จากนั้นพิมพ์คำสั่งนี้ลงในช่องแชท:

/golive Help me take this app live.

ถ้าใช้งาน Codex ให้พิมพ์ขึ้นต้นด้วย $golive แทน /golive

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

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

Use golive to take this app live. Use test resources for now.

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

ที่มา: โปรเจกต์ golive-skill บน GitHub