ถ้าคุณอยากมีแอปของตัวเองแต่ยังไม่รู้ว่าจะทำอะไร replica-skill เป็นชุดสกิลฟรีสำหรับผู้ช่วย AI อย่าง Claude ที่ชวนให้หาโจทย์จากสิ่งที่ผู้ใช้เกลียดในแอปที่มีคนยอมจ่ายเงินใช้อยู่แล้ว โจทย์ที่ดีจึงอาจซ่อนอยู่ในรีวิว 1 ดาวของแอปเหล่านั้นนี่เอง

สกิล ในที่นี้คือชุดคำสั่งที่สอนให้ Claude ทำงานเป็นขั้นตอน โดยโปรเจกต์นี้มีทั้งหมด 11 สกิล พัฒนาโดย Jake Schincariol ไม่ใช่ผลงานของบริษัท Anthropic เขาเผยแพร่โค้ดไว้บน GitHub แบบโอเพนซอร์สภายใต้สัญญาอนุญาต MIT ทุกคนนำไปใช้และปรับแก้ต่อได้ฟรีทันที โดยไม่ต้องสมัครสมาชิกและไม่ต้องใช้ API key

โปรเจกต์เวอร์ชัน 1.0 เพิ่งปล่อยออกมาเมื่อวันที่ 3 ตุลาคม 2026 และถึงวันที่ 5 ตุลาคม ก็มียอดกดดาวบน GitHub ไปแล้ว 451 ดาว

สกิลทั้ง 11 ตัวนี้จะพาเราไล่ไปตั้งแต่แกะว่าแอปเดิมทำอะไรได้บ้าง สร้างเวอร์ชันใหม่ของเราขึ้นมา ทดสอบหาบั๊ก ไปจนถึงนำขึ้นเว็บบนโดเมนของตัวเอง ฟังดูเหมือนเครื่องมือลอกแอป แต่คำสั่งของสกิลตัวที่ชื่อ entrepreneur กลับเริ่มต้นด้วยประโยคที่ตรงกันข้าม:

ถ้าเราสร้างแอปที่หน้าตาเหมือนตัวเดิมทุกปุ่ม คนที่จ่ายเงินให้แอปเดิมอยู่แล้วก็ไม่มีเหตุผลอะไรต้องย้ายมา สิ่งที่จะทำให้เขาย้ายมาได้ คือแอปที่แก้ปัญหาตรงจุดที่เขาบ่น ซึ่งเรื่องเหล่านั้นมีเขียนบอกไว้แล้วในรีวิว เป้าหมายของ replica-skill จึงไม่ได้หยุดอยู่แค่การลอกให้เหมือน แต่ไปต่อจนถึงการสร้างแอปที่แก้ปัญหาได้ดีกว่าเดิม ถ้าอยากอ่านเรื่องแนวนี้ต่อ มีบทความเรื่อง ditto.site ไว้ให้แล้ว

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

11 สกิลที่ส่งงานต่อกันในโฟลเดอร์ replica

สกิลทั้งหมดทำงานต่อเนื่องกันเป็นสาย โดยสกิลในขั้นถัดไปจะเปิดอ่านไฟล์ที่สกิลก่อนหน้าบันทึกไว้ในโฟลเดอร์ replica/ ของโปรเจกต์ เช่น เมื่อ recon แกะโครงสร้างแอปเสร็จ ก็จะเขียนตารางฟีเจอร์ลงไฟล์ replica/features.csv จากนั้น build ก็จะหยิบตารางนี้ไปไล่สร้างทีละรายการ แล้วทำเครื่องหมายรายการที่เสร็จแล้ว

ลำดับขั้นตอนทั้งหมดเรียงได้ดังนี้:

