🇹🇭 ภาษาไทย · 🇬🇧 English

xeno-skills

Agent skills สำหรับโหลดเข้า Claude Code

ความเป็นมา

repo นี้เติบโตมาจากโปรเจกต์ที่ต้องการกำจัดคอขวด "คนกลาง" ของการ brainstorm ด้วย AI — แทนที่จะให้ developer นั่งหน้า terminal คอยตอบคำถามของแต่ละโมเดลทีละข้อ ให้ master agent กระจายปัญหาออกไปยังคณะของ CLI agent อิสระที่ถกกันเองโดยอัตโนมัติ แล้วค่อยสรุปเฉพาะผลลัพธ์สุดท้ายที่สังเคราะห์แล้วขึ้นมาให้คนอนุมัติ

สถาปัตยกรรมนี้บันทึกไว้ใน docs/agentic-workflow-presentation.md — เอกสารอธิบาย Hybrid Multi-Agent Architecture (Multi-Turn Negotiation Loop + Dynamic Skill Injection) ซึ่งเดิมจัดทำเป็น presentation ของโปรเจกต์

โครงสร้าง

Skills อยู่ภายใต้ skills/:

• multi-agent/ — การ orchestrate CLI ของ AI หลายตัวให้ทำงานร่วมกัน
• t4/ — มาตรฐานการทำงานแบบ agent-primary ของทีม T4 (entry map, bootstrap, memory, records, workflow)
• design/ — ตระกูล skill ออกแบบเว็บ/UI (setup, rules, audit, psychology) พร้อมคลัง reference
• karpathy-guidelines/ — guardrails เชิงพฤติกรรมสำหรับการเขียนโค้ด (T4 โหลดอัตโนมัติตอนเริ่ม session)

แต่ละ skill เป็น directory ของตัวเอง มี SKILL.md (พร้อม YAML frontmatter — name และ description) และไฟล์ reference ที่แนบมา

repo นี้ยังเป็น Claude Code plugin ด้วย (.claude-plugin/ + hooks/) — ที่ ship workflow-enforcement hooks เพื่อดึง session ให้อยู่บนรางของ T4

การติดตั้ง

ด้วย npx skills (แนะนำ — ใช้ได้กับทุก agent)

npx skills add xenodeve/xeno-skills

ติดตั้ง skill เฉพาะตัวตามชื่อ:

npx skills add xenodeve/xeno-skills --skill clink-brainstorm

ด้วย plugin (ได้ workflow-enforcement hooks เพิ่ม)

ติดตั้งเป็น Claude Code plugin เพื่อให้ได้ hook ที่ดึง session ให้อยู่บนราง T4:

/plugin marketplace add xenodeve/xeno-skills
/plugin install xeno-skills

hook สามตัว — ยิงเฉพาะ repo ที่มี marker .claude/t4.json เท่านั้น (repo อื่นไม่ถูกแตะ):

• SessionStart → inject เนื้อ using-t4 ครั้งเดียวต่อ session (แก้ปัญหา "ไม่เรียก skill ตั้งแต่ต้น")
• UserPromptSubmit → เตือน rails สั้นๆ ทุก turn (ลด drift กลางทาง)
• PreToolUse → บล็อก/ถาม ก่อนคำสั่งเสี่ยง: gh pr create ที่ไม่มี issue อ้างอิง, git อันตราย (reset --hard, force-push, clean -f, branch -D — โดย reset --hard/clean อนุญาตใต้ "afk" เพื่อ revert-to-green), และ ship gate — รันคำสั่ง verify ของ repo (.claude/t4.json "verify") เอง ก่อน gh pr merge แล้ว deny ถ้าไม่ผ่าน (verify ควรเป็นชุดเร็ว unit+build+lint; e2e ปล่อยให้ CI); gh pr merge ยัง ask ให้ยืนยัน /scrutinize + /code-review — ข้ามได้เมื่อตั้ง "autoMerge"/"afk" ตอน AFK; ถ้าตั้ง "requireGreenCI": true จะรัน gh pr checks ด้วยแล้ว deny ตราบใดที่ยังมี check แดงหรือค้างอยู่

