# Copycat

> คัดลอกและดัดแปลง skill ของคนอื่น (จาก GitHub repo, marketplace อื่น, หรือเนื้อหาที่แปะมาให้) ให้กลายเป็น skill ที่ใช้งานได้จริงใน marketplace นี้ — สรุปก่อนว่า skill ต้นทางทำอะไรได้บ้าง เสนอว่าอะไรเหมาะกับผู้ใช้คนนี้โดยเฉพาะ (เช็ค dependency ที่เครื่องนี้ไม่มี, license ของต้นทาง, ภาษา) ปรับโครงสร้างไฟล์และ frontmatter ให้ตรง pattern ของ repo นี้ แล้วถามก่อนเสมอว่าจะใส่ไว้ใน plugin ไหน ใช้ skill นี้ทันทีเมื่อผู้ใช้พูดถึง "เอา skill นี้มาปรับใช้หน่อย", "copycat skill จาก repo นี้ให้หน่อย", "เจอ skill นี้ในเน็ต อยากได้แบบนี้บ้าง", "ก็อป skill อันนี้มาแปลงให้เข้ากับของเรา" หรือแปะลิงก์ GitHub ของ skill/agent มาพร้อมบอกว่าอยากใช้ในเครื่องนี้ เรียกใช้ผ่าน `/copycat` เท่านั้น — ไม่ auto-trigger จากบทสนทนา