1. recon แกะว่าแอปเดิมมีหน้าจออะไรบ้าง ลำดับการใช้งานเป็นอย่างไร และใช้ข้อมูลอะไร
2. architect วางโครงสร้างระบบ เลือกเทคโนโลยี ออกแบบฐานข้อมูลและ API
3. design กำหนดแนวทางดีไซน์ ทั้งโทนสี ตัวอักษร ระยะห่าง และองค์ประกอบบนหน้าจอ โดยใช้ไฟล์ภาพของเราเอง
4. build สร้างแอปทีละหน้าจอตามผังที่ recon ทำไว้
5. backend สร้างระบบหลังบ้าน ทั้งระบบล็อกอิน ฐานข้อมูล ระบบรับเงิน และการเชื่อมต่อบริการภายนอก
6. test คลิกทดสอบทุกลำดับการใช้งานเพื่อค้นหาบั๊ก
7. diff เปรียบเทียบกับแอปเดิม ให้คะแนนความสมบูรณ์ แล้วระบุจุดที่ยังขาด
8. entrepreneur อ่านรีวิวจริงว่าผู้ใช้เกลียดอะไร แล้วเปลี่ยนเป็นแผนแก้ไขพร้อมกำหนดจุดยืนทางการตลาด
9. brand ตั้งชื่อใหม่และปรับภาพลักษณ์ทั้งหมดให้เป็นแบรนด์ของเราเอง
10. launch ทำหน้าขายสินค้า ตั้งราคา และเขียนเนื้อหาสำหรับหน้าร้านใน App Store
11. deploy นำแอปขึ้นระบบจริงบนโดเมนของเราเอง

จุดที่ชวนงงคือ entrepreneur อยู่ลำดับที่ 8 หลังสร้างและทดสอบระบบเสร็จแล้ว แต่จริงๆ แล้วเราเรียกใช้แต่ละสกิลแยกกันได้ โดยไม่ต้องรันเรียงครบทุกขั้นตอน

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

recon แกะระบบแอปโดยไม่แตะโค้ดต้นฉบับ

ก่อนเริ่มทำงาน recon จะถามเรา 3 เรื่อง คือ แอปอะไรบนแพลตฟอร์มไหน ต้องการแกะส่วนใดบ้าง และทำไปเพื่อใคร (เช่น ใช้ในธุรกิจตัวเอง เจาะกลุ่มเฉพาะ หรือทำเป็นสินค้าขาย) ถ้าเราไม่ได้เลือกว่าจะแกะส่วนไหน ระบบจะเริ่มศึกษาจากลำดับการใช้งานหลักที่ผู้ใช้ยอมจ่ายเงินให้ก่อน

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

แหล่งข้อมูลที่ recon ใช้ศึกษา เรียงจากแหล่งที่คุ้มค่าที่สุดลงไป มีดังนี้:

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

ทุกแถวในตารางแหล่งข้อมูลต้องมีลิงก์กำกับเสมอ ส่วนโค้ดของแอปเดิมไม่อยู่ในรายการเลย recon จะไม่อ่านและไม่บันทึกไฟล์ JavaScript ของแอป ไม่แกะไฟล์โปรแกรมออกมาดู และไม่ดักดูว่าแอปส่งข้อมูลอะไรไปหาเซิร์ฟเวอร์

recon จะเข้าถึงข้อมูลด้วยการเปิดอ่านเหมือนคนทั่วไป ไม่ใช่การดูดข้อมูลอัตโนมัติ ไม่ใช้บอตไล่เก็บข้อมูล ไม่ดาวน์โหลดไฟล์ทีละมากๆ ไม่วนลูปอัตโนมัติ และใช้ความเร็วเท่ากับที่คนอ่านจริง

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

ผลลัพธ์ที่ได้จากขั้นตอนนี้คือไฟล์ replica/recon.md ตาราง replica/features.csv และภาพหน้าจออ้างอิงในโฟลเดอร์ replica/screens/ (ซึ่งเก็บไว้เพื่อเทียบการจัดวางหน้าจอเท่านั้น จะไม่นำภาพไปใส่ในแอปจริง) นอกจากนี้ recon ยังประเมินขนาดและระยะเวลาของงานให้ด้วย:

• S ใช้เวลาราว 1 ช่วงสุดสัปดาห์
• M ใช้เวลาประมาณไม่กี่สัปดาห์
• L ใช้เวลาประมาณหนึ่งไตรมาส
• XL สเกลใหญ่เกินไป ให้ลดขอบเขตงานลงก่อน

entrepreneur เปลี่ยนเสียงบ่นในรีวิวเป็นแผนแก้

เก็บรีวิวจากไหน

เป้าหมายของ entrepreneur คือการเก็บรีวิวจริงให้ได้ 100 รีวิวขึ้นไปจากอย่างน้อย 3 แหล่งข้อมูล โดยเน้นอ่านรีวิวล่าสุดก่อน แหล่งข้อมูลที่คำสั่งระบุไว้มีดังนี้:

