Skills ใน Sharkly: เปลี่ยนทักษะการเขียนพรอมป์ของนักพัฒนาคนเดียวให้เป็นโครงสร้างพื้นฐานระดับทีม

ทุกทีมที่นำ AI coding agent มาใช้ย่อมมีนักพัฒนาอยู่หนึ่งคนที่พรอมป์ต์ของเขาทำงานได้ผลเสมอ คำขอรีวิวที่ส่งออกไปได้ผลลัพธ์กลับมาในโครงสร้างที่ทีมชอบ คำสั่งสำหรับเขียนเทสต์ให้ผลลัพธ์เป็นเทสต์ที่ตรงตามสไตล์ของทีมตั้งแต่ครั้งแรก ถ้าถามเขาว่าทำได้อย่างไร คำตอบมักเป็นไฟล์ทดลองสักไฟล์ รีโป dotfiles หรือย่อหน้าหนึ่งที่เขาแปะลงในเซสชันใหม่ทุกเช้า ฝีมือนี้มีอยู่จริง ปัญหาอยู่ที่ว่ามันถูกเก็บไว้ที่ไหน

ฝีมือการเขียนพรอมป์ต์ที่อยู่ในหัวของคนเพียงคนเดียวขยายไม่ได้ ไม่รอดช่วงลาพักร้อน และไม่ปรากฏในการทำงานของ agent ของคนอื่นเลย เมื่อนักพัฒนาคนนั้นไม่อยู่ คุณภาพก็ตก เมื่อทีมขยายจาก agent หนึ่งตัวเป็นห้าตัว ทั้งห้าก็ไม่เห็นตรงกันว่าควรทำงานอย่างไร

Skills คือคำตอบของ Sharkly สำหรับช่องว่างนี้ Skill คือการแพ็กคำสั่งที่นำกลับมาใช้ซ้ำได้ พร้อมไฟล์ประกอบสำหรับงานของ Agent โดยมีเจ้าของ มีขอบเขต และมีการระบุสิทธิ์อย่างชัดเจน ถ้าอยากเข้าใจแนวคิดภาพรวมก่อน coding agent Skill คืออะไร อธิบายคำจำกัดความและระบบนิเวศที่กว้างกว่าไว้แล้ว ส่วนโพสต์นี้จะพูดถึงเวิร์กโฟลว์ภายใน Sharkly เอง

สรุปสั้น ๆ

Skill ใน Sharkly คือการแพ็กคำสั่งที่นำกลับมาใช้ซ้ำได้พร้อมไฟล์ประกอบสำหรับงานของ Agent ไม่ว่าจะเป็นกฎการรีวิว เช็กลิสต์การส่งมอบ มาตรฐานการเขียน หรือกระบวนการของทีม คุณจะสร้างขึ้นใหม่ตั้งแต่ต้น ติดตั้ง Skill ที่เผยแพร่แล้วจากแหล่งสาธารณะที่รองรับ นำเข้าจาก Skill ที่ตรวจพบโดย Runtime ภายในเครื่อง หรืออัปโหลดไฟล์ SKILL.md, ไฟล์ .skill หรือแพ็กเกจ zip ทุก Skill มีขอบเขตเพียงหนึ่งเดียวเท่านั้น จะเป็น Organization, Space หรือ Agent ซึ่งเลือกตอนสร้างและคงที่ตลอดไป Agent จะผูก Skill ที่มีสิทธิ์ผ่านการตั้งค่า Skills ของตัวเอง การเปลี่ยนแปลงมีผลกับการรันครั้งถัดไป และสิทธิ์ในการแก้ไขยังอยู่กับผู้สร้าง, Organization Owner และ Admin ผลลัพธ์คือ ฝีมือการเขียนพรอมป์ต์จะไม่ถูกเก็บไว้ใน dotfiles ของนักพัฒนาคนใดคนหนึ่งอีกต่อไป แต่กลายเป็นโครงสร้างพื้นฐานของทีมที่แชร์ร่วมกันและควบคุมด้วยสิทธิ์

อะไรเปลี่ยนไปเมื่อฝีมือการเขียนพรอมป์ต์มีที่อยู่เป็นหลักแหล่ง

ความต่างระหว่างพรอมป์ต์ที่ดีกับ Skill ไม่ได้อยู่ที่ตัวข้อความ แต่อยู่ที่ทุกสิ่งรอบ ๆ ข้อความนั้น

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