- Skill: `natthasath/copycat` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add natthasath/copycat`
- Raw SKILL.md: https://api.skillmd.com/api/skills/natthasath/copycat/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: natthasath (https://skillmd.com/u/natthasath)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/natthasath/copycat

---


# บทบาท:
คุณทำหน้าที่เป็น "ตัวแปลง skill ให้เข้าที่" — รับ skill ที่เขียนมาเพื่อคนอื่นหรือ environment อื่น
แล้วปรับให้เข้ากับทั้ง (1) เครื่องและ workflow ของผู้ใช้คนนี้ และ (2) pattern โครงสร้างไฟล์ของ
marketplace นี้โดยเฉพาะ

เหตุผลที่ต้องทำมากกว่าก็อปวางตรงๆ: skill ที่ไม่ตรง pattern จะดูแปลกแยกจาก skill อื่นในนี้ทันทีที่เปิดอ่าน,
มักพึ่ง CLI tool ที่เครื่องนี้ไม่มีแล้วพังเงียบๆ ตอนใช้งานจริง, และ description ที่เขียนมาคนละสไตล์มักทำให้
Claude ไม่ trigger skill นั้นตอนควรจะ trigger — การดัดแปลงให้ตรง pattern ตั้งแต่แรกแก้ปัญหาทั้งสามอย่าง
พร้อมกัน

# ขั้นตอน:

## 0. เช็คว่ามี skill ต้นทางมาให้แล้วหรือยัง
ถ้าข้อความผู้ใช้ยังไม่มีลิงก์ เนื้อหา หรือ path ของ skill ต้นทาง **ให้ถามก่อนเสมอ** อย่าเดาว่าผู้ใช้
หมายถึง skill ไหน — ถามได้ตรงๆ ว่า "มีลิงก์ GitHub, เนื้อหา SKILL.md, หรือ path ในเครื่องของ skill
ที่อยากเอามาปรับไหม"

## 1. ดึงเนื้อหา skill ต้นทาง

**กรณี URL ไป GitHub repo/folder:** รัน script ที่ bundle มากับ skill นี้

```bash
python3 <base-directory-ของ-skill-นี้>/scripts/fetch_skill_source.py "<url>" "<output-dir>"
```

ใช้ path แบบ absolute ต่อจาก base directory ของ skill นี้ (ที่ระบบแจ้งไว้ตอนโหลด skill) เสมอ — อย่า
พึ่ง relative path เพราะ working directory ตอนรันอาจไม่ใช่โฟลเดอร์ของ skill นี้ ลองรันตามลำดับ
`python3` → `py` → `python` จนกว่าจะได้ JSON กลับมาจริง (ไม่ใช่ error แบบ "command not found" หรือ
Microsoft Store alias เปล่าบน Windows — เจอแบบนั้นให้ข้ามไปลองตัวถัดไปทันที) ใช้โฟลเดอร์ใน
scratchpad หรือ temp เป็น `<output-dir>` เพราะเป็นแค่ที่พักไฟล์ต้นทางก่อนอ่าน ไม่ใช่ปลายทางสุดท้าย

Script รองรับ URL ทั้ง `.../tree/<ref>/path/to/skill`, `.../blob/<ref>/path/to/skill/SKILL.md`,
repo root เฉยๆ, หรือ shorthand `owner/repo/path` — ลอง `gh api` ก่อน (ได้ rate limit สูงกว่า ใช้กับ
private repo ได้ถ้า login ไว้) แล้ว fallback เป็น public API อัตโนมัติ ผลลัพธ์เป็น JSON บรรทัดเดียว
`{owner, repo, ref, path, output_dir, files, error}`

ถ้า `error` ไม่ใช่ null ให้อ่านข้อความ error ตรงๆ กับผู้ใช้ — สาเหตุที่พบบ่อยคือ path ที่ให้มากว้างเกินไป
(ดึงได้เกิน 200 ไฟล์ เพราะดันชี้ไป repo ทั้งก้อนแทนที่จะเป็นแค่โฟลเดอร์ของ skill เดียว) ในกรณีนี้ขอให้
ผู้ใช้ช่วยระบุ path ที่แคบลงไปที่โฟลเดอร์ของ skill นั้นโดยตรง

**กรณีผู้ใช้แปะเนื้อหา SKILL.md มาตรงๆ ในแชท:** ใช้เนื้อหานั้นได้เลย ไม่ต้องดึงอะไรเพิ่ม

**กรณี path ในเครื่อง:** Read ไฟล์ SKILL.md ตรงๆ แล้ว Glob หาไฟล์อื่นในโฟลเดอร์เดียวกัน
(`references/`, `scripts/`, `assets/`) มาอ่านประกอบด้วยถ้ามี

## 2. อ่าน pattern ของ repo นี้
เปิด `references/repo-pattern.md` อ่านให้ครบก่อนเริ่มวางแผนดัดแปลง — เป็นฐานของทุกอย่างที่จะสร้าง
ในขั้นถัดไป (โครงสร้างไดเรกทอรี, frontmatter, หัวข้อ body, checklist หลังสร้าง)

## 3. ประเมินและวางแผนดัดแปลง
เปิด `references/adaptation-guide.md` ทำตามขั้นตอน 1–6 ในนั้น: เช็ค dependency ภายนอกที่เครื่องนี้
อาจไม่มี, เช็ค license/การอ้างอิงต้นทาง, generalize สิ่งที่เฉพาะเจาะจงกับคนอื่น, เขียน description
ใหม่ตาม pattern (manual-invoke-only เสมอ ไม่ auto-trigger), และร่างชื่อ skill ใหม่

## 4. สรุปให้ผู้ใช้ฟังก่อนเสมอ
แสดงสรุปสั้นๆ (ไม่ใช่ก็อปเนื้อหาต้นฉบับมาแปะทั้งดุ้น) ว่า:
1. skill ต้นทางทำอะไรได้บ้าง
2. อะไรที่เสนอปรับให้เหมาะกับผู้ใช้คนนี้โดยเฉพาะ พร้อมเหตุผล (dependency ที่ไม่มี, license ที่เจอ,
   ภาษา/บริบทที่ต้องปรับ)

รอให้ผู้ใช้ตอบรับหรือแก้ไขก่อนไปขั้นถัดไป

## 5. ถามว่าจะใส่ plugin ไหน
อ่าน `.claude-plugin/marketplace.json` ที่ root ของ repo เพื่อ list ชื่อ plugin ที่มีอยู่ปัจจุบันทั้งหมด
เสนอเป็นตัวเลือกให้ผู้ใช้เลือก พร้อมตัวเลือก "สร้าง plugin ใหม่" — **ห้ามข้ามขั้นนี้แม้ผู้ใช้จะรีบหรือ
เคยบอกไว้ก่อนหน้าว่าจะใส่ plugin ไหน** เพราะบริบทอาจเปลี่ยนหลังเห็นสรุปในขั้น 4 แล้ว ให้ถามยืนยัน
อีกครั้งเสมอก่อนสร้างไฟล์จริง

## 6. ยืนยันชื่อ skill
เสนอชื่อ kebab-case ที่ตรง naming convention ของ repo นี้ (ดูตัวอย่างชื่อ skill ที่มีอยู่แล้วในตาราง
plugin ที่ผู้ใช้เลือก) ให้ผู้ใช้คอนเฟิร์มหรือแก้ก่อนสร้างไฟล์จริง

## 7. สร้างไฟล์
สร้างโฟลเดอร์ `plugins/<plugin>/skills/<skill-name>/` ตามโครงสร้างใน `references/repo-pattern.md`
— SKILL.md เสมอ, ส่วน `references/`, `scripts/`, `assets/` สร้างเฉพาะที่จำเป็นจริงตามที่วางแผนไว้ใน
ขั้น 3

## 8. อัปเดตไฟล์ที่เกี่ยวข้องให้ครบ
ทำตาม "Checklist หลังสร้าง/แก้ skill" ในหัวข้อ 4 ของ `references/repo-pattern.md` ให้ครบทุกข้อ —
plugin.json (bump version), README ของ plugin นั้น, README ที่ root, และ marketplace.json ที่ root

## 9. เสนอ commit
สรุปรายการไฟล์ที่เปลี่ยน/สร้างทั้งหมด ถามผู้ใช้ก่อน commit เสมอ และถามอีกครั้งก่อน push — ตาม
git safety protocol ของระบบ (ห้าม commit หรือ push เองโดยไม่ถาม)

# คำขอ:
- ห้ามเดา URL, path, ชื่อ plugin ปลายทาง, หรือชื่อ skill ใหม่เอง — ต้องถามหรือยืนยันกับผู้ใช้ในจุดที่
  ระบุไว้ในขั้นตอนข้างบนเสมอ แม้จะดูเดาได้ไม่ยากก็ตาม
- ห้ามคง dependency ภายนอกที่เครื่องผู้ใช้ไม่มีไว้เงียบๆ — ต้องถามตามขั้นตอนในข้อ 1 ของ
  `references/adaptation-guide.md` เสมอว่าจะเรียก CLI tool จริงหรือ bundle เป็น script ของตัวเอง
- ห้ามใส่ attribution/license comment ของต้นทางลงในไฟล์ที่สร้างใหม่ — แค่แจ้งในแชทให้ผู้ใช้รู้ว่า
  ต้นทางใช้ license อะไรก็พอ เว้นแต่ license นั้นห้าม redistribute/modify ชัดเจน กรณีนั้นให้เตือนหนักขึ้น
  และถามก่อนดำเนินการต่อจริงๆ
- ไฟล์ที่สร้างทุกไฟล์ต้องตรงกับ `references/repo-pattern.md` ทั้งโครงสร้างไดเรกทอรีและสไตล์การเขียน
  — ไม่ใช่แค่แปลเนื้อหาต้นฉบับเป็นไทยแล้วจบ
- ทำ checklist ในขั้นตอน 8 ให้ครบทุกข้อก่อนเสนอ commit เสมอ อย่าลืมไฟล์ไหนไป (สาเหตุที่พบบ่อยที่สุด
  ของ plugin ที่ไม่ปรากฏใน marketplace คือลืมอัปเดต `.claude-plugin/marketplace.json`)

# ไฟล์แนบ:
- `references/repo-pattern.md` — โครงสร้างไฟล์, frontmatter, หัวข้อ body, checklist หลังสร้าง
  ต้องอ่านทุกครั้งก่อนเขียนไฟล์ใหม่
- `references/adaptation-guide.md` — วิธีเช็ค dependency/license/ภาษา และเสนอการดัดแปลงให้เหมาะกับ
  ผู้ใช้ ต้องอ่านทุกครั้งก่อนเริ่มดัดแปลง
- `scripts/fetch_skill_source.py` — ดึงไฟล์ skill ทั้งโฟลเดอร์จาก GitHub repo มาไว้ในเครื่อง
  ใช้เมื่อ skill ต้นทางมาในรูป URL