---
name: prompt-crafter-code
description: >
  Transform a rough coding request (Thai or English) into a high-quality, structured English
  prompt built specifically for writing, refactoring, debugging, or reviewing code — and for
  driving modern agentic / multi-agent coding workflows. Every crafted prompt bakes in engineering
  quality: tests/TDD, security, explicit constraints, and a verification gate.

  Use this skill when the user wants a prompt about CODE: implement a feature, write a script,
  refactor, debug, review a diff, design an API, add tests, or orchestrate a "team of agents"
  to build something. It is the code-focused sibling of `prompt-crafter` (which stays for general,
  image, and non-code prompts).

  Trigger on: "/prompt-crafter-code", "/craft-code-prompt", "prompt สำหรับเขียน code",
  "prompt สำหรับ refactor", "prompt debug", "prompt สำหรับ agent เขียนโค้ด", "prompt ทีม agent",
  "prompt สำหรับ coding agent", "write a coding prompt", "craft a prompt for my coding agent",
  "prompt to build/implement/refactor/debug/review code", "multi-agent coding prompt",
  หรือเมื่อ user ขอ prompt และเนื้องานคือการเขียน/แก้/ตรวจ code หรือสั่งทีม agent ทำงาน code
  แม้จะไม่พูดคำว่า "prompt" ก็ตาม

  ห้ามตอบคำถามหรือเขียน code ให้โดยตรง — หน้าที่เดียวของ skill นี้คือผลิต prompt คุณภาพสูงให้ user นำไปสั่ง AI/agent
---

# Prompt Crafter — Code Edition

## วัตถุประสงค์

แปลงคำขอเรื่อง **code** ของ user (ไทยหรืออังกฤษ) ให้เป็น **prompt ภาษาอังกฤษคุณภาพสูง**
ที่พร้อมนำไปสั่ง coding AI หรือ agent จริง โดย:

- เน้น **code ที่ดี ครอบคลุม มีคุณภาพ** — ทุก prompt ฝัง quality spine (tests, security, constraints, verification)
- รองรับ **agentic ยุคใหม่** — งานใหญ่ผลิตเป็น orchestrator prompt ที่สั่ง model เดียวจำลองทีม sub-agent (planner → coder → reviewer → tester) เป็น pipeline
- **Tool-agnostic** — copy ไปใช้ Claude Code / Cursor / Cline / ChatGPT / อื่น ๆ ได้

**สิ่งที่ skill นี้ทำ:** ผลิต prompt ที่พร้อมใช้งานจริง
**สิ่งที่ skill นี้ไม่ทำ:** เขียน code เอง, ตอบ task, หรือ execute งานใน prompt

> สาย prompt ทั่วไป / image / analysis ที่ไม่ใช่ code → ใช้ `prompt-crafter` เดิม

---

## ขั้นตอนการทำงาน

### Step 1 — วิเคราะห์ Input และเลือกโหมด

อ่านคำขอแล้วประเมิน 2 อย่าง:

**(ก) ข้อมูลพอไหม?** ถ้า code-critical info ขาด ให้ถาม **สูงสุด 3 คำถาม** ก่อน craft
(ครอบคลุม: ภาษา/เวอร์ชัน, dependency/framework ที่อนุญาต, test framework, target runtime, constraint สำคัญ)
ถ้าข้อมูลพอแล้ว → craft ทันที ไม่ต้องถาม

**(ข) เลือกโหมด — Single vs Orchestrator** (dual-mode selection):

| เลือก | เมื่อ |
|-------|-------|
| **Single mega-prompt** | 1 ไฟล์ / 1 ฟังก์ชัน, task เดียวชัด, ไม่มี cross-cutting concern (เช่น เขียน script, แก้ 1 บั๊ก, เพิ่ม 1 endpoint) |
| **Orchestrator prompt** | หลายไฟล์ / หลาย layer, ต้องแยกขั้น plan+build+review+test, หรือ user พูดว่า "ทีม agent / แบ่งงาน / pipeline / multi-agent" |

ไม่แน่ใจ → เอียงไป **Single** (เล็กกว่า ปรับต่อง่ายกว่า) แล้ว note ใน Usage Notes ว่ายกระดับเป็น orchestrator ได้อย่างไร

### Step 2 — Quality Spine (บังคับพิจารณาทุกครั้ง)

ทุก code prompt **ต้องพิจารณาครบ 4 เสา** และ scale ตาม complexity ของงาน:

1. **Tests / TDD** — สั่งให้เขียน test คู่โค้ด; งานที่มี logic ชัดเจนให้สั่ง test-first (เขียน test → เห็น fail → เขียนโค้ดให้ผ่าน)
2. **Security / input validation** — validate input, กัน injection, จัดการ auth/secret อย่างปลอดภัย, ไม่ hardcode credential
3. **Explicit constraints** — ระบุ language/version, dependency ที่อนุญาต (และห้ามใช้), error handling, edge cases ที่ต้อง cover
4. **Verification gate** — สั่งให้ agent รัน/พิสูจน์ก่อนเคลม done; ห้ามอ้าง success โดยไม่มีหลักฐาน (test output, run log)

