ส่วนเสริม design-system

มอบ DESIGN.md ให้ repository ที่มีพื้นผิวอินเทอร์เฟซที่ผู้ใช้มองเห็น — ไฟล์ระบบดีไซน์รูปแบบ Markdown ที่เอเจนต์เขียนโค้ดทุกตัวอ่านเพื่อสร้างเอาต์พุตอินเทอร์เฟซที่สอดคล้องกับข้อตกลงของ repo เอง แทนที่จะเป็นค่าเริ่มต้นที่ไม่มีสไตล์และพบบ่อยทางสถิติซึ่งเอเจนต์มักหวนกลับไปใช้เมื่อไม่มีคำชี้แนะ นี่คือส่วนเสริม Deep Work Plan แบบเลือกเข้าร่วมตัวที่สี่

“พื้นผิวอินเทอร์เฟซ” มีได้หลายแบบ: UI เชิงภาพที่เรนเดอร์ออกมา เอาต์พุต CLI ที่จัดสไตล์ และพื้นผิวเชิงสนทนา (ผลิตภัณฑ์พูดคุยบนแชตหรืออีเมล) แต่ละอย่างนับทั้งสิ้น ส่วนเสริมนี้ตรวจพบแต่ละอย่างอย่างเป็นอิสระในฐานะโปรไฟล์ และโปรไฟล์ที่ได้รับการยอมรับจะซ้อนรวมกันลงใน DESIGN.md ไฟล์เดียวเดิม

สิ่งที่มันเพิ่มเข้ามา

• DESIGN.md ที่ docs/DESIGN.md (อยู่เคียงข้างสเปกอื่น ๆ ของ repo; จะวางไว้ที่รากของ repo ก็ต่อเมื่อไม่มีโครงสร้าง docs/ เท่านั้น) อ้างอิงจาก AGENTS.md เพื่อให้เอเจนต์ค้นพบมันเหมือนกับเอกสารอื่น ๆ หนึ่ง repo หนึ่งไฟล์ — ไม่มีไฟล์พี่น้องแยกตามพื้นผิวเด็ดขาด
• โปรไฟล์ visual-ui — หมวดเชิงภาพมาตรฐานต่าง ๆ ได้แก่ ภาพรวม/บรรยากาศ พาเลตต์สีและบทบาท (โหมดสว่าง + โหมดมืด) งานพิมพ์ เลย์เอาต์และระยะห่าง การยกระดับและความลึก รูปทรง คอมโพเนนต์ พฤติกรรมเชิงตอบสนอง สิ่งที่ควรทำและไม่ควรทำ (รวมถึงกฎการเข้าถึงของ repo)
• โปรไฟล์ cli-output — อินเทอร์เฟซเทอร์มินัลที่จัดสไตล์: น้ำเสียงของเอาต์พุต สีและสไตล์เชิงความหมาย (success/error/warning/info/dim ที่จับคู่กับธีมจริง) คอมโพเนนต์เอาต์พุต (แผง ตาราง สปินเนอร์ พรอมต์เชิงโต้ตอบ — ตั้งชื่อตามตัวช่วยจริงของ repo) ข้อตกลงด้านเลย์เอาต์ และกฎการลดระดับ (TTY เทียบกับไพป์ NO_COLOR วินัย stdout/stderr และโค้ดออกจากโปรแกรม)
• โปรไฟล์ conversational — พื้นผิวการส่งข้อความของผลิตภัณฑ์: น้ำเสียงและระดับภาษา (โทน ความกระชับ กฎการเรียกชื่อแบรนด์) กายวิภาคของข้อความ (DM โพสต์ในแชนเนล การตอบในเธรด การแก้ไขในที่) และการเรนเดอร์ต่อแพลตฟอร์ม (Slack mrkdwn, Discord markdown, Teams adaptive cards, อีเมล) พร้อมข้อความสำรองแบบ plain text
• ไกด์พรอมต์สำหรับเอเจนต์ที่ใช้ร่วมกัน บวกขั้นตอนตรวจสอบที่เช็กความสมบูรณ์ของแต่ละโปรไฟล์: คอนทราสต์ของข้อความที่บันทึกไว้เป็นไปตาม WCAG AA (เชิงภาพ) สีไม่เคยเป็นตัวพาความหมายเพียงอย่างเดียว (CLI) การเรนเดอร์แบบ rich ระบุข้อความสำรองแบบ plain text (เชิงสนทนา) และการอ้างอิง token แปลงค่าได้

พฤติกรรม

