@warnyin/agents 0.1.0 → 0.4.0

package/.claude/agents/warnyin-infra.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-infra
+description: Reviewer มุม Infra สำหรับ review panel ของ DESIGN stage — รีวิวผลกระทบ env/service/config/migration/observability (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **Infra** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `warnyin/workflow/roles/infra.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + `docs/infra.md` + config จริง (docker/compose, env, scripts) — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** / **suggestion** — ทุกข้อมีเหตุผล + จุดอ้างอิง + สิ่งที่ต้องเพิ่มใน `docs/infra.md` (ถ้ามี)
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม Infra พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-qa.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-qa
+description: Reviewer มุม QA สำหรับ review panel ของ DESIGN stage — รีวิว testability, acceptance, edge case ของ design (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **QA** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `warnyin/workflow/roles/qa.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้น (รวม checklist เพิ่มสำหรับรีวิว design ใน panel) อย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + `docs/techstack/*/test.md` + โค้ด/เทสจริงที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** (เทสไม่ได้/acceptance วัดไม่ได้) / **suggestion** — ทุกข้อมีเหตุผล + จุดอ้างอิง
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม QA พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-sa.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-sa
+description: Reviewer มุม Solution Architect สำหรับ review panel ของ DESIGN stage — รีวิว design เรื่อง architecture, data model, contract, vertical slice (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **SA (Solution Architect)** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `warnyin/workflow/roles/sa.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + โค้ดจริง/`docs/techstack/`/`docs/codemap/` ที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** (ต้องแก้ก่อนไปต่อ) / **suggestion** (ควรปรับ) — ทุกข้อมีเหตุผล + จุดอ้างอิง (ไฟล์/section/บรรทัด) ห้ามวิจารณ์ลอยๆ ห้ามเดา
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม SA พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-security.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-security
+description: Reviewer มุม Security/DevSecOps สำหรับ review panel ของ DESIGN stage — หาช่องโหว่ระดับ design เช่น input validation, authz, ข้อมูลอ่อนไหว, secret, dependency (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **Security (DevSecOps)** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `warnyin/workflow/roles/security.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + โค้ด/config จริงที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** (ช่องโหว่จริงต้องแก้ก่อน BUILD) / **suggestion** (hardening) — ทุกข้อระบุ จุดที่พบ + ความเสี่ยง + แนวทางแก้ ห้ามรายงานความเสี่ยงลอยๆ ที่ไม่เกี่ยวกับ change นี้
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม Security พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-tech-lead.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-tech-lead
+description: Reviewer มุม Tech Lead สำหรับ review panel ของ DESIGN stage — รีวิว feasibility, ขนาด task, dependency graph, ความเสี่ยง technical (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **Tech Lead** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `warnyin/workflow/roles/tech-lead.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + โค้ดจริงที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** / **suggestion** — ทุกข้อมีเหตุผล + จุดอ้างอิง; dependency/ขนาด task ไม่เหมาะ → เสนอวิธีแตกใหม่ให้ชัด
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม Tech Lead พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

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

@@ -5,25 +5,25 @@ 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
+0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:build <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ) — อย่าเริ่ม fan-out ทั้งที่ context ใกล้เต็ม
+1. อ่าน `warnyin/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** ด้วย `{ scriptPath: "warnyin/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)
+   - **รวม 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`
+   - ปัญหา **ยาก/เจอซ้ำ** ที่แก้สำเร็จในรอบนี้ → บันทึกลง `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`
+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`)
+- ปัญหายาก/ซ้ำที่แก้ได้ → `warnyin/stages/<slug>/troubleshooting.md` (SHIP จะยกขึ้น `docs/troubleshooting.md`)
 - เกณฑ์ปิด BUILD ดู Gate ข้อ 7 ของ playbook

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

@@ -5,19 +5,20 @@ argument-hint: "[slug ของ topic] [อธิบาย change สั้น
 
 ทำหน้าที่เป็น DESIGN architect ตาม **playbook กลาง** ของ workflow มาตรฐาน
 
-1. อ่าน `workflow/stages/design.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+1. อ่าน `warnyin/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 ใช้โฟลเดอร์เดิม)
+   - ระบุ 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`
+4. ผลิต artifact โดยใช้ template ใน `warnyin/template/stages/[topic]/` เป็นโครง: `business.md` (ข้ามได้ถ้า change เล็ก), `proposal.md`, `design.md` (lens `warnyin/workflow/roles/sa.md`), แล้วแตก `tasks/<task-name>/` (lens `warnyin/workflow/roles/tech-lead.md`) แต่ละใบมี `spec.md` `standard.md` `rule.md` `task.md`
+   - **Review panel (ถาม user ก่อน):** หลัง `design.md` เสร็จ ก่อนแตก task — ใช้ AskUserQuestion ถามว่าจะให้ panel รีวิวไหม ถ้า ok → fan-out subagent `warnyin-sa`, `warnyin-tech-lead`, `warnyin-qa`, `warnyin-security`, `warnyin-infra` (Agent tool, ขนาน, read-only) รีวิว proposal+design → รวมความเห็น สรุปให้ user → แก้ blocker ให้ครบ (ห้ามเดา) → บันทึก section "Design review" ท้าย `design.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
+   - 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

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

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

@@ -4,7 +4,7 @@ description: รัน INIT — วิเคราะห์โปรเจกต
 
 ทำหน้าที่เป็นผู้วิเคราะห์โปรเจกต์ตาม **playbook กลาง** ของ workflow มาตรฐาน
 
-1. อ่าน `workflow/init.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+1. อ่าน `warnyin/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 ห้ามเดา

package/.claude/commands/warnyin/install-skill.md

@@ -0,0 +1,14 @@
+---
+description: ติดตั้ง skill เสริมประจำ role (SA/PO/Developer/QA ฯลฯ) ตามตารางใน warnyin/workflow/roles/README.md
+argument-hint: "[ชื่อ role เช่น sa, qa — เว้นว่าง = ทั้งหมด]"
+---
+
+ทำหน้าที่ติดตั้ง skill เสริมประจำ role ของ Warnyin Standard Workflow
+
+1. อ่านตาราง **"Skill เสริมต่อ role"** ใน `warnyin/workflow/roles/README.md` — นั่นคือ single source of truth ของรายการ skill (**ห้าม hardcode รายการในไฟล์นี้** — แก้รายการให้แก้ที่ตารางนั้น)
+2. **เช็คสถานะก่อน:** ตัวไหนติดตั้งแล้วบ้าง — ดูจาก `npx skills ls -g` (ถ้าไม่มีคำสั่งนี้ให้ดูโฟลเดอร์ `~/.agents/skills/` และ `~/.claude/skills/`) — สรุปเป็นตาราง ติดตั้งแล้ว ✅ / ยังไม่ติดตั้ง ⬜
+3. ขอบเขต: $ARGUMENTS ระบุ role → เฉพาะ skill ของ role นั้น; เว้นว่าง → ทุกตัวที่ยังไม่ติดตั้ง
+4. **ให้ user เลือกก่อนติดตั้ง:** ใช้ AskUserQuestion (multiSelect) แสดงแต่ละตัวพร้อม ที่มา (`owner/repo@skill`) + คำเตือนว่าเป็น third-party (ไม่ใช่ official, ตรวจเนื้อหาได้ที่ skills.sh)
+5. **ติดตั้งทีละตัว:** `npx skills add <owner/repo@skill> -g -y` (global — reference ไม่ vendor เข้า repo) → รายงานผลรวม สำเร็จ/ล้มเหลว พร้อมวิธีแก้ถ้าล้ม
+6. รายการที่เป็น **Claude Code built-in** (`/code-review`, `/security-review`) ไม่ต้องติดตั้ง — แจ้งว่าพร้อมใช้อยู่แล้ว
+7. ปิดท้าย: แนะนำว่า role ไหนใน workflow จะหยิบ skill เหล่านี้ใช้ตอนไหน (ตาม section "Skill เสริม" ใน role card)

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

@@ -5,12 +5,12 @@ 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
+1. อ่าน `warnyin/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
+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 หรือตัดทิ้งพร้อมเหตุผล)
@@ -18,7 +18,7 @@ argument-hint: "[slug ของ topic]"
    - `docs/rule.md` — global rule ใหม่/ที่เปลี่ยน (เฉพาะกฎระดับโปรเจกต์)
    - `docs/troubleshooting.md` — merge entry จาก `troubleshooting.md` ของ topic
    - `docs/infra.md` + `docs/project.md` — เฉพาะถ้ามีข้อมูลเกี่ยวข้อง
-   - `docs/codemap/` ทั้งหมด — อัปเดตให้ตรงโค้ดจริงปัจจุบัน (อย่างน้อยทุกส่วนที่ change กระทบ)
+   - `docs/codemap/` ทั้งหมด — อัปเดตให้ตรงโค้ดจริงปัจจุบัน ตาม `warnyin/workflow/codemap.md` (= ขั้นตอนเดียวกับ `/warnyin:update-codemaps`)
 8. **เขียนสรุป** `achieved/<YYYY-MM-DD>-<slug>/ship.md` (feature ใหม่/ปรับปรุง + ตารางเอกสารที่อัปเดต + note ที่ตัดทิ้งพร้อมเหตุผล) → รายงาน user ว่าส่งมอบครบ topic ปิดสมบูรณ์
 
 หมายเหตุ:

package/.claude/commands/warnyin/update-codemaps.md

@@ -0,0 +1,12 @@
+---
+description: Scan project structure and generate token-lean architecture codemaps (docs/codemap/)
+---
+
+ทำหน้าที่เป็น codemap generator ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `warnyin/workflow/codemap.md` ให้ครบก่อน แล้วทำตามทุกขั้นอย่างเคร่งครัด
+2. **Step 1 — สแกน:** ระบุชนิดโปรเจกต์, source dirs, entry points — fan-out sub-agent (Explore, read-only) ขนานต่อ component/พื้นที่ได้
+3. **Step 2 — สร้าง/อัปเดต `docs/codemap/`:** index / architecture / backend / frontend / data / dependencies — **เฉพาะไฟล์ที่ relevant**, รูปแบบ token-lean (< 1000 tokens/ไฟล์, path + signature, ASCII diagram)
+4. **Step 3 — diff detection:** มี codemap เดิม → คำนวณ % เปลี่ยนแปลง; **> 30% → แสดง diff + AskUserQuestion ขออนุมัติก่อนเขียนทับ**; ≤ 30% → อัปเดตเลย
+5. **Step 4 — metadata:** ใส่ freshness header `<!-- Generated: YYYY-MM-DD | Files scanned: N | Token estimate: ~X -->` ทุกไฟล์
+6. **Step 5 — report:** เขียน `.reports/codemap-diff.txt` (added/removed/modified, dependency ใหม่, architecture changes, staleness 90+ วัน) → สรุปผลให้ user

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

@@ -5,15 +5,15 @@ 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` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:verify <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ) — อย่าเริ่มลูปเทส-แก้ทั้งที่ context ใกล้เต็ม
+1. อ่าน `warnyin/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`
+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`
+7. **ข้อไหนไม่ผ่าน → แก้ → rerun** วนจนผ่าน **นับจำนวนการแก้ไข**; เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน, ปัญหายาก/ซ้ำที่แก้ได้ → บันทึก `warnyin/stages/<slug>/troubleshooting.md`
 8. **ถ้านาน/วนหลายรอบเกินไป → ถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนเงียบไม่จบ)
-9. **เขียนสรุป** `warnyin-stages/<slug>/verify.md` (ผลเทส + รายการแก้ไข + จำนวนรอบ + ผล UXUI) → เสนอเข้า SHIP ด้วย `/warnyin:ship`
+9. **เขียนสรุป** `warnyin/stages/<slug>/verify.md` (ผลเทส + รายการแก้ไข + จำนวนรอบ + ผล UXUI) → เสนอเข้า SHIP ด้วย `/warnyin:ship`
 
 หมายเหตุ: ห้ามแตะไฟล์กลางใน `docs/` — `test.md` เขียนระดับ topic ก่อน รอ SHIP merge. เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook

package/AGENTS.md

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

package/CLAUDE.md

@@ -4,32 +4,35 @@ repo มาตรฐานกลางของ **ways of work** สำหรั
 `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]/`)