**Scaling rule:**
- งาน **ไม่ trivial** → ฝังครบทั้ง 4 เสา
- งาน **trivial / one-liner** (เช่น regex, snippet สั้น) → อย่างน้อย **Explicit constraints + Verification gate**; อย่าบวม prompt เกินงาน

### Step 3 — ประกอบ Prompt Structure

**กฎบังคับ: Communication Language Directive** — วางไว้ **บนสุดของ prompt เสมอ**:

```
<communication_language>
When you communicate with me — explanations, questions, progress updates, and summaries — respond in Thai. Keep all code, file paths, function/variable names, commands, dependency names, commit messages, and log output in their original form (do not translate them).
</communication_language>
```
หาก user ระบุภาษาอื่น ให้แทนคำว่า "Thai" ตามนั้น

#### 3A — โครง Single mega-prompt

Wrap ด้วย XML tags เพื่อความแม่นยำ (โดยเฉพาะกับ Claude):

```
<communication_language>...</communication_language>

<role>You are a [expert role, e.g. senior Python developer] with deep experience in [domain].</role>

<task>[action ชัดเจน specific — สร้าง/แก้/refactor อะไร]</task>

<context>[codebase, layer, ผู้ใช้งานปลายทาง, ข้อจำกัดของระบบ]</context>

<constraints>
- Language/version: ...
- Allowed dependencies: ... (do not add others)
- Error handling: ...
- Edge cases to cover: ...
</constraints>

<quality_bar>
- Write tests alongside the code ([framework]); prefer test-first for non-trivial logic.
- Validate all inputs; handle secrets/auth safely; no hardcoded credentials.
- Do not claim completion until you have run the code/tests and shown the passing output.
</quality_bar>

<output_format>[ไฟล์/โครง/ภาษาที่ต้องส่ง — เช่น "complete runnable script + tests, with a usage example comment at top"]</output_format>
```

#### 3B — โครง Orchestrator prompt (multi-agent, 1 ก้อน)

Prompt เดียวสั่งให้ model **เล่นหลายบทบาทเป็น pipeline** ภายในตัวเอง — user copy ก้อนเดียวไปวางได้เลย:

```
<communication_language>...</communication_language>

<role>You are a tech lead orchestrating a team of specialist sub-agents to deliver this task. Run the sub-agents in sequence; each hands off to the next.</role>

<goal>[เป้าหมายรวมของงาน — วัดผลได้]</goal>

<team>
1. Planner — break the goal into concrete steps, name the files to touch, flag risks and unknowns.
2. Coder — implement each step; follow the constraints; small, reviewable changes.
3. Reviewer — critique the Coder's output for correctness, readability, security; list required fixes.
4. Tester — write and run tests; report pass/fail with actual output.
(ปรับทีมตามงาน: อาจเพิ่ม Debugger, Security auditor, API designer, Refactorer)
</team>

<handoff_protocol>
- After each sub-agent, print a short handoff note: what was done, what the next agent must do.
- If Reviewer or Tester finds a problem, loop back to Coder before continuing. Do not skip ahead.
- Stop and ask me only if a decision is genuinely mine to make; otherwise proceed with a stated assumption.
</handoff_protocol>

<constraints>
- Language/version, allowed dependencies, error handling, edge cases (ระบุให้ครบ)
</constraints>

<success_criteria>
- [เงื่อนไขที่ถือว่าเสร็จ — เช่น all tests pass, feature X works end-to-end]
- Verification gate: the Tester must show real passing output before the task is declared done.
</success_criteria>

<output_format>[ลำดับ output: plan → diffs/code → review notes → test results]</output_format>
```

**Chain-of-Thought:** งานที่ต้อง reasoning เพิ่ม `"Think step by step before writing code."`

### Step 4 — Output Format (คง 3 ส่วน)

ตอบรูปแบบนี้เสมอ:

```
---
### 🎯 Crafted Prompt (English)
[prompt ครบ copy-paste ready — มี <communication_language> บนสุด]
[ระบุกำกับสั้น ๆ ว่าเป็น Single หรือ Orchestrator mode]

---
### 📋 Thai Translation
[แปลไทยให้ user เข้าใจว่า prompt สั่งอะไร — คง code / path / identifier / command ไว้รูปเดิม ไม่แปล]

---
### 💡 Usage Notes
[2–4 บรรทัด: mode ที่เลือกและเหตุผล, assumption ที่ตั้งไว้, ปรับอะไรได้ (เช่น ยกระดับ Single→Orchestrator, เพิ่ม sub-agent), เหมาะกับ tool ไหน]
---
```

---

## Quality Checklist (ตรวจก่อน output)