นี่คือแนวคิดเรื่องพลังทวีคูณของทีมในฉบับย่อ พลังทวีคูณของทีมไม่ได้มาจากการเปิดแชท AI เพิ่มขึ้น แต่มาจากการแชร์บทบาท กฎ บริบท และเวิร์กโฟลว์ และเนื่องจาก Agent ส่งผลลัพธ์กลับไปที่ Task ผลลัพธ์จากการรันที่ขับเคลื่อนด้วย Skill จึงไปอยู่ในบันทึกที่แชร์ร่วมกันซึ่งทีมสามารถรีวิวได้

มีข้อควรแยกแยะหนึ่งอย่างก่อนเข้าสู่เวิร์กโฟลว์ Skill ไม่ใช่ข้อกำหนดของ Task ให้เก็บความต้องการแบบใช้ครั้งเดียวไว้ในคำอธิบายหรือคอมเมนต์ของ Task ถ้ามีแค่ Task นี้ที่ต้องใช้ มันคือบริบท แต่ถ้าการรันในเดือนหน้าก็ต้องใช้ด้วย มันคือโครงสร้างพื้นฐาน

การสร้าง Skill ขึ้นมาใหม่ตั้งแต่ต้น

Skill เริ่มต้นจากสามสิ่ง ได้แก่ ชื่อ คำอธิบาย และคำสั่ง การแยกส่วนนี้สำคัญกว่าที่คิด

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

เบื้องหลังนั้น คำสั่งหลักจะอยู่ในไฟล์ SKILL.md โดยมีฟิลด์ YAML name และ description อยู่ด้านบน ตามด้วยคำสั่งต่าง ๆ ไฟล์ประกอบสามารถแนบไปด้วยได้เพื่อให้เทมเพลต ตัวอย่าง หรือข้อมูลอ้างอิง Skill สำหรับเช็กลิสต์การส่งมอบอาจมีเทมเพลตเช็กลิสต์ติดมาด้วย ส่วน Skill สำหรับเขียน migration อาจมีตัวอย่างที่ใส่คำอธิบายประกอบไว้สองตัวอย่าง ให้ไฟล์เหล่านี้มีจุดโฟกัส เพราะคอลเลกชันไฟล์ที่ใหญ่เกินไปหรือไม่เกี่ยวข้องจะเพิ่มบริบทโดยไม่ได้ช่วยให้ Agent ตัดสินใจได้ดีขึ้น

การนำเข้าฝีมือที่คุณมีอยู่แล้ว

ทีมส่วนใหญ่ไม่ได้เริ่มจากศูนย์ ฝีมือการเขียนพรอมป์ต์มีอยู่แล้ว เพียงแต่กระจัดกระจายอยู่ Sharkly จึงมีเส้นทางการนำเข้าให้สามทาง

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

นำเข้าจาก Runtime ภายในเครื่อง นี่คือเส้นทางที่สร้างมาเพื่อแก้ปัญหา dotfiles โดยเฉพาะ Runtime ภายในเครื่องที่ออนไลน์อยู่สามารถรายงาน Skill ที่ตรวจพบในไดเรกทอรี Skill ภายในเครื่องได้ ซึ่งหมายความว่าฝีมือที่นักพัฒนาเก็บสะสมไว้เงียบ ๆ จะกลายเป็นสิ่งที่องค์กรมองเห็น การนำเข้าจะคัดลอก Skill เข้าสู่องค์กร ส่วนสำเนาในเครื่องเดิมยังแยกออกจากกัน ดังนั้นการตั้งค่าของนักพัฒนาคนนั้นจะไม่พัง มีข้อควรระวังหนึ่งอย่างที่ช่วยให้เรื่องนี้ตรงไปตรงมา: Skill ภายในเครื่องที่ Agent เข้าถึงได้โดยตรงผ่าน Runtime ไม่จำเป็นต้องผูกในตัวผลิตภัณฑ์เลย ให้นำเข้าเมื่อมันควรกลายเป็น Skill ที่จัดการได้ ใช้ซ้ำได้ และมีขอบเขตชัดเจน ไม่ใช่แค่เพราะมันมีอยู่

อัปโหลดแพ็กเกจ ถ้า Skill อยู่ในรีโปหรือได้มาจากเพื่อนร่วมงาน ให้อัปโหลดไฟล์ SKILL.md, ไฟล์ .skill หรือแพ็กเกจ zip Sharkly จะตรวจสอบสิ่งที่นำเข้า: พาธของไฟล์ต้องเป็นพาธสัมพัทธ์และต้องไม่ทะลุออกนอก Skill และการอัปโหลดและการนำเข้าจะปฏิเสธพาธที่ซ่อนอยู่หรือละเอียดอ่อน เนื้อหาไบนารีที่ไม่รองรับ รายการในไฟล์บีบอัดที่ไม่ปลอดภัย พาธซ้ำ และแพ็กเกจที่เกินขีดจำกัดของบริการ Skill คือคำสั่งที่ Agent จะปฏิบัติตาม มันจึงควรได้รับการตรวจสอบอย่างละเอียดพอ ๆ กับ dependency

