---
name: project-job-description
description: >
  ใช้ทุกครั้งเมื่อผู้ใช้ต้องการวิเคราะห์ source code หรือ codebase ของโปรเจกต์จริง
  แล้วแปลงเป็น Job Description, resume work experience, portfolio entry,
  career highlight หรือ technical accomplishment summary ในรูปแบบ Markdown
  ที่ recruiter อ่านเข้าใจง่าย รวมถึงคำขออย่าง "ช่วยสรุปโปรเจกต์นี้ลง resume",
  "เขียนผลงานจากโค้ดนี้", "ทำ portfolio จากโปรเจกต์", "อธิบายงานที่ทำจาก codebase"
  หรือ "แปลงโปรเจกต์เป็น JD" ไม่ใช้กับการเขียน job description ทั่วไป,
  rewrite resume, career advice หรือคำแนะนำสมัครงานที่ไม่ได้อ้างอิง source code
  หรือหลักฐานจากโปรเจกต์จริง
---

# Project Job Description

Skill สำหรับวิเคราะห์ source code ของโปรเจกต์แล้วสรุปเป็น Job Description มืออาชีพในรูปแบบ Markdown
ที่พร้อมใช้งานใน resume, portfolio และ career profile

## ภาพรวมกระบวนการทำงาน

กระบวนการทำงานมาตรฐานแบ่งเป็น 6 ขั้นตอนหลักตามลำดับ ปรับความละเอียดได้ตาม scope ที่ผู้ใช้ต้องการ
และขนาดของโปรเจกต์ หากผู้ใช้ต้องการเพียง resume bullets สั้น ๆ หรือมีเพียง snippet ให้ลดขั้นตอนที่ไม่จำเป็นได้
แต่ต้องระบุ assumption หรือข้อมูลที่ข้ามไว้ให้ชัดเจน

```
สแกนโครงสร้าง → ตรวจจับ Tech Stack → วิเคราะห์ Features → แมปบทบาท → เขียน Achievements → ส่งออก Markdown
```

## ขั้นตอนที่ 1: สแกนโครงสร้างโปรเจกต์

เริ่มจากการทำความเข้าใจภาพรวมของโปรเจกต์ก่อนลงลึกรายละเอียด เพื่อให้เห็นขอบเขตและความซับซ้อนของระบบ

### สิ่งที่ต้องทำ

1. ใช้ `rg --files` เป็นเครื่องมือหลักในการแสดงไฟล์ของโปรเจกต์ และจำกัดผลลัพธ์ให้เห็นโครงสร้างระดับ 2 ชั้นเมื่อเป็นไปได้
2. นับจำนวนไฟล์ source code ทั้งหมดด้วยคำสั่งที่เหมาะกับ shell ปัจจุบัน แยกตามนามสกุล เพื่อประเมินขนาดโปรเจกต์
3. ระบุไดเรกทอรีหลักที่บ่งบอกสถาปัตยกรรม (เช่น src, lib, api, components, models, routes, services)
4. ระบุ entry point หลักของโปรเจกต์ (เช่น main, index, app, server)

หากโปรเจกต์มีไฟล์จำนวนมาก ให้เริ่มจากการสรุป root directories, config files และ entry points สำคัญก่อน
แล้วค่อยอ่านรายละเอียดเฉพาะส่วนที่จำเป็นต่อการเขียน JD เพื่อหลีกเลี่ยงการไล่อ่านไฟล์ที่ไม่ส่งผลต่อผลลัพธ์

### ตัวอย่างคำสั่งสแกน

ใช้ `rg --files` ก่อนเสมอเพราะทำงานเร็วและใช้ได้ข้าม platform:

```powershell
rg --files C:\path\to\project
```

ตัวอย่างดูโครงสร้างระดับบนสำหรับ PowerShell:

```powershell
Get-ChildItem -Path 'C:\path\to\project' -Directory |
  Select-Object -ExpandProperty Name
```

ตัวอย่างสำหรับ PowerShell:

