ปัญหาต่าง ๆ ของคุณอยู่ใน GitHub อยู่แล้ว เช่นเดียวกับโค้ด รีวิว pull request และกฎของ branch ที่ทีมใช้เวลาทั้งไตรมาสกว่าจะตกลงกันได้ ไม่มีใครอยากได้บอร์ดที่สองที่ต้องคอยซิงก์กับบอร์ดแรก สิ่งที่ขาดไปคือวิธีส่ง issue เหล่านั้นให้ coding agent ทำงาน แล้วได้ pull request กลับมาที่พร้อมรีวิว โดยไม่ต้องออกจาก repo ต้นทาง
นั่นคือสิ่งที่การเชื่อมต่อ GitHub เข้ากับ Sharkly ทำได้ Sharkly เป็นแพลตฟอร์มสั่งการและจัดการ Agent แบบครบวงจร: เปลี่ยน GitHub issue ให้กลายเป็น Task ที่มอบหมายได้ ส่งต่อไปยัง coding agent (Claude Code, Codex, Gemini หรือ Runtime ใดก็ตามที่ทีมของคุณใช้) ลงมือทำงานบน Computer ใน worktree ที่แยกออกมา และส่งผลลัพธ์กลับมาเป็น pull request ที่คุณรีวิวตามปกติ มีสองเรื่องที่สำคัญที่สุดตรงนี้: ใครกันแน่ที่มีสิทธิ์แตะ repository และตรงไหนที่มนุษย์ยังต้องเป็นคนอนุมัติ
วงจรทั้งหมดในประโยคเดียว
เชื่อมต่อ GitHub ผูก repository เข้ากับ Space และ issue ใหม่จะกลายเป็น Task มอบหมายให้ Agent แล้วสัญญาเดียวกันนี้ใช้ได้ทุกที่ใน Sharkly: Agent จะค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนเป็นผู้รีวิว diff และตัดสินใจว่าอะไรควรถูก merge
การเชื่อมต่อสองแบบ และทำไมมันไม่เหมือนกัน
การผสานรวมกับ GitHub มีสองชั้น และการสับสนระหว่างสองชั้นนี้คือหนทางที่เร็วที่สุดที่จะไม่เข้าใจว่าใครมองเห็นอะไรได้บ้าง
ชั้นแรกคือการเชื่อมต่อระดับองค์กร Organization Owner หรือ Admin เปิด Integrations หา GitHub แล้วติดตั้ง GitHub App ให้เข้าถึง repository ที่ควรเห็น การเชื่อมต่อนี้เองที่ทำให้การเชื่อม pull request และคอมเมนต์ linkback เป็นไปได้ สมาชิกแต่ละคนก็เชื่อมบัญชี GitHub ส่วนตัวได้เช่นกัน แต่ผลลัพธ์คือแค่เปลี่ยนว่าชื่อใครจะปรากฏบนคอมเมนต์ที่ซิงก์มา ไม่ได้เปลี่ยนสิ่งที่การเชื่อมต่อระดับองค์กรทำอยู่แล้ว
ชั้นที่สองคือการผูก repository ตัวใดตัวหนึ่งเหล่านั้นเข้ากับ Space เมื่อทำแล้ว GitHub issue ใหม่จะเริ่มปรากฏเป็น Task ส่วน issue ที่มีอยู่เดิมจะไม่ถูกนำเข้า repository จะป้อนข้อมูลให้ Space แบบทางเดียวได้ (การเปลี่ยนแปลงของ issue ไหลเข้ามา แต่ไม่ไหลกลับ) หรือแบบสองทาง (issue กับ Task ซิงก์หากันทั้งสองทิศทาง) และ Space หนึ่งแห่งจะมี repository แบบสองทางได้ทีละหนึ่งตัวเท่านั้น ดังนั้นเลือกให้ดี
นี่คือเส้นแบ่งที่ทำให้คนสับสน: ทั้งหมดนี้ไม่ใช่วิธีที่ Agent ได้สิทธิ์ clone โค้ดของคุณ การผสานรวมกับ GitHub ครอบคลุมการเชื่อม pull request การซิงก์ issue และคอมเมนต์ linkback เท่านั้น ไม่ได้ให้สิทธิ์อ่านหรือเขียน repository แก่ Agent ใด ๆ
ให้สิทธิ์เข้าถึงโค้ดกับ Agent แยกต่างหาก
การเข้าถึงโค้ดเป็นการตั้งค่าแยกต่างหาก กำหนดที่ Agent หรือที่ Space ไม่ใช่ที่การเชื่อมต่อ GitHub Agent ที่ไม่มี repository เป็นของตัวเองจะใช้ค่าที่ตั้งไว้ใน Space ของ Task นั้นแทน เมื่อ Agent ควรแตะโค้ดเบสเดียวจากหลาย ๆ ตัวที่ Space อ้างอิงถึง ก็ให้จำกัดรายการนั้นที่ตัว Agent เอง
ไม่ว่าจะแบบไหน การรันก็ยังต้องมีสิทธิ์การเข้าถึง Git ที่ใช้งานได้บน Computer นั้นเอง ไม่ว่าจะเป็น SSH key, HTTPS token หรือ credential ของโฮสต์ที่ตั้งไว้แล้ว การเชื่อมต่อระดับองค์กรไม่ได้จัดหาและไม่ได้แทนที่สิ่งเหล่านั้น ถ้าการรัน clone ไม่ได้ นั่นคือปัญหาของ Computer ไม่ใช่การตั้งค่า GitHub App
มอบหมาย issue ให้ Agent
เมื่อผูก repository แล้ว GitHub issue ใหม่จะเข้ามาเป็น Task (Issue, Bug, Feature และ Ticket ล้วนเป็นประเภท Task ที่ใช้ได้ ขึ้นอยู่กับว่า Space ของคุณใช้แบบไหน) การมอบหมายให้ Agent ก็ทำเหมือนการมอบหมายให้เพื่อนร่วมทีม: เปิดตัวควบคุม Assignee แล้วเลือก Agent แทน
Agent คือชุดการตั้งค่าการทำงานที่บันทึกไว้ ไม่ใช่พรอมป์ต์ครั้งเดียวจบ: คำสั่ง Runtime, repository และการตั้งค่าการรันของมันเป็นตัวกำหนดรูปแบบงาน เหมือนกับที่คำบรรยายหน้าที่กำหนดว่าพนักงานใหม่จะทำอะไร ถ้า Task ตกลงไปอยู่ใน Backlog ก็ยังไม่มีการรันอะไร นั่นคือที่พักชั่วคราว ย้ายมันไปยังสถานะที่ถือว่ากำลังทำงาน แล้ว Sharkly จะส่งงานไปรันเมื่อ Computer และ Runtime พร้อม
เมื่อ Agent สองตัวแตะ repository เดียวกัน
นี่คือส่วนที่ทีมกังวลมากที่สุด โหมดเริ่มต้นคือ Temporary: Task แต่ละอันได้ไดเรกทอรีที่แยกออกมา และการรันที่อิงกับ repository จะเตรียม worktree ใหม่ให้ Agent สองตัวที่ทำ issue ต่างกันใน repository เดียวกันจะได้ checkout ของตัวเอง ไม่ใช่ใช้ร่วมกัน จึงเขียนทับไฟล์ของกันและกันหรือแย่ง branch กันไม่ได้ แม้จะอยู่บน Computer เครื่องเดียวกันก็ตาม นี่คือวินัยแบบเดียวกับที่อยู่เบื้องหลังการใช้ git worktrees กับ AI coding agentsด้วยมือ เพียงแต่เป็นแบบอัตโนมัติ
การทำงานพร้อมกันมีเพดานของตัวเอง การรันแบบ Temporary มีค่าเริ่มต้นอยู่ที่ประมาณครึ่งหนึ่งของขีดจำกัดโดยรวมของ Computer ถ้าปรับขึ้นเอง ผลิตภัณฑ์จะเตือนเมื่อค่าที่ตั้งเกินความจุไดเรกทอรีที่มี ซึ่งเป็นจุดที่การชนกันเริ่มเกิดขึ้นจริง นอกจากนี้ยังมีโหมด Specified ที่ Agent ใช้ไดเรกทอรีคงที่หนึ่งแห่งซ้ำแทนการสร้าง worktree ใหม่ แต่โหมดนี้รองรับการรันได้ครั้งละหนึ่งงาน จึงเหมาะน้อยกว่าสำหรับ repository ที่มี Agent หลายตัวแตะพร้อมกัน
สิ่งที่ได้กลับมา: pull request
เมื่อ Agent เปิด pull request คุณเชื่อมมันเข้ากับ Task ได้โดยเขียน Task ID ลงในชื่อ branch ชื่อเรื่อง หรือเนื้อความ อย่างใดอย่างหนึ่งในสามอย่างนี้ก็เพียงพอ ID เปล่า ๆ อย่าง SH-312 ก็ใช้ได้เหมือนกับ Fixes SH-312 เพราะไม่มีการจัดการพิเศษสำหรับคำอย่าง fixes, closes หรือ skip บน repository สาธารณะ เฉพาะผู้เขียนที่เชื่อถือได้ เจ้าของ สมาชิก หรือ collaborator เท่านั้นที่จะถูกเชื่อม ดังนั้น pull request จากคนแปลกหน้าจึงปลอมแปลงเพื่อเข้ามาเกาะ Task ของคุณไม่ได้
pull request ที่เชื่อมแล้วยังได้รับคอมเมนต์ linkback ที่ชี้กลับไปยัง Task ได้ด้วย ค่าเริ่มต้นคือเปิดสำหรับ repository ส่วนตัว และปิดสำหรับ repository สาธารณะ เป็นสวิตช์ที่อยู่ใน GitHub settings แยกต่างหากจากว่า Space เองจะเป็นสาธารณะหรือส่วนตัว
ด่านรีวิว: จุดที่การตัดสินใจอยู่
การ merge pull request ไม่เปลี่ยนสถานะของ Task และไม่เกิดขึ้นเองโดยอัตโนมัติ นี่เป็นเจตนา สถานะของ Task กับสถานะการทำงานของ Agent ถูกติดตามแยกกัน ดังนั้น Task ที่เป็น Started ก็อาจแสดงเป็น Working, Waiting for human reply, Waiting for human review หรือ Error ได้ และสัญญาณเหล่านี้จะปรากฏใน Inbox ให้คนที่รับผิดชอบเห็น การปิดหรือเปิด GitHub issue ต้นทางใหม่สามารถเปลี่ยนสถานะของ Task แบบสองทางได้ แต่การ merge pull request ทำไม่ได้
Agent จะค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนจะอ่าน diff เทียบกับ issue ต้นฉบับ ขอแก้ไขหรือยอมรับ และตัดสินใจเรื่อง merge กับ release ด้วยตัวเอง การแบ่งหน้าที่นี้ใช้ตลอดทั้งกระบวนการ บน GitHub ก็เหมือนกับที่อื่น ๆ ใน Sharkly: ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้วิจารณญาณของทีมพอดี สำหรับกลไกเชิงลึก เวิร์กโฟลว์รีวิวแบบ human-in-the-loop ของ Sharklyอธิบายไว้โดยตรง
เมื่อ agent hub ของ GitHub เองก็เพียงพอ
ถ้าทีมของคุณใช้ GitHub ล้วน ๆ ทั้ง source, CI, review และที่นั่ง Copilot แบบเสียเงิน Agent HQ ของ GitHub เองก็ประสานงาน Agent ภายในระบบนิเวศนั้นได้ดี และคุณอาจไม่ต้องใช้อะไรเพิ่ม เหตุผลที่จะใช้ Sharkly จะปรากฏขึ้นเมื่องานต้องผ่าน Jira ด้วย เมื่อ Agent รันบน Computer นอกคลาวด์ของ GitHub หรือเมื่อทีมของคุณใช้ Runtime หลายแบบปนกันและไม่อยากสร้างเวิร์กโฟลว์ใหม่ทุกครั้งที่ตัวที่ดีที่สุดเปลี่ยนไป ถ้า Jira เป็นส่วนหนึ่งของการผสมนี้ การมอบหมาย Jira ticket ให้ AI Agentจะพาคุณเดินวงจรเดียวกันจากฝั่งนั้น
ถ้าอยากลองกับ issue จริงสักหนึ่งอัน: เปิดการผสานรวม GitHub, Jira และ Slack ของ Sharkly เชื่อมต่อองค์กร GitHub ของคุณ ผูก repository ที่มีทราฟฟิกต่ำสักหนึ่งตัวเข้ากับ Space แล้วมอบหมาย issue เล็ก ๆ อันถัดไปให้ Agent แทนตัวเอง
คำถามที่พบบ่อย
การเชื่อมต่อองค์กร GitHub ของฉันให้ Agent เข้าถึงโค้ดหรือไม่? ไม่ การเชื่อมต่อระดับองค์กรครอบคลุมการเชื่อม pull request การซิงก์ issue และคอมเมนต์ linkback เท่านั้น การเข้าถึงโค้ดตั้งค่าแยกต่างหากที่ Agent หรือที่ Space และการรันก็ยังต้องมี Git credential ของตัวเองบน Computer
Agent สองตัวที่ทำ repository เดียวกันจะชนกันไหม? ไม่ ในโหมด Temporary ซึ่งเป็นค่าเริ่มต้น การรันแต่ละครั้งได้ worktree ที่แยกออกมา จึงไม่มี Agent ที่ทำงานพร้อมกันแชร์สำเนาการทำงานเดียวกัน แม้จะอยู่บน Computer เครื่องเดียวกัน
การ merge pull request จะปิด GitHub issue หรือ Task ไหม? การ merge ไม่เปลี่ยนสถานะของ Task ด้วยตัวเอง ส่วนการปิด GitHub issue ต้นทางทำได้ ในกรณีที่ repository ซิงก์แบบสองทาง แต่นั่นเป็นการกระทำที่แยกจากการ merge PR
pull request ของ Agent ตั้งเป้าไปที่อะไรกันแน่? Sharkly เชื่อม pull request ด้วย Task ID ในชื่อ branch ชื่อเรื่อง หรือเนื้อความ แล้วแต่ว่า Runtime ของคุณเขียนอะไรลงไป มันไม่ได้กำหนดกลยุทธ์เรื่อง branch ฉะนั้นตรวจสอบพฤติกรรม base branch เริ่มต้นของ Runtime ก่อนมอบหมายอะไรที่เดิมพันสูงกว่า issue ทดสอบ
เก็บ GitHub issue เดิมไว้ได้ไหม ไม่ใช่แค่ issue ใหม่? การผูก repository จะซิงก์ issue ที่สร้างขึ้นใหม่ต่อจากนี้ไป ส่วน issue ที่มีอยู่เดิมจะไม่ถูกนำเข้าโดยอัตโนมัติ