ขอบเขต: ตัดสินใจว่าใครใช้ Skill ได้

ทุก Skill เป็นขององค์กรหนึ่งแห่ง และมีขอบเขตเพียงหนึ่งเดียวซึ่งเลือกตอนสร้าง ขอบเขตเป็นตัวกำหนดว่า Agent ตัวไหนผูกได้ และไม่สามารถเปลี่ยนแปลงภายหลังได้

หลักง่าย ๆ จากเอกสารคือสิ่งที่ถูกต้อง: เลือกขอบเขตที่แคบที่สุดซึ่งตรงกับกลุ่มเป้าหมายที่ตั้งใจไว้ ขอบเขตยังเป็นรัศมีผลกระทบด้วย Skill ที่ผูกกับ Space ซึ่งล้าสมัยจะสร้างความสับสนให้ Agent ของทีมเดียว แต่ถ้าผูกกับ Organization ก็จะสร้างความสับสนให้ทั้งหมด พรอมป์ต์ใน dotfiles มีกลุ่มเป้าหมายเพียงคนเดียวตลอดกาล ส่วนกลุ่มเป้าหมายของ Skill คือการตัดสินใจที่ตั้งใจและถูกบันทึกไว้ในระบบ

การผูก Skill กับ Agent

Skill จะไม่ทำอะไรเลยจนกว่า Agent จะพกมันไว้ ใน Sharkly Agent คือการตั้งค่าการทำงานที่บันทึกไว้ และการผูก Skill เข้าไปก็คือการเพิ่มความสามารถให้มัน

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

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

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

การผูกคือสิ่งที่ทำให้ส่วนอื่น ๆ ของแพลตฟอร์มทบต้นกัน Agent ตัวเดียวกับที่พก Skill การรีวิวของคุณ คือตัวเดียวกันกับที่ Automations ของคุณกระตุ้นตามกำหนดเวลาหรือตามการเปลี่ยนสถานะ ดังนั้นมาตรฐานที่บันทึกไว้ครั้งเดียวจะปรากฏในการรันซ้ำ ๆ ที่ไม่มีใครต้องสั่งด้วยมือ Skill ยังเขียนเป็นสคริปต์ได้ด้วย: CLI มีคำสั่ง sharkly skill list และ sharkly skill view พร้อมเอาต์พุตแบบ JSON

การกำกับดูแล: ใครแก้ไข ใครลบ ใครรีวิว

ความสามารถที่แชร์กันต้องมีการควบคุมที่แชร์กัน และนี่คือจุดที่ Skill ต่างจากไฟล์พรอมป์ต์มากที่สุด

Skill สามารถแก้ไขหรือลบได้โดยผู้สร้าง หรือ Organization Owner หรือ Admin ส่วน Skill ที่ผูกกับ Space ยังต้องมีสิทธิ์เขียนใน Space นั้นด้วย การสร้างหรือนำเข้า Skill ที่ผูกกับ Agent และการเปลี่ยนการผูก Skill ของ Agent ต้องมีสิทธิ์ในการจัดการ Agent เป้าหมาย ไม่มีใครแอบเขียนมาตรฐานการรีวิวใหม่ในบ่ายวันศุกร์ได้

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

กฎด้านความปลอดภัยสั้นและต่อรองไม่ได้ ห้ามเก็บรหัสผ่าน โทเคนการเข้าถึง คีย์ส่วนตัว หรือความลับอื่น ๆ ไว้ในคำสั่งหรือไฟล์ประกอบของ Skill เด็ดขาด ตรวจสอบทุก Skill ที่นำเข้าจากภายนอกหรือจากในเครื่องก่อนใช้งาน ให้คำสั่งและตัวอย่างมีสิทธิ์น้อยที่สุดเท่าที่จำเป็น และตรวจสอบการผูกซ้ำอีกครั้งหลังจากเปลี่ยนความเชื่อมโยง Space ของ Agent หรือเนื้อหาของ Skill เพราะความมีสิทธิ์อาจเปลี่ยนไปใต้การผูกที่มีอยู่