```powershell
$SOURCE_EXTENSIONS = '.ts', '.tsx', '.js', '.jsx', '.py', '.go', '.rs', '.java', '.rb', '.cs', '.php', '.swift', '.kt'
$EXCLUDED_PATTERN = '\\(node_modules|vendor|__pycache__|\.git)\\'

Get-ChildItem -Path 'C:\path\to\project' -Recurse -File |
  Where-Object { $SOURCE_EXTENSIONS -contains $_.Extension -and $_.FullName -notmatch $EXCLUDED_PATTERN } |
  Group-Object Extension |
  Sort-Object Count -Descending
```

ตัวอย่างสำหรับ Unix shell:

```bash
rg --files /path/to/project \
  | rg -v '(^|/)(node_modules|vendor|__pycache__|\.git)(/|$)' \
  | rg '\.(ts|tsx|js|jsx|py|go|rs|java|rb|cs|php|swift|kt)$'
```

หาก `rg` ไม่มีใน environment ให้ใช้เครื่องมือ native ของ shell นั้นแทน และบอกผู้ใช้สั้น ๆ ว่าใช้ fallback ใด

## ขั้นตอนที่ 2: ตรวจจับ Tech Stack

อ่านไฟล์ config และ dependency เพื่อระบุเทคโนโลยีที่ใช้จริงในโปรเจกต์ ขั้นตอนนี้สำคัญมากเพราะ tech stack
ที่ถูกต้องทำให้ recruiter ค้นหาโปรไฟล์ได้ตรง keyword

### ไฟล์ที่ต้องอ่าน (ตามลำดับความสำคัญ)

อ่านเฉพาะไฟล์ที่มีอยู่จริงในโปรเจกต์ก่อน หากไฟล์ใดไม่มี ไม่ต้องค้นหาต่อจนเกินจำเป็น
ให้ข้ามไปยังไฟล์หรือไดเรกทอรีถัดไปที่มีหลักฐานอยู่จริง

| ลำดับ | ไฟล์                                                                     | สิ่งที่ได้                                                    |
| ----- | ------------------------------------------------------------------------ | ------------------------------------------------------------- |
| 1     | `package.json`                                                           | JavaScript/TypeScript dependencies, scripts, project metadata |
| 2     | `requirements.txt`, `Pipfile`, `pyproject.toml`, `setup.py`, `setup.cfg` | Python dependencies                                           |
| 3     | `go.mod`, `go.sum`                                                       | Go modules                                                    |
| 4     | `Cargo.toml`                                                             | Rust crates                                                   |
| 5     | `Gemfile`                                                                | Ruby gems                                                     |
| 6     | `pom.xml`, `build.gradle`, `build.gradle.kts`                            | Java/Kotlin dependencies                                      |
| 7     | `composer.json`                                                          | PHP dependencies                                              |
| 8     | `*.csproj`, `*.sln`                                                      | .NET dependencies                                             |
| 9     | `Package.swift`, `Podfile`                                               | Swift/iOS dependencies                                        |
| 10    | `pubspec.yaml`                                                           | Dart/Flutter dependencies                                     |
| 11    | `docker-compose.yml`, `Dockerfile`                                       | Infrastructure และ services                                   |
| 12    | `schema.graphql`, `*.proto`, `asyncapi.yaml`                             | สัญญาและรูปแบบการสื่อสารระหว่างบริการ                         |
| 13    | `terraform/*.tf`, `k8s/*.yaml`, `helm/`                                  | Infrastructure as Code                                        |
| 14    | `.nvmrc`, `.node-version`, `.python-version`, `.ruby-version`            | เวอร์ชัน runtime ที่กำหนดสำหรับโปรเจกต์                       |
| 15    | `.env.example`, `.env.sample`                                            | Environment variables (ระบุ services ที่เชื่อมต่อ)            |
| 16    | `prisma/schema.prisma`, `migrations/`, `alembic/`                        | Database schema และ ORM                                       |

### การจัดหมวดหมู่ Tech Stack

จัดกลุ่มเทคโนโลยีที่พบเป็นหมวดหมู่ต่อไปนี้ เรียงตามความสำคัญที่ recruiter มักค้นหา

1. **ภาษาโปรแกรม** — ภาษาหลักที่ใช้พัฒนา
2. **Frontend** — framework, UI library, state management, styling
3. **Backend** — framework, runtime, API style (REST/GraphQL/gRPC)
4. **ฐานข้อมูล** — RDBMS, NoSQL, cache, search engine
5. **Cloud & Infrastructure** — cloud provider, containerization, orchestration
6. **Security & Authentication** — authentication provider, authorization, session management
7. **Messaging & Background Processing** — message queue, event stream, background worker, task scheduler
8. **เครื่องมืออื่น ๆ** — payment, external storage, third-party integration