• App Store และ Google Play
• เว็บไซต์รีวิวซอฟต์แวร์ เช่น G2, Capterra และ Trustpilot โดยกรองดูรีวิว 1 ถึง 3 ดาวด้วย
• เว็บบอร์ด Reddit และผลค้นหาด้วยคำว่า X alternative เพื่อหาแอปทางเลือก หรือ switched from X เพื่อดูคนที่ย้ายมาจากแอปเดิม โดย X คือชื่อแอปเดิม
• Hacker News เว็บบอร์ดข่าวสารของคนสายเทค
• บอร์ดขอฟีเจอร์ของแอปเดิม เช่น Canny พร้อมดูจำนวนคะแนนโหวตของแต่ละคำขอ
• บันทึกการอัปเดตระบบของแอปเดิม เพื่อเช็กว่าเราไม่ได้เผลอไป "แก้" เรื่องที่เขาแก้ไปเรียบร้อยแล้ว

จุดที่พลาดง่ายคือคิดว่าต้องอ่านแค่รีวิว 1 ดาว แต่คำสั่งแนะนำให้อ่านรีวิว 3 และ 4 ดาวด้วย เพราะรีวิวแนว "ชอบนะ แต่ติดตรงที่…" มักมีไอเดียดีๆ สำหรับพัฒนาแอปซ่อนอยู่

ส่วนที่เราต้องลงแรงทำเองคือการเก็บรวบรวมรีวิว โดยต้องเปิดหน้ารีวิวในเบราว์เซอร์ อ่านเองเหมือนคนทั่วไป แล้วคัดลอกทีละรายการลงไฟล์ replica/reviews.csv ซึ่งมี 5 ช่องดังนี้:

source,url,date,rating,text

ในช่อง text ต้องคัดลอกข้อความรีวิวมาตรงๆ ทุกคำ ส่วนร้านแอปหรือเว็บรีวิวที่เงื่อนไขไม่อนุญาต ห้ามใช้โปรแกรมดูดข้อมูลเด็ดขาด ถ้าแหล่งไหนมีฟีดหรือ API ทางการให้ใช้ เช่น ฟีด RSS รีวิวของ App Store ก็นำมาใช้ได้ตามเงื่อนไขของแหล่งนั้น

จากรีวิวเป็นสามรายการ

เมื่อเตรียมไฟล์เสร็จแล้ว สคริปต์ reviews.py ที่มาพร้อมกับสกิลจะจัดกลุ่มรีวิวตามประเด็นที่คนบ่น แล้วบันทึกผลลงไฟล์ replica/feedback.md โดยรีวิวคะแนนต่ำและรีวิวใหม่จะได้น้ำหนักมากกว่า

สคริปต์ตัวนี้มีกฎเกณฑ์ที่เข้มงวด แถวไหนไม่มีลิงก์ สคริปต์จะตัดทิ้งทันที เรื่องไหนมีไม่ถึง 3 รีวิวหรือมาจากแหล่งเดียว สคริปต์จะติดป้ายว่าหลักฐานบาง ส่วนรีวิวคะแนนต่ำที่ไม่เข้ากลุ่มไหนเลยก็จะแยกออกมาให้เราอ่านเอง ซึ่งคำสั่งบอกว่าข้อมูลส่วนนี้มักเป็นส่วนที่ดีที่สุด

จากไฟล์ feedback.md สกิลจะสรุปข้อมูลออกมาเป็น 3 รายการ เรียงตามน้ำหนักของหลักฐาน:

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

แต่ละข้อจะมีสรุปใจความสำคัญใน 1 บรรทัด พร้อมระบุจำนวนรีวิว จำนวนแหล่งข้อมูล และยกคำพูดจริงของผู้ใช้มา 1 ถึง 2 ประโยคพร้อมลิงก์ประกอบ เรื่องไหนหลักฐานบางก็ต้องเขียนบอกไว้ชัดเจน คำสั่งเตือนไว้ว่าคอมเมนต์โกรธๆ บน Reddit เพียง 3 ข้อความยังไม่ใช่กระแส และตัวเลขทุกตัวต้องเป็นข้อมูลจริง เช่น มี 14 รีวิวก็ต้องระบุว่า 14

จากสามรายการเป็นแผนแก้และจุดยืน

จากนั้น สกิลจะคัดเลือกปัญหาออกมา 5 ถึง 8 ข้อ โดยคำนวณจากน้ำหนักหลักฐานคูณกับความง่ายในการแก้ไข แต่ละข้อจะระบุชัดเจนว่าต้องสร้างหรือปรับเปลี่ยนอะไร งานมีขนาดเท่าใด (S, M หรือ L) สกิลตัวไหนรับไปทำต่อ และมีหลักฐานอะไรรองรับ ส่วนข้อร้องเรียนเรื่องราคาและระบบคิดเงินจะส่งต่อไปให้สกิล launch ดูแล

