sgui-stakeholder-update
Newใช้เมื่อผู้ใช้ต้องการแปลงสถานะ/ความคืบหน้า/risk/decision/event ดิบ เป็น stakeholder update ที่ reframe ตาม audience, cadence, channel และปิดท้ายด้วย "so what + the ask" เช่น executive/sponsor update, weekly/status update, Slack status, escalation/risk flag, decision request, delay/timeline change, launch/milestone notice, planned downtime/maintenance notice, customer/partner notice หรือคำไทยอย่าง "เขียนอัปเดต", "รายงานสถานะ", "อัปเดตผู้บริหาร", "แจ้งทีม", "แจ้งคู่ค้า", "make this exec-friendly". ห้ามใช้กับ full report/deck, postmortem/incident report, retrospective, requirement/spec, release note ละเอียด, meeting minutes ถอดคำ, หรือ performance review.
Summary
This skill transforms raw status, progress, risks, decisions, or events into concise stakeholder updates that answer 'so what' for the audience and end with a clear ask.
- It helps developers communicate effectively with executives, teams, or partners by reframing information for the right audience, cadence, and channel.
Overview
Stakeholder Update
แปลงสถานะงานให้เป็นข้อความที่ผู้ฟังอ่านแล้ว "รู้ว่าต้องทำอะไรต่อ" ไม่ใช่ log ของสิ่งที่ทีมทำ
หลักคิดแกน: อัปเดตที่ดีตอบ "แล้วไง" (so what) ของผู้ฟัง แล้วปิดท้ายด้วย the ask — ทุกอัปเดตต้องบอกได้ว่า (1) มีอะไรใหม่/เปลี่ยน/เกิดขึ้น (2) มันแปลว่าอะไรสำหรับ "คนอ่านคนนี้" (3) คุณอยากให้เขาทำอะไร/ตัดสินใจอะไร หรือแค่รับทราบ — อัปเดตที่อ่านจบแล้วไม่รู้ว่าจะทำอะไรต่อคืออัปเดตที่ยังไม่เสร็จ
When NOT to use this skill
อย่าใช้ skill นี้เมื่อเป้าหมายหลักคือ:
- •เขียนรายงานฉบับสมบูรณ์ / สไลด์นำเสนอเต็ม (full report, pitch deck) — อันนี้เป็นเอกสารยาว ไม่ใช่ update สั้น
- •postmortem / incident report / root cause analysis — ใช้ template เฉพาะของมัน
- •retrospective หรือ team health review
- •เขียน requirement, spec, release note ละเอียด, หรือ meeting minutes แบบถอดคำต่อคำ
- •performance review / feedback รายบุคคล
ถ้างานปนกัน (เช่นมี incident แล้วต้องแจ้ง stakeholder ด้วย) ให้แยกส่วน "สื่อสารสั้นถึง stakeholder" ออกมาทำด้วย skill นี้ ส่วนเอกสารเต็มทำแยก
Default interaction pattern
ถ้ามีข้อมูลพอ:
- สรุปสั้นๆ ว่าเข้าใจสถานการณ์อย่างไร
- ยืนยัน 3 ตัวแปร: ใครฟัง (audience) / จังหวะหรือโอกาส (cadence) / ช่องทาง (channel) — ใช้ กฎ guess-vs-ask (ด้านล่าง): infer ได้ชัดให้เดา+ระบุว่าเดา, เคสเสี่ยงให้ถามก่อน
- ผ่าน Input Quality Gate — ถ้าขาดข้อมูล blocking ให้ถามเฉพาะข้อนั้น
- ออก update ตาม Output Contract ที่เหมาะ
- ตรวจ Review checklist + ปิดท้ายด้วย Final label
ถ้าข้อมูลไม่พอ: ถามทีละคำถามเฉพาะที่ขาดจริง พร้อมเสนอคำตอบที่เดาได้ อย่าถามสิ่งที่ infer จากบริบทได้ สิ่งที่เดาเองให้ระบุชัดว่าเป็นการเดา
ถ้าผู้ใช้สั่งให้ทำรวดเดียว / วางข้อมูลดิบมาเยอะ: อย่าหยุดถามยาว ทำ draft ที่ดีที่สุดจากข้อมูลที่มี แล้วระบุท้ายว่าจุดไหนเดาไว้และควรยืนยัน
กฎ guess-vs-ask (ใช้กับ audience/channel/cadence):
- •infer ได้ชัด → เดาแล้วระบุว่าเดา (อย่าถาม) — เช่น บริบทบอกอยู่แล้วว่าส่งหัวหน้า
- •ถามก่อน เมื่อ audience เปลี่ยน framing อย่างมีนัยสำคัญ หรือเสี่ยงสับสน internal/external (เช่น ไม่รู้ว่าเป็นคนในหรือคู่ค้า — เพราะ guardrails ต่างกันมาก)
Input Quality Gate
ข้อมูลขั้นต่ำก่อนเขียน — ถ้าขาด ให้แยก blocking / non-blocking:
| Input | Required? | ถ้าขาดทำอย่างไร |
|---|---|---|
| สิ่งใหม่ที่ต้องสื่อสาร — progress / change / event / risk / decision / reminder | Required | ถามตรงๆ — ถ้าไม่มีอะไรใหม่เลย ก็ไม่มีอะไรให้ส่ง |
| สถานะรวม (on track / at risk / off track) | Required / infer if obvious | ประเมินจากข้อมูลที่มี แล้วให้ผู้ใช้ยืนยัน |
| Blocker / risk / decision ที่ค้าง | Required / infer if obvious | ถ้าไม่มีให้ระบุ "ไม่มี blocker" อย่างชัดเจน อย่าเว้นว่าง |
| The ask — อยากให้ผู้ฟังทำ/ตัดสินใจอะไร | Required / infer if obvious | infer ได้ถ้าชัด (เช่น downtime→preparation, escalation→decision/action/support) ถ้า infer ไม่ได้ค่อยถาม; ไม่มี action จริง→ระบุ "FYI" |
| Audience | Required / infer if obvious | เดาจากบริบท + ระบุว่าเดา; ถามเมื่อเสี่ยงสับสน internal/external (default: ผู้บริหาร/หัวหน้า) |
| Channel | Recommended | เดาจากความยาว/ความเป็นทางการ (default: email) |
| Cadence / โอกาส | Recommended | infer จาก event (default: general update ไม่ใช่ weekly เสมอ — หลาย prompt เป็น event-driven: delay/downtime/escalation) |
| สถานะครั้งก่อน (เทียบ delta ได้) | Optional | ถ้ามีช่วยให้เขียน "เปลี่ยนจาก X เป็น Y" ได้คม |
กฎ infer-if-obvious: อย่าถามสิ่งที่ผู้ใช้สื่อมาชัดอยู่แล้วในบริบท — เช่น "แจ้ง planned downtime ให้คู่ค้า" บอก audience (คู่ค้า) + the ask (เตรียมตัว) มาในตัวแล้ว ให้ลงมือเขียน ไม่ต้องถามซ้ำ ถามเฉพาะตอน infer ไม่ได้จริงหรือเสี่ยงผิดทาง
กฎ delta (เฉพาะ recurring/weekly update): weekly/progress update ควร delta-first — เน้นสิ่งที่เปลี่ยนตั้งแต่ครั้งก่อน ถ้าไม่มี movement ให้พูดตรงๆ ว่า "ไม่มี movement เพราะ [เหตุผล]" ซึ่งตัวมันเองคือสัญญาณที่ stakeholder ควรรู้ — แต่ event-driven update (downtime, decision request, launch, escalation, first-time notice) ไม่ต้องมี "delta จากครั้งก่อน" เพราะตัว event/decision/risk คือสิ่งใหม่ที่สื่อสารอยู่แล้ว
Audience taxonomy — ปรับ "แล้วไง" ตามคนอ่าน
หัวใจของ skill นี้: ข้อเท็จจริงเดียวกัน เล่าต่างกันตามคนฟัง
| Audience | สนใจอะไรจริงๆ | Framing | Detail level | ตัดอะไรทิ้ง |
|---|---|---|---|---|
| Exec / Sponsor | outcome, เงิน/เวลา/คน, risk ที่ต้องตัดสินใจ | "ผลลัพธ์และสิ่งที่ต้องการจากคุณ" | สูงสุด — 3-5 บรรทัดพอ | รายละเอียด implementation, ชื่อ ticket, ศัพท์เทคนิค |
| Peer / Cross-functional | dependency ที่กระทบงานเขา, timing | "อะไรกระทบทีมคุณ และเมื่อไหร่" | กลาง | เรื่องภายในทีมที่ไม่เกี่ยวเขา |
| Delivery team | scope, blocker, ลำดับงาน, ใครทำอะไร | "เราอยู่ตรงไหนและทำอะไรต่อ" | ละเอียดได้ | การ spin เชิงบวก, exec framing |
| Customer / External | ผลกระทบต่อเขา, เมื่อไหร่ได้ใช้, ต้องทำอะไรไหม | "สิ่งนี้แปลว่าอะไรสำหรับคุณ" | กลาง-ต่ำ | internal blocker, ปัญหาภายใน, ภาษาตำหนิทีม |
กฎ: audience เปลี่ยนทั้ง framing และสิ่งที่ตัดทิ้ง ไม่ใช่แค่ tone — ใช้กฎ guess-vs-ask: เดาได้ถ้าชัด, ถามเมื่อเสี่ยงสับสน internal/external
Reframing matrix — fact เดียว เปลี่ยน framing ทุก audience
ใช้เมื่อ "เหตุการณ์เดียว ต้องสื่อสารหลายกลุ่ม" (เช่น delay, downtime) — framing เปลี่ยน ไม่ใช่แค่ตัดให้สั้น:
| Fact เดียว | Exec / Sponsor | Delivery team | Customer / Partner |
|---|---|---|---|
| งานเลื่อน 1 สัปดาห์ | ผลต่อ timeline + risk + decision ที่ขอ | dependency, งานที่ทำต่อได้, owner | timeline ใหม่ + ผลกระทบ + next update |
| API ทีมอื่นยังไม่พร้อม | dependency risk (ไม่โทษทีม) | integration blocker + ระบุทีมตรงๆ | "internal dependency" ไม่ลงรายละเอียด |
| Planned downtime | ผลกระทบที่ควบคุมได้ + แผนเฝ้าระวัง | pre-check / monitor / post-check + owner | ช่วงเวลาใช้ไม่ได้ + สิ่งที่ต้องเตรียม |
| Defect ค้างหลายตัว | risk ต่อ go/no-go | fix + retest + severity + owner | ผลกระทบที่อาจเจอ + next update |
ดูตัวอย่างเต็มที่ references/examples.md
Cadence × purpose — โอกาสกำหนดโครง
| Cadence / โอกาส | โฟกัส | โครงที่เหมาะ |
|---|---|---|
| Weekly status | delta + blocker + next | สั้น: สถานะ → คืบหน้า → ติดอะไร → สัปดาห์หน้า → ask |
| Monthly / QBR | trend, outcome เทียบเป้า, ทิศทาง | progress vs goal → highlight → risk → ทิศทางถัดไป |
| Launch / milestone | เกิดอะไรขึ้น, ผลกระทบ, ต่อไปคืออะไร | what shipped → impact/ผล → ขอบเขต → next/known issues |
| Escalation / risk flag | ปัญหา, ผลกระทบ, ตัวเลือก, สิ่งที่ขอ | issue → impact → options → recommendation → decision/action/support needed by [when] |
| Scheduled change / maintenance | กำหนดการ, ผลกระทบ, สิ่งที่ต้องเตรียม/เฝ้าระวัง | window → impact → preparation → monitor/post-check → escalation |
template เต็มของแต่ละโหมด (downtime, decision request, delay, PO ops, UAT, release readiness, customer) อยู่ที่ references/templates.md — โหลดเมื่อผู้ใช้ขอสถานการณ์นั้นโดยเฉพาะ
Channel format — ช่องทางกำหนดความยาวและน้ำเสียง
| Channel | ความยาว | น้ำเสียง | หมายเหตุ |
|---|---|---|---|
| ยาวได้ มีโครง | เป็นทางการกว่า | มี subject ที่บอก ask/สถานะตั้งแต่หัวเรื่อง | |
| Slack / chat | สั้น scan ได้ | กระชับ ตรง | bold คำสำคัญ, ใส่ ask เป็นบรรทัดท้ายชัดๆ |
| Standup line | 1-3 บรรทัด | สั้นมาก | yesterday/today/blocker หรือ status/next/ask |
| Meeting talking points | bullet สำหรับพูด | พูดได้ลื่น | เรียงตามลำดับที่จะพูด + ประเด็นที่ต้องดันให้จบ |
Status taxonomy — RAG ด้วยเกณฑ์ ไม่ใช่ความรู้สึก
| สถานะ | เกณฑ์ | ต้องมีอะไรประกอบ |
|---|---|---|
| 🟢 On track | จะถึงเป้า/กำหนดตามแผน ไม่มี risk ที่เปลี่ยนผลลัพธ์ | ระบุสั้นๆ ว่า "ตามแผน" พอ |
| 🟡 At risk | มีปัญหาที่ "อาจ" ทำให้พลาดเป้า/เลื่อน ถ้าไม่จัดการ | cause + impact + สิ่งที่กำลังทำ + ask |
| 🔴 Off track | พลาดเป้า/เลื่อนแล้ว หรือจะพลาดแน่ถ้าไม่มีการตัดสินใจ | cause + impact + options + recommendation + decision needed by [when] |
กฎ:
- •🟡 และ 🔴 ห้ามมาเดี่ยวๆ ต้องพ่วงเหตุ-ผลกระทบ-สิ่งที่ขอเสมอ และ ห้ามวางท้ายเอกสารให้คนอ่านพลาด — Red/risk ต้องอยู่บนสุดหรือใน subject
- •ห้ามใช้ 🟢 ถ้ามี blocker ค้าง ที่กระทบ timeline/scope/quality/customer แม้ทีมจะ "รู้สึก" ว่าคุมได้
- •Planned downtime/maintenance อย่าตีเป็น 🔴 อัตโนมัติ และอย่าใช้ 🟢 (สื่อว่า "ไม่มี impact" ทั้งที่ระบบเข้าไม่ได้จริง) — default ใช้ 🔵 Planned / Controlled impact (มี impact จริงแต่ตามแผน, communicate แล้ว, มี monitoring) · ขยับเป็น 🟡 At risk เมื่อ comms ยังไม่ครบ / window เสี่ยงพลาด / impact สูง · เป็น 🔴 เมื่อ unplanned, เกินเวลา, หรือกระทบเกินแผน
The Ask — ส่วนที่ขาดไม่ได้
ทุก update ต้องจบด้วยหนึ่งในนี้ ระบุชัด:
- •Decision needed: [อะไร] จาก [ใคร] ภายใน [เมื่อไหร่]
- •Action needed: [ทำอะไร] โดย [ใคร] ภายใน [เมื่อไหร่]
- •FYI / no action: ระบุตรงๆ ว่าแค่รับทราบ ไม่ต้องทำอะไร
กฎสำคัญ: ถ้าไม่มี action จริง อย่ายัด ask ปลอม — awareness update, milestone recap, launch announcement ที่ไม่ต้องการการตัดสินใจ ให้ใช้ "FYI / no action" อย่างมั่นใจ การฝืนสร้าง ask ในทุกข้อความทำให้ผู้อ่านชินชาและมองข้าม ask จริงในครั้งที่สำคัญ
ถ้ามีหลาย ask ให้จัดลำดับและบอกว่าอันไหนด่วน/สำคัญสุด — อย่าทิ้ง ask ปนกันใน prose ให้คนอ่านไปขุดเอง
No-blame framing — สำคัญมากเมื่อมี dependency จากทีม/คู่ค้าอื่น
งาน PO/BA เจอ dependency เยอะ (API ทีมอื่น, vendor, partner ส่งข้อมูลช้า, business ยังไม่ sign-off) — ระบุ dependency ให้ชัดเพื่อ actionable แต่ เล่าแบบ fact + solution-oriented ไม่ใช่ชี้นิ้ว
| ❌ อย่าเขียน | ✅ เขียนแบบนี้ |
|---|---|
| "ทีม API ทำให้งานล่าช้า" | "timeline เสี่ยงเพราะ API dependency ที่ยังไม่พร้อมสำหรับ integration" |
| "vendor ส่งของไม่ทันอีกแล้ว" | "รอ environment จาก vendor — ขอ ETA ที่ confirm ได้เพื่อวางแผนต่อ" |
ข้อยกเว้น: ฝั่ง delivery team ภายใน ระบุชื่อทีม/เจ้าของ dependency ตรงๆ ได้ เพราะต้อง actionable — แต่ยังคงน้ำเสียง fact ไม่ใช่ตำหนิ
External / customer / partner guardrails
เมื่อ audience เป็นลูกค้า/คู่ค้า/บุคคลภายนอก เพิ่ม guardrail:
- •ห้ามเปิดเผย internal blocker ที่ไม่จำเป็นต่อการตัดสินใจของเขา
- •ห้ามโทษทีม/คน/vendor ภายใน — ใช้ no-blame framing เสมอ
- •ห้าม promise timeline ที่ยังไม่ confirm — ถ้ายังไม่นิ่งให้บอก "จะแจ้ง next update เมื่อ [เงื่อนไข]"
- •ต้องมีครบ: expected impact + preparation/action (ถ้ามี) + next update (เมื่อไหร่จะได้ยินอีก)
- •น้ำเสียง: calm, professional, non-defensive — ไม่อธิบาย internal process เกินจำเป็น
Output Contract — เลือกตามที่ผู้ใช้ขอ
| โหมด | Output | เมื่อไหร่ |
|---|---|---|
| Quick line | 1-3 บรรทัด: สถานะ + delta + ask | standup, Slack, อัปเดตเร็ว |
| Standard update | สถานะ → คืบหน้า → blocker/risk → next → ask | weekly/ปกติ |
| Exec brief | บนสุด: สถานะ + the ask → ผล/outcome → risk ที่ต้องตัดสินใจ (ตัด detail) | ผู้บริหาร/สปอนเซอร์ |
| Escalation | issue → impact → options → recommendation → decision/action/support needed by [when] | risk/blocker ที่ต้องการการ decide/act/escalate |
| Launch note | what shipped → impact → scope/known issues → next | ประกาศ launch/milestone |
| Scenario template | โหลดจาก references/templates.md | downtime, decision request, delay, PO ops, UAT, release, customer |
ถ้าผู้ใช้ขอ "หลายเวอร์ชันให้เลือก" (เช่น เวอร์ชันนุ่ม vs เวอร์ชันดันให้จบ) ให้ทำหลาย variant พร้อม label บอกว่าแต่ละอันเหมาะกับสถานการณ์ไหน
หลักการที่ห้ามละเมิด
- •มี the ask เสมอ — อ่านจบต้องรู้ว่าต้องทำอะไรต่อ หรือรู้ว่าไม่ต้องทำอะไร (แต่ห้ามยัด ask ปลอม)
- •ไม่ซ่อน Red — risk/blocker/ข่าวร้ายอยู่บนสุด ไม่ใช่ท้ายเอกสาร และไม่กลบด้วย highlight เชิงบวก
- •แยก fact จาก spin — รายงานสิ่งที่เกิดจริง ไม่ใช่สิ่งที่อยากให้เป็น; "เกือบเสร็จ" ที่ไม่มีเกณฑ์คือ spin
- •no-blame — ระบุ dependency ได้ แต่ไม่ชี้นิ้ว โดยเฉพาะกับ external audience
- •ไม่ overclaim "เสร็จ" — เสร็จคือผ่านเกณฑ์/ส่งมอบแล้ว ไม่ใช่ code เขียนเสร็จแต่ยังไม่ verify
- •แปลตามคนฟัง ไม่ใช่ย่อเฉยๆ — exec update ที่แค่เอา detail ทีมมาตัดให้สั้นคือทำผิด ต้องเปลี่ยนเป็นภาษา outcome
- •new-info first; delta-first สำหรับ recurring — เริ่มด้วยสิ่งใหม่ที่ต้องสื่อสารก่อนเสมอ (event/decision/risk); ถ้าเป็น recurring/weekly update ให้เน้น delta จากครั้งก่อน ไม่ทวนทุกอย่างซ้ำ
- •ข้อมูลไม่พอให้บอกตรงๆ ว่าอะไรคือ fact, อะไรคือสิ่งที่เดาไว้และควรยืนยัน
Review checklist — gate ก่อนส่งมอบ
- มี the ask ชัดเจน (decision/action/FYI) พร้อม owner + by-when ถ้าต้องการ action — และไม่ใช่ ask ปลอม
- เปิดด้วยสิ่งที่คนอ่านสนใจสุด ไม่ใช่ลำดับเหตุการณ์
- สถานะ RAG มีเกณฑ์ และ 🟡/🔴 พ่วงเหตุ-ผลกระทบ-ทางแก้
- risk/ข่าวร้ายอยู่ตำแหน่งที่คนอ่านไม่พลาด (บนสุด/subject)
- framing ตรงกับ audience — ตัดสิ่งที่ผู้ฟังคนนี้ไม่ต้องการออกแล้ว
- ถ้าเป็น external: ผ่าน guardrails (ไม่เผย internal blocker, no-blame, ไม่ promise ที่ยังไม่ confirm, มี next update)
- ความยาว/น้ำเสียงเข้ากับ channel
- เริ่มด้วยสิ่งใหม่ก่อน (new-info first); ถ้า recurring/weekly เน้น delta ไม่ทวนของเก่าทั้งหมด
- ไม่มี overclaim — "เสร็จ" คือเสร็จจริง
- ถ้าเดาข้อมูลไว้ ระบุให้ผู้ใช้ยืนยัน
Final label — metadata หลัง draft (ไม่ใช่ส่วนของข้อความที่ส่ง)
หลัง draft ทุกครั้ง ให้แนบ readiness label แยกออกจากตัวข้อความที่จะส่งจริง (เป็นบันทึกถึงผู้ใช้ ไม่ใช่บรรทัดในอีเมล/Slack) — เขียนนอก code block หรือกำกับว่า "Label:" เสมอ:
- •✅ Ready to send — ข้อมูลครบ ส่งได้เลย
- •🟡 Needs minor confirmation — ส่งได้หลังยืนยัน 1-2 จุดที่ระบุ
- •🟠 Needs key detail — ขาดข้อมูลสำคัญ (เช่น the ask, วันที่, audience) ต้องเติมก่อน
- •🔴 Not ready — ข้อมูลไม่พอจะเขียนให้ไม่ misleading
ตัวอย่าง: หลังร่างอีเมล exec → Label: 🟡 Needs minor confirmation — ยืนยันวันใหม่ที่จะ ship ก่อนส่ง
Install & Usage
mkdir -p .claude/skillsAdd the configuration to .claude/skills/sgui-stakeholder-update.md
/sgui-stakeholder-updateUse Cases
Usage Examples
/sgui-stakeholder-update We completed backend API integration and frontend is 80% done, but we need a decision on the color scheme by Friday to avoid delay. Audience: product manager, channel: Slack, cadence: weekly.
/sgui-stakeholder-update Our database migration is at risk due to unexpected schema conflicts. We need to decide whether to rollback or extend the timeline. Make this an escalation for the VP of Engineering.
/sgui-stakeholder-update The new feature launch is on track for next Monday. Please prepare the customer-facing announcement and confirm go/no-go by Thursday. Audience: marketing team, channel: email.
Security Audits
Frequently Asked Questions
What is sgui-stakeholder-update?
This skill transforms raw status, progress, risks, decisions, or events into concise stakeholder updates that answer 'so what' for the audience and end with a clear ask. It helps developers communicate effectively with executives, teams, or partners by reframing information for the right audience, cadence, and channel.
How to install sgui-stakeholder-update?
To install sgui-stakeholder-update: create the skills directory (mkdir -p .claude/skills), then add the config to .claude/skills/sgui-stakeholder-update.md. Finally, /sgui-stakeholder-update in Claude Code.
What is sgui-stakeholder-update best for?
sgui-stakeholder-update is a other categorized under General. It is designed for: code-review. Created by sgui.
What can I use sgui-stakeholder-update for?
sgui-stakeholder-update is useful for: Convert a list of completed tasks into a weekly status update for your engineering manager.; Reframe a project delay into an escalation notice for the executive sponsor with a decision request.; Turn a risk identification into a Slack message for the team with a clear ask for mitigation.; Create a launch milestone notification for customers or partners highlighting key dates and next steps.; Draft a planned downtime maintenance notice for internal stakeholders with impact and timeline.; Transform a decision log entry into a decision request email for a cross-functional audience..