• ให้เหตุผล อย่าคัดลอก ทุกค่ามาจากแหล่งดีไซน์จริงของ repo — สไตล์ชีต CSS custom properties การกำหนดค่า Tailwind ไฟล์ token สไตล์ของคอมโพเนนต์ โมดูลแสดงผล/ธีมของ CLI หรือตัวช่วยประกอบข้อความของมัน มันไม่เคยแปะ DESIGN.md ของแบรนด์บุคคลที่สาม และไม่นำเข้าข้อตกลงของผลิตภัณฑ์อื่นมาทั้งยวง แคตตาล็อกอ้างอิงเป็นเพียงแรงบันดาลใจสำหรับโครงสร้าง ไม่ใช่เนื้อหา
• กระทบยอด อย่าทับ DESIGN.md หรือแหล่ง token ที่มีอยู่จะถูกกระทบยอดแบบเพิ่มเติม ไม่เคยถูกเขียนทับ การเพิ่มโปรไฟล์ที่เพิ่งได้รับการยอมรับจะผนวกหมวดของมันเข้าไปโดยไม่เขียนส่วนที่เหลือใหม่ การเปลี่ยนแปลงที่ทำลายต้องได้รับอนุมัติ
• ค้นพบด้วยการอ้างอิง ไม่ว่า DESIGN.md จะอยู่ที่ใด AGENTS.md (และ CLAUDE.md) อ้างอิงถึงมัน — ตัวชี้ ไม่ใช่ตำแหน่งทางกายภาพ คือสิ่งที่รับประกันว่าเอเจนต์จะโหลดมัน
• เน้นปฏิบัติได้จริง ไม่ผูกตายตัว มันอ้างอิงข้อตกลง DESIGN.md ที่กำลังก่อตัวขึ้นในฐานะรูปแบบที่จะทำตาม ขยายมันไปยังพื้นผิวที่ไม่ใช่เชิงภาพ และยังคงยึด Markdown เป็นหลักโดยไม่ผูกติดกับ schema ของ token ใด ๆ เพียงตัวเดียว

จำกัดขอบเขตเฉพาะอินเทอร์เฟซ พร้อมระดับคำแนะนำต่อโปรไฟล์

ส่วนเสริมนี้สำหรับ repo ที่มีพื้นผิวอินเทอร์เฟซจริงอย่างน้อยหนึ่งอย่าง มันไม่เคยถูกเสนอให้กับ repo ที่ไม่มีเลย (ไลบรารีล้วน บริการแบบ headless หรือ repo เฉพาะโครงสร้างพื้นฐาน) แต่ละโปรไฟล์มีระดับคำแนะนำของตัวเอง:

• visual-ui เปิดใช้งานเป็นค่าเริ่มต้นเมื่อตรวจพบ — สไตล์ชีตที่มี CSS custom properties การกำหนดค่า Tailwind หรือบล็อก @theme คอมโพเนนต์ UI หรือไกด์แบรนด์/สไตล์ การออนบอร์ดจะใช้มันในโหมดไว้วางใจและแนะนำอย่างหนักแน่นในโหมดมีคำแนะนำ
• cli-output และ conversational ถูกแนะนำเมื่อตรวจพบ — และถูกถามเสมอ ไม่เคยถูกใช้อัตโนมัติ แม้ในโหมดไว้วางใจก็ตาม ไลบรารีเรนเดอร์ CLI บวกชั้นแสดงผลที่สร้างอย่างจงใจเป็นสัญญาณของอย่างแรก SDK ของแพลตฟอร์มแชตหรือชั้นประกอบข้อความเป็นสัญญาณของอย่างหลัง ตัวแยกวิเคราะห์อาร์กิวเมนต์เปล่า ๆ ที่พิมพ์ผลแบบดิบ ๆ ไม่เข้าเกณฑ์

มันไม่เคยถูกบังคับ — repository ที่ไม่มีส่วนเสริมใด ๆ ก็สอดคล้องอย่างสมบูรณ์ และคุณปฏิเสธโปรไฟล์ใดก็ได้หรือทั้งส่วนเสริมได้เสมอ DESIGN.md ที่สร้างก่อนจะมีโปรไฟล์ถือเป็นไฟล์เชิงภาพแบบโปรไฟล์เดียวที่ใช้ได้: ไม่ต้องย้ายระบบ

คำสั่งเสริม

เมื่อยอมรับ ส่วนเสริมอาจติดตั้งตัวส่งต่อ /design-system ลงใน .agents/commands/ ของ repo เพื่อสร้างหรือรีเฟรช DESIGN.md ใหม่ในภายหลัง การติดตั้งคำสั่งเป็นทางเลือก ส่วนเสริมที่ถูกปฏิเสธจะไม่ติดตั้งคำสั่งใด ๆ

ความสัมพันธ์กับเอกสารดีไซน์ระดับฟีเจอร์

นี่คือไฟล์ระบบดีไซน์ ระดับ repo ที่คงอยู่ถาวร — แตกต่างจากเอกสารดีไซน์เชิงเทคนิคระดับฟีเจอร์ (ไฟล์ design.md แบบ “requirements → design → tasks” ของเวิร์กโฟลว์ spec-driven ที่ผูกกับเครื่องมือ) Deep Work Plan จงใจไม่จัดส่ง archetype เอกสารดีไซน์ระดับฟีเจอร์แยกต่างหาก: README ของแผน เกณฑ์การยอมรับของแต่ละงาน และ validation gate ครอบคลุมบทบาทนั้นอยู่แล้ว ส่วนเสริมนี้เติมเต็มช่องว่างหนึ่งเดียวที่บทบาทนั้นไม่ได้ครอบคลุม: บริบทดีไซน์อินเทอร์เฟซที่คงทนและเป็นเนื้อแท้ของ repo