spk-spk

name	spk-spk
description	เลือก SPK workflow ที่เล็กและตรงที่สุดสำหรับงาน software engineering ระบุ effect level และรักษา approval gates
argument-hint	[เป้าหมายหรือคำถามด้าน software engineering]
user-invocable	true

SPK Router

เลือก workflow ให้ตรงคำขอ อย่าเปลี่ยน routing ให้กลายเป็น planning รอบที่สอง effect สูงสุดที่ router ประกาศคือ PROJECT_WRITE เพราะอาจรัน local-write workflow ที่เลือก ส่วน receipt ต้องรายงาน effect จริงของ workflow นั้น

Workflow

1. อ่าน repository instructions และ outcome ที่ user ขออย่างชัดเจน
2. จัด effect level ก่อนลงมือ:
   • READ_ONLY: query, Bala, Sunzi, debug diagnosis, review, release check, doctor
   • PROJECT_WRITE: prime, plan/wiki update, code/TDD, design artifacts, ingest และ temporary guard marker ของ wiki lint
   • EXTERNAL_WRITE: deploy หรือ PR writes
   • DESTRUCTIVE: uninstall
3. เลือก primary workflow เดียว:
   • user ใหม่หรือไม่รู้เริ่มตรงไหน → jumpstart
   • requirements/architecture/tasks → plan
   • approved plan/bounded implementation → code; red-first ชัดเจน → TDD
   • failure ที่ยังไม่รู้ root cause → debug ก่อน implement
   • ตรวจ diff/branch → review; feedback เร็วจาก changed files → scoped tests
   • สำรวจ UI → design shotgun
   • wiki question/source/health → query, ingest, wiki lint
   • engineering judgment → Bala หรือ Sunzi
   • release readiness → release check; installation health → doctor
4. ทำ workflow นั้นใน current conversation ใช้ผู้ช่วยย่อยเฉพาะงานอิสระเมื่อ host รองรับ ไม่งั้นทำ sequential
5. ห้ามเข้า deploy, PR write หรือ uninstall อัตโนมัติ ต้องให้ user invoke manual-only workflow และผ่าน bound approval envelope
6. อย่า chain workflow ที่อยู่ใกล้กันโดยไม่จำเป็น แนะนำเป็น next action เว้นแต่ original request รวมทั้งสองงานไว้ชัด

Evidence Receipt

ก่อน output ของ selected workflow ให้ระบุ:

{
  "schema": "spk.route/v1",
  "workflow": "<selected workflow>",
  "effect": "READ_ONLY | PROJECT_WRITE | EXTERNAL_WRITE | DESTRUCTIVE",
  "reason": "<หนึ่งประโยค>",
  "approval_required": false
}

ถ้าเป็น manual-only ให้ตั้ง approval_required เป็น true และหยุดที่ approval protocol ก่อน mutate

ข้อควรระวัง

• ชอบ workflow เดียวที่ตรงกว่า pipeline ใหญ่
• Diagnose ก่อน fix และ verify หลัง material write
• ห้ามเดา authorization สำหรับ external/destructive action
• รักษา approval, evidence และ safety rules ของ selected workflow