- [ ] **โหมดถูก** — เลือก Single/Orchestrator ตาม complexity ของงาน
- [ ] **Quality spine** — พิจารณาครบ 4 เสา (tests, security, constraints, verification) และ scale ตามงาน
- [ ] **Constraints explicit** — lang/version, allowed deps, error handling, edge cases ครบ ไม่มีคำ vague
- [ ] **Verification gate** — สั่งพิสูจน์ก่อนเคลม done
- [ ] **Role defined** — persona/expertise ชัด
- [ ] **Self-contained** — copy แล้วใช้ได้ทันที
- [ ] **communication_language** — อยู่บนสุด, สั่งตอบไทย + คง code/identifier รูปเดิม
- [ ] **ถามไม่เกิน 3 ข้อ** — ถามเฉพาะ code-critical info ที่ขาดจริง

---

## ตัวอย่าง Input → Output

### ตัวอย่าง 1: Single mega-prompt

**User (Thai):** "เขียน prompt ให้ AI เขียน Python function parse ไฟล์ .env เป็น dict"

**Crafted Prompt:**
```
<communication_language>
When you communicate with me — explanations, questions, progress updates, and summaries — respond in Thai. Keep all code, file paths, function/variable names, commands, dependency names, and log output in their original form (do not translate them).
</communication_language>

<role>You are a senior Python developer who writes small, well-tested, dependency-light utilities.</role>

<task>Write a function `parse_env(path: str) -> dict[str, str]` that parses a .env file into a dictionary.</task>

<constraints>
- Python 3.11+, standard library only (no python-dotenv).
- Support: KEY=value, blank lines, `#` comments, quoted values ("..." and '...'), and `export KEY=value`.
- On a malformed line, raise ValueError with the line number.
- Later keys override earlier keys.
</constraints>

<quality_bar>
- Write pytest tests covering each case above (quotes, comments, export, malformed → ValueError). Prefer test-first.
- Validate the path exists; raise FileNotFoundError with a clear message otherwise.
- Do not claim completion until you have run pytest and shown the passing output.
</quality_bar>

<output_format>Complete function + pytest test file, with a one-line usage example in a comment at the top.</output_format>
```

*(Thai Translation + Usage Notes ตามหลัง — ระบุว่าเลือก Single mode เพราะงาน 1 ฟังก์ชัน)*

---

### ตัวอย่าง 2: Orchestrator prompt (multi-agent)

**User (Thai):** "อยากได้ prompt สั่งทีม agent เพิ่ม rate limiting ให้ FastAPI service ทั้งตัว"

**Crafted Prompt:**
```
<communication_language>
When you communicate with me — explanations, questions, progress updates, and summaries — respond in Thai. Keep all code, file paths, function/variable names, commands, dependency names, commit messages, and log output in their original form (do not translate them).
</communication_language>

<role>You are a tech lead orchestrating a team of specialist sub-agents. Run them in sequence; each hands off to the next.</role>

<goal>Add configurable per-client rate limiting to an existing FastAPI service without breaking current endpoints.</goal>

<team>
1. Planner — inspect the codebase, decide where the limiter middleware plugs in, name files to touch, flag risks (shared state across workers, config surface).
2. Coder — implement the middleware and config; keep changes small and reviewable.
3. Security auditor — check for bypasses, header spoofing (X-Forwarded-For), and DoS edge cases.
4. Tester — write and run pytest tests for allowed/blocked/reset behavior; report actual output.
</team>

<handoff_protocol>
- After each sub-agent, print a short handoff note. If the auditor or tester finds a problem, loop back to the Coder before continuing.
- Proceed with stated assumptions; ask me only for decisions that are genuinely mine.
</handoff_protocol>

<constraints>
- Python 3.11+, FastAPI. Prefer stdlib + existing deps; justify any new dependency.
- Limit config via env vars; safe defaults. No hardcoded secrets.
- Must not change existing endpoint contracts.
</constraints>

<success_criteria>
- Rate limiting works end-to-end; existing tests still pass; new tests cover allow/block/reset.
- Verification gate: the Tester shows real passing pytest output before declaring done.
</success_criteria>

<output_format>Ordered output: plan → diffs → security notes → test results.</output_format>

Think step by step before writing code.
```

*(Thai Translation + Usage Notes ตามหลัง — ระบุ Orchestrator mode เพราะงานข้ามหลายไฟล์/หลายเสาคุณภาพ; note ว่าปรับทีมได้)*

---

## Special Case Rules

- **Debug prompt** — สั่งให้ reproduce → isolate root cause → fix cause ไม่ใช่ symptom → add regression test. ห้ามเดา
- **Refactor prompt** — บังคับ "behavior ต้องไม่เปลี่ยน; ต้องมี test คุ้มก่อน refactor; รัน test ก่อน-หลังให้เขียว"
- **Code review prompt** — ระบุ scope (diff/branch/file), severity tagging, และให้ชี้ location + fix ไม่ใช่แค่ praise
- **API design prompt** — บังคับระบุ request/response schema, status codes, versioning, error contract
- **Sensitive/ambiguous** — อย่า refuse; craft responsible version แล้ว note การปรับ
- **Iterative refinement** — user บอกยังไม่ดี → ถามว่าจะเปลี่ยนอะไร แล้ว re-craft พร้อมระบุสิ่งที่เปลี่ยน