### สิ่งที่ต้องระวัง

- แยก devDependencies ออกจาก dependencies เพราะ devDependencies มักเป็นเครื่องมือพัฒนาไม่ใช่ feature หลัก
- ตรวจสอบ dependency สำคัญที่ต้องนำไปกล่าวในผลลัพธ์ว่ามีหลักฐานการใช้งานจริงในโค้ดหรือ config อย่าไล่ตรวจทุก dependency ในโปรเจกต์ใหญ่หากไม่จำเป็น
- ห้ามระบุเลขเวอร์ชันของ dependency ใดๆ ในผลลัพธ์ เพราะเวอร์ชันเปลี่ยนบ่อย และทำให้ JD ล้าสมัยเร็ว

## ขั้นตอนที่ 3: วิเคราะห์ Features

อ่าน source code เพื่อระบุ features และความสามารถหลักของระบบ ขั้นตอนนี้เปลี่ยนจาก "โค้ดทำอะไร"
เป็น "ระบบนี้ให้คุณค่าอะไร"

### วิธีค้นหา Features

1. **Models / Schema** — อ่าน data model เพื่อเข้าใจ domain ของระบบ

   ```bash
   # ค้นหา model files
   rg --files /path/to/project \
     | rg -v '(^|/)(node_modules|vendor|__pycache__|\.git)(/|$)' \
     | rg '(model|schema|entity)'
   ```

2. **Routes / Endpoints** — อ่าน router files เพื่อเห็น API ที่ระบบให้บริการ

   ```bash
   # ค้นหาไฟล์ route/router
   rg --files /path/to/project \
     | rg -v '(^|/)(node_modules|vendor|__pycache__|\.git)(/|$)' \
     | rg '(route|router|controller|endpoint)'
   ```

3. **Services / Use Cases** — ดู business logic หลักจาก service layer

   ```bash
   # ค้นหา service files
   rg --files /path/to/project \
     | rg -v '(^|/)(node_modules|vendor|__pycache__|\.git)(/|$)' \
     | rg '(service|usecase|handler)'
   ```

4. **Components / Pages** — สำหรับ frontend ให้ดูจากโครงสร้าง component และ page

   ```bash
   # ค้นหา page/view files
   rg --files /path/to/project \
     | rg -v '(^|/)(node_modules|vendor|__pycache__|\.git)(/|$)' \
     | rg '(^|/)(pages|views|screens)(/|$)'
   ```

5. **Middleware / Interceptors** — ตรวจสอบ cross-cutting concerns เช่น auth, logging, rate limiting

6. **Config / Feature Flags** — ดูการตั้งค่าที่บ่งบอก feature ที่เปิด-ปิดได้

### การจัดกลุ่ม Features

จัดกลุ่ม features ที่พบเป็นหมวดหมู่เชิงธุรกิจ ไม่ใช่เชิงเทคนิค เพราะ recruiter ต้องการเห็นคุณค่า
ไม่ใช่รายละเอียดทางเทคนิค

**ตัวอย่างการแปลงจากเทคนิคเป็นธุรกิจ:**

| สิ่งที่พบในโค้ด                          | สิ่งที่เขียนใน JD                                       |
| ---------------------------------------- | ------------------------------------------------------- |
| JWT auth middleware + RBAC               | ระบบยืนยันตัวตนและจัดการสิทธิ์ผู้ใช้                    |
| Stripe integration + webhook handler     | ระบบชำระเงินออนไลน์                                     |
| Redis caching layer + cache invalidation | ระบบแคชเพื่อเพิ่มประสิทธิภาพการตอบสนอง                  |
| WebSocket + event emitter                | ระบบแจ้งเตือนแบบ real-time                              |
| S3 upload + image processing             | ระบบจัดการไฟล์และประมวลผลรูปภาพ                         |
| Elasticsearch integration                | ระบบค้นหาข้อมูลแบบ full-text                            |
| i18n middleware + locale files           | ระบบรองรับหลายภาษา                                      |
| Rate limiter + API key management        | ระบบจัดการ API และควบคุมปริมาณการใช้งาน                 |
| Cron jobs + queue workers                | ระบบประมวลผลงานอัตโนมัติแบบ background                  |
| event sourcing + message broker          | ระบบกระจายข้อมูลและสื่อสารระหว่างบริการแบบ asynchronous |