hook พวกนี้เป็นของ Claude Code จึงเห็นเฉพาะคำสั่งที่ Claude รัน — repo ที่รัน Codex/Gemini ด้วย (หรือคน) จะหลุดไป จึงมีชั้น git pre-push guard เสริม (ตรวจ issue ref จาก branch/commit/PR body + บล็อก dirty tree เกินงบและ build artifact) ที่ผูกทุก agent บน clone นั้น — ดู guards-layer.md

hook แบบ inject = "เตือน" (model ยังเลือกไม่ทำตามได้) ที่ "บังคับ" ได้จริงคือ PreToolUse deny + verify ที่ hook รันเอง (ปลอมไม่ได้เพราะ hook รันเทสต์เอง ไม่เชื่อคำอ้าง) การันตีสูงสุด "ห้าม merge ถ้าไม่เขียว" อยู่ที่ CI required-check + branch ruleset: t4-project-bootstrap ให้ทั้ง workflow (lint · typecheck · test · build แยกเป็น required check คนละตัว, ชุด e2e แยกต่างหาก และ CD ที่ gate ด้วย verify เขียว) และคำสั่งตั้ง ruleset ที่ทำให้เป็น required + ห้าม push ตรงเข้า main — ดู ci-cd-layer.md — repo นี้เองก็รัน gate แบบเดียวกัน (.github/workflows/t4-verify.yml: tests = ชุดเทสต์ contract ทั้งหมด, skill-discovery = ยิง installer จริงเพื่อยืนยันว่าทุก SKILL.md ถูกค้นพบ) · สถานะ 2026-08-09: ruleset T4 main gate ติดตั้งแล้ว (deletion + non_fast_forward + pull_request — ห้าม push ตรงเข้า main, merge ผ่าน squash เท่านั้น) แต่ ยังไม่ได้เพิ่ม tests/skill-discovery เป็น required check เพราะ CI โดน lock ด้วยปัญหา billing ของ account (ทุก run ล้มที่ provisioning — annotation: "account is locked due to a billing issue") — ต้องแก้ billing, ให้ CI เขียว, แล้วเพิ่มสอง check นั้นใน ruleset ก่อนปิด #109 · การเขียนเป็นอย่างอื่นคือภาพของการบังคับใช้ที่ส่วนนี้เตือนไว้เองพอดี ชั้นนี้คุมการ merge บนเว็บของคนได้ด้วย — local hook คุมได้แค่คำสั่งที่ agent รัน ส่วน repo ที่ผ่าน bootstrap พก hook ชุดเดียวกันไปเองผ่าน git (ไม่ต้องมี plugin)

เหตุผลการออกแบบทั้งหมด (ปัญหา 2 อย่างที่แก้, enforcement ladder, เพดานความจริงว่าอะไรบังคับได้/อะไรเป็น theater) อยู่ใน docs/adr/0001 · ภาพรวม workflow ระดับรายงาน (pipeline + enforcement ladder) อยู่ใน docs/development-workflow.md

รายการอ้างอิง

เริ่มที่นี่

• ask-xeno — ยอดของคลัง และตั้งใจให้บาง: ทางเข้าสี่ตระกูล ไม่มีอย่างอื่น มันบอกว่าให้เข้าตรงไหน — using-t4, clink-masteragent, design, karpathy-guidelines — แล้วแต่ละทางเข้าแบก map ของตัวเอง จึงไม่มีอะไรถูกเขียนซ้ำสองที่ เขียนขึ้นเพราะเก้าจากสิบเจ็ด skill ที่นี่ คือทั้งตระกูล clink-* และตระกูล design ทั้งหมด เข้าไม่ถึงจากเส้นทางไหนเลย มี contract test ที่ตรวจว่าทุก skill ต้องเข้าถึงได้ภายใน สองต่อ และไฟล์นี้ต้องไม่เกิน 1800 ไบต์ เพื่อไม่ให้ router ยอดโตเงียบๆ จนกลายเป็นสำเนาที่สองของทุกอย่างที่อยู่ข้างล่าง

