speccrew 0.7.45 → 0.7.46
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.speccrew/agents/speccrew-team-leader.md +6 -6
- package/README.ar.md +5 -17
- package/README.de.md +5 -17
- package/README.en.md +5 -17
- package/README.es.md +5 -17
- package/README.fr.md +5 -17
- package/README.hi.md +384 -0
- package/README.ja.md +5 -17
- package/README.md +5 -17
- package/README.pt-BR.md +5 -17
- package/README.ru.md +5 -17
- package/docs/GETTING-STARTED.ar.md +39 -40
- package/docs/GETTING-STARTED.de.md +39 -40
- package/docs/GETTING-STARTED.en.md +39 -40
- package/docs/GETTING-STARTED.es.md +39 -40
- package/docs/GETTING-STARTED.fr.md +39 -40
- package/docs/GETTING-STARTED.hi.md +636 -0
- package/docs/GETTING-STARTED.ja.md +39 -40
- package/docs/GETTING-STARTED.md +39 -40
- package/docs/GETTING-STARTED.pt-BR.md +25 -26
- package/docs/GETTING-STARTED.ru.md +37 -38
- package/lib/commands/init.js +3 -3
- package/package.json +1 -1
- package/README.bn.md +0 -174
- package/README.bs.md +0 -394
- package/README.da.md +0 -394
- package/README.el.md +0 -174
- package/README.it.md +0 -394
- package/README.ko.md +0 -394
- package/README.no.md +0 -394
- package/README.pl.md +0 -394
- package/README.th.md +0 -311
- package/README.tr.md +0 -306
- package/README.uk.md +0 -306
- package/README.vi.md +0 -174
- package/README.zh-TW.md +0 -394
- package/docs/GETTING-STARTED.bn.md +0 -219
- package/docs/GETTING-STARTED.bs.md +0 -219
- package/docs/GETTING-STARTED.da.md +0 -637
- package/docs/GETTING-STARTED.el.md +0 -633
- package/docs/GETTING-STARTED.it.md +0 -639
- package/docs/GETTING-STARTED.ko.md +0 -639
- package/docs/GETTING-STARTED.no.md +0 -563
- package/docs/GETTING-STARTED.pl.md +0 -597
- package/docs/GETTING-STARTED.th.md +0 -219
- package/docs/GETTING-STARTED.tr.md +0 -597
- package/docs/GETTING-STARTED.uk.md +0 -597
- package/docs/GETTING-STARTED.vi.md +0 -217
- package/docs/GETTING-STARTED.zh-TW.md +0 -639
package/README.th.md
DELETED
|
@@ -1,311 +0,0 @@
|
|
|
1
|
-
# SpecCrew - เฟรมเวิร์กวิศวกรรมซอฟต์แวร์ที่ขับเคลื่อนด้วย AI
|
|
2
|
-
|
|
3
|
-
<p align="center">
|
|
4
|
-
<a href="./README.md">简体中文</a> |
|
|
5
|
-
<a href="./README.zh-TW.md">繁體中文</a> |
|
|
6
|
-
<a href="./README.en.md">English</a> |
|
|
7
|
-
<a href="./README.ko.md">한국어</a> |
|
|
8
|
-
<a href="./README.de.md">Deutsch</a> |
|
|
9
|
-
<a href="./README.es.md">Español</a> |
|
|
10
|
-
<a href="./README.fr.md">Français</a> |
|
|
11
|
-
<a href="./README.it.md">Italiano</a> |
|
|
12
|
-
<a href="./README.da.md">Dansk</a> |
|
|
13
|
-
<a href="./README.ja.md">日本語</a> |
|
|
14
|
-
<a href="./README.pl.md">Polski</a> |
|
|
15
|
-
<a href="./README.ru.md">Русский</a> |
|
|
16
|
-
<a href="./README.bs.md">Bosanski</a> |
|
|
17
|
-
<a href="./README.ar.md">العربية</a> |
|
|
18
|
-
<a href="./README.no.md">Norsk</a> |
|
|
19
|
-
<a href="./README.pt-BR.md">Português (Brasil)</a> |
|
|
20
|
-
<a href="./README.th.md">ไทย</a> |
|
|
21
|
-
<a href="./README.tr.md">Türkçe</a> |
|
|
22
|
-
<a href="./README.uk.md">Українська</a> |
|
|
23
|
-
<a href="./README.bn.md">বাংলা</a> |
|
|
24
|
-
<a href="./README.el.md">Ελληνικά</a> |
|
|
25
|
-
<a href="./README.vi.md">Tiếng Việt</a>
|
|
26
|
-
</p>
|
|
27
|
-
|
|
28
|
-
<p align="center">
|
|
29
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/v/speccrew.svg" alt="npm version"></a>
|
|
30
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/dm/speccrew.svg" alt="npm downloads"></a>
|
|
31
|
-
<a href="https://github.com/charlesmu99/speccrew/blob/main/LICENSE"><img src="https://img.shields.io/npm/l/speccrew.svg" alt="license"></a>
|
|
32
|
-
</p>
|
|
33
|
-
|
|
34
|
-
> ทีมพัฒนา AI เสมือนที่ช่วยให้การใช้งานวิศวกรรมอย่างรวดเร็วสำหรับโปรเจกต์ซอฟต์แวร์ใดๆ
|
|
35
|
-
|
|
36
|
-
## SpecCrew คืออะไร?
|
|
37
|
-
|
|
38
|
-
SpecCrew เป็นเฟรมเวิร์กทีมพัฒนา AI เสมือนแบบฝังตัว มันแปลงเวิร์กโฟลว์วิศวกรรมซอฟต์แวร์มืออาชีพ (PRD → Feature Design → System Design → Dev → Deployment → Test) เป็นเวิร์กโฟลว์ Agent ที่นำกลับมาใช้ใหม่ได้ ช่วยให้ทีมพัฒนาบรรลุ Specification-Driven Development (SDD) โดยเฉพาะเหมาะสำหรับโปรเจกต์ที่มีอยู่แล้ว
|
|
39
|
-
|
|
40
|
-
โดยการรวม Agent และ Skill เข้ากับโปรเจกต์ที่มีอยู่ ทีมสามารถเริ่มต้นระบบเอกสารโปรเจกต์และทีมซอฟต์แวร์เสมือนได้อย่างรวดเร็ว ดำเนินการเพิ่มและแก้ไขคุณสมบัติใหม่ตามเวิร์กโฟลว์วิศวกรรมมาตรฐาน
|
|
41
|
-
|
|
42
|
-
---
|
|
43
|
-
|
|
44
|
-
## ✨ จุดเด่นหลัก
|
|
45
|
-
|
|
46
|
-
### 🏭 ทีมซอฟต์แวร์เสมือน
|
|
47
|
-
การสร้างด้วยคลิกเดียว **7 บทบาท Agent มืออาชีพ** + **30+ เวิร์กโฟลว์ Skill** สร้างทีมซอฟต์แวร์เสมือนที่สมบูรณ์:
|
|
48
|
-
- **Team Leader** - การวางแผนระดับโลกและการจัดการการทำซ้ำ
|
|
49
|
-
- **Product Manager** - การวิเคราะห์ความต้องการและผลลัพธ์ PRD
|
|
50
|
-
- **Feature Designer** - การออกแบบฟีเจอร์ + สัญญา API
|
|
51
|
-
- **System Designer** - การออกแบบระบบ Frontend/Backend/Mobile/Desktop
|
|
52
|
-
- **System Developer** - การพัฒนาขนานข้ามแพลตฟอร์ม
|
|
53
|
-
- **Test Manager** - การประสานการทดสอบสามขั้นตอน
|
|
54
|
-
- **Task Worker** - การทำงานย่อยขนานกัน
|
|
55
|
-
|
|
56
|
-
### 📐 การสร้างแบบจำลอง ISA-95 หกขั้นตอน
|
|
57
|
-
อิงตามวิธีการสร้างแบบจำลองมาตรฐานสากล **ISA-95** การ стандарти化การแปลงความต้องการทางธุรกิจเป็นระบบซอฟต์แวร์:
|
|
58
|
-
```
|
|
59
|
-
Domain Descriptions → Functions in Domains → Functions of Interest
|
|
60
|
-
↓ ↓ ↓
|
|
61
|
-
Information Flows → Categories of Information → Information Descriptions
|
|
62
|
-
```
|
|
63
|
-
- แต่ละขั้นตอนสอดคล้องกับแผนภาพ UML เฉพาะ (use case, sequence, class)
|
|
64
|
-
- ความต้องการทางธุรกิจ "ถูกกลั่นกรองทีละขั้นตอน" โดยไม่สูญเสียข้อมูล
|
|
65
|
-
- ผลลัพธ์สามารถนำไปใช้ในการพัฒนาได้โดยตรง
|
|
66
|
-
|
|
67
|
-
### 📚 ระบบฐานความรู้
|
|
68
|
-
สถาปัตยกรรมฐานความรู้สามชั้นที่รับรองว่า AI ทำงานอิงตาม "แหล่งความจริงเดียว" เสมอ:
|
|
69
|
-
|
|
70
|
-
| ชั้น | ไดเรกทอรี | เนื้อหา | วัตถุประสงค์ |
|
|
71
|
-
|------|-----------|---------|-------------|
|
|
72
|
-
| L1 ความรู้ระบบ | `knowledge/techs/` | Stack เทคโนโลยี, สถาปัตยกรรม, ข้อตกลง | AI เข้าใจขอบเขตทางเทคนิคของโปรเจกต์ |
|
|
73
|
-
| L2 ความรู้ธุรกิจ | `knowledge/bizs/` | ฟังก์ชันโมดูล, การไหลทางธุรกิจ, เอนทิตี | AI เข้าใจตรรกะทางธุรกิจ |
|
|
74
|
-
| L3 สิ่งซ้ำการทำซ้ำ | `iterations/iXXX/` | PRD, เอกสารการออกแบบ, รายงานการทดสอบ | โซ่การติดตามที่สมบูรณ์สำหรับความต้องการปัจจุบัน |
|
|
75
|
-
|
|
76
|
-
### 🔄 ไปป์ไลน์ความรู้สี่ขั้นตอน
|
|
77
|
-
**สถาปัตยกรรมการสร้างความรู้โดยอัตโนมัติ** การสร้างเอกสารธุรกิจ/เทคนิคโดยอัตโนมัติจากรหัสต้นฉบับ:
|
|
78
|
-
```
|
|
79
|
-
ขั้นตอนที่ 1: สแกนรหัสต้นฉบับ → สร้างรายการโมดูล
|
|
80
|
-
ขั้นตอนที่ 2: การวิเคราะห์ขนาน → สกัดฟีเจอร์ (multi-Worker ขนาน)
|
|
81
|
-
ขั้นตอนที่ 3: การสรุปขนาน → ทำให้ภาพรวมโมดูลสมบูรณ์ (multi-Worker ขนาน)
|
|
82
|
-
ขั้นตอนที่ 4: การรวมระบบ → สร้างภาพพาโนรามาของระบบ
|
|
83
|
-
```
|
|
84
|
-
- รองรับ **การซิงค์แบบเต็ม** และ **การซิงค์แบบเพิ่ม** (อิงตาม Git diff)
|
|
85
|
-
- คนเดียวปรับปรุง ทีมแชร์
|
|
86
|
-
|
|
87
|
-
### 🔧 Harness กรอบการลงมือปฏิบัติจริง
|
|
88
|
-
**กรอบการดำเนินการมาตรฐาน** เพื่อให้แน่ใจว่าเอกสารการออกแบบถูกแปลงเป็นคำสั่งพัฒนาที่ปฏิบัติได้อย่างแม่นยำ:
|
|
89
|
-
- **หลักคู่มือการดำเนินการ**: Skill คือ SOP ขั้นตอนชัดเจน ต่อเนื่อง และครบถ้วนในตัวเอง
|
|
90
|
-
- **สัญญาอินพุต-เอาต์พุต**: กำหนดอินเทอร์เฟซชัดเจน ปฏิบัติอย่างเคร่งครัดเหมือน pseudocode
|
|
91
|
-
- **สถาปัตยกรรมการเปิดเผยแบบก้าวหน้า**: โหลดข้อมูลแบบเลเยอร์ หลีกเลี่ยงการโหลดบริบทมากเกินไปในครั้งเดียว
|
|
92
|
-
- **การมอบหมาย Sub-Agent**: แยกงานอัตโนมัติสำหรับงานที่ซับซ้อน ดำเนินการแบบขนานเพื่อรับประกันคุณภาพ
|
|
93
|
-
|
|
94
|
-
---
|
|
95
|
-
|
|
96
|
-
## แก้ปัญหาหลัก 8 ประการ
|
|
97
|
-
|
|
98
|
-
### 1. AI เพิกเฉยต่อเอกสารโปรเจกต์ที่มีอยู่ (ช่องว่างความรู้)
|
|
99
|
-
**ปัญหา**: เมธอด SDD หรือ Vibe Coding ที่มีอยู่พึ่งพา AI สรุปโปรเจกต์แบบเรียลไทม์ ซึ่งมักพลาดบริบทสำคัญ ทำให้ผลลัพธ์การพัฒนาเบี่ยงเบนจากความคาดหวัง
|
|
100
|
-
|
|
101
|
-
**แนวทางแก้ไข**: รีโพสิทอรี `knowledge/` ทำหน้าที่เป็น "แหล่งความจริงเดียว" ของโปรเจกต์ สะสมการออกแบบสถาปัตยกรรม โมดูลฟังก์ชัน และกระบวนการทางธุรกิจ เพื่อให้มั่นใจว่าความต้องการยังคงอยู่ในแนวทางจากแหล่งที่มา
|
|
102
|
-
|
|
103
|
-
### 2. เอกสารทางเทคนิคโดยตรงจาก PRD (การละเว้นเนื้อหา)
|
|
104
|
-
**ปัญหา**: การข้ามจาก PRD ไปยังการออกแบบโดยละเอียดโดยตรงมักพลาดรายละเอียดความต้องการ ทำให้ฟังก์ชันที่ใช้งานเบี่ยงเบนจากความต้องการ
|
|
105
|
-
|
|
106
|
-
**แนวทางแก้ไข**: แนะนำเฟส **เอกสาร Feature Design** โดยเน้นเฉพาะโครงสร้างความต้องการโดยไม่มีรายละเอียดทางเทคนิค:
|
|
107
|
-
- มีหน้าและคอมโพเนนต์ใดบ้าง?
|
|
108
|
-
- โฟลว์การดำเนินการของหน้า
|
|
109
|
-
- ตรรกะการประมวลผลแบ็กเอนด์
|
|
110
|
-
- โครงสร้างการจัดเก็บข้อมูล
|
|
111
|
-
|
|
112
|
-
การพัฒนาเพียงแค่ต้อง "เติมเนื้อ" ตามเทคสแต็กเฉพาะ ทำให้มั่นใจว่าฟังก์ชันเติบโต "ใกล้กระดูก (ความต้องการ)"
|
|
113
|
-
|
|
114
|
-
### 3. ขอบเขตการค้นหา Agent ไม่แน่นอน (ความไม่แน่นอน)
|
|
115
|
-
**ปัญหา**: ในโปรเจกต์ที่ซับซ้อน การค้นหาโค้ดและเอกสารอย่างกว้างขวางโดย AI ให้ผลลัพธ์ที่ไม่แน่นอน ทำให้ความสอดคล้องรับประกันได้ยาก
|
|
116
|
-
|
|
117
|
-
**แนวทางแก้ไข**: โครงสร้างไดเรกทอรีเอกสารและเทมเพลตที่ชัดเจน ออกแบบตามความต้องการของแต่ละ Agent ใช้ **การเปิดเผยแบบก้าวหน้าและการโหลดตามความต้องการ** เพื่อรับประกันดีเทอร์มินิซึม
|
|
118
|
-
|
|
119
|
-
### 4. ขาดขั้นตอนและงาน (การขาดตอนของกระบวนการ)
|
|
120
|
-
**ปัญหา**: การขาดความครอบคลุมกระบวนการวิศวกรรมอย่างสมบูรณ์มักพลาดขั้นตอนสำคัญ ทำให้คุณภาพรับประกันได้ยาก
|
|
121
|
-
|
|
122
|
-
**แนวทางแก้ไข**: ครอบคลุมวงจรชีวิตวิศวกรรมซอฟต์แวร์ทั้งหมด:
|
|
123
|
-
```
|
|
124
|
-
PRD (ความต้องการ) → Feature Design (การออกแบบฟังก์ชัน) → API Contract (สัญญา)
|
|
125
|
-
→ System Design (การออกแบบระบบ) → Dev (การพัฒนา) → Test (การทดสอบ)
|
|
126
|
-
```
|
|
127
|
-
- เอาต์พุตของแต่ละเฟสเป็นอินพุตของเฟสถัดไป
|
|
128
|
-
- แต่ละขั้นตอนต้องการการยืนยันจากมนุษย์ก่อนดำเนินการต่อ
|
|
129
|
-
- การดำเนินการ Agent ทั้งหมดมีรายการ todo พร้อมการตรวจสอบตัวเองหลังเสร็จสิ้น
|
|
130
|
-
|
|
131
|
-
### 5. ประสิทธิภาพการทำงานร่วมกันของทีมต่ำ (ไซโลความรู้)
|
|
132
|
-
**ปัญหา**: ประสบการณ์การเขียนโปรแกรม AI แบ่งปันระหว่างทีมได้ยาก นำไปสู่ข้อผิดพลาดซ้ำๆ
|
|
133
|
-
|
|
134
|
-
**แนวทางแก้ไข**: Agent, Skill และเอกสารที่เกี่ยวข้องทั้งหมดถูกควบคุมเวอร์ชันด้วยโค้ดต้นฉบับ:
|
|
135
|
-
- การเพิ่มประสิทธิภาพของคนหนึ่งแบ่งปันโดยทีม
|
|
136
|
-
- ความรู้สะสมในฐานโค้ด
|
|
137
|
-
- ประสิทธิภาพการทำงานร่วมกันของทีมเพิ่มขึ้น
|
|
138
|
-
|
|
139
|
-
### 7. บริบท Agent เดี่ยวยาวเกินไป (คอขวดประสิทธิภาพ)
|
|
140
|
-
**ปัญหา**: งานซับซ้อนขนาดใหญ่เกินหน้าต่างบริบท Agent เดี่ยว ทำให้เกิดการเบี่ยงเบนความเข้าใจและลดคุณภาพเอาต์พุต
|
|
141
|
-
|
|
142
|
-
**แนวทางแก้ไข**: **กลไก Auto-Dispatch Sub-Agent**:
|
|
143
|
-
- งานซับซ้อนถูกระบุโดยอัตโนมัติและแบ่งเป็นงานย่อย
|
|
144
|
-
- แต่ละงานย่อยดำเนินการโดย Sub-Agent อิสระพร้อมบริบทแยก
|
|
145
|
-
- Parent Agent ประสานและรวบรวมเพื่อรับประกันความสอดคล้องโดยรวม
|
|
146
|
-
- หลีกเลี่ยงการขยายบริบท Agent เดี่ยว รับประกันคุณภาพเอาต์พุต
|
|
147
|
-
|
|
148
|
-
### 8. ความโกลาหลในการวนซ้ำความต้องการ (ความยากลำบากในการจัดการ)
|
|
149
|
-
**ปัญหา**: ความต้องการหลายอย่างผสมในสาขาเดียวกันมีผลกระทบต่อกัน ทำให้ติดตามและย้อนกลับยาก
|
|
150
|
-
|
|
151
|
-
**แนวทางแก้ไข**: **แต่ละความต้องการเป็นโปรเจกต์อิสระ**:
|
|
152
|
-
- แต่ละความต้องการสร้างไดเรกทอรีวนซ้ำอิสระ `iterations/iXXX-[ชื่อความต้องการ]/`
|
|
153
|
-
- การแยกโดยสมบูรณ์: เอกสาร, การออกแบบ, โค้ด และการทดสอบจัดการอย่างอิสระ
|
|
154
|
-
- การวนซ้ำอย่างรวดเร็ว: การส่งมอบแบบละเอียดเล็กน้อง, การตรวจสอบอย่างรวดเร็ว, การปรับใช้อย่างรวดเร็ว
|
|
155
|
-
- การเก็บถาวรที่ยืดหยุ่น: หลังเสร็จสิ้น เก็บถาวรใน `archive/` พร้อมการติดตามประวัติที่ชัดเจน
|
|
156
|
-
|
|
157
|
-
### 6. การอัปเดตเอกสารล่าช้า (การเสื่อมสภาพของความรู้)
|
|
158
|
-
**ปัญหา**: เอกสารล้าสมัยเมื่อโปรเจกต์พัฒนา ทำให้ AI ทำงานด้วยข้อมูลที่ไม่ถูกต้อง
|
|
159
|
-
|
|
160
|
-
**แนวทางแก้ไข**: Agent มีความสามารถอัปเดตเอกสารอัตโนมัติ ซิงโครไนซ์การเปลี่ยนแปลงโปรเจกต์แบบเรียลไทม์เพื่อรักษาความถูกต้องของฐานความรู้
|
|
161
|
-
|
|
162
|
-
---
|
|
163
|
-
|
|
164
|
-
## เวิร์กโฟลว์หลัก
|
|
165
|
-
|
|
166
|
-
```mermaid
|
|
167
|
-
graph LR
|
|
168
|
-
A[PRD<br/>เอกสารความต้องการ] --> B[Feature Design<br/>การออกแบบฟังก์ชัน]
|
|
169
|
-
B --> C[API Contract<br/>สัญญาอินเทอร์เฟซ]
|
|
170
|
-
C --> D[System Design<br/>การออกแบบระบบ]
|
|
171
|
-
D --> E[Dev<br/>การใช้งาน]
|
|
172
|
-
E --> F[Deployment<br/>การปรับใช้]
|
|
173
|
-
F --> G[System Test<br/>การทดสอบ]
|
|
174
|
-
G --> H[Archive<br/>การเก็บถาวร]
|
|
175
|
-
|
|
176
|
-
I[Knowledge<br/>รีโพสิทอรี] -.-> A
|
|
177
|
-
I -.-> B
|
|
178
|
-
I -.-> D
|
|
179
|
-
I -.-> E
|
|
180
|
-
I -.-> F
|
|
181
|
-
|
|
182
|
-
E -.-> I
|
|
183
|
-
F -.-> I
|
|
184
|
-
G -.-> I
|
|
185
|
-
```
|
|
186
|
-
|
|
187
|
-
### คำอธิบายแต่ละเฟส
|
|
188
|
-
|
|
189
|
-
| เฟส | Agent | อินพุต | เอาต์พุต | การยืนยันจากมนุษย์ |
|
|
190
|
-
|------|-------|--------|---------|-------------------|
|
|
191
|
-
| PRD | PM | ความต้องการผู้ใช้ | เอกสารความต้องการผลิตภัณฑ์ | ✅ จำเป็น |
|
|
192
|
-
| Feature Design | Feature Designer | PRD | เอกสาร Feature Design + สัญญา API | ✅ จำเป็น |
|
|
193
|
-
| System Design | System Designer | Feature Spec | เอกสารการออกแบบ Frontend/Backend | ✅ จำเป็น |
|
|
194
|
-
| Dev | Dev | Design | โค้ด + บันทึกงาน | ✅ จำเป็น |
|
|
195
|
-
| Deployment | System Deployer | เอาต์พุต Dev | รายงานการปรับใช้ + แอปพลิเคชันที่ทำงาน | ✅ จำเป็น |
|
|
196
|
-
| System Test | Test Manager | เอาต์พุต Deployment + Feature Spec | เคสทดสอบ + โค้ดทดสอบ + รายงานการทดสอบ + รายงาน Bug | ✅ จำเป็น |
|
|
197
|
-
|
|
198
|
-
---
|
|
199
|
-
|
|
200
|
-
## การเปรียบเทียบกับโซลูชันที่มีอยู่
|
|
201
|
-
|
|
202
|
-
| มิติ | Vibe Coding | Ralph Loop | **SpecCrew** |
|
|
203
|
-
|------|-------------|------------|-------------|
|
|
204
|
-
| การพึ่งพาเอกสาร | เพิกเฉยเอกสารที่มีอยู่ | พึ่งพา AGENTS.md | **ฐานความรู้แบบโครงสร้าง** |
|
|
205
|
-
| การถ่ายโอนความต้องการ | เขียนโค้ดโดยตรง | PRD → โค้ด | **PRD → Feature Design → System Design → โค้ด** |
|
|
206
|
-
| การมีส่วนร่วมของมนุษย์ | น้อยที่สุด | ตอนเริ่มต้น | **ในทุกเฟส** |
|
|
207
|
-
| ความสมบูรณ์ของกระบวนการ | อ่อนแอ | ปานกลาง | **เวิร์กโฟลว์วิศวกรรมที่สมบูรณ์** |
|
|
208
|
-
| การทำงานร่วมกันของทีม | แชร์ยาก | ประสิทธิภาพส่วนบุคคล | **การแชร์ความรู้ของทีม** |
|
|
209
|
-
| การจัดการบริบท | อินสแตนซ์เดียว | ลูปอินสแตนซ์เดียว | **Auto-dispatch Sub-Agent** |
|
|
210
|
-
| การจัดการวนซ้ำ | ผสม | รายการงาน | **ความต้องการเป็นโปรเจกต์, วนซ้ำอิสระ** |
|
|
211
|
-
| ดีเทอร์มินิซึม | ต่ำ | ปานกลาง | **สูง (การเปิดเผยแบบก้าวหน้า)** |
|
|
212
|
-
|
|
213
|
-
---
|
|
214
|
-
|
|
215
|
-
## เริ่มต้นอย่างรวดเร็ว
|
|
216
|
-
|
|
217
|
-
### ข้อกำหนดเบื้องต้น
|
|
218
|
-
|
|
219
|
-
- Node.js >= 16.0.0
|
|
220
|
-
- IDE ที่รองรับ: Qoder (ค่าเริ่มต้น), Cursor, Claude Code
|
|
221
|
-
|
|
222
|
-
> **หมายเหตุ**: อะแดปเตอร์สำหรับ Cursor และ Claude Code ยังไม่ได้ทดสอบในสภาพแวดล้อม IDE จริง (ใช้งานในระดับโค้ดและตรวจสอบผ่านการทดสอบ E2E แต่ยังไม่ได้ทดสอบใน Cursor/Claude Code จริง)
|
|
223
|
-
|
|
224
|
-
### 1. ติดตั้ง SpecCrew
|
|
225
|
-
|
|
226
|
-
```bash
|
|
227
|
-
npm install -g speccrew
|
|
228
|
-
```
|
|
229
|
-
|
|
230
|
-
### 2. เริ่มต้นโปรเจกต์
|
|
231
|
-
|
|
232
|
-
ไปที่ไดเรกทอรีรากของโปรเจกต์และรันคำสั่งเริ่มต้น:
|
|
233
|
-
|
|
234
|
-
```bash
|
|
235
|
-
cd /path/to/your-project
|
|
236
|
-
|
|
237
|
-
# ใช้ Qoder เป็นค่าเริ่มต้น
|
|
238
|
-
speccrew init
|
|
239
|
-
|
|
240
|
-
# หรือระบุ IDE
|
|
241
|
-
speccrew init --ide qoder
|
|
242
|
-
speccrew init --ide cursor
|
|
243
|
-
speccrew init --ide claude
|
|
244
|
-
```
|
|
245
|
-
|
|
246
|
-
หลังจากการเริ่มต้น สิ่งต่อไปนี้จะถูกสร้างในโปรเจกต์ของคุณ:
|
|
247
|
-
- `.qoder/agents/` / `.cursor/agents/` / `.claude/agents/` — นิยามบทบาท Agent 7 ตัว
|
|
248
|
-
- `.qoder/skills/` / `.cursor/skills/` / `.claude/skills/` — เวิร์กโฟลว์ Skill 30+ ตัว
|
|
249
|
-
- `speccrew-workspace/` — พื้นที่ทำงาน (ไดเรกทอรีวนซ้ำ, ฐานความรู้, เทมเพลตเอกสาร)
|
|
250
|
-
- `.speccrewrc` — ไฟล์การกำหนดค่า SpecCrew
|
|
251
|
-
|
|
252
|
-
เพื่ออัปเดต Agent และ Skill สำหรับ IDE เฉพาะภายหลัง:
|
|
253
|
-
|
|
254
|
-
```bash
|
|
255
|
-
speccrew update --ide cursor
|
|
256
|
-
speccrew update --ide claude
|
|
257
|
-
```
|
|
258
|
-
|
|
259
|
-
### 3. เริ่มเวิร์กโฟลว์การพัฒนา
|
|
260
|
-
|
|
261
|
-
ทำตามเวิร์กโฟลว์วิศวกรรมมาตรฐานทีละขั้นตอน:
|
|
262
|
-
|
|
263
|
-
1. **PRD**: Agent Product Manager วิเคราะห์ความต้องการและสร้างเอกสารความต้องการผลิตภัณฑ์
|
|
264
|
-
2. **Feature Design**: Agent Feature Designer สร้างเอกสาร Feature Design + สัญญา API
|
|
265
|
-
3. **System Design**: Agent System Designer สร้างเอกสาร System Design ตามแพลตฟอร์ม (frontend/backend/moble/desktop)
|
|
266
|
-
4. **Dev**: Agent System Developer ใช้งานการพัฒนาตามแพลตฟอร์มแบบขนาน
|
|
267
|
-
5. **Deployment**: Agent System Deployer ดำเนินการ build, database migration, service startup และ smoke test
|
|
268
|
-
6. **System Test**: Agent Test Manager ประสานการทดสอบสามเฟส (การออกแบบเคส → การสร้างโค้ด → รายงานการดำเนินการ)
|
|
269
|
-
7. **Archive**: เก็บถาวรการวนซ้ำ
|
|
270
|
-
|
|
271
|
-
> ผลลัพธ์ของแต่ละเฟสต้องการการยืนยันจากมนุษย์ก่อนดำเนินการต่อไปยังเฟสถัดไป
|
|
272
|
-
|
|
273
|
-
### 4. อัปเดต SpecCrew
|
|
274
|
-
|
|
275
|
-
เมื่อมีการเปิดตัว SpecCrew เวอร์ชันใหม่ ให้ทำการอัปเดตให้เสร็จสิ้นใน 2 ขั้นตอน:
|
|
276
|
-
|
|
277
|
-
```bash
|
|
278
|
-
# Step 1: Update the global CLI tool to the latest version
|
|
279
|
-
npm install -g speccrew@latest
|
|
280
|
-
|
|
281
|
-
# Step 2: Sync Agents and Skills in your project to the latest version
|
|
282
|
-
cd /path/to/your-project
|
|
283
|
-
speccrew update
|
|
284
|
-
```
|
|
285
|
-
|
|
286
|
-
> **หมายเหตุ**: `npm install -g speccrew@latest` อัปเดตเครื่องมือ CLI เอง ในขณะที่ `speccrew update` อัปเดตไฟล์กำหนด Agent และ Skill ในโปรเจกต์ของคุณ ต้องใช้ทั้งสองขั้นตอนสำหรับการอัปเดตที่สมบูรณ์
|
|
287
|
-
|
|
288
|
-
### 5. คำสั่ง CLI อื่นๆ
|
|
289
|
-
|
|
290
|
-
```bash
|
|
291
|
-
speccrew list # แสดงรายการ agent และ skill ที่ติดตั้ง
|
|
292
|
-
speccrew doctor # วินิจฉัยสภาพแวดล้อมและสถานะการติดตั้ง
|
|
293
|
-
speccrew update # อัปเดต agent และ skill เป็นเวอร์ชันล่าสุด
|
|
294
|
-
speccrew uninstall # ถอนการติดตั้ง SpecCrew (--all ลบพื้นที่ทำงานด้วย)
|
|
295
|
-
```
|
|
296
|
-
|
|
297
|
-
📖 **คู่มือโดยละเอียด**: หลังการติดตั้ง ดู [คู่มือเริ่มต้น](docs/GETTING-STARTED.th.md) สำหรับเวิร์กโฟลว์เต็มรูปแบบและคู่มือการสนทนา Agent
|
|
298
|
-
|
|
299
|
-
---
|
|
300
|
-
|
|
301
|
-
## ข้อมูลเพิ่มเติม
|
|
302
|
-
|
|
303
|
-
- **แผนที่ความรู้ Agent**: [speccrew-workspace/docs/agent-knowledge-map.md](./speccrew-workspace/docs/agent-knowledge-map.md)
|
|
304
|
-
- **npm**: https://www.npmjs.com/package/speccrew
|
|
305
|
-
- **GitHub**: https://github.com/charlesmu99/speccrew
|
|
306
|
-
- **Gitee**: https://gitee.com/amutek/speccrew
|
|
307
|
-
- **Qoder IDE**: https://qoder.com/
|
|
308
|
-
|
|
309
|
-
---
|
|
310
|
-
|
|
311
|
-
> **SpecCrew ไม่ได้มีจุดประสงค์เพื่อแทนที่นักพัฒนา แต่เพื่อทำให้ส่วนที่น่าเบื่อเป็นอัตโนมัติ เพื่อให้ทีมสามารถมุ่งเน้นไปที่งานที่มีคุณค่ามากขึ้น**
|
package/README.tr.md
DELETED
|
@@ -1,306 +0,0 @@
|
|
|
1
|
-
# SpecCrew - AI Destekli Yazılım Mühendisliği Çerçevesi
|
|
2
|
-
|
|
3
|
-
<p align="center">
|
|
4
|
-
<a href="./README.md">简体中文</a> |
|
|
5
|
-
<a href="./README.zh-TW.md">繁體中文</a> |
|
|
6
|
-
<a href="./README.en.md">English</a> |
|
|
7
|
-
<a href="./README.ko.md">한국어</a> |
|
|
8
|
-
<a href="./README.de.md">Deutsch</a> |
|
|
9
|
-
<a href="./README.es.md">Español</a> |
|
|
10
|
-
<a href="./README.fr.md">Français</a> |
|
|
11
|
-
<a href="./README.it.md">Italiano</a> |
|
|
12
|
-
<a href="./README.da.md">Dansk</a> |
|
|
13
|
-
<a href="./README.ja.md">日本語</a> |
|
|
14
|
-
<a href="./README.pl.md">Polski</a> |
|
|
15
|
-
<a href="./README.ru.md">Русский</a> |
|
|
16
|
-
<a href="./README.bs.md">Bosanski</a> |
|
|
17
|
-
<a href="./README.ar.md">العربية</a> |
|
|
18
|
-
<a href="./README.no.md">Norsk</a> |
|
|
19
|
-
<a href="./README.pt-BR.md">Português (Brasil)</a> |
|
|
20
|
-
<a href="./README.th.md">ไทย</a> |
|
|
21
|
-
<a href="./README.tr.md">Türkçe</a> |
|
|
22
|
-
<a href="./README.uk.md">Українська</a> |
|
|
23
|
-
<a href="./README.bn.md">বাংলা</a> |
|
|
24
|
-
<a href="./README.el.md">Ελληνικά</a> |
|
|
25
|
-
<a href="./README.vi.md">Tiếng Việt</a>
|
|
26
|
-
</p>
|
|
27
|
-
|
|
28
|
-
<p align="center">
|
|
29
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/v/speccrew.svg" alt="npm version"></a>
|
|
30
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/dm/speccrew.svg" alt="npm downloads"></a>
|
|
31
|
-
<a href="https://github.com/charlesmu99/speccrew/blob/main/LICENSE"><img src="https://img.shields.io/npm/l/speccrew.svg" alt="license"></a>
|
|
32
|
-
</p>
|
|
33
|
-
|
|
34
|
-
> Herhangi bir yazılım projesi için hızlı mühendislik uygulaması sağlayan sanal bir AI geliştirme ekibi
|
|
35
|
-
|
|
36
|
-
## SpecCrew Nedir?
|
|
37
|
-
|
|
38
|
-
SpecCrew, gömülü bir sanal AI geliştirme ekibi çerçevesidir. Profesyonel yazılım mühendisliği iş akışlarını (PRD → Feature Design → System Design → Dev → Test) yeniden kullanılabilir Agent iş akışlarına dönüştürerek geliştirme ekiplerinin Specification-Driven Development (SDD) elde etmesine yardımcı olur ve özellikle mevcut projeler için uygundur.
|
|
39
|
-
|
|
40
|
-
Mevcut projelere Agent'ları ve Skill'leri entegre ederek, ekipler proje dokümantasyon sistemlerini ve sanal yazılım ekiplerini hızla başlatabilir ve standart mühendislik iş akışlarını takip ederek yeni özellikleri ve modifikasyonları adım adım uygulayabilir.
|
|
41
|
-
|
|
42
|
-
---
|
|
43
|
-
|
|
44
|
-
## ✨ Ana Özellikler
|
|
45
|
-
|
|
46
|
-
### 🏭 Sanal Yazılım Ekibi
|
|
47
|
-
Tek tıkla **7 profesyonel Agent rolü** + **30+ Skill iş akışı** oluşturma, eksiksiz bir sanal yazılım ekibi oluşturma:
|
|
48
|
-
- **Team Leader** - Global planlama ve iterasyon yönetimi
|
|
49
|
-
- **Product Manager** - Gereksinim analizi ve PRD çıktısı
|
|
50
|
-
- **Feature Designer** - Özellik tasarımı + API sözleşmeleri
|
|
51
|
-
- **System Designer** - Frontend/Backend/Mobil/Desktop sistem tasarımı
|
|
52
|
-
- **System Developer** - Çoklu platform paralel geliştirme
|
|
53
|
-
- **Test Manager** - Üç aşamalı test koordinasyonu
|
|
54
|
-
- **Task Worker** - Alt görev paralel yürütme
|
|
55
|
-
|
|
56
|
-
### 📐 ISA-95 Altı Aşamalı Modelleme
|
|
57
|
-
Uluslararası **ISA-95** modelleme metodolojisine dayalı, iş gereksinimlerinden yazılım sistemlerine dönüşümün standartlaştırılması:
|
|
58
|
-
```
|
|
59
|
-
Domain Descriptions → Functions in Domains → Functions of Interest
|
|
60
|
-
↓ ↓ ↓
|
|
61
|
-
Information Flows → Categories of Information → Information Descriptions
|
|
62
|
-
```
|
|
63
|
-
- Her aşama belirli UML diyagramlarına karşılık gelir (use case, sequence, class)
|
|
64
|
-
- İş gereksinimleri "adım adım rafine edilir", bilgi kaybı olmadan
|
|
65
|
-
- Çıktılar geliştirme için doğrudan kullanılabilir
|
|
66
|
-
|
|
67
|
-
### 📚 Bilgi Tabanı Sistemi
|
|
68
|
-
AI'nın her zaman "tek gerçek kaynağına" dayanarak çalışmasını sağlayan üç katmanlı bilgi tabanı mimarisi:
|
|
69
|
-
|
|
70
|
-
| Katman | Dizin | İçerik | Amaç |
|
|
71
|
-
|--------|-------|--------|------|
|
|
72
|
-
| L1 Sistem Bilgisi | `knowledge/techs/` | Tech stack, mimari, sözleşmeler | AI projenin teknik sınırlarını anlar |
|
|
73
|
-
| L2 İş Bilgisi | `knowledge/bizs/` | Modül işlevleri, iş akışları, varlıklar | AI iş mantığını anlar |
|
|
74
|
-
| L3 İterasyon Eserleri | `iterations/iXXX/` | PRD, tasarım belgeleri, test raporları | Mevcut gereksinimler için eksiksiz izlenebilirlik zinciri |
|
|
75
|
-
|
|
76
|
-
### 🔄 Dört Aşamalı Bilgi Hattı
|
|
77
|
-
**Otomatik bilgi üretimi mimarisi**, kaynak koddan iş/teknik dokümantasyonun otomatik olarak oluşturulması:
|
|
78
|
-
```
|
|
79
|
-
Aşama 1: Kaynak kod tarama → Modül listesi oluşturma
|
|
80
|
-
Aşama 2: Paralel analiz → Özellik çıkarma (çoklu Worker paralel)
|
|
81
|
-
Aşama 3: Paralel özetleme → Modül görünümlerini tamamlama (çoklu Worker paralel)
|
|
82
|
-
Aşama 4: Sistem agregasyonu → Sistem panoraması oluşturma
|
|
83
|
-
```
|
|
84
|
-
- **Tam senkronizasyon** ve **artımlı senkronizasyon** destekler (Git diff tabanlı)
|
|
85
|
-
- Bir kişi optimize eder, ekip paylaşır
|
|
86
|
-
|
|
87
|
-
### 🔧 Harness Pratik Uygulama Çerçevesi
|
|
88
|
-
**Standartlaştırılmış yürütme çerçevesi**, tasarım belgelerinin yürütülebilir geliştirme talimatlarına hassas bir şekilde dönüştürülmesini sağlar:
|
|
89
|
-
- **Operasyonel kılavuz ilkesi**: Skill bir SOP'dur, adımlar net, ardışık ve kendi kendine yeten
|
|
90
|
-
- **Girdi-çıktı sözleşmesi**: Arayüzleri açıkça tanımlar, pseudocode gibi titizlikle yürütür
|
|
91
|
-
- **Aşamalı açıklama mimarisi**: Bilgileri katmanlı yükler, tek seferde bağlam aşırı yüklenmesini önler
|
|
92
|
-
- **Alt Agent delege etme**: Karmaşık görevleri otomatik böler, paralel yürütme kaliteyi güvence altına alır
|
|
93
|
-
|
|
94
|
-
---
|
|
95
|
-
|
|
96
|
-
## Çözülen 8 Temel Sorun
|
|
97
|
-
|
|
98
|
-
### 1. AI Mevcut Proje Dokümantasyonunu Görmezden Gelir (Bilgi Boşluğu)
|
|
99
|
-
**Problem**: Mevcut SDD veya Vibe Coding yöntemleri, AI'nın projeleri gerçek zamanlı özetlemesine dayanır, bu da kritik içeriğin kolayca kaçırılmasına ve geliştirme sonuçlarının beklentilerden sapmasına neden olur.
|
|
100
|
-
|
|
101
|
-
**Çözüm**: `knowledge/` deposu projenin "tek doğruluk kaynağı" olarak hizmet eder, mimari tasarımı, işlevsel modülleri ve iş süreçlerini biriktirerek gereksinimlerin kaynaktan itibaren yolda kalmasını sağlar.
|
|
102
|
-
|
|
103
|
-
### 2. PRD'den Doğrudan Teknik Dokümantasyon (İçerik Atlama)
|
|
104
|
-
**Problem**: PRD'den doğrudan detaylı tasarıma atlamak, gereksinim detaylarını kolayca kaçırır ve uygulanan özelliklerin gereksinimlerden sapmasına neden olur.
|
|
105
|
-
|
|
106
|
-
**Çözüm**: Teknik detaylar olmadan yalnızca gereksinim iskeletine odaklanan **Feature Design Dokümanı** aşamasını tanıtın:
|
|
107
|
-
- Hangi sayfalar ve bileşenler dahil?
|
|
108
|
-
- Sayfa operasyon akışları
|
|
109
|
-
- Backend işleme mantığı
|
|
110
|
-
- Veri depolama yapısı
|
|
111
|
-
|
|
112
|
-
Geliştirme, belirli teknoloji yığınına dayalı olarak sadece "eti doldurmak" zorundadır ve özelliklerin "kemiklere (gereksinimlere) yakın" büyümesini sağlar.
|
|
113
|
-
|
|
114
|
-
### 3. Belirsiz Agent Arama Kapsamı (Belirsizlik)
|
|
115
|
-
**Problem**: Karmaşık projelerde, AI'nın geniş kod ve doküman araması belirsiz sonuçlar verir ve tutarlılığı garanti etmeyi zorlaştırır.
|
|
116
|
-
|
|
117
|
-
**Çözüm**: Her Agent'ın ihtiyaçlarına göre tasarlanmış net doküman dizin yapıları ve şablonlar, determinizmi garanti etmek için **aşamalı açıklama ve talep üzerine yükleme** uygular.
|
|
118
|
-
|
|
119
|
-
### 4. Eksik Aşamalar ve Görevler (Süreç Kopukluğu)
|
|
120
|
-
**Problem**: Eksik mühendislik süreci kapsamı kritik adımları kolayca kaçırır ve kaliteyi garanti etmeyi zorlaştırır.
|
|
121
|
-
|
|
122
|
-
**Çözüm**: Yazılım mühendisliği yaşam döngüsünün tamamını kapsar:
|
|
123
|
-
```
|
|
124
|
-
PRD (Gereksinimler) → Feature Design (Özellik Tasarımı) → API Contract (Sözleşme)
|
|
125
|
-
→ System Design (Sistem Tasarımı) → Dev (Geliştirme) → Test (Test)
|
|
126
|
-
```
|
|
127
|
-
- Her aşamanın çıktısı bir sonraki aşamanın girdisidir
|
|
128
|
-
- Her adım devam etmeden önce insan onayı gerektirir
|
|
129
|
-
- Tüm Agent yürütmelerinin tamamlanma sonrası kendi kendini kontrol eden todo listeleri vardır
|
|
130
|
-
|
|
131
|
-
### 5. Düşük Takım İşbirliği Verimliliği (Bilgi Siloları)
|
|
132
|
-
**Problem**: AI programlama deneyimi takımlar arasında paylaşılması zor olduğundan, tekrarlanan hatalara yol açar.
|
|
133
|
-
|
|
134
|
-
**Çözüm**: Tüm Agent'lar, Skill'ler ve ilgili dokümanlar kaynak koduyla birlikte versiyon kontrol edilir:
|
|
135
|
-
- Bir kişinin optimizasyonu takım tarafından paylaşılır
|
|
136
|
-
- Bilgi kod tabanında birikir
|
|
137
|
-
- Takım işbirliği verimliliği artar
|
|
138
|
-
|
|
139
|
-
### 7. Tek Agent Bağlamı Çok Uzun (Performans Darboğazı)
|
|
140
|
-
**Problem**: Büyük karmaşık görevler tek Agent bağlam pencerelerini aşar, anlama sapmalarına ve çıktı kalitesinin düşmesine neden olur.
|
|
141
|
-
|
|
142
|
-
**Çözüm**: **Sub-Agent Otomatik Dispatch Mekanizması**:
|
|
143
|
-
- Karmaşık görevler otomatik olarak tanımlanır ve alt görevlere bölünür
|
|
144
|
-
- Her alt görev, izole bağlam ile bağımsız bir Sub-Agent tarafından yürütülür
|
|
145
|
-
- Parent Agent koordine eder ve birleştirerek genel tutarlılığı sağlar
|
|
146
|
-
- Tek Agent bağlam genişlemesini önler ve çıktı kalitesini garanti eder
|
|
147
|
-
|
|
148
|
-
### 8. Gereksinim İterasyon Kaosu (Yönetim Zorluğu)
|
|
149
|
-
**Problem**: Aynı dalda karıştırılan birden fazla gereksinim birbirini etkiler, takip ve geri alma işlemlerini zorlaştırır.
|
|
150
|
-
|
|
151
|
-
**Çözüm**: **Her Gereksinim Bir Bağımsız Proje Olarak**:
|
|
152
|
-
- Her gereksinim bağımsız bir iterasyon dizini oluşturur `iterations/iXXX-[gereksinim-adı]/`
|
|
153
|
-
- Tam izolasyon: dokümanlar, tasarım, kod ve testler bağımsız yönetilir
|
|
154
|
-
- Hızlı iterasyon: küçük parçalı teslimat, hızlı doğrulama, hızlı dağıtım
|
|
155
|
-
- Esnek arşivleme: tamamlandıktan sonra, net tarihsel izlenebilirlikle `archive/` altında arşivlenir
|
|
156
|
-
|
|
157
|
-
### 6. Doküman Güncelleme Gecikmesi (Bilgi Çürümesi)
|
|
158
|
-
**Problem**: Projeler geliştikçe dokümanlar eskir ve AI yanlış bilgiyle çalışır.
|
|
159
|
-
|
|
160
|
-
**Çözüm**: Agent'lar otomatik doküman güncelleme yeteneklerine sahiptir, proje değişikliklerini gerçek zamanlı senkronize ederek bilgi tabanının doğruluğunu korur.
|
|
161
|
-
|
|
162
|
-
---
|
|
163
|
-
|
|
164
|
-
## Temel İş Akışı
|
|
165
|
-
|
|
166
|
-
```mermaid
|
|
167
|
-
graph LR
|
|
168
|
-
A[PRD<br/>Gereksinim Dokümanı] --> B[Feature Design<br/>Özellik Tasarımı]
|
|
169
|
-
B --> C[API Contract<br/>Arayüz Sözleşmesi]
|
|
170
|
-
C --> D[System Design<br/>Sistem Tasarımı]
|
|
171
|
-
D --> E[Dev<br/>Uygulama]
|
|
172
|
-
E --> F[System Test<br/>Test]
|
|
173
|
-
F --> G[Archive<br/>Arşivleme]
|
|
174
|
-
|
|
175
|
-
H[Knowledge<br/>Depo] -.-> A
|
|
176
|
-
H -.-> B
|
|
177
|
-
H -.-> D
|
|
178
|
-
H -.-> E
|
|
179
|
-
|
|
180
|
-
E -.-> H
|
|
181
|
-
F -.-> H
|
|
182
|
-
```
|
|
183
|
-
|
|
184
|
-
### Aşama Açıklamaları
|
|
185
|
-
|
|
186
|
-
| Aşama | Agent | Girdi | Çıktı | İnsan Onayı |
|
|
187
|
-
|-------|-------|-------|-------|-------------|
|
|
188
|
-
| PRD | PM | Kullanıcı Gereksinimleri | Ürün Gereksinim Dokümanı | ✅ Gerekli |
|
|
189
|
-
| Feature Design | Feature Designer | PRD | Feature Design Dokümanı + API Sözleşmesi | ✅ Gerekli |
|
|
190
|
-
| System Design | System Designer | Feature Spec | Frontend/Backend Tasarım Dokümanları | ✅ Gerekli |
|
|
191
|
-
| Dev | Dev | Design | Kod + Görev Kayıtları | ✅ Gerekli |
|
|
192
|
-
| System Test | Test Manager | Dev Çıktısı + Feature Spec | Test Senaryoları + Test Kodu + Test Raporu + Bug Raporu | ✅ Gerekli |
|
|
193
|
-
|
|
194
|
-
---
|
|
195
|
-
|
|
196
|
-
## Mevcut Çözümlerle Karşılaştırma
|
|
197
|
-
|
|
198
|
-
| Boyut | Vibe Coding | Ralph Loop | **SpecCrew** |
|
|
199
|
-
|-------|-------------|------------|-------------|
|
|
200
|
-
| Doküman Bağımlılığı | Mevcut dokümanları görmezden gelir | AGENTS.md'e bağımlı | **Yapılandırılmış Bilgi Tabanı** |
|
|
201
|
-
| Gereksinim Transferi | Doğrudan kodlama | PRD → Kod | **PRD → Feature Design → System Design → Kod** |
|
|
202
|
-
| İnsan Katılımı | Minimal | Başlangıçta | **Her aşamada** |
|
|
203
|
-
| Süreç Tamlığı | Zayıf | Orta | **Tam mühendislik iş akışı** |
|
|
204
|
-
| Takım İşbirliği | Paylaşım zor | Kişisel verimlilik | **Takım bilgi paylaşımı** |
|
|
205
|
-
| Bağlam Yönetimi | Tek örnek | Tek örnek döngüsü | **Sub-Agent otomatik dispatch** |
|
|
206
|
-
| İterasyon Yönetimi | Karışık | Görev listesi | **Gereksinim proje olarak, bağımsız iterasyon** |
|
|
207
|
-
| Determinizm | Düşük | Orta | **Yüksek (aşamalı açıklama)** |
|
|
208
|
-
|
|
209
|
-
---
|
|
210
|
-
|
|
211
|
-
## Hızlı Başlangıç
|
|
212
|
-
|
|
213
|
-
### Önkoşullar
|
|
214
|
-
|
|
215
|
-
- Node.js >= 16.0.0
|
|
216
|
-
- Desteklenen IDE'ler: Qoder (varsayılan), Cursor, Claude Code
|
|
217
|
-
|
|
218
|
-
> **Not**: Cursor ve Claude Code için adaptörler gerçek IDE ortamlarında test edilmemiştir (kod seviyesinde uygulanmış ve E2E testleri ile doğrulanmış, ancak gerçek Cursor/Claude Code'da henüz test edilmemiştir).
|
|
219
|
-
|
|
220
|
-
### 1. SpecCrew'ü Kurun
|
|
221
|
-
|
|
222
|
-
```bash
|
|
223
|
-
npm install -g speccrew
|
|
224
|
-
```
|
|
225
|
-
|
|
226
|
-
### 2. Projeyi Başlatın
|
|
227
|
-
|
|
228
|
-
Projenizin kök dizinine gidin ve başlatma komutunu çalıştırın:
|
|
229
|
-
|
|
230
|
-
```bash
|
|
231
|
-
cd /path/to/your-project
|
|
232
|
-
|
|
233
|
-
# Varsayılan olarak Qoder kullanır
|
|
234
|
-
speccrew init
|
|
235
|
-
|
|
236
|
-
# Veya IDE belirtin
|
|
237
|
-
speccrew init --ide qoder
|
|
238
|
-
speccrew init --ide cursor
|
|
239
|
-
speccrew init --ide claude
|
|
240
|
-
```
|
|
241
|
-
|
|
242
|
-
Başlatmadan sonra projenizde şu dosyalar oluşturulacaktır:
|
|
243
|
-
- `.qoder/agents/` / `.cursor/agents/` / `.claude/agents/` — 7 Agent rol tanımı
|
|
244
|
-
- `.qoder/skills/` / `.cursor/skills/` / `.claude/skills/` — 30+ Skill iş akışı
|
|
245
|
-
- `speccrew-workspace/` — Çalışma alanı (iterasyon dizinleri, bilgi tabanı, doküman şablonları)
|
|
246
|
-
- `.speccrewrc` — SpecCrew yapılandırma dosyası
|
|
247
|
-
|
|
248
|
-
Daha sonra belirli bir IDE için Agent'ları ve Skill'leri güncellemek için:
|
|
249
|
-
|
|
250
|
-
```bash
|
|
251
|
-
speccrew update --ide cursor
|
|
252
|
-
speccrew update --ide claude
|
|
253
|
-
```
|
|
254
|
-
|
|
255
|
-
### 3. Geliştirme İş Akışını Başlatın
|
|
256
|
-
|
|
257
|
-
Standart mühendislik iş akışını adım adım takip edin:
|
|
258
|
-
|
|
259
|
-
1. **PRD**: Product Manager Agent gereksinimleri analiz eder ve ürün gereksinim dokümanı oluşturur
|
|
260
|
-
2. **Feature Design**: Feature Designer Agent feature design dokümanı + API sözleşmesi oluşturur
|
|
261
|
-
3. **System Design**: System Designer Agent platformlara göre sistem tasarım dokümanları oluşturur (frontend/backend/mobile/desktop)
|
|
262
|
-
4. **Dev**: System Developer Agent platformlara göre paralel geliştirme uygular
|
|
263
|
-
5. **System Test**: Test Manager Agent üç aşamalı test koordine eder (senaryo tasarımı → kod üretimi → yürütme raporu)
|
|
264
|
-
6. **Archive**: İterasyonu arşivle
|
|
265
|
-
|
|
266
|
-
> Her aşamanın teslim edilebilirleri bir sonraki aşamaya geçmeden önce insan onayı gerektirir.
|
|
267
|
-
|
|
268
|
-
### 4. SpecCrew'ü Güncelle
|
|
269
|
-
|
|
270
|
-
SpecCrew'un yeni bir sürümü yayınlandığında, güncellemeyi iki adımda tamamlayın:
|
|
271
|
-
|
|
272
|
-
```bash
|
|
273
|
-
# Step 1: Update the global CLI tool to the latest version
|
|
274
|
-
npm install -g speccrew@latest
|
|
275
|
-
|
|
276
|
-
# Step 2: Sync Agents and Skills in your project to the latest version
|
|
277
|
-
cd /path/to/your-project
|
|
278
|
-
speccrew update
|
|
279
|
-
```
|
|
280
|
-
|
|
281
|
-
> **Not**: `npm install -g speccrew@latest` CLI aracının kendisini güncellerken, `speccrew update` projenizdeki Agent ve Skill tanım dosyalarını günceller. Tam bir güncelleme için her iki adım da gereklidir.
|
|
282
|
-
|
|
283
|
-
### 5. Diğer CLI Komutları
|
|
284
|
-
|
|
285
|
-
```bash
|
|
286
|
-
speccrew list # Yüklü agent'ları ve skill'leri listele
|
|
287
|
-
speccrew doctor # Ortamı ve kurulum durumunu teşhis et
|
|
288
|
-
speccrew update # Agent'ları ve skill'leri en son sürüme güncelle
|
|
289
|
-
speccrew uninstall # SpecCrew'ü kaldır (--all çalışma alanını da siler)
|
|
290
|
-
```
|
|
291
|
-
|
|
292
|
-
📖 **Detaylı Kılavuz**: Kurulumdan sonra, tam iş akışı ve Agent konuşma kılavuzu için [Başlangıç Kılavuzu](docs/GETTING-STARTED.tr.md)'na bakın.
|
|
293
|
-
|
|
294
|
-
---
|
|
295
|
-
|
|
296
|
-
## Daha Fazla Bilgi
|
|
297
|
-
|
|
298
|
-
- **Agent Bilgi Haritası**: [speccrew-workspace/docs/agent-knowledge-map.md](./speccrew-workspace/docs/agent-knowledge-map.md)
|
|
299
|
-
- **npm**: https://www.npmjs.com/package/speccrew
|
|
300
|
-
- **GitHub**: https://github.com/charlesmu99/speccrew
|
|
301
|
-
- **Gitee**: https://gitee.com/amutek/speccrew
|
|
302
|
-
- **Qoder IDE**: https://qoder.com/
|
|
303
|
-
|
|
304
|
-
---
|
|
305
|
-
|
|
306
|
-
> **SpecCrew geliştiricilerin yerini almayı değil, sıkıcı kısımları otomatikleştirerek ekiplerin daha değerli işlere odaklanmasını sağlar.**
|