## ขั้นตอนที่ 4: แมปบทบาท (Role Mapping)

จากสิ่งที่วิเคราะห์ได้ในขั้นตอนที่ 1-3 ให้ระบุบทบาทที่เหมาะสมที่สุด บทบาทต้องสะท้อนสิ่งที่ทำจริง
ในโปรเจกต์ ไม่ใช่ตำแหน่งที่อยากได้

### หลักการแมปบทบาท

ดูจากสัดส่วนของงานที่ปรากฏในโค้ดเป็นหลัก โดยประเมินจากหลายหลักฐานร่วมกัน เช่น สัดส่วนไฟล์ source code,
entry points, routes/pages, service layer, dependency, config และ feature surface ที่ผู้ใช้มองเห็นได้
อย่าใช้จำนวนไฟล์เพียงอย่างเดียวในการตัดสินบทบาท เพราะบางโปรเจกต์มี frontend/backend ที่ไฟล์ไม่สมดุลกัน

| สัดส่วนงานที่พบ                                         | บทบาทที่เหมาะสม                             |
| ------------------------------------------------------- | ------------------------------------------- |
| Frontend 80%+                                           | Frontend Developer / Frontend Engineer      |
| Backend 80%+                                            | Backend Developer / Backend Engineer        |
| ทั้ง Frontend และ Backend                               | Full Stack Developer / Full Stack Engineer  |
| Mobile (React Native/Flutter/Swift/Kotlin)              | Mobile Developer / Mobile Engineer          |
| Containerization + orchestration เป็นหลัก               | Platform Engineer / Infrastructure Engineer |
| Data pipeline + ETL + analytics                         | Data Engineer                               |
| ML model training + inference serving                   | Machine Learning Engineer                   |
| Distributed systems + service decomposition             | Software Architect / Software Engineer      |
| ทั้งระบบครอบคลุมทุก layer ตั้งแต่ UI ถึง infrastructure | Software Engineer (Full Lifecycle)          |

หากหลักฐานไม่ชัดพอที่จะเลือกบทบาทเฉพาะทาง ให้ใช้บทบาทกว้างกว่า เช่น Software Engineer
หรือถามผู้ใช้เมื่อบทบาทที่เลือกจะมีผลต่อเนื้อหา JD อย่างมีนัยสำคัญ

### ปัจจัยเสริมที่ปรับระดับ

- มีการออกแบบ architecture ชัดเจน (design patterns, modular structure) → บ่งบอกประสบการณ์
- เป็นโปรเจกต์ที่ดูแลระบบ production → สามารถระบุ scale ได้
- มีการแยก business logic ออกจาก infrastructure layer อย่างชัดเจน → บ่งบอกความเข้าใจด้านสถาปัตยกรรมระดับสูง
- มีการจัดการ error handling อย่างครอบคลุมและสม่ำเสมอทั่วทั้ง codebase → สะท้อนประสบการณ์ด้านความทนทานของระบบ

### สิ่งที่ต้องระวัง

- หากผู้ใช้ระบุบทบาทมาแล้ว ให้ใช้บทบาทของผู้ใช้เป็นหลักแล้วปรับรายละเอียดให้สอดคล้อง
- หากไม่แน่ใจว่าเป็น Senior หรือ Mid-level ให้ถามผู้ใช้ก่อน ห้ามสมมติเอง
- หากโปรเจกต์เป็นงาน side project หรือ open source ให้ระบุ context ด้วย (เช่น "Personal Project" หรือ "Open Source Contributor")

## ขั้นตอนที่ 5: เขียน Achievement Bullets

ขั้นตอนนี้สำคัญที่สุดในบรรดาทุกขั้นตอน เพราะ achievement bullets คือสิ่งแรกที่ recruiter อ่าน
ต้องเขียนให้กระชับ มีน้ำหนัก และวัดผลได้