ตลอดทั้งหมดนี้ สัญญาระหว่างมนุษย์กับ agent ยังคงเดิม Agent โหลด Skill ทำตามกระบวนการ และส่งผลลัพธ์กลับไปที่ Task ส่วนคนเป็นผู้ตัดสินว่า Skill ใดควรได้รับอำนาจจากทีม Skill ยกมาตรฐานความสม่ำเสมอขึ้นมา แต่ไม่ได้แทนที่คนรีวิว

เมื่อใดที่ไม่ควรสร้าง Skill

Skill คือโครงสร้างพื้นฐาน และโครงสร้างพื้นฐานมีต้นทุนในการดูแล คู่การตัดสินใจที่ตรงไปตรงมาคือ: เก็บความต้องการแบบใช้ครั้งเดียวไว้ในคำอธิบายหรือคอมเมนต์ของ Task สร้าง Skill เมื่อความสามารถเดียวกันนั้นควรใช้ได้ในการรันครั้งต่อ ๆ ไป

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

เริ่มจากกระบวนการเดียว

เลือกกระบวนการหนึ่งที่ทีมทำซ้ำและแอบพึ่งพาคนคนเดียวอยู่เงียบ ๆ เขียนมันเป็น Skill แคบ ๆ หนึ่งอัน: ชื่อ คำอธิบายที่ระบุว่าเมื่อใดใช้ และคำสั่งที่นิยามกระบวนการกับผลลัพธ์ที่คาดหวัง กำหนดขอบเขตให้เป็น Space ของคุณ ผูกกับ Agent ตัวหนึ่ง มอบ Task จริงให้ Agent ตัวนั้น แล้วอ่านผลลัพธ์ที่ได้กลับมา

นั่นคือลูปทั้งหมด ฝีมือที่เคยอยู่ในหัวของนักพัฒนาคนเดียว ตอนนี้มีชื่อ มีขอบเขต มีเจ้าของ และมีที่ให้อัปเดตเพียงที่เดียว ถ้าคุณเพิ่งเริ่มใช้แพลตฟอร์ม ภาพรวม Sharkly อธิบายว่า Skill อยู่ร่วมกับ Task, Agent และ Computer อย่างไร และ เริ่มต้นใช้งาน Sharkly พาเดินผ่านการเชื่อมต่อครั้งแรกแบบครบขั้นตอน ส่วนเอกสาร Skills ครอบคลุมทุกกฎข้างต้นอย่างละเอียด

คำถามที่พบบ่อย

Skill ต่างจากคำสั่งของ Agent อย่างไร

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

เปลี่ยนขอบเขตของ Skill หลังสร้างแล้วได้ไหม

ไม่ได้ ขอบเขตของ Skill ถูกกำหนดตายตัวตั้งแต่สร้าง เมื่อกลุ่มเป้าหมายต้องเปลี่ยน ให้สร้าง Skill ใหม่ที่ขอบเขตเหมาะสมแล้วผูกใหม่กับ Agent ที่ต้องการ นี่คือเหตุผลที่เอกสารแนะนำให้เลือกขอบเขตที่แคบที่สุดซึ่งตรงกับกลุ่มเป้าหมายที่ตั้งใจไว้ตั้งแต่แรก

Skill ที่นำเข้ามาจะซิงก์กับต้นทางอยู่ไหม

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

การผูก Skill ใหม่จะกระทบ Task ที่ Agent กำลังรันอยู่ไหม

ไม่ การเปลี่ยนแปลงการผูก Skill ของ Agent มีผลกับการรันครั้งถัดไป งานที่ดำเนินอยู่แล้วจะเสร็จสิ้นภายใต้การตั้งค่าเดิมที่เริ่มไว้ และการรันครั้งถัดไปจะรับชุด Skill ที่อัปเดตแล้วไปใช้

การติดตั้ง Skill จากแหล่งสาธารณะปลอดภัยไหม

ปลอดภัยได้ หากมีการตรวจสอบ ให้ถือว่าทุก Skill ที่นำเข้าจากภายนอกหรือจากในเครื่องเป็นโค้ดหรือการตั้งค่าของบุคคลที่สาม: อ่านคำสั่งและไฟล์ประกอบก่อนผูก ให้คำสั่งมีสิทธิ์น้อยที่สุดเท่าที่จำเป็น และห้ามให้ความลับเข้าไปอยู่ใน Skill เด็ดขาด การตรวจสอบความถูกต้องตอนอัปโหลดของ Sharkly จะปฏิเสธพาธและรายการในไฟล์บีบอัดที่ไม่ปลอดภัย แต่การตัดสินใจว่าคำสั่งนั้นสมควรได้รับความไว้วางใจจากทีมของคุณหรือไม่ ยังเป็นเรื่องของคน