orchestrator เบา — coding · design · document
3 ตัวที่ใช้เมื่องานไม่ต้องการพิธีของ dev-team: เขียนโค้ดขอบเขตเล็ก, ทำ mockup/diagram, และเขียนเอกสารจาก source จริง — พร้อม lane, gate และ guardrail ของแต่ละตัว
อัปเดต: 2026-08-06
3 plugin นี้ใช้โครงเดียวกัน: orchestrator วิ่งบน main thread → เรียก agent เป็น wave → ปิดด้วย critic/reviewer ต่างจาก dev-team ตรงที่ ไม่มี run directory, ไม่มี evidence matrix, ไม่มี evaluator — เร็วและถูกกว่า แต่ตรวจย้อนหลังไม่ได้
1. /coding — งานโค้ดขอบเขตเล็ก
เส้นแบ่งกับ dev-team: งานหลาย lane หรือ high-risk → route ไป /dev-team · ถ้าโหมดกำกวม → ถามก่อนทำ
โหมด
| โหมด | คือ |
|---|---|
| Real | ทำใน repo จริง มี build/test และ review |
| POC | โฟลเดอร์ใหม่แยกต่างหาก ทางด่วน และ รายงานชัดว่าไม่ใช่ของ production |
Lane — ตัวแปรที่กำหนดว่าจะเรียก agent กี่ตัว
| Lane | เงื่อนไข | ทำยังไง |
|---|---|---|
| Trivial | ครบทุกข้อ: ≤ 2 ไฟล์ · ไม่แตะ public contract / protected config / dependency / ของ destructive · คำสั่งไม่กำกวม | orchestrator เขียนเองบน main thread แล้วเรียกแค่ runner ตรวจ — ไม่มี planner ไม่มี reviewer |
| Standard | นอกเหนือจากนั้น | workflow เต็ม 5 ขั้นด้านล่าง |
งานที่เริ่มแบบ trivial แล้วโตเกินขอบเขตกลางคัน → หยุด แล้วเริ่มใหม่ใน standard lane พร้อมเรียก planner
Workflow (standard)
flowchart LR
P["code-planner<br/>file whitelist + success criteria"] --> C["coder<br/>เขียนเฉพาะใน whitelist"]
C --> R["runner<br/>หลักฐานคำสั่งจริง"]
R --> V["code-reviewer<br/>อ่าน diff จริง"]
V -->|must-fix| C- ข้าม planner ได้เมื่อคำสั่งของ Owner ระบุไฟล์และการเปลี่ยนแปลงมาครบแล้ว
- งานจริงเกิน 5 ไฟล์ หรือแตะของที่ป้องกันไว้ → ขออนุมัติก่อน
- must-fix loop จำกัด 2 รอบ แล้ว escalate
Guardrail
- งบ 6 subagent call ต่องาน ถึงแล้วหยุด — รายงานสถานะและถาม Owner ก่อนไปต่อ
- ห้าม refactor นอกเรื่อง / เปลี่ยน dependency / แตะ protected config / git แบบ destructive / ลบ-เปลี่ยนชื่อ โดยไม่ได้อนุมัติ
- ห้าม writer 2 ตัวเขียนไฟล์ทับกันแบบขนาน
- ห้าม claim ว่าเสร็จโดยไม่มีหลักฐาน build/test
Roster
| Agent | Model | หน้าที่ |
|---|---|---|
code-planner | opus | วางแผน — approach + file plan + success criteria (read-only) |
coder | sonnet | เขียนโค้ด + unit test ตามแผน ตาม convention ของ repo เดิม |
runner | haiku | รัน build/test สรุป error สั้นๆ ไม่ทิ้ง log กองโต |
code-reviewer | opus | review diff — correctness, simplicity, YAGNI, scope-lock (read-only) |
2. /design — mockup · diagram · design spec
Routing
| ขอ | ไปที่ |
|---|---|
| UI / component / variation | mockup-builder |
| flow / architecture / sequence / ERD | diagrammer |
| design spec | main thread ร่างเอง แล้วให้ design-critic review |
| requirement กำกวม | ถามก่อน — ผู้ใช้คือใคร, บริบท, reference, brand |
Workflow
build → critique (design-critic จัดระดับความรุนแรงของ finding) → revise must-fix ไม่เกิน 2 รอบ → ถ้ายังไม่สะอาด หยุดให้ Owner ตัดสิน → deliver
Guardrail
- ห้ามทับงานเดิม — สร้าง
_V2,_V3ไล่ไป - ห้าม hotlink asset ภายนอก — ใช้ asset ฝังหรือ system font
- ทำเฉพาะ scope ที่ขอ ไม่เพิ่มหน้าจอหรือ state ที่ไม่มีใครสั่ง
- ก่อนสร้างไฟล์ต้อง resolve
docs_rootจาก project instruction หรือ config ไม่มี → ถาม ห้าม hardcode path ของเครื่อง
Output
บันทึกที่ <docs-root>/design/{DDMMYYYY}/ — MOCKUP_<TOPIC>.html (variation _A, _B) · DIAGRAM_<TOPIC>.md · DESIGN_SPEC_<TOPIC>.md · คำแนะนำสั้นๆ ตอบในแชทได้เลยไม่ต้องสร้างไฟล์
| Agent | Model | หน้าที่ |
|---|---|---|
mockup-builder | sonnet | HTML/CSS mockup แบบ self-contained 1 ทิศทาง |
diagrammer | haiku | mermaid — flowchart, sequence, ERD, state (อ่าน source จริงก่อนถ้ามี) |
design-critic | opus | ตรวจ hierarchy, consistency, a11y, layout (read-only) |
3. /document — เขียนเอกสารจาก source จริง
หลักการแกน: เอกสารที่ดีเขียนจากหลักฐาน ไม่ใช่จากความจำ — ทุกส่วนของเนื้อหาต้องสาวกลับไปหา source ได้ (repo, git log, แชท, เอกสารเดิม)
Routing
| แบบไหน | ทำยังไง |
|---|---|
| เอกสารใหญ่ (spec, รายงานหลายหน้า, design doc) | loop เต็ม + GATE อนุมัติ outline ก่อนเขียน |
| เอกสารเล็ก (README สั้น, สรุป 1 หน้า, commit note) | ข้าม gate — mine → write → review รวดเดียว |
| source อยู่ในบทสนทนาอยู่แล้ว | ข้าม source-miner แพ็คจาก context ตรงๆ |
| ขอ publish ขึ้น Confluence/Jira/email | 🛑 สร้างไฟล์ local ก่อน แล้ว ยืนยันทุกครั้งก่อน publish |
Wave
| Wave | Agent | Model | ทำอะไร |
|---|---|---|---|
| 1 — Mine | source-miner | sonnet | ขุด raw facts + source ต่อ fact (ไม่เล่าเรื่อง) |
| — Outline | main thread | — | ร่างโครง: หัวข้อ + ประเด็น + fact ไหนไปอยู่ตรงไหน |
| 🚦 GATE | — | — | เอกสารใหญ่เท่านั้น: ขออนุมัติ outline (แก้ outline ถูกกว่าแก้เอกสารเต็ม) |
| 2 — Write | writer | sonnet | เขียนตาม outline + fact ที่ให้ เท่านั้น — ช่องว่างเป็น TBD ห้ามแต่งเอง |
| 3 — Review | doc-reviewer | opus | ตรวจความถูกต้อง/ครบถ้วนกับ source เดิม → must-fix ย้อนกลับหา writer จนสะอาด |
Guardrail
- ไม่มีข้อมูล =
TBDห้ามแต่ง - ห้าม publish ออกนอกเครื่องโดยไม่ได้สั่งชัดเจน — ไม่มีข้อยกเว้นแม้ใน auto mode เพราะกระทบคนอื่น ไม่ใช่แค่เรื่อง permission
- Redact ความลับเสมอ — connection string / token / password ที่เจอใน source แทนด้วย
<REDACTED> - cross-reference ระหว่างเอกสารใช้ relative link ห้าม copy เนื้อหาซ้ำข้ามไฟล์
Output
<docs-root>/{service-name}/{DDMMYYYY}/ALL_CAPS_SNAKE_CASE.md — ไม่ผูกกับ service ใด → general · handoff ขึ้นต้นด้วย HANDOFF_ · ตอบเป็นภาษาไทย ศัพท์เทคนิคภาษาอังกฤษ