### สูตร Achievement Bullet

ใช้สูตร **Action + Scope + Impact** สำหรับทุก bullet:

```
[Action Verb ที่ทรงพลัง] + [สิ่งที่ทำ + ขอบเขต] + [ผลลัพธ์หรือผลกระทบ]
```

**ตัวอย่าง:**

| แบบอ่อน (หลีกเลี่ยง) | แบบแข็ง (ใช้แบบนี้)                                                                                        |
| -------------------- | ---------------------------------------------------------------------------------------------------------- |
| ทำระบบ login         | ออกแบบและพัฒนาระบบยืนยันตัวตนด้วย JWT, OAuth 2.0 และ role-based access control                             |
| เขียน API            | พัฒนา RESTful API จำนวน 25+ endpoints พร้อม rate limiting และ caching เพื่อรองรับ [requests/วินาที]        |
| ทำหน้าเว็บ           | สร้าง responsive web application ด้วย React พร้อม SSR เพื่อลดเวลาโหลดหน้าแรกลง [X]%                         |
| ดูแลฐานข้อมูล        | ออกแบบ database schema สำหรับระบบ multi-tenant พร้อม migration strategy ที่รองรับ zero-downtime deployment |

### Action Verbs ที่ทรงพลัง

เลือก verb ที่สื่อถึงระดับความรับผิดชอบ:

อย่าใช้ verb ระดับ Lead, Architect หรือ Senior หากไม่มีหลักฐานเรื่อง ownership, architecture decision,
mentoring, production responsibility หรือการตัดสินใจเชิงระบบจากโค้ด เอกสาร หรือข้อมูลที่ผู้ใช้ยืนยัน

- **ระดับ Lead/Architect:** ออกแบบ (Architected), กำหนดทิศทาง (Spearheaded), วางกลยุทธ์ (Strategized)
- **ระดับ Senior:** พัฒนา (Engineered), ปรับปรุงประสิทธิภาพ (Optimized), บูรณาการ (Integrated), ปรับโครงสร้าง (Refactored)
- **ระดับ Mid:** สร้าง (Built), พัฒนา (Developed), ดำเนินการ (Implemented), เชื่อมต่อ (Connected)
- **ระดับ Junior:** ช่วยพัฒนา (Contributed to), สนับสนุน (Supported), ดูแล (Maintained)

### การประมาณตัวเลข

แยกตัวเลขออกเป็น 2 ประเภทก่อนเขียนทุกครั้ง:

1. **ตัวเลขที่นับได้จาก repository** — ใช้ได้เมื่อมีหลักฐานในโค้ดหรือ config เช่น จำนวน endpoints, models, tables, components, pages, test files และจำนวนไฟล์
2. **ตัวเลข business impact** — ใช้ได้เฉพาะเมื่อผู้ใช้ให้ข้อมูลไว้ หรือพบใน README, docs, metrics, issue, changelog หรือแหล่งข้อมูลในโปรเจกต์ ห้ามอนุมานจากโค้ดเพียงอย่างเดียว

เมื่อไม่มีตัวเลขจริง ให้ประมาณเฉพาะตัวเลขที่นับได้จาก repository อย่างสมเหตุสมผล:

- ดู commit history (ถ้ามี) เพื่อประมาณระยะเวลาพัฒนา
- นับจำนวน API endpoints จาก route files
- นับจำนวน database tables/models จาก schema
- นับจำนวน components/pages จาก frontend structure
- ดูจำนวนและตำแหน่งของ test files เพื่อระบุขอบเขตการทดสอบที่พบ ห้ามสรุป test coverage เป็นเปอร์เซ็นต์หากไม่มีรายงาน coverage จริง

หากไม่สามารถประมาณตัวเลขได้อย่างมั่นใจ หรือเป็นตัวเลข business impact เช่น จำนวนผู้ใช้, traffic, revenue, latency, conversion rate หรือ uptime ให้ใช้ placeholder แบบ `[X]` หรือ `[ระบุ]` เพื่อให้ผู้ใช้กรอกเอง
ห้ามสร้างตัวเลขขึ้นมาโดยไม่มีหลักฐานรองรับ และห้ามทำให้ placeholder ดูเหมือนเป็นค่าที่วัดได้จริง