ขั้นตอนถัดมา สกิลจะเพิ่มแผนแก้ไขทุกข้อเป็นแถวใหม่ในไฟล์ features.csv พร้อมระบุหมายเหตุว่าแอปเดิมไม่มีสิ่งนี้ ไฟล์นี้คือตารางเดียวกับที่ recon ใช้จดฟีเจอร์ของแอปเดิม ตอนนี้ในตารางจึงมีแถวของฟังก์ชันที่แอปเดิมไม่มีเพิ่มเข้ามา

ปิดท้ายด้วยการสร้างประโยคจุดยืนทางการตลาด 3 แบบ แต่ละแบบตั้งจากปัญหาหลักที่ผู้ใช้บ่นหนักที่สุด โดยใช้แม่แบบ "สำหรับ [ใคร] ที่ [เกลียดอะไรในแอปเดิม] [แอปของเรา] [ทำอะไรแทน]" ตามด้วยหลักฐานประกอบว่ามาจากปัญหาเรื่องไหน มีกี่รีวิว และมาจากกี่แหล่งข้อมูล แล้วสกิลจะแนะนำแบบที่เหมาะสมที่สุด 1 แบบ ไว้ใช้กำหนดชื่อแอปและน้ำเสียงในขั้น brand รวมถึงใช้เป็นข้อความหลักบนหน้าขายในขั้น launch

ตัวอย่างแอปนัดหมาย

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

ในตัวอย่างนั้น entrepreneur ได้อ่านรีวิวจริง 140 รีวิวจาก App Store, G2, Capterra และ Reddit แล้วพบเรื่องที่คนบ่นมากที่สุด 3 เรื่อง ก่อนจะแปลงมาเป็นแผนแก้ไขทันที:

• ราคาพุ่งขึ้นตามจำนวนคนในทีม: แก้ด้วยราคาแบบเหมาจ่าย
• ไม่มีข้อความเตือนนัดทาง SMS: แก้ด้วยการเตือนทาง SMS
• แขกสับสนเรื่องเขตเวลา: แก้ด้วยขั้นตอนยืนยันเขตเวลา

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

สร้างสิ่งที่แอปทำได้ แต่ไม่หยิบของที่เขาเป็นเจ้าของ

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

ในตัวอย่างแอปนัดหมายก็เป็นแบบเดียวกัน recon จะติดป้าย partner marketplace ของแอปเดิมว่าอยู่นอกขอบเขตงาน เพราะนั่นคือเครือข่ายธุรกิจของเขา ไม่ใช่ฟังก์ชันทางเทคนิค

นอกจากนี้ ตัวสกิลยังมีกฎบังคับใช้อีก 3 ข้อ:

• อ่านเฉพาะสิ่งที่มีสิทธิ์อ่าน: ศึกษาได้เฉพาะหน้าเว็บสาธารณะกับบัญชีของเราเอง สกิลจะไม่ล็อกอินด้วยบัญชีของคนอื่น และไม่พยายามเลี่ยงหน้าจ่ายเงินเพื่อเข้าไปดูข้อมูล
• รีแบรนด์ทุกครั้งก่อนเปิดตัว: ต้องเปลี่ยนใหม่ทั้งหมด ทั้งชื่อ โทนสี โลโก้ และข้อความ สคริปต์ sweep.py จะไล่ค้นหาชื่อ โดเมน และรหัสสีของแอปเดิมทั่วทั้งโค้ด รวมถึงชื่อที่แฝงอยู่ในชื่อตัวแปรหรือชื่อฟังก์ชัน และสกิล deploy จะไม่ยอมนำแอปขึ้นเว็บจนกว่าจะไม่เหลือร่องรอยของแอปเดิม
• รีวิวเป็นข้อมูลวิจัย ไม่ใช่คำชม: ห้ามยกคำพูดของผู้ใช้แอปเดิมไปแปะบนหน้าขายเพื่อโปรโมตแอปเรา ห้ามใส่ชื่อแอปเดิมในชื่อแอปเรา ในโฆษณา หรือในหน้าร้านค้า และห้ามสร้างรีวิวปลอมเด็ดขาด ไม่ว่าจะเชียร์แอปตัวเองหรือโจมตีแอปคู่แข่ง คำสั่งระบุชัดเจนว่ารีวิวปลอมเป็นเรื่องผิดกฎหมายในสหรัฐฯ ตามกฎปี 2024 ของหน่วยงานกำกับดูแลการค้าอย่าง FTC