Multi-agent

• using-clink — ทางเข้าของตระกูล: จะใช้ตัวไหนในสี่ตัวข้างล่าง ตัดสินก่อนที่จะเสียค่าเรียกไปแล้ว · งาน เทียบกับ การตัดสิน คือจุดตัดสินใจทั้งหมด และเป็นจุดที่มักสลับกัน — ตั้ง panel สำหรับคำถามที่ worker เดียวตอบได้ คือเผาหลายเลนเพื่อให้ได้ความเห็นในที่ที่ต้องการข้อเท็จจริง · ส่ง worker ไปผลิตการตัดสิน คือได้คำตอบมั่นใจที่ไม่มีใครตรวจ · clink-masteragent ถูกระบุไว้ในนั้นในฐานะเงื่อนไขก่อนใช้ ไม่ใช่ตัวเลือกที่สี่

• clink-brainstorm — กระจายคำถามออกไปยัง CLI agent อิสระหลายตัว (Gemini/Antigravity, Codex, Claude ฯลฯ) ผ่าน tool clink ของ PAL แล้วสังเคราะห์เป็นข้อเสนอแนะเดียว แต่ละ agent มี cognitive lens ที่ต่างกัน (Code-centric, System-centric, Logic-centric, Conceptual-centric) ซึ่งกำหนดวิธีปรับ prompt สำหรับการ challenge มี judge-led challenge loop สำหรับตอนที่ agent เห็นไม่ตรงกัน และ adversarial round แบบเจาะ lens สำหรับตอนที่ทุกตัวเห็นตรงกัน (การเห็นตรงกันโดยไม่ถูกกดดัน ≠ การยืนยันว่าถูก) ต้องมี PAL MCP server เชื่อมต่อกับ agent ของคุณ พร้อม clink CLI agent อย่างน้อยสองตัว

• clink-subagents — มอบหมาย งานที่มีขอบเขตชัด (เขียน implementation, refactor, แปลงชุดใหญ่, research เฉพาะจุด, ร่างแรก) ให้ Codex (GPT-5.6) หรือ Antigravity (Gemini) ทำเป็น subagent ผ่าน tool clink ของ PAL — เพื่อ offload งาน, รันขนานกัน หรือประหยัด context ต่างจาก clink-brainstorm (ที่ขอ ความเห็น) ตรงที่อันนี้ สั่งให้ทำงานจริงแล้วเอาผลกลับมา มาพร้อม routing rubric อิงดัชนี Artificial Analysis (Codex = โมเดล coding เทพแต่ harness อ่อน → งานยาก self-contained + ต้อง verify; Antigravity = agentic อ่อน → เฉพาะงาน single-shot ง่าย ๆ; คุณ = orchestrate + verify) และกฎเหล็ก verify ทุกอย่างที่ subagent คืนมา ต้องมี PAL MCP server พร้อม clink agent codex/antigravity

• clink-masteragent — สิ่งที่ master agent เป็นเจ้าของและมอบต่อไม่ได้ (การแตกงาน, การรวมงาน, การตรวจขั้นสุดท้าย, ขอบเขตความเชื่อถือ, สัญญาการมอบงาน) และวิธีเลือกโมเดลจากคะแนนที่วัดได้แทนความจำ ตารางคะแนนอยู่ในไฟล์เอง เพราะ agent ที่ไม่มีที่ให้เปิดดูจะเลือกจากที่นึกออก — และ session ที่สร้าง skill นี้ก็ทำแบบนั้นจริง เลือกโมเดลที่อ่อนกว่าบนแกนที่งานต้องการ อ่านก่อนเรียก clink ทุกครั้ง