## ขั้นตอนที่ 6: ส่งออก Markdown

โดยค่าเริ่มต้น ให้ส่งผลลัพธ์เป็น Markdown ในคำตอบ ไม่ต้องสร้างไฟล์จริง เว้นแต่ผู้ใช้ขอให้สร้างไฟล์โดยตรง
หากผู้ใช้ต้องการไฟล์ Markdown ให้ใช้ path และชื่อไฟล์ที่ผู้ใช้ยืนยันแล้วเท่านั้น จากนั้นใช้โครงสร้างต่อไปนี้เป็นเทมเพลต และปรับเนื้อหาตามข้อมูลที่วิเคราะห์ได้จริง

### เทมเพลตผลลัพธ์

```markdown
# [ชื่อตำแหน่ง] — [ชื่อโปรเจกต์หรือบริษัท]

> [คำอธิบายโปรเจกต์ 1-2 ประโยค สื่อว่าโปรเจกต์นี้แก้ปัญหาอะไรให้ใคร]

## Tech Stack

**ภาษาโปรแกรม:** [รายการ]
**Frontend:** [รายการ]
**Backend:** [รายการ]
**ฐานข้อมูล:** [รายการ]
**Cloud & Infrastructure:** [รายการ]
**Security & Authentication:** [รายการ]
**Messaging & Background Processing:** [รายการ]
**อื่น ๆ:** [รายการ]

## ความรับผิดชอบหลักและผลงาน

- [Achievement bullet 1 — สิ่งที่สำคัญที่สุด]
- [Achievement bullet 2]
- [Achievement bullet 3]
- [Achievement bullet 4]
- [Achievement bullet 5]
- [Achievement bullet 6 — หากมีมากพอ]

## คุณสมบัติหลักของระบบ

- [Feature 1 + คำอธิบายสั้น ๆ]
- [Feature 2 + คำอธิบายสั้น ๆ]
- [Feature 3 + คำอธิบายสั้น ๆ]
- [Feature 4 + คำอธิบายสั้น ๆ]

## ขอบเขตโปรเจกต์

- **ขนาดโค้ด:** [จำนวนบรรทัดโดยประมาณ]
- **จำนวนไฟล์:** [จำนวนไฟล์ source code]
- **ประเภท:** [Production / Side Project / Open Source / Freelance]
- **ทีม:** [ทำคนเดียว / ทีม X คน] (ถ้าทราบ)

## หลักฐานและข้อมูลที่ต้องยืนยัน

- **ไฟล์สำคัญที่ใช้วิเคราะห์:** [package.json, routes, models, services, README หรือไฟล์อื่นที่อ้างอิงจริง]
- **สิ่งที่ยืนยันจากโค้ดได้:** [tech stack, features, endpoints, models, components]
- **สิ่งที่ต้องให้ผู้ใช้ยืนยัน:** [business impact, จำนวนผู้ใช้, traffic, revenue, uptime, ขนาดทีม, ช่วงเวลา]
- **Assumptions:** [สมมติฐานที่ใช้ หรือ "ไม่มี" หากไม่ต้องสมมติ]
```

### กฎสำคัญสำหรับผลลัพธ์

1. **ความซื่อสัตย์** — เขียนเฉพาะสิ่งที่มีหลักฐานในโค้ดจริง ใช้ `[X]` หรือ `[ระบุ]` สำหรับตัวเลขที่ไม่แน่ใจ
2. **Recruiter-friendly** — หลีกเลี่ยงศัพท์เฉพาะทางมากเกินไป ใช้คำที่คนทั่วไปในวงการ tech เข้าใจได้
3. **ภาษา** — ใช้ภาษาไทยเป็นหลัก ยกเว้นชื่อเทคโนโลยี ตำแหน่งงาน และ technical terms ให้คงภาษาอังกฤษ
4. **ความกระชับ** — achievement bullet แต่ละข้อไม่เกิน 2 บรรทัด
5. **เรียงลำดับ** — achievement bullets เรียงจากสำคัญที่สุดไปน้อยที่สุด
6. **ไม่ซ้ำซ้อน** — ทุก bullet ต้องสื่อสิ่งที่ต่างกัน ไม่ทับซ้อนกัน
7. **ไม่ระบุเวอร์ชัน** — ไม่ใส่เลขเวอร์ชันของเทคโนโลยีใดๆ
8. **อธิบายหลักฐาน** — ระบุไฟล์หรือส่วนของระบบที่ใช้เป็นหลักฐาน เพื่อให้ผู้ใช้ตรวจสอบและแก้ข้อมูลได้ง่าย

