@warnyin/agents 0.1.0

package/.claude/commands/warnyin/build.md

@@ -0,0 +1,29 @@
+---
+description: รัน BUILD stage — fan-out sub-agent ต่อ task ตาม dependency (Workflow + worktree) แล้ว integrate
+argument-hint: "[slug ของ topic]"
+---
+
+ทำหน้าที่เป็น BUILD orchestrator ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:build <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin-stages/<slug>/` ครบ) — อย่าเริ่ม fan-out ทั้งที่ context ใกล้เต็ม
+1. อ่าน `workflow/stages/build.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ build topic ไหน (ดูโฟลเดอร์ใน `warnyin-stages/`)
+3. **อ่าน task ทั้งหมด** ใน `warnyin-stages/<slug>/tasks/*/task.md` + `design.md` → ดึง dependency → สร้าง DAG → จัด **wave** ด้วย topological order
+4. **Pre-check:** target เป็น git repo ไหม (จำเป็นสำหรับ worktree isolation) — ถ้าไม่ใช่ → fallback sequential shared-tree (`isolate:false`) และแจ้ง user. สร้าง build branch ใหม่ก่อนเริ่ม
+5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion แสดง execution plan: แต่ละ wave มี task อะไร, อันไหน parallel, isolation mode, build branch → รอ go/no-go (อย่าเริ่มก่อนได้ไฟเขียว)
+6. **เดินทีละ wave** (หลังอนุมัติ):
+   - เรียก **Workflow** ด้วย `{ scriptPath: "workflow/scripts/build-wave.mjs", args: { slug, tasks: [<task ใน wave นี้>], isolate } }`
+   - เมื่อ workflow คืนผล: ถ้า `isolate` → **merge** branch ที่แต่ละ agent รายงาน (`result.branch`) เข้า build branch ทีละอัน, แก้ conflict ถ้ามี; ถ้า shared-tree → review + commit ให้
+   - ถ้ามี task `failed` หรือ `skipped` → **หยุด** รายงาน user ก่อนไป wave ถัดไป
+   - **รวม troubleshooting:** ดึงฟิลด์ `troubleshooting` จากผลของทุก agent ในรอบนี้ → เขียนรวมลง `warnyin-stages/<slug>/troubleshooting.md` (main loop เขียนเอง กันไฟล์ชนกันใน worktree)
+7. **★ Full build & test gate (หลัง merge ทุก wave):** บน build branch ที่ integrate แล้ว รัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) ของทุก component ที่กระทบ
+   - **เจอ error → อ่าน `docs/troubleshooting.md` ก่อน** เผื่อเคยแก้แล้ว
+   - มี build error / test แดง → **แก้จนเขียวหมด (loop)**: วิเคราะห์ error, แก้ (จะ delegate fix ให้ sub-agent ทีละจุดก็ได้), rerun build/test ใหม่ ทำซ้ำจนผ่าน
+   - ปัญหา **ยาก/เจอซ้ำ** ที่แก้สำเร็จในรอบนี้ → บันทึกลง `warnyin-stages/<slug>/troubleshooting.md`
+   - ห้ามปิด BUILD ถ้ายังแดง; ถ้าวนหลายรอบยังไม่ผ่าน → หยุด รายงาน user พร้อม error log
+8. **ปิดงาน:** เขียน `warnyin-stages/<slug>/build.md` (ผลต่อ task + ผล full build/test + integration notes), อัปเดตสถานะใน `task.md` แต่ละใบ → เสนอเข้า VERIFY ด้วย `/warnyin:verify`
+
+หมายเหตุ:
+- ห้ามแก้ rule/standard กลางใน `docs/` (rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` รอ SHIP)
+- ปัญหายาก/ซ้ำที่แก้ได้ → `warnyin-stages/<slug>/troubleshooting.md` (SHIP จะยกขึ้น `docs/troubleshooting.md`)
+- เกณฑ์ปิด BUILD ดู Gate ข้อ 7 ของ playbook

package/.claude/commands/warnyin/design.md

@@ -0,0 +1,23 @@
+---
+description: รัน DESIGN stage — เสนอ change พร้อมผลิต proposal/design/tasks ครบในขั้นเดียว
+argument-hint: "[slug ของ topic] [อธิบาย change สั้นๆ]"
+---
+
+ทำหน้าที่เป็น DESIGN architect ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `workflow/stages/design.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+   - **ห้ามเดาเอง** — ไม่ชัดให้ถามทีละข้อ + เสนอคำตอบที่แนะนำทุกข้อ
+   - ออกแบบแบบ **vertical slice architecture**
+   - **Gate ก่อนเขียนไฟล์ task** แล้วค่อยโยนให้ sub-agent
+2. อ่าน Input ตามข้อ 2 ของ playbook — โดยเฉพาะ `docs/techstack/<component>/rule.md` และ `standard.md`
+3. งาน: $ARGUMENTS
+   - ระบุ slug → ใช้/สร้าง `warnyin-stages/<slug>/` (ถ้ามาจาก Discovery ใช้โฟลเดอร์เดิม)
+   - ถ้าเป็นคำถาม/ยังไม่มั่นใจเรื่อง design → แนะนำ `/warnyin:discovery` ก่อน
+4. ผลิต artifact โดยใช้ template ใน `warnyin-stages/[topic]/` เป็นโครง: `business.md` (ข้ามได้ถ้า change เล็ก), `proposal.md`, `design.md`, แล้วแตก `tasks/<task-name>/` แต่ละใบมี `spec.md` `standard.md` `rule.md` `task.md`
+5. ตอน generate ไฟล์ task หลายใบ สามารถใช้ sub-agent (Task/Agent tool) fan-out หนึ่ง agent ต่อหนึ่ง task ได้ — **แต่ต้องผ่าน Gate (ข้อ 8 ของ playbook) ก่อน**
+6. **Dry-run (ถาม user ก่อนเสมอ):** หลังเขียนไฟล์ task ครบ ใช้ AskUserQuestion ถามว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok ทำตามข้อ 4.9 ของ playbook:
+   - fan-out agent (Agent tool) **หนึ่งตัวต่อหนึ่ง task แบบขนาน, read-only** — อ่าน task ทั้ง 4 ไฟล์ + design/proposal + โค้ดจริงที่เกี่ยว เดิน implement ในหัว หา **blocker** (implement ตาม spec ไม่ได้ — ต้องแก้ก่อน BUILD) และ **defer** (ทำ/ตัดสินใจทีหลังได้ แต่ต้อง track)
+   - task ที่พบ issue → เขียน `warnyin-stages/<slug>/tasks/<task>/issue.md` (ตาม template); รันครบทุก task → **สรุปผลรวม** ให้ user
+   - **หาวิธีแก้ DESIGN ตาม issue โดยห้ามเดา ห้ามคิดขึ้นเอง** — ติดจริงๆ → สัมภาษณ์ user ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
+   - แก้แล้ว rerun dry-run เฉพาะ task ที่กระทบ วนจน **ไม่มี blocker ค้าง**
+7. เมื่อพร้อม implement → บอกให้รัน `/warnyin:build`

package/.claude/commands/warnyin/discovery.md

@@ -0,0 +1,17 @@
+---
+description: รัน Discovery stage — research + สัมภาษณ์ผู้ใช้เพื่อตี scope จนเข้าใจตรงกัน
+argument-hint: "[ชื่อหัวข้องาน / slug]"
+---
+
+ทำหน้าที่เป็น Discovery facilitator ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `workflow/stages/discovery.md` ให้ครบก่อน แล้วทำตามทุกหลักการในนั้นอย่างเคร่งครัด
+   (กว้าง→แคบ, ถามทีละข้อ + เสนอคำตอบที่แนะนำ, โค้ดตอบได้ให้ไปอ่านเอง, เดินทีละกิ่ง decision tree)
+2. อ่าน Input ตามข้อ 2 ของ playbook — เริ่มที่ `docs/project.md` เสมอ
+3. หัวข้องาน: $ARGUMENTS
+   - ถ้าระบุมา → ใช้เป็น slug ของ topic (kebab-case) สร้าง/ใช้โฟลเดอร์ `warnyin-stages/<slug>/`
+   - ถ้าไม่ระบุ → ถาม user ก่อนว่าหัวข้องานคืออะไร
+4. เขียน output ลง `warnyin-stages/<slug>/discovery.md` และ `research.md` โดยใช้ template ในโฟลเดอร์ `warnyin-stages/[topic]/` เป็นโครง
+5. ปิดงานเมื่อผ่าน Gate (ข้อ 6 ของ playbook) แล้วเสนอว่าพร้อมเข้า DESIGN ด้วย `/warnyin:design`
+
+หมายเหตุ: ถ้า user พิมพ์ "ซักถามฉันหน่อย" / "grill me" → เข้าโหมด grill ตาม playbook

package/.claude/commands/warnyin/init.md

@@ -0,0 +1,12 @@
+---
+description: รัน INIT — วิเคราะห์โปรเจกต์ที่มีอยู่ แล้วเติม docs/ (project, techstack, codemap, infra) ครั้งแรกหลังติดตั้ง
+---
+
+ทำหน้าที่เป็นผู้วิเคราะห์โปรเจกต์ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `workflow/init.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+2. **สแกนภาพรวม repo:** โครงสร้าง, manifest, ภาษา/framework → ระบุว่าแบ่งเป็น component อะไรบ้าง
+3. **วิเคราะห์ลึกต่อ component แบบขนาน:** fan-out sub-agent (Agent tool, read-only) หนึ่งตัวต่อหนึ่ง component — โครงสร้าง, pattern/convention ที่ใช้จริง, วิธี build/test; วิเคราะห์ infra จาก config จริง (docker/compose, env, scripts)
+4. **ข้อมูลธุรกิจที่โค้ดตอบไม่ได้** (เป้าหมาย, ลูกค้า, ขอบเขต) → สัมภาษณ์ user **ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (ใช้ README/โค้ดเป็น recommended); กฎใน `rule.md` → ถาม user ห้ามเดา
+5. **เสนอ summary** (สิ่งที่วิเคราะห์ได้ + รายการไฟล์ docs/ ที่จะเขียน) → ขอ user ยืนยัน**ครั้งเดียว** → เขียน/เติมไฟล์ตามตาราง Output ข้อ 4 ของ playbook — **ไฟล์ที่มีเนื้อหาอยู่แล้วให้เติม ไม่เขียนทับทิ้ง**
+6. **รายงานปิดท้าย:** ส่วนที่ยังว่าง/ไม่แน่ใจ (ระบุ "ยังว่าง รอเติม" ในไฟล์ ห้ามแต่งขึ้นเอง) → เสนอเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`

package/.claude/commands/warnyin/ship.md

@@ -0,0 +1,27 @@
+---
+description: รัน SHIP stage — ส่งมอบ: promote ความรู้ของ topic ขึ้นเอกสารกลางใน docs/ + archive topic
+argument-hint: "[slug ของ topic]"
+---
+
+ทำหน้าที่เป็นผู้ส่งมอบ (SHIP) ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `workflow/stages/ship.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ ship topic ไหน (ดูโฟลเดอร์ใน `warnyin-stages/`)
+3. **อ่านทำความเข้าใจ topic:** อ่าน `warnyin-stages/<slug>/` ทุกไฟล์ (รวม `tasks/*/rule.md` section "รอ SHIP" + `standard.md`) — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง; เช็คว่า VERIFY ผ่าน Gate แล้ว (`verify.md` สรุปผลผ่าน) — ถ้ายังไม่ผ่าน → หยุด แจ้ง user
+4. **จำแนก feature:** feature ใหม่ หรือปรับปรุง feature เดิม (เทียบกับ `docs/features/` ที่มีอยู่)
+5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion สรุป promotion plan: feature ใหม่/ปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive → รอ go/no-go (อย่าแก้ไฟล์ใดก่อนได้ไฟเขียว)
+6. **★ Archive ก่อน:** ย้ายทั้งโฟลเดอร์ `warnyin-stages/<slug>/` → `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv`; วันที่ = วันที่ ship) แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
+7. **อัปเดตเอกสารกลาง** (กลั่นเข้าโครงสร้างไฟล์เดิม ไม่ copy ดิบ, ระวัง duplicate):
+   - `docs/features/<feature-name>/` — ใหม่ → สร้าง (feature.md + business.md); เดิม → อัปเดต โดยใช้ business/proposal/design ของ topic
+   - `docs/techstack/<component>/{rule,standard}.md` — จาก note "รอ SHIP" (พิจารณาครบทุกข้อ: promote หรือตัดทิ้งพร้อมเหตุผล)
+   - `docs/techstack/<component>/structure.md` + `test.md` — โครงสร้างที่เปลี่ยน (ดูโค้ดจริง) + merge แผนเทสจาก `test.md` ของ topic
+   - `docs/rule.md` — global rule ใหม่/ที่เปลี่ยน (เฉพาะกฎระดับโปรเจกต์)
+   - `docs/troubleshooting.md` — merge entry จาก `troubleshooting.md` ของ topic
+   - `docs/infra.md` + `docs/project.md` — เฉพาะถ้ามีข้อมูลเกี่ยวข้อง
+   - `docs/codemap/` ทั้งหมด — อัปเดตให้ตรงโค้ดจริงปัจจุบัน (อย่างน้อยทุกส่วนที่ change กระทบ)
+8. **เขียนสรุป** `achieved/<YYYY-MM-DD>-<slug>/ship.md` (feature ใหม่/ปรับปรุง + ตารางเอกสารที่อัปเดต + note ที่ตัดทิ้งพร้อมเหตุผล) → รายงาน user ว่าส่งมอบครบ topic ปิดสมบูรณ์
+
+หมายเหตุ:
+- SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — ไม่ merge โค้ด (build branch → main จัดการเองนอก workflow)
+- เนื้อหาที่ไม่แน่ใจว่าควร promote/วางไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ อย่าเดา
+- เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook

package/.claude/commands/warnyin/verify.md

@@ -0,0 +1,19 @@
+---
+description: รัน VERIFY stage — strategy tester: เทสตามจุดประสงค์ใน local env (FE: e2e smoke + UXUI) แก้จนผ่าน
+argument-hint: "[slug ของ topic]"
+---
+
+ทำหน้าที่เป็น strategy tester ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:verify <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin-stages/<slug>/` ครบ) — อย่าเริ่มลูปเทส-แก้ทั้งที่ context ใกล้เต็ม
+1. อ่าน `workflow/stages/verify.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ verify topic ไหน
+3. **เข้าใจจุดประสงค์ก่อนเทส:** อ่าน `tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md` ทั้งหมดให้เข้าใจดี แล้วค่อยเทสตามเจตนาของ topic
+4. **guideline:** อ่าน `docs/techstack/<component>/test.md` ว่าเทสยังไง (เช่น FE: e2e smoke ผ่าน playwright-cli) — ไม่มีก็เสนอวิธีแล้วเขียนแผนเอง; ดู `docs/infra.md` สำหรับ local env
+5. **เขียนแผนลง** `warnyin-stages/<slug>/test.md`
+6. **เทสจริงใน local env:** รัน service ที่เกี่ยวข้อง (ใช้ skill `run`/`verify` ช่วย launch ได้) → รันเทสตามแผน; FE → e2e smoke + ตรวจ UX/UI
+7. **ข้อไหนไม่ผ่าน → แก้ → rerun** วนจนผ่าน **นับจำนวนการแก้ไข**; เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน, ปัญหายาก/ซ้ำที่แก้ได้ → บันทึก `warnyin-stages/<slug>/troubleshooting.md`
+8. **ถ้านาน/วนหลายรอบเกินไป → ถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนเงียบไม่จบ)
+9. **เขียนสรุป** `warnyin-stages/<slug>/verify.md` (ผลเทส + รายการแก้ไข + จำนวนรอบ + ผล UXUI) → เสนอเข้า SHIP ด้วย `/warnyin:ship`
+
+หมายเหตุ: ห้ามแตะไฟล์กลางใน `docs/` — `test.md` เขียนระดับ topic ก่อน รอ SHIP merge. เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook

package/AGENTS.md

@@ -0,0 +1,38 @@
+# AGENTS.md
+
+มาตรฐานเปิดสำหรับ AI agent ทุกเจ้าที่อ่านไฟล์นี้ (Codex, Antigravity, และเครื่องมืออื่นที่รองรับ `AGENTS.md`)
+
+## repo นี้คืออะไร
+
+repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ — เดินงานผ่าน 5 stage:
+
+```
+Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
+```
+
+## กฎสำคัญ: ทำตาม playbook กลางเสมอ
+
+แก่นของแต่ละ stage คือ **single source of truth** อยู่ที่ `workflow/stages/`
+ก่อนทำงานใน stage ใด ให้เปิดอ่านไฟล์ playbook ของ stage นั้นแล้วทำตามอย่างเคร่งครัด
+
+| Stage | playbook | สถานะ |
+|---|---|---|
+| Discovery | `workflow/stages/discovery.md` | ✅ พร้อมใช้ |
+| DESIGN | `workflow/stages/design.md` | ✅ พร้อมใช้ |
+| BUILD | `workflow/stages/build.md` | ✅ พร้อมใช้ |
+| VERIFY | `workflow/stages/verify.md` | ✅ พร้อมใช้ |
+| SHIP | `workflow/stages/ship.md` | ✅ พร้อมใช้ |
+
+## วิธีเริ่ม
+
+0. ครั้งแรกในโปรเจกต์ (docs/ ยังว่าง) → ทำตาม `workflow/init.md` เพื่อวิเคราะห์โปรเจกต์ + เติม `docs/` ก่อน
+1. อ่าน `workflow/README.md` เพื่อเข้าใจภาพรวมและโครงสร้าง
+2. งานใหม่ → copy `warnyin-stages/[topic]/` เป็น `warnyin-stages/<slug>/`
+3. รัน stage ตามลำดับ โดยทำตาม playbook ของแต่ละ stage
+4. output ของงานเก็บใน `warnyin-stages/<slug>/`, ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/`
+
+## รัน Discovery
+
+ทำตาม `workflow/stages/discovery.md` — เริ่มอ่าน `docs/project.md`, ตี scope กว้าง→แคบ,
+ถามทีละข้อพร้อมเสนอคำตอบที่แนะนำ, คำถามที่ตอบได้ด้วยโค้ดให้ไปอ่านโค้ดเอง,
+เขียน output ลง `warnyin-stages/<slug>/discovery.md` และ `research.md`

package/CLAUDE.md

@@ -0,0 +1,35 @@
+# CLAUDE.md
+
+repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ เดินงานผ่าน 5 stage:
+`Discovery (optional) ▶ DESIGN ▶ BUILD ▶ VERIFY ▶ SHIP`
+
+## กฎหลัก
+- แก่นของแต่ละ stage เป็น single source of truth ที่ `workflow/stages/` — **ทำตาม playbook นั้นเสมอ** ก่อนเริ่มงานใน stage
+- อย่า duplicate logic ของ workflow ลงที่อื่น ถ้าต้องแก้พฤติกรรมให้แก้ที่ `workflow/stages/`
+- output ของงานจริงเก็บใน `warnyin-stages/<slug>/` (copy จาก template `warnyin-stages/[topic]/`)
+- ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
+
+## Slash commands (namespace `warnyin:`)
+- `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`.claude/commands/warnyin/init.md` → `workflow/init.md`)
+- `/warnyin:discovery [topic]` → Discovery stage (`.claude/commands/warnyin/discovery.md` → `workflow/stages/discovery.md`)
+- `/warnyin:design [slug] [change]` → DESIGN stage (`.claude/commands/warnyin/design.md` → `workflow/stages/design.md`)
+- `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`workflow/stages/build.md` + `workflow/scripts/build-wave.mjs`)
+- `/warnyin:verify [slug]` → VERIFY stage — strategy tester เทส local env + UXUI แก้จนผ่าน (`workflow/stages/verify.md`)
+- `/warnyin:ship [slug]` → SHIP stage — ส่งมอบ: promote ความรู้ขึ้น `docs/` + archive topic (`workflow/stages/ship.md`)
+
+## การติดตั้งไปโปรเจกต์อื่น (npx installer)
+- `npx @warnyin/agents` (หรือสำรอง `npx github:warnyin/warnyin-agents`) → copy โครงทั้งหมดลงโปรเจกต์ปลายทาง (ข้ามไฟล์ที่มีอยู่, CLAUDE.md/AGENTS.md ที่มีอยู่จะต่อท้ายเป็น section)
+- `--update` → เขียนทับเฉพาะ core (`workflow/`, `.claude/commands/warnyin/`, template `[topic]`) ไม่แตะ `docs/`/งานจริง
+- ตัว installer: `bin/cli.mjs` + template CLAUDE.md ของโปรเจกต์ปลายทางที่ `installer/templates/CLAUDE.md` (แก้ commands list ที่ไหน ให้แก้ template นี้ด้วย)
+- หลังติดตั้ง → รัน `/warnyin:init` เพื่อเติม `docs/`
+
+## รองรับหลาย AI
+repo นี้ tool-agnostic: Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
+ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `workflow/stages/` — ดูภาพรวมที่ `workflow/README.md`
+
+## สถานะการสร้าง workflow (อัปเดต 2026-06-04)
+ครบทั้ง 5 stage: Discovery ✅ · DESIGN ✅ · BUILD ✅ · VERIFY ✅ · SHIP ✅
+(playbook + command + template + build-wave.mjs ครบทุก stage)
+
+แพทเทิร์นการเติม/แก้ stage: playbook `workflow/stages/<stage>.md` + command `.claude/commands/warnyin/<stage>.md` + อัปเดตตาราง stage ใน `AGENTS.md`/`CLAUDE.md`/`workflow/README.md` + output template ใน `warnyin-stages/[topic]/`
+**สำคัญ: การเปลี่ยนพฤติกรรม stage ใดๆ ให้ user เป็นคนอธิบาย/ยืนยันก่อน อย่าเดาเอง**

package/bin/cli.mjs

@@ -0,0 +1,117 @@
+#!/usr/bin/env node
+/**
+ * warnyin-agents installer
+ * ติดตั้ง Warnyin Standard Workflow ลงโปรเจกต์ปัจจุบัน (cwd)
+ *
+ *   npx @warnyin/agents             ติดตั้ง (ข้ามไฟล์ที่มีอยู่แล้ว)
+ *   npx @warnyin/agents --update    อัปเดต playbook กลาง (เขียนทับเฉพาะไฟล์ core)
+ *   npx @warnyin/agents --dry-run   แสดงว่าจะทำอะไร โดยไม่เขียนไฟล์จริง
+ *   (ทางสำรองไม่ผ่าน npm: npx github:warnyin/warnyin-agents)
+ */
+import fs from 'node:fs'
+import path from 'node:path'
+import { fileURLToPath } from 'node:url'
+
+const pkgRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..')
+const target = process.cwd()
+const args = new Set(process.argv.slice(2))
+const UPDATE = args.has('--update')
+const DRY = args.has('--dry-run')
+
+if (args.has('--help') || args.has('-h')) {
+  console.log(`warnyin-agents — ติดตั้ง Warnyin Standard Workflow ลงโปรเจกต์ปัจจุบัน
+
+ใช้งาน:
+  npx @warnyin/agents             ติดตั้ง (ข้ามไฟล์ที่มีอยู่แล้ว ไม่เขียนทับ)
+  npx @warnyin/agents --update    อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
+                                  (เขียนทับเฉพาะ workflow/, .claude/commands/warnyin/,
+                                   template warnyin-stages/[topic] — ไม่แตะ docs/ และงานจริง)
+  npx @warnyin/agents --dry-run   แสดงรายการไฟล์ที่จะสร้าง/อัปเดต โดยไม่เขียนจริง
+
+หลังติดตั้ง: เปิด Claude Code ในโปรเจกต์ แล้วรัน /warnyin:init ให้ agent วิเคราะห์โปรเจกต์ + เติม docs/`)
+  process.exit(0)
+}
+
+if (path.resolve(pkgRoot) === path.resolve(target)) {
+  console.error('✖ กำลังรันอยู่ใน repo ของ warnyin-agents เอง — ให้ cd ไปที่โปรเจกต์ปลายทางก่อน')
+  process.exit(1)
+}
+
+// core = playbook กลาง + command + template หน่วยงาน — เขียนทับได้เมื่อ --update
+const CORE = [
+  'workflow',
+  path.join('.claude', 'commands', 'warnyin'),
+  path.join('warnyin-stages', '[topic]'),
+]
+// scaffold = โครง docs/ + พื้นที่ทำงาน — เป็นข้อมูลของโปรเจกต์ ไม่เขียนทับเด็ดขาด
+const SCAFFOLD = ['docs', 'warnyin-stages']
+
+const stats = { created: 0, updated: 0, skipped: 0 }
+
+function copyTree(relDir, { overwrite }) {
+  const srcDir = path.join(pkgRoot, relDir)
+  if (!fs.existsSync(srcDir)) return
+  for (const entry of fs.readdirSync(srcDir, { withFileTypes: true })) {
+    const rel = path.join(relDir, entry.name)
+    if (entry.isDirectory()) {
+      copyTree(rel, { overwrite })
+      continue
+    }
+    const src = path.join(pkgRoot, rel)
+    const dest = path.join(target, rel)
+    const exists = fs.existsSync(dest)
+    if (exists && !overwrite) {
+      stats.skipped++
+      continue
+    }
+    if (exists && overwrite && fs.readFileSync(src).equals(fs.readFileSync(dest))) {
+      stats.skipped++
+      continue
+    }
+    if (!DRY) {
+      fs.mkdirSync(path.dirname(dest), { recursive: true })
+      fs.copyFileSync(src, dest)
+    }
+    stats[exists ? 'updated' : 'created']++
+    console.log(`  ${exists ? '↻' : '+'} ${rel}`)
+  }
+}
+
+/** CLAUDE.md / AGENTS.md: ไม่มี → สร้างจาก template; มีอยู่แล้วแต่ยังไม่มี workflow → ต่อท้ายเป็น section */
+function installRootDoc(name, srcPath) {
+  const dest = path.join(target, name)
+  const content = fs.readFileSync(srcPath, 'utf8')
+  if (!fs.existsSync(dest)) {
+    if (!DRY) fs.writeFileSync(dest, content)
+    stats.created++
+    console.log(`  + ${name}`)
+    return
+  }
+  const existing = fs.readFileSync(dest, 'utf8')
+  if (existing.includes('workflow/stages/')) {
+    stats.skipped++
+    return
+  }
+  const section = '\n\n' + content.replace(/^#\s[^\n]*\n/, '## Warnyin Standard Workflow\n')
+  if (!DRY) fs.appendFileSync(dest, section)
+  stats.updated++
+  console.log(`  ± ${name} (ต่อท้าย section Warnyin Standard Workflow)`)
+}
+
+console.log(`Warnyin Standard Workflow → ${target}${DRY ? '  (dry-run)' : ''}\n`)
+
+for (const dir of CORE) copyTree(dir, { overwrite: UPDATE })
+for (const dir of SCAFFOLD) copyTree(dir, { overwrite: false })
+installRootDoc('CLAUDE.md', path.join(pkgRoot, 'installer', 'templates', 'CLAUDE.md'))
+installRootDoc('AGENTS.md', path.join(pkgRoot, 'AGENTS.md'))
+
+console.log(`\nสรุป: สร้างใหม่ ${stats.created} · อัปเดต ${stats.updated} · ข้าม (มีอยู่แล้ว) ${stats.skipped}`)
+
+if (!UPDATE) {
+  console.log(`
+ขั้นถัดไป:
+  1. เปิด Claude Code ในโปรเจกต์นี้ แล้วรัน  /warnyin:init  — ให้ agent วิเคราะห์โปรเจกต์ + เติม docs/
+  2. เริ่มงานแรก:  /warnyin:discovery <topic>  หรือ  /warnyin:design <slug> <change>
+
+อัปเดต playbook ภายหลัง:  npx @warnyin/agents --update`)
+}

package/docs/troubleshooting.md

@@ -0,0 +1,39 @@
+# Troubleshooting KB (กลาง)
+
+> คลังความรู้ปัญหา-วิธีแก้ของทั้งโปรเจกต์ — สะสมจากทุก topic
+> **อ่านไฟล์นี้ก่อนเสมอเมื่อเจอ build error / ปัญหาระหว่างทำงาน** เผื่อเคยแก้แล้ว
+> ป้อนเข้ามาตอน **SHIP**: ยก entry ที่มีค่าจาก `warnyin-stages/<topic>/troubleshooting.md` มารวมที่นี่ (ลบของซ้ำ/รวมที่คล้ายกัน)
+
+---
+
+## วิธีค้น
+ค้นด้วย error message, component, หรือ keyword อาการ — entry เรียงตาม component แล้วตามความถี่
+
+## สารบัญตาม component
+- [api-service](#api-service)
+- [admin-console](#admin-console)
+- [ทั่วไป / cross-cutting](#ทั่วไป--cross-cutting)
+
+---
+
+## api-service
+<!-- ยังไม่มี entry — เพิ่มตอน SHIP จาก topic troubleshooting.md -->
+
+## admin-console
+<!-- ยังไม่มี entry -->
+
+## ทั่วไป / cross-cutting
+<!-- ยังไม่มี entry -->
+
+---
+
+## รูปแบบ entry (ใช้ตอนเพิ่มจาก SHIP)
+```markdown
+### <ชื่อปัญหา>  ·  เจอ N ครั้ง  ·  อัปเดต YYYY-MM-DD
+- **อาการ/error:** ...
+- **trigger:** ...
+- **root cause:** ...
+- **วิธีแก้:** ...
+- **ป้องกันซ้ำ:** ...
+- **มาจาก topic:** <slug>
+```

package/installer/templates/CLAUDE.md

@@ -0,0 +1,25 @@
+# CLAUDE.md
+
+โปรเจกต์นี้ใช้ **Warnyin Standard Workflow** — มาตรฐานกลางของ ways of work เดินงานผ่าน 5 stage:
+`Discovery (optional) ▶ DESIGN ▶ BUILD ▶ VERIFY ▶ SHIP`
+
+## กฎหลัก
+- แก่นของแต่ละ stage เป็น single source of truth ที่ `workflow/stages/` — **ทำตาม playbook นั้นเสมอ** ก่อนเริ่มงานใน stage
+- อย่า duplicate logic ของ workflow ลงที่อื่น ถ้าต้องแก้พฤติกรรมให้แก้ที่ `workflow/stages/`
+- output ของงานจริงเก็บใน `warnyin-stages/<slug>/` (copy จาก template `warnyin-stages/[topic]/`)
+- ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
+
+## Slash commands (namespace `warnyin:`)
+- `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`workflow/init.md`)
+- `/warnyin:discovery [topic]` → Discovery stage (`workflow/stages/discovery.md`)
+- `/warnyin:design [slug] [change]` → DESIGN stage (`workflow/stages/design.md`)
+- `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`workflow/stages/build.md` + `workflow/scripts/build-wave.mjs`)
+- `/warnyin:verify [slug]` → VERIFY stage — strategy tester เทส local env + UXUI แก้จนผ่าน (`workflow/stages/verify.md`)
+- `/warnyin:ship [slug]` → SHIP stage — ส่งมอบ: promote ความรู้ขึ้น `docs/` + archive topic (`workflow/stages/ship.md`)
+
+## รองรับหลาย AI
+Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
+ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `workflow/stages/` — ดูภาพรวมที่ `workflow/README.md`
+
+## อัปเดต workflow
+`npx @warnyin/agents --update` — เขียนทับเฉพาะ playbook กลาง (`workflow/`, `.claude/commands/warnyin/`, template `warnyin-stages/[topic]/`) ไม่แตะ `docs/` และงานจริงใน `warnyin-stages/`

package/package.json

@@ -0,0 +1,30 @@
+{
+  "name": "@warnyin/agents",
+  "version": "0.1.0",
+  "description": "Warnyin Standard Workflow installer — 5-stage ways of work (Discovery/DESIGN/BUILD/VERIFY/SHIP) สำหรับทุกโปรเจกต์",
+  "type": "module",
+  "license": "MIT",
+  "publishConfig": {
+    "access": "public"
+  },
+  "bin": {
+    "warnyin-agents": "bin/cli.mjs"
+  },
+  "files": [
+    "bin",
+    "installer",
+    "workflow",
+    "docs",
+    "warnyin-stages",
+    ".claude",
+    "CLAUDE.md",
+    "AGENTS.md"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/warnyin/warnyin-agents.git"
+  }
+}

package/warnyin-stages/[topic]/build.md

@@ -0,0 +1,58 @@
+# Build Report — <ชื่อ change>
+
+> Output ของ BUILD stage · playbook: `workflow/stages/build.md`
+> รายงานผลการ implement ต่อ task + การ integrate
+
+| | |
+|---|---|
+| **Slug** | `<kebab-case>` |
+| **Build branch** | `<branch>` |
+| **Isolation** | `worktree` / `shared-tree` |
+| **วันที่** | `YYYY-MM-DD` |
+| **ผลรวม** | ผ่าน __ / ล้ม __ / ทั้งหมด __ task |
+
+## 1. Execution plan (waves ตาม dependency)
+```
+wave 1 (parallel): task-a, task-b
+wave 2:            task-c  (ขึ้นกับ task-a)
+wave 3:            task-d  (ขึ้นกับ task-b, task-c)
+```
+
+## 2. ผลต่อ task
+| Wave | Task | สถานะ | Test/Lint | ไฟล์ที่แก้ | Branch | หมายเหตุ |
+|---|---|---|---|---|---|---|
+| 1 | task-a | ✅ passed | | | | |
+| 1 | task-b | ❌ failed | | | | เหตุผล... |
+
+## 3. Integration notes
+- การ merge แต่ละ wave / conflict ที่เจอและวิธีแก้:
+
+## 3.5 Full build & test gate (หลัง integrate ทุก wave)
+> รัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) บน build branch — ต้องเขียวหมดก่อนปิด BUILD
+
+| Component | Build | Unit test | Test อื่น | รอบที่แก้ |
+|---|---|---|---|---|
+| api-service | ✅ / ❌ | ผ่าน __/__ | | |
+| admin-console | | | | |
+
+- error ที่เจอตอนรวม + วิธีแก้:
+
+## 4. ปัญหา/ค้าง (ถ้ามี)
+- task ที่ล้ม + สาเหตุ + แผนแก้:
+
+## 5. Rule/standard ใหม่ที่ note ไว้ (รอ SHIP)
+> รวบรวมจาก `tasks/<task>/rule.md` และ `standard.md` — รอ SHIP อัปเดตไฟล์กลางใน `docs/`
+-
+
+## 6. ปัญหายาก/ซ้ำที่เจอ
+> บันทึกละเอียดที่ `./troubleshooting.md` (SHIP ยกขึ้น `docs/troubleshooting.md`)
+- ดู `./troubleshooting.md`
+
+## ✅ Gate → VERIFY (ดู `workflow/stages/build.md` ข้อ 7)
+- [ ] ทุก task implement + merge เข้า build branch แล้ว
+- [ ] ทุก task `passed` (test/build เขียว) ไม่มี `failed` ค้าง
+- [ ] ไม่มี merge conflict ค้าง
+- [ ] Full build ของทุก component ผ่าน (ไม่มี build error)
+- [ ] test suite ทั้งหมด (รวม unit test) เขียวหมดบน build branch
+- [ ] build.md สรุปครบทุก task + ผล full build/test
+- [ ] ไม่แตะ rule/standard กลางใน docs/

package/warnyin-stages/[topic]/business.md

@@ -0,0 +1,21 @@
+# Business — <ชื่อ change>
+
+> Output ของ DESIGN stage · playbook: `workflow/stages/design.md`
+> **optional** — ข้ามได้ถ้า change เล็ก (เช่น fix bug นิดหน่อย)
+
+## 1. เป้าหมายเชิงธุรกิจ (what & why)
+- ทำ change นี้เพื่ออะไร / แก้ปัญหาธุรกิจอะไร:
+- ผูกกับเป้าหมายโปรเจกต์ (`docs/project.md`) อย่างไร:
+
+## 2. Persona / ใครได้ประโยชน์
+- ผู้ใช้/ผู้มีส่วนได้ส่วนเสีย:
+- คุณค่าที่เขาได้รับ:
+
+## 3. Success metric (วัดผลได้)
+- ตัวชี้วัดความสำเร็จ:
+- เป้าหมายตัวเลข (ถ้ามี):
+
+## 4. ขอบเขตเชิงธุรกิจ / ข้อจำกัด
+- in scope:
+- out of scope:
+- ข้อจำกัด (compliance, เวลา, งบ ฯลฯ):

package/warnyin-stages/[topic]/design.md

@@ -0,0 +1,42 @@
+# Design (How) — <ชื่อ change>
+
+> Output ของ DESIGN stage · playbook: `workflow/stages/design.md`
+> ออกแบบเชิงเทคนิคแบบ **vertical slice architecture** — แต่ละ slice ตัดผ่านทุก layer ทำงาน end-to-end
+
+## 1. ภาพรวมสถาปัตยกรรม
+- component/service ที่เกี่ยวข้อง (อิง `docs/techstack/*`):
+- แนวทางหลัก:
+
+## 2. Vertical slices
+> หนึ่ง slice = หนึ่งหน่วยคุณค่า end-to-end (UI → API → domain → data → test) → จะกลายเป็น 1 task
+> **ไม่แบ่งตาม layer แนวนอน**
+
+| # | Slice (ส่งมอบคุณค่าอะไร) | ตัดผ่าน layer ไหน | → task |
+|---|---|---|---|
+| 1 | | UI · API · domain · data · test | `tasks/<task-1>/` |
+| 2 | | | `tasks/<task-2>/` |
+
+## 3. Data model / schema
+- entity / ตาราง / field ที่เพิ่มหรือแก้:
+- migration (ถ้ามี):
+
+## 4. Interface / contract
+- API contract / event / interface ระหว่าง component:
+
+## 5. Flow
+- data-flow:
+- user-flow:
+
+## 6. ผลกระทบต่อระบบเดิม
+- จุดที่ต้องระวัง / backward compatibility:
+
+## 7. Dependency ระหว่าง slice/task
+> slice/task เชื่อมกันยังไง ลำดับการทำ
+
+```
+task-1 ──▶ task-2 ──▶ task-3
+              └──▶ task-4
+```
+
+## 8. Test strategy ระดับ design
+- จะยืนยันว่า design ทำงานถูกอย่างไร (ภาพรวม — รายละเอียดอยู่ใน task spec):