+- แก่นของแต่ละ stage เป็น single source of truth ที่ `warnyin/workflow/stages/` — **ทำตาม playbook นั้นเสมอ** ก่อนเริ่มงานใน stage
+- อย่า duplicate logic ของ workflow ลงที่อื่น ถ้าต้องแก้พฤติกรรมให้แก้ที่ `warnyin/workflow/stages/`
+- output ของงานจริงเก็บใน `warnyin/stages/<slug>/` (copy จาก template `warnyin/template/stages/[topic]/`)
 - ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
+- role card กลางอยู่ที่ `warnyin/workflow/roles/` (BA/PO/SA/Tech Lead/Developer/QA/Security/Infra) — stage ไหนใช้ role ไหนดูใน playbook; reviewer subagent ของ Claude Code อยู่ที่ `.claude/agents/warnyin-*`
 
 ## 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`)
+- `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`.claude/commands/warnyin/init.md` → `warnyin/workflow/init.md`)
+- `/warnyin:install-skill [role]` → ติดตั้ง skill เสริมประจำ role (รายการอยู่ที่ตารางใน `warnyin/workflow/roles/README.md`)
+- `/warnyin:update-codemaps` → สแกนโครงสร้าง + สร้าง/อัปเดต codemap แบบ token-lean ใน `docs/codemap/` (`warnyin/workflow/codemap.md`)
+- `/warnyin:discovery [topic]` → Discovery stage (`.claude/commands/warnyin/discovery.md` → `warnyin/workflow/stages/discovery.md`)
+- `/warnyin:design [slug] [change]` → DESIGN stage (`.claude/commands/warnyin/design.md` → `warnyin/workflow/stages/design.md`)
+- `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`warnyin/workflow/stages/build.md` + `warnyin/workflow/scripts/build-wave.mjs`)
+- `/warnyin:verify [slug]` → VERIFY stage — strategy tester เทส local env + UXUI แก้จนผ่าน (`warnyin/workflow/stages/verify.md`)
+- `/warnyin:ship [slug]` → SHIP stage — ส่งมอบ: promote ความรู้ขึ้น `docs/` + archive topic (`warnyin/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 นี้ด้วย)
+- `--update` → เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) ไม่แตะ `docs/`/งานจริง
+- ตัว installer: `bin/cli.mjs` + template CLAUDE.md ของโปรเจกต์ปลายทางที่ `warnyin/installer/templates/CLAUDE.md` (แก้ commands list ที่ไหน ให้แก้ template นี้ด้วย; โฟลเดอร์นี้ไม่ถูก copy ไป target)
 - หลังติดตั้ง → รัน `/warnyin:init` เพื่อเติม `docs/`
 
 ## รองรับหลาย AI
 repo นี้ tool-agnostic: Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
-ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `workflow/stages/` — ดูภาพรวมที่ `workflow/README.md`
+ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `warnyin/workflow/stages/` — ดูภาพรวมที่ `warnyin/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: playbook `warnyin/workflow/stages/<stage>.md` + command `.claude/commands/warnyin/<stage>.md` + อัปเดตตาราง stage ใน `AGENTS.md`/`CLAUDE.md`/`warnyin/workflow/README.md` + output template ใน `warnyin/template/stages/[topic]/`
 **สำคัญ: การเปลี่ยนพฤติกรรม stage ใดๆ ให้ user เป็นคนอธิบาย/ยืนยันก่อน อย่าเดาเอง**

package/README.md

@@ -0,0 +1,121 @@
+# warnyin-agents
+
+[![npm](https://img.shields.io/npm/v/%40warnyin%2Fagents)](https://www.npmjs.com/package/@warnyin/agents)
+
+**Warnyin Standard Workflow** — มาตรฐานกลางของ "วิธีทำงาน" (ways of work) สำหรับทุกโปรเจกต์
+ให้ AI agent (Claude Code / Codex / Antigravity / อื่นๆ) เดินงานผ่าน 5 stage ด้วย playbook กลางชุดเดียวกัน:
+
+```
+Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
+     ตี scope             ออกแบบ +     fan-out      เทสจริง       ส่งมอบ +
+   จนเข้าใจตรงกัน          แตก task    sub-agent    แก้จนผ่าน    promote ความรู้
+```
+
+ทุก stage มี **Gate** — ผ่านเกณฑ์ครบจึงไปต่อได้ และความรู้ที่เกิดระหว่างงานจะถูก SHIP
+กลั่นกลับเข้า `docs/` เสมอ → งานถัดไปเริ่มจากความรู้ล่าสุดทุกครั้ง
+
+## ติดตั้ง
+
+```bash
+cd my-project
+npx @warnyin/agents             # ติดตั้ง (ข้ามไฟล์ที่มีอยู่ ไม่เขียนทับ)
+npx @warnyin/agents --dry-run   # ดูก่อนว่าจะสร้างอะไร
+npx @warnyin/agents --update    # อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
+# ทางสำรอง (ดึงตรงจาก main): npx github:warnyin/warnyin-agents
+```
+
+- โปรเจกต์ที่มี `CLAUDE.md` / `AGENTS.md` อยู่แล้ว → installer **ต่อท้ายเป็น section** ไม่เขียนทับ
+- `--update` เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) — ไม่แตะ `docs/` และงานจริง
+
+## เริ่มใช้งาน
+
+```bash
+# 1. ติดตั้งแล้วเปิด Claude Code ในโปรเจกต์ → รัน
+/warnyin:init                      # agent วิเคราะห์โปรเจกต์ + เติม docs/ ให้
+/warnyin:install-skill             # (optional) ติดตั้ง skill เสริมประจำ role
+/warnyin:update-codemaps           # (รันซ้ำได้เสมอ) สแกน + อัปเดต codemap หลัง refactor/feature ใหญ่
+
+# 2. เริ่มงานแรก
+/warnyin:discovery <topic>         # โจทย์กว้าง/กำกวม → ตี scope ก่อน
+/warnyin:design <slug> <change>    # scope ชัดแล้ว → ออกแบบ + แตก task เลย
+
+# 3. ไล่ตาม stage จนจบ
+/warnyin:build <slug>              # fan-out sub-agent implement ตาม dependency
+/warnyin:verify <slug>             # strategy tester เทสจริงใน local env แก้จนผ่าน
+/warnyin:ship <slug>               # promote ความรู้ขึ้น docs/ + archive topic
+```
+
+## แนวคิดหลัก: Tool-agnostic, single source of truth
+
+แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน**ครั้งเดียว**เป็น markdown ใน `warnyin/workflow/stages/`
+AI แต่ละเครื่องมีแค่ adapter บางๆ ชี้กลับมาที่ playbook กลางชุดเดียวกัน
+
+| AI tool | Adapter | อ่าน playbook จาก |
+|---|---|---|
+| **Claude Code** | `.claude/commands/warnyin/*` + `CLAUDE.md` | `warnyin/workflow/stages/*.md` |
+| **Codex / Antigravity** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
+| เครื่องอื่นๆ | ชี้มาที่ `warnyin/workflow/stages/` ได้ทันที | `warnyin/workflow/stages/*.md` |
+
+> แก้กฎที่ `warnyin/workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
+
+## โครงสร้างที่ติดตั้งลงโปรเจกต์
+
+```
+warnyin/               # ★ ทุกอย่างของ workflow รวมใต้โฟลเดอร์เดียว
+  workflow/            #   playbook กลาง — single source of truth
+    init.md            #     INIT: วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
+    roles/             #     role card: BA · PO · SA · Tech Lead · Developer · QA · Security · Infra
+    stages/            #     discovery / design / build / verify / ship
+    scripts/           #     build-wave.mjs — fan-out sub-agent ต่อ wave (worktree isolation)
+  template/            #   template ทั้งหมด: stages/[topic]/ · docs/ (project/rule/infra/troubleshooting/codemap
+                       #   + techstack/[component]/ · features/[feature-name]/)
+  stages/              #   พื้นที่ทำงานจริงราย topic (copy [topic] เป็น <slug>)
+    achieved/          #     archive หลัง SHIP (<YYYY-MM-DD>-<slug>)
+
+docs/                  # ความรู้ถาวรระดับโปรเจกต์ — ของจริงล้วน (seed จาก warnyin/template/docs ตอนติดตั้ง)
+  project.md           #   ★ จุดเริ่มของ Discovery
+  rule.md  infra.md  troubleshooting.md
+  codemap/  features/  techstack/<component>/{about,rule,standard,structure,test}.md
+
+.claude/commands/warnyin/   # adapter สำหรับ Claude Code (slash commands)
+.claude/agents/             # reviewer subagent: warnyin-{sa,tech-lead,qa,security,infra}
+AGENTS.md                   # adapter สำหรับ Codex / Antigravity
+CLAUDE.md                   # adapter สำหรับ Claude Code
+```
+
+รายละเอียดเต็ม: [`warnyin/workflow/README.md`](warnyin/workflow/README.md)
+
+## จุดเด่นของแต่ละ stage
+
+- **Discovery** — สัมภาษณ์ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
+- **DESIGN** — vertical slice architecture, task self-contained พร้อมโยน sub-agent, มี **review panel** (optional — SA/Tech Lead/QA/Security/Infra รีวิวขนานก่อนแตก task) และ **dry-run** (optional) สแกนหา blocker/defer ก่อนเข้า BUILD
+- **BUILD** — จัด task เป็น wave ตาม dependency (DAG), รัน parallel ใน git worktree แยกกัน, ปิดท้ายด้วย full build + full test gate แก้จนเขียวหมด
+- **VERIFY** — เทสตาม "จุดประสงค์ของ topic" ในสภาพแวดล้อมจริง ไม่ใช่แค่ unit test เขียว; FE ตรวจ UX/UI ด้วย
+- **SHIP** — จำแนก feature ใหม่/ปรับปรุง, promote rule/standard/test/troubleshooting ขึ้นไฟล์กลาง, อัปเดต code map, archive topic
+
+## Role system
+
+role card กลางที่ `warnyin/workflow/roles/` — แต่ละใบกำหนด Mission / Lens / Checklist / Output ของหนึ่งบทบาท
+
+| Role | ใช้ใน | รูปแบบ |
+|---|---|---|
+| BA + PO | Discovery | lens ของ AI หลักตอนสัมภาษณ์/จัด priority |
+| SA + Tech Lead | DESIGN | lens ตอนออกแบบ/แตก task + reviewer ใน panel |
+| Developer | BUILD | system prompt ของ build agent ทุกตัว |
+| QA | VERIFY + panel | lens ของ strategy tester |
+| Security + Infra | DESIGN panel | reviewer (read-only) |
+
+- Tech Lead/Security ผูกกับ built-in `/code-review` และ `/security-review` ของ Claude Code
+- skill เสริมต่อ role ติดตั้งด้วย `/warnyin:install-skill` (รายการกลาง: `warnyin/workflow/roles/README.md`)
+
+## Release เวอร์ชันใหม่ (สำหรับผู้ดูแล repo นี้)
+
+```bash
+npm version patch      # bump เวอร์ชัน + git tag
+npm publish            # ขึ้น npm registry (มี OTP)
+git push --follow-tags
+```
+
+## License
+
+MIT