## การถามข้อมูลเพิ่มเติม

มีบางข้อมูลที่ไม่สามารถอ่านได้จากโค้ด ให้ถามผู้ใช้เมื่อจำเป็น:

- **บทบาทที่ต้องการ** — หากผู้ใช้ต้องการตำแหน่งเฉพาะ
- **ชื่อบริษัท/องค์กร** — หากไม่ปรากฏใน README หรือ config
- **ประเภทโปรเจกต์** — production, side project, open source, freelance
- **ช่วงเวลาทำงาน** — วันเริ่มต้นและสิ้นสุด
- **ขนาดทีม** — ทำคนเดียวหรือกี่คน
- **ตัวเลข impact** — จำนวนผู้ใช้, traffic, revenue impact (ถ้ามี)

ถามเฉพาะสิ่งที่จำเป็นจริงๆ รวมคำถามเป็นชุดเดียว ห้ามถามทีละข้อ
หากผู้ใช้ไม่ตอบข้อใด ให้ใช้ `[ระบุ]` เป็น placeholder แล้วดำเนินการต่อ

## กรณีพิเศษ

### โปรเจกต์ Monorepo

หากพบว่าโปรเจกต์เป็น monorepo (มีหลาย packages/apps ในโปรเจกต์เดียว):

- สร้าง JD แยกสำหรับแต่ละ package/app หากแตกต่างกันมาก
- หรือสร้าง JD เดียวที่ครอบคลุมทุกส่วน หากทำงานเชื่อมโยงกัน
- ถามผู้ใช้ว่าต้องการแบบใด

### โปรเจกต์ที่ไม่มีโค้ด

หากโปรเจกต์เป็นเพียง config, infrastructure, หรือ documentation:

- ปรับบทบาทให้เหมาะสม (DevOps, Technical Writer, Platform Engineer)
- เน้น achievement ที่วัดผลได้จากมุมมอง infrastructure/process

### โปรเจกต์ขนาดเล็กมาก

หากโปรเจกต์มีไฟล์น้อยกว่า 10 ไฟล์:

- ระบุเป็น "Side Project" หรือ "Proof of Concept" ตามความเหมาะสม
- ลดจำนวน achievement bullets ให้เหมาะสม (3-4 ข้อ)
- เน้นทักษะและเทคโนโลยีที่ใช้มากกว่า impact

### หลายภาษาในโปรเจกต์เดียว

หากโปรเจกต์ใช้หลายภาษาโปรแกรม:

- ระบุภาษาหลักและภาษารอง
- จัด tech stack ตามส่วนที่ใช้ (เช่น Python สำหรับ backend, TypeScript สำหรับ frontend)

## ตัวอย่างผลลัพธ์จริง

### ตัวอย่างที่ 1: E-commerce Platform