ติดตั้ง replica-skill ใน Claude Code

คนที่ใช้ Claude Code เครื่องมือช่วยเขียนโค้ดของ Anthropic สามารถพิมพ์คำสั่ง 2 บรรทัดนี้เพื่อติดตั้ง:

/plugin marketplace add Jakeschincariol/replica-skill
/plugin install replica-skill@replica-skill

เมื่อติดตั้งแบบปลั๊กอินแล้ว ชื่อสกิลจะมีชื่อชุดนำหน้า เช่น /replica-skill:replica-recon อีกทางหนึ่งคือส่งลิงก์โปรเจกต์ https://github.com/Jakeschincariol/replica-skill ให้ Claude ในแชต แล้วพิมพ์คำสั่งว่า install skill

ถ้าไม่ได้ใช้ Claude Code ก็ยังนำวิธีคิดของชุดนี้ไปใช้ได้ โดยเปิดไฟล์คำสั่งหลัก SKILL.md ของสกิลที่ต้องการ เช่น SKILL.md ของ entrepreneur แล้วคัดลอกไปวางเป็นข้อความแรกตอนเริ่มแชต สกิลก็จะทำงานตามบทบาทนั้นทันที

วิธีนี้มีข้อจำกัดคือ จะไม่สามารถเรียกใช้เครื่องมือ Python ทั้ง 6 ตัวในชุดได้ ซึ่งรวมถึงสคริปต์ reviews.py ที่ช่วยจัดกลุ่มรีวิว แต่ขั้นตอนการทำงานและกฎเกณฑ์ทั้งหมดยังคงเหมือนเดิม ทั้งนี้ หากต้องการรันเครื่องมือเหล่านี้ ในเครื่องต้องมี Python เวอร์ชัน 3.8 ขึ้นไป ไม่ต้องติดตั้งไลบรารีอื่นเพิ่มเติม และไม่มีเครื่องมือตัวไหนที่เชื่อมต่ออินเทอร์เน็ต

ไม่ใช่กดทีเดียวแล้วได้แอป

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

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

ก่อนจะเปิดขายจริง README แนะนำสิ่งที่ควรทำ 3 อย่าง คือ ตรวจสอบเครื่องหมายการค้าตามรายการที่สกิล brand เตรียมไว้ให้ อ่านเงื่อนไขของทุกบริการที่นำมาใช้ และปรึกษาทนายความก่อนเปิดตัวหากมีเรื่องเงินเข้ามาเกี่ยวข้อง พร้อมเขียนกำกับไว้ว่านี่ไม่ใช่คำแนะนำทางกฎหมาย ส่วนการทำหน้าเว็บเปรียบเทียบกับแอปเดิม คำสั่งของ entrepreneur ระบุว่าเป็นประเด็นทางกฎหมายที่ต้องปรึกษาทนายความเป็นรายกรณี

เริ่มจากแอปที่ทำให้คุณหงุดหงิด

README แนะนำเทคนิคหนึ่งที่นำไปใช้ได้ทันที คือการรันเฉพาะสกิล entrepreneur ตัวเดียวกับไอเดียแอปที่เราคิดจะทำ เพื่อดูว่าควรทำต่อหรือไม่

ลองเริ่มจากแอปที่เราใช้อยู่แล้วรู้สึกหงุดหงิด เก็บรีวิวจริงจากอย่างน้อย 3 แหล่งข้อมูลลงในไฟล์ reviews.csv แล้วให้ entrepreneur ช่วยสรุปว่าผู้ใช้คนอื่นเกลียดอะไร หากพบประเด็นที่มีหลักฐานแน่นหนาและแอปเดิมยังทิ้งไว้ ค่อยเดินหน้าพัฒนาต่อทั้งสาย แต่ถ้าทุกเรื่องติดป้ายว่าหลักฐานบาง เราก็จะได้คำตอบทันทีว่าไม่ควรทำต่อ และได้คำตอบนี้ก่อนที่จะเสียเวลาลงแรงสร้างจริง

ความหงุดหงิดของเราอาจเป็นแค่สมมติฐาน แต่รีวิวจริงของคนอื่นที่มีลิงก์ยืนยันต่างหาก ที่บอกว่าเรื่องนั้นเป็นโจทย์ที่คุ้มค่าแก่การลงมือแก้

ที่มา:

• โปรเจกต์ replica-skill บน GitHub
• เอกสารทางการของ replica-recon
• เอกสารทางการของ replica-entrepreneur