• clink-debug — ที่เดียวสำหรับการมอบการไล่บั๊ก: ส่งบั๊กเล็กให้ worker ราคาถูกหนึ่งตัว แล้วยกระดับเฉพาะสิ่งที่รอด กำหนดหลักฐานที่ต้องเดินทางไปด้วย และห้ามให้สายพันธุ์ที่เสนอสมมติฐานเป็นคนพิสูจน์ว่ามันผิด

ทีม T4 (มาตรฐานการทำงานแบบ agent-primary)

ตระกูลของ skill ที่กลั่นออกมาแบบไม่ผูกกับโปรเจกต์เดียว จาก repo ที่โตเต็มที่ของทีม T4 (MangaDock, T4-Fastwork) สำหรับ repo ที่ coding agent เป็น developer หลัก ออกแบบมาแบบ retrieval-first เพื่อให้ agent คง context ข้าม session และการ compaction ได้ แต่ละตัวค้นเจอได้เองด้วย trigger ของตัวเอง; using-t4 เป็น entry map, t4-project-bootstrap เป็นตัวติดตั้งไฟล์ ส่วนตัวที่เหลือดูแล discipline ที่ทำต่อเนื่อง

• using-t4 — entry-point map ของทั้งตระกูล (คล้าย using-superpowers) ตอนเริ่ม task ใดๆ ใน T4 repo มันจะ route คุณไปยัง skill ที่ถูกต้อง — memory ตอนเริ่ม session, การ setup repo, pipeline ของ feature หรือ engineering record — และแบก non-negotiable rules ของทีมไว้ CLAUDE.md ของ repo จะชี้ agent ที่เพิ่งเข้ามาให้มาที่นี่ก่อน
• t4-project-bootstrap — scaffold repo T4 ใหม่ (หรือที่ยังมีเอกสารไม่ครบ) ด้วย operating layer ในรอบเดียว: เอกสาร domain/product (CONTEXT.md, UBIQUITOUS_LANGUAGE.md, PRODUCT.md, DESIGN.md, docs/agents/domain.md), knowledge dir ที่ index ตามสถานะ และการ wiring CLAUDE.md — โดย orchestrate สาม skill พี่น้องด้านล่าง แบ่งเป็น tier ตามภาระ context ของ agent (memory layer เปิดเป็น default) พร้อมชุด deliverable ของ Software-Engineering แบบ 7 เฟสให้เลือกเสริม
• t4-agent-memory — working memory ถาวรที่ repo แบบ agent-primary ใช้ขับเคลื่อน: team memory vault (Home.md Map-of-Content → note ที่ link กัน), open-work ledger, ship log, survey-provenance cache และ Serena code memories — พร้อม protocol การอ่านตอนเริ่ม session และกฎ retrieval-first (index-then-open, single-source, จำกัดขนาด log, ความสดใหม่เหนือ authority)
• t4-engineering-records — เลือกว่าจะเขียน record แบบไหนเมื่อมีอะไรสำคัญเกิดขึ้น (post-mortem vs ADR vs system-impact entry vs bug-case-catalog) และเขียนอย่างไรให้ยังเป็น index ที่เชื่อถือได้ (file:line, commit SHA, เฉพาะที่ validated แล้ว, blameless) มีเทมเพลตให้
• t4-dev-workflow — pipeline ของ feature (grill→survey→PRD→issues→TDD), gate แบบ PRD→issues→PR, map ของ skill ที่ trigger อัตโนมัติ, triage label, issue lifecycle และกฎ tracker แบบ bilingual (ไทยสะท้อนอังกฤษ) มีเทมเพลต docs/agents/* + PRD/spec/plan ให้
• t4-afk — ชั้น discipline สำหรับรัน autonomous batch แบบไม่มีคนเฝ้า: preflight scope-lock (AFK รันได้เฉพาะ worklist ที่อนุมัติไว้ก่อน), เส้นแบ่ง "ตัดสินเองได้ vs ต้อง park", ลูปต่อชิ้นงานที่ปลอดภัย (convention→TDD→gate→checkpoint), เงื่อนไข stop-and-park ที่กัน tree ไม่ให้พัง และวิธีปิดจบ batch ด้วย digest เดียวพร้อม reconcile ทุก issue มีเทมเพลต preflight / park-note / landing-digest ให้ มันไม่ผ่อนกฎ T4 ข้อไหน — มันแค่เอา human checkpoint ออก ดังนั้น gate ต่างๆ ต้องยืนด้วยตัวเอง
• t4-bro — ระดับภาษาของทุกอย่างที่ dev ต้องอ่าน: ภาษาไทยธรรมดาระดับ dev ทำงานจริง พร้อมบททดสอบความจำเป็นสามทางที่คำอังกฤษต้องผ่านจึงจะได้อยู่ต่อ (เป็น identifier · dev ใช้คำนี้อยู่แล้ว · ตัดแล้วเสียความแม่นยำ) และกฎหลักฐานสำหรับกรณีตรงกลาง — คำหนึ่งนับว่าเป็นคำที่ใช้จริงเมื่อ dev เขียนคำนั้นเอง มีเพดานความถูกต้องกำกับ (ทำให้ง่ายห้ามทำให้ข้อความกลายเป็นเท็จ, คำที่กันไว้ไม่ใช่ศัพท์เทคนิค), คู่ตัวอย่างก่อน/หลังจาก session จริง และระบุขอบเขตที่ไม่ครอบคลุมไว้ชัด เพื่อให้ identifier, commit message และกฎ tracker แบบ bilingual ยังเป็นไปตามที่ t4-dev-workflow กำหนดทุกประการ

Coding behavior

• karpathy-guidelines — guardrails เชิงพฤติกรรมที่ลดข้อผิดพลาดที่ LLM มักทำตอนเขียนโค้ด (คิดก่อนเขียน, ทำให้ง่ายที่สุด, แก้แบบ surgical, ตั้งเกณฑ์ success ที่ตรวจสอบได้) กลั่นจากข้อสังเกตของ Andrej Karpathy using-t4 โหลดตัวนี้อัตโนมัติครั้งเดียวตอนเริ่ม session ใน T4 repo — จึงใช้ควบคู่กับตระกูล T4 ได้ทันที (MIT, ให้เครดิต Karpathy)

Design (เว็บ/UI)

ตระกูล skill ด้านการออกแบบเว็บ กลั่นจากคลังวิดีโอของ Chase AI, Flux Academy (Ran Segall), Chris McCoy, Kole Jain และ Satori Graphics โดย design เป็นตัวประสานที่ route ไปยังอีกสี่ตัว (transcript ต้นทางอยู่ใน skills/design/references/ — เครดิตเป็นของผู้สร้างวิดีโอแต่ละราย)

• using-design — ตัวประสานของตระกูล route งานออกแบบไปยัง skill ที่ถูกต้อง

• design-setup — กรอบการ setup + prototype เว็บแบบ 0→1 ครบวงจร: preflight check, decision gate, การแยกโค้ดทดลอง, prompt 4 ส่วน, ลำดับ build 3 เฟส และการปิดท้ายด้วยการ commit token

• design-rules — กฎ micro-UI ระดับ CSS/Tailwind: typography (tracking -2%, สเกล Major Third 1.25x, line-height 150%), สมดุลสี 60-30-10, กริด 12/8/4 คอลัมน์, จังหวะ spacing 8pt, ปุ่ม 4 สถานะ และระบบ LIFT กับ 6 ระดับของ visual flow

• design-audit — กรอบการรีวิว UI/portfolio ด้วย 30-Second First Impression Test และระบบ LIFT: ความชัดในทันที, visual hierarchy, trust signal, ความพร้อมด้าน conversion

• design-psychology — จิตวิทยา UX/conversion: 3-Brain Persona (Survival/Emotional/Rational), mental model ของ layout, การหักแพตเทิร์นแบบ MAYA, cognitive chunking (กฎ 3-4 ชิ้นของ working memory) และ Luxury White Space

• design-ship-gate — gate ปิดงานสำหรับหน้าเว็บที่โมเดลเล็กสร้าง: ตรวจความครอบคลุมของ brief แล้วตามด้วยการตรวจที่รันได้แปดข้อ ข้อละหนึ่งข้อบกพร่องที่เกิดซ้ำในหน้าเว็บเก้าหน้าของ Qwen3.8-27B (ฟอนต์, OG tag, dark mode, การล้นที่ 390 px, การตัดบรรทัดของตัวเลข, hero ที่ชนกัน, tracking, ภาษา) วัดได้ 8/8 ×3 เมื่อมี gate เทียบ 6/8 ×3 เมื่อไม่มี ส่วน skill ความรู้ด้าน design เดี่ยว ๆ ได้ 4/8 ×3 ซึ่งต่ำกว่าการไม่มี skill เลย เป็นคำสั่งพร้อมเงื่อนไขผ่าน เพราะกฎที่เป็นร้อยแก้วไม่ถ่ายทอด

Qwen3.8-27B (skill ที่เขียนให้ model ขนาดเล็กทำตามได้)

ตระกูลสำหรับ session ที่ model คือ Qwen3.8-27B (ผ่าน Claude Code บน server ในเครื่อง) model ตัวนี้ทำได้เกือบทุกอย่างแต่ละเว้นสิ่งที่ไม่ได้ถูกเขียนไว้ skill ในตระกูลนี้จึง "นับให้" และ "ตรวจให้" แทนการให้หลักการ calibrate จากการรัน 2026-09-05 (Qwen-3.8-27B-Tuning docs/results/11-quality-bench-2026-09-05.md, #353, #354) ใช้กับ Claude หรือ GPT จะรู้สึกจำกัดเกิน — ตั้งใจให้เป็นอย่างนั้น

• using-qwen38 — router ที่ model โหลดตอนเริ่ม session: งานแบบไหน → โหลด skill ไหน → จบด้วย gate ไหน พร้อมกฎสี่ข้อ (เขียนตาราง brief ก่อน, รันแล้วแปะ output, ห้าม install/หา tool/เปิด agent, หยุดที่รายงาน) · ฉีดให้ model เองตอน SessionStart (startup/clear/compact) ด้วย hooks/session-start ในโฟลเดอร์ของ skill ซึ่งผูกไว้ใน settings ของ profile Qwen เท่านั้น (~/.claude-xeno-exl3.json, ~/.claude-xeno.json, ~/.claude-9arm.json) session ของ frontier model ไม่เห็น

• qwen38-skill-style — มาตรฐานสำหรับคนเขียน skill ในตระกูลนี้: เก้ากฎพร้อมการรันที่เป็นที่มาของแต่ละข้อ บวกข้อยกเว้นหนึ่งข้อที่ระบุไว้สำหรับ harness, โครงไฟล์, checklist ก่อนเปิด PR รวมถึงคู่ทดสอบ มี/ไม่มี หนึ่งคู่

• qwen38-think — การคิดที่โมเดลข้าม เขียนเป็นขั้นตอนที่มันต้องจดลงไป: ตารางสมมติฐานและการตรวจข้อบกพร่องสามแบบ (ขัดแย้ง, ข้อเท็จจริงที่หายไป, สิ่งที่เป็นไปไม่ได้) ก่อนแก้ไฟล์แรก แต่ละข้อตรวจด้วยคำสั่ง เมื่อติดขัดให้เขียนหนึ่งสิ่งที่สังเกต หนึ่งสมมติฐาน หนึ่งคำสั่งที่พิสูจน์ว่าผิด การท้วงเป็นบรรทัดที่เขียนไว้ ไม่ใช่คำถามที่หยุดงาน วัดได้ 3/4 ทั้งสี่ brief ที่ฝังข้อบกพร่องเมื่อไม่มี และ 4/4 เมื่อมี — ลำพังตัวเองโมเดลเห็นข้อบกพร่องแล้วไปถาม developer ที่ไม่อยู่ หรือส่งคำตอบที่รู้ว่าผิดว่าเสร็จ

• qwen38-code-gate — gate ปิดงานสำหรับการแก้โค้ด: ตาราง brief ของโค้ด (test ที่แดงแล้วเขียว, เส้นทาง error, บรรทัดเอกสาร, ห้ามเพิ่ม dependency) แล้วตามด้วยหกคำสั่งพร้อมเงื่อนไขผ่าน — ขอบเขตของ diff, placeholder, ความลับ, test ของ repo พร้อมแปะบรรทัดสุดท้าย, lint หรือ typecheck ถ้าตั้งไว้ และบรรทัด RED ก่อนบรรทัด GREEN บันทึกตามจริง: โค้ดอยู่ที่เพดานของ fixture ทุก arm และผลเดียวของ gate คือวินัยการทดสอบ RED ก่อน GREEN 2 จาก 6 รอบที่มี gate เทียบ 0 จาก 3 รอบที่ไม่มี

• qwen38-claude-code — คู่มือ harness และเป็นข้อยกเว้นเดียวของตระกูลที่ครอบทุกอย่าง Claude Code ส่ง tool 31 ตัวและ schema ของมัน 87,799 ตัวอักษรทุก request เทียบกับ 6,186 ของ system prompt ทั้งก้อน และ schema บอกว่า tool รับอะไร ไม่เคยบอกว่ามีไว้ทำอะไร โมเดลจึงแตะ 12 จาก 31 ตัวใน 44 รอบที่บันทึกไว้ นั่นไม่ใช่การตัดสินใจ แต่เป็นช่อง ไฟล์นี้ให้คำตัดสินของทุกตัว (ใช้ / ใช้เมื่อ X / ห้าม พร้อมเหตุผล), อยากได้อะไรใช้ tool ไหน, ทำอะไรต่อเมื่อ tool คืน error รวมถึงการถูก harness ปฏิเสธ และ session ทำงานอย่างไรจริง ๆ ไฟล์ harness-tools.txt บันทึกชื่อจาก request ที่ดักไว้ เพื่อให้ tool ที่เวอร์ชันหน้าเพิ่มมาทำให้ suite แดงแทนที่จะหลุดไป

ที่เกี่ยวข้อง

Companion skill ecosystems — ตระกูล t4-* เป็นชั้นบางๆ เฉพาะทีมที่วางทับสิ่งเหล่านี้; using-t4 route ไปหาพวกมัน และตั้งใจให้ติดตั้งควบคู่กัน:

• superpowers — process discipline ทั่วไป (brainstorming, TDD, systematic-debugging, writing-plans/skills, verification-before-completion) entry map ของมันเองคือ superpowers:using-superpowers; T4 ยกเรื่อง วิธีการทำงาน ให้มัน
• mattpocock/skills — "Skills for Real Engineers" flow ที่ pipeline ของ T4 สร้างขึ้นมาจาก: loop grill→spec→tickets บวกกับ convention ของ issue-tracker / triage-label / domain-doc ที่ T4 นำมาใช้ซ้ำ ติดตั้ง/ตั้งค่าผ่าน /setup-matt-pocock-skills
• thananon/9arm-skills — debug-mantra, post-mortem, scrutinize, qwen-agent (delegate ไปยัง subagent ราคาถูกที่ขับด้วย Qwen ผ่าน claude-9arm), qwenchance, management-talk

เครื่องมือ:

• xenodeve/pal-mcp-server — fork ของ PAL ที่เพิ่ม clink agent antigravity (ตัวสืบทอดของ Gemini จาก Google, agy, ผ่าน ConPTY บน Windows) และเทมเพลต claude-9arm.json.example สำหรับชี้ claude ไปยัง model gateway อื่น เป็นสิ่งที่ต้องมีก่อนจะใช้ clink-brainstorm / clink-subagents กับ Antigravity หรือ gateway ที่กำหนดเอง

License

MIT — ดู LICENSE