```markdown
# Full Stack Developer — ShopFlow Platform

> แพลตฟอร์ม e-commerce สำหรับร้านค้าขนาดกลางที่รองรับการขายสินค้าออนไลน์ การชำระเงิน และการจัดการคลังสินค้าแบบครบวงจร

## Tech Stack

**ภาษาโปรแกรม:** TypeScript, Python
**Frontend:** Next.js, React, Tailwind CSS, Zustand
**Backend:** NestJS, PostgreSQL, Redis, Elasticsearch
**Cloud & Infrastructure:** AWS (ECS, RDS, S3, CloudFront), Docker, Terraform
**Security & Authentication:** JWT, OAuth 2.0
**Messaging & Background Processing:** background workers, scheduled tasks

## ความรับผิดชอบหลักและผลงาน

- ออกแบบและพัฒนา RESTful API จำนวน 45+ endpoints สำหรับระบบจัดการสินค้า คำสั่งซื้อ และผู้ใช้ พร้อม role-based access control
- สร้างระบบชำระเงินที่เชื่อมต่อกับ Stripe รองรับบัตรเครดิตและ PromptPay พร้อม webhook สำหรับอัปเดตสถานะอัตโนมัติ
- พัฒนาระบบค้นหาสินค้าแบบ full-text ด้วย Elasticsearch พร้อม autocomplete และ faceted filtering ลดเวลาค้นหาลง [X]%
- สร้าง responsive storefront ด้วย Next.js และ SSR เพื่อรองรับ SEO readiness และลดเวลาโหลดหน้าแรกลง [X]% หากมี metric ยืนยัน
- ออกแบบ database schema แบบ normalized สำหรับ 20+ tables พร้อม migration strategy ที่รองรับ zero-downtime deployment
- ออกแบบระบบยืนยันตัวตนและจัดการสิทธิ์ผู้ใช้ด้วย OAuth 2.0 รองรับหลาย identity provider พร้อม session rotation อัตโนมัติ

## คุณสมบัติหลักของระบบ

- ระบบจัดการสินค้าพร้อม variant management และ inventory tracking
- ระบบตะกร้าสินค้าและชำระเงินแบบ multi-step
- แดชบอร์ดผู้ดูแลระบบสำหรับจัดการคำสั่งซื้อและรายงานยอดขาย
- ระบบแจ้งเตือนหลายช่องทางผ่านอีเมลและแอปพลิเคชันแชท

## ขอบเขตโปรเจกต์

- **ขนาดโค้ด:** ~35,000 บรรทัด
- **จำนวนไฟล์:** 280+ ไฟล์
- **ประเภท:** Production
- **ทีม:** 4 คน

## หลักฐานและข้อมูลที่ต้องยืนยัน

- **ไฟล์สำคัญที่ใช้วิเคราะห์:** package.json, src/routes, src/models, prisma/schema.prisma, Dockerfile
- **สิ่งที่ยืนยันจากโค้ดได้:** tech stack, API endpoints, database models, payment integration, authentication flow
- **สิ่งที่ต้องให้ผู้ใช้ยืนยัน:** traffic, revenue impact, conversion rate, uptime
- **Assumptions:** ใช้ `[X]` สำหรับ performance metric ที่ไม่มีหลักฐานใน repository
```

### ตัวอย่างที่ 2: CLI Tool (โปรเจกต์ขนาดเล็ก)

```markdown
# Software Engineer — LogStream CLI

> เครื่องมือ command-line สำหรับ stream, filter และวิเคราะห์ log files แบบ real-time ออกแบบมาเพื่อทดแทน grep + tail ในงาน debugging

## Tech Stack

**ภาษาโปรแกรม:** Rust
**เครื่องมือ:** Clap, Tokio, Serde, Regex
**Concurrency & Performance:** async I/O, streaming processing
**System Integration:** standard I/O, cross-platform compatibility

## ความรับผิดชอบหลักและผลงาน

- พัฒนา CLI tool ด้วย Rust ที่ประมวลผล log files ขนาด 1GB+ ได้ภายใน [X] วินาที โดยใช้ async I/O
- สร้างระบบ filter แบบ composable รองรับ regex, JSON path และ time-range query
- ออกแบบ output format ที่ปรับแต่งได้ รองรับทั้ง plain text, JSON และ colored terminal output
- ออกแบบ parser logic ที่รองรับรูปแบบ log หลากหลาย ครอบคลุมทั้ง structured และ unstructured format พร้อม error recovery แบบ graceful

## ขอบเขตโปรเจกต์

- **ขนาดโค้ด:** ~3,500 บรรทัด
- **จำนวนไฟล์:** 15 ไฟล์
- **ประเภท:** Open Source / Side Project
- **ทีม:** ทำคนเดียว

## หลักฐานและข้อมูลที่ต้องยืนยัน

- **ไฟล์สำคัญที่ใช้วิเคราะห์:** Cargo.toml, src/main.rs, src/parser, src/filters, tests
- **สิ่งที่ยืนยันจากโค้ดได้:** CLI commands, parser behavior, output formats, async processing
- **สิ่งที่ต้องให้ผู้ใช้ยืนยัน:** benchmark time, target users, release status
- **Assumptions:** โปรเจกต์ถูกจัดเป็น Side Project หาก README ไม่ระบุสถานะ production
```