@torus-engineering/tas-kit 1.6.0 → 1.8.0
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/.claude/commands/tas-adr.md +33 -29
- package/.claude/commands/tas-api-test.md +95 -0
- package/.claude/commands/tas-bug.md +113 -109
- package/.claude/commands/tas-design.md +37 -33
- package/.claude/commands/tas-dev.md +128 -115
- package/.claude/commands/tas-e2e-mobile.md +155 -0
- package/.claude/commands/tas-e2e-web.md +163 -0
- package/.claude/commands/tas-e2e.md +102 -0
- package/.claude/commands/tas-epic.md +35 -31
- package/.claude/commands/tas-feature.md +47 -43
- package/.claude/commands/tas-fix.md +51 -47
- package/.claude/commands/tas-functest-mobile.md +144 -0
- package/.claude/commands/tas-functest-web.md +192 -0
- package/.claude/commands/tas-functest.md +76 -0
- package/.claude/commands/tas-plan.md +200 -184
- package/.claude/commands/tas-prd.md +37 -33
- package/.claude/commands/tas-review.md +111 -104
- package/.claude/commands/tas-sad.md +43 -39
- package/.claude/commands/tas-security.md +81 -80
- package/.claude/commands/tas-story.md +91 -87
- package/.claude/commands/tas-verify.md +51 -41
- package/.claude/rules/common/post-review-agent.md +49 -39
- package/.claude/rules/common/testing.md +24 -0
- package/.claude/rules/common/token-logging.md +27 -0
- package/.claude/rules/csharp/api-testing.md +171 -0
- package/.claude/rules/csharp/patterns.md +10 -0
- package/.claude/rules/python/patterns.md +10 -0
- package/.claude/rules/typescript/patterns.md +10 -0
- package/.claude/rules/web/performance.md +9 -0
- package/.claude/skills/api-design/SKILL.md +3 -1
- package/.claude/skills/{backend-patterns → js-backend-patterns}/SKILL.md +2 -1
- package/.claude/skills/tas-implementation-complete/SKILL.md +99 -97
- package/.claude/skills/tas-tdd/SKILL.md +123 -82
- package/.claude/skills/token-logger/SKILL.md +19 -0
- package/.tas/templates/E2E-Execution-Report.md +198 -0
- package/.tas/templates/E2E-Mobile-Spec.md +130 -0
- package/.tas/templates/E2E-Report.md +174 -0
- package/.tas/templates/E2E-Scenario.md +180 -0
- package/.tas/templates/E2E-Web-Spec.md +164 -0
- package/.tas/templates/Feature.md +55 -55
- package/.tas/templates/Func-Test-Script.md +254 -0
- package/.tas/templates/Func-Test-Spec.md +187 -0
- package/.tas/templates/SAD.md +274 -64
- package/.tas/templates/Story.md +90 -88
- package/bin/cli.js +56 -49
- package/lib/deleted-files.json +33 -0
- package/lib/install.js +213 -114
- package/package.json +34 -34
- package/.claude/agents/README.md +0 -83
- package/.claude/agents/ado-agent.md +0 -39
- package/.claude/agents/code-architect.md +0 -62
- package/.claude/agents/code-simplifier.md +0 -53
- package/.claude/agents/comment-analyzer.md +0 -59
- package/.claude/agents/conversation-analyzer.md +0 -57
- package/.claude/agents/docs-lookup.md +0 -55
- package/.claude/agents/harness-optimizer.md +0 -62
- package/.claude/agents/loop-operator.md +0 -56
- package/.claude/agents/performance-optimizer.md +0 -78
- package/.claude/agents/pr-test-analyzer.md +0 -68
- package/.claude/agents/pytorch-build-resolver.md +0 -76
- package/.claude/agents/refactor-cleaner.md +0 -70
- package/.claude/agents/seo-specialist.md +0 -75
- package/.claude/agents/silent-failure-hunter.md +0 -69
- package/.claude/agents/type-design-analyzer.md +0 -75
- package/.claude/rules/common/agents.md +0 -65
- package/.claude/rules/common/coding-style.md +0 -90
- package/.claude/rules/common/development-workflow.md +0 -44
- package/.claude/rules/common/git-workflow.md +0 -24
- package/.claude/rules/common/performance.md +0 -55
- package/.claude/skills/agent-harness-construction/SKILL.md +0 -77
- package/.claude/skills/agent-introspection-debugging/SKILL.md +0 -157
|
@@ -1,29 +1,33 @@
|
|
|
1
|
-
# /tas-adr $ARGUMENTS
|
|
2
|
-
|
|
3
|
-
Vai trò: SE - Software Engineer
|
|
4
|
-
Tạo mới hoặc cập nhật Architecture Decision Record.
|
|
5
|
-
|
|
6
|
-
## Hành động
|
|
7
|
-
1. Cần context từ .tas/templates/ADR.md
|
|
8
|
-
2. Quét docs/adr/ để xác định các ADR hiện có
|
|
9
|
-
3. Xác định chế độ dựa vào $ARGUMENTS:
|
|
10
|
-
|
|
11
|
-
### Chế độ CREATE ($ARGUMENTS là tiêu đề mới, ví dụ: "Use CQRS for Order Service"):
|
|
12
|
-
4. Xác định số thứ tự tiếp theo (ADR-001, ADR-002...)
|
|
13
|
-
5. Nếu docs/sad.md tồn tại, cần context từ SAD để đảm bảo ADR consistent
|
|
14
|
-
6. Tạo file docs/adr/ADR-{NNN}-{slug}.md
|
|
15
|
-
7. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm entry vào `adrs`.
|
|
16
|
-
|
|
17
|
-
### Chế độ UPDATE ($ARGUMENTS là ADR ID, ví dụ: "ADR-001"):
|
|
18
|
-
4. Cần context từ file ADR hiện tại
|
|
19
|
-
5. Hỏi user cần thay đổi gì (cập nhật status, thêm consequences, supersede...)
|
|
20
|
-
6. Cập nhật file, thêm changelog
|
|
21
|
-
7. Nếu supersede: cập nhật status ADR cũ thành "Superseded by ADR-{NNN}"
|
|
22
|
-
8. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `adrs.{ADR_ID}.status`.
|
|
23
|
-
|
|
24
|
-
## Nguyên tắc
|
|
25
|
-
- ADR phải có: Context, Decision, Rationale, Consequences, Alternatives Considered
|
|
26
|
-
- Status: Proposed | Accepted | Deprecated | Superseded
|
|
27
|
-
- Mỗi ADR độc lập, tự chứa đủ context để hiểu
|
|
28
|
-
- Link sang ADR liên quan nếu có (Supersedes, Related to)
|
|
29
|
-
- Sơ đồ Mermaid tuân thủ quy tắc: :::mermaid wrapper, không dùng ()
|
|
1
|
+
# /tas-adr $ARGUMENTS
|
|
2
|
+
|
|
3
|
+
Vai trò: SE - Software Engineer
|
|
4
|
+
Tạo mới hoặc cập nhật Architecture Decision Record.
|
|
5
|
+
|
|
6
|
+
## Hành động
|
|
7
|
+
1. Cần context từ .tas/templates/ADR.md
|
|
8
|
+
2. Quét docs/adr/ để xác định các ADR hiện có
|
|
9
|
+
3. Xác định chế độ dựa vào $ARGUMENTS:
|
|
10
|
+
|
|
11
|
+
### Chế độ CREATE ($ARGUMENTS là tiêu đề mới, ví dụ: "Use CQRS for Order Service"):
|
|
12
|
+
4. Xác định số thứ tự tiếp theo (ADR-001, ADR-002...)
|
|
13
|
+
5. Nếu docs/sad.md tồn tại, cần context từ SAD để đảm bảo ADR consistent
|
|
14
|
+
6. Tạo file docs/adr/ADR-{NNN}-{slug}.md
|
|
15
|
+
7. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm entry vào `adrs`.
|
|
16
|
+
|
|
17
|
+
### Chế độ UPDATE ($ARGUMENTS là ADR ID, ví dụ: "ADR-001"):
|
|
18
|
+
4. Cần context từ file ADR hiện tại
|
|
19
|
+
5. Hỏi user cần thay đổi gì (cập nhật status, thêm consequences, supersede...)
|
|
20
|
+
6. Cập nhật file, thêm changelog
|
|
21
|
+
7. Nếu supersede: cập nhật status ADR cũ thành "Superseded by ADR-{NNN}"
|
|
22
|
+
8. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `adrs.{ADR_ID}.status`.
|
|
23
|
+
|
|
24
|
+
## Nguyên tắc
|
|
25
|
+
- ADR phải có: Context, Decision, Rationale, Consequences, Alternatives Considered
|
|
26
|
+
- Status: Proposed | Accepted | Deprecated | Superseded
|
|
27
|
+
- Mỗi ADR độc lập, tự chứa đủ context để hiểu
|
|
28
|
+
- Link sang ADR liên quan nếu có (Supersedes, Related to)
|
|
29
|
+
- Sơ đồ Mermaid tuân thủ quy tắc: :::mermaid wrapper, không dùng ()
|
|
30
|
+
|
|
31
|
+
## Bước cuối — Token Log
|
|
32
|
+
|
|
33
|
+
Invoke skill `token-logger`: ghi AI Usage Log vào file ADR đang làm việc.
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
# /tas-api-test $ARGUMENTS
|
|
2
|
+
|
|
3
|
+
Vai trò: SE - Software Engineer
|
|
4
|
+
Generate .NET xUnit automation test project cho REST API từ spec (OpenAPI 3.0, Markdown, YAML).
|
|
5
|
+
|
|
6
|
+
## Always / Ask / Never
|
|
7
|
+
|
|
8
|
+
| | Hành động |
|
|
9
|
+
|---|---|
|
|
10
|
+
| **Always** | Đọc toàn bộ spec trước khi generate bất kỳ test nào |
|
|
11
|
+
| **Always** | Tổ chức tests theo API version — mỗi version một folder riêng |
|
|
12
|
+
| **Always** | Append-only: không sửa files trong version folder cũ đã tồn tại |
|
|
13
|
+
| **Always** | URL và credentials ra `appsettings.json` — không hardcode trong code |
|
|
14
|
+
| **Always** | XML doc comment trên mỗi test method |
|
|
15
|
+
| **Ask** | Khi spec không rõ expected response schema |
|
|
16
|
+
| **Never** | Sửa hoặc xóa test files của version cũ hơn |
|
|
17
|
+
| **Never** | Hardcode base URL, API key, credentials trong test code |
|
|
18
|
+
| **Never** | Bỏ qua error path — mỗi endpoint cần ≥1 happy path + ≥1 error path |
|
|
19
|
+
|
|
20
|
+
## Hành động
|
|
21
|
+
|
|
22
|
+
### Bước 1 — Locate Inputs
|
|
23
|
+
|
|
24
|
+
`$ARGUMENTS` là path đến spec file hoặc Story ID. Nếu không có → hỏi user.
|
|
25
|
+
|
|
26
|
+
Nếu là Story ID: glob tìm `docs/epics/**/Story-{ID}*.md`, đọc Story để tìm link spec trong `## Technical Plan` hoặc `## Acceptance Criteria`.
|
|
27
|
+
|
|
28
|
+
### Bước 2 — Parse API Spec
|
|
29
|
+
|
|
30
|
+
Đọc `.claude/rules/csharp/api-testing.md` để nắm convention trước khi generate.
|
|
31
|
+
|
|
32
|
+
Từ spec, thu thập cho mỗi endpoint:
|
|
33
|
+
- HTTP method + path, path/query params, request body schema
|
|
34
|
+
- Response schemas theo từng status code
|
|
35
|
+
- Auth requirement, description/summary
|
|
36
|
+
|
|
37
|
+
Nếu có Story: đọc thêm `## Acceptance Criteria` để bổ sung business rule test cases.
|
|
38
|
+
|
|
39
|
+
### Bước 3 — Detect Existing Test Project
|
|
40
|
+
|
|
41
|
+
Glob tìm `**/ApiTests/*.csproj`, `**/Api.Tests/*.csproj`, `**/IntegrationTests/*.csproj`.
|
|
42
|
+
|
|
43
|
+
- **Tìm thấy**: Đọc framework đang dùng (xUnit/NUnit/MSTest), glob `v*/` folders để biết versions đã có.
|
|
44
|
+
- **Không tìm thấy**: Tạo mới tại `tests/ApiTests/` với xUnit + FluentAssertions (per `csharp/testing.md`).
|
|
45
|
+
|
|
46
|
+
### Bước 4 — Detect API Version
|
|
47
|
+
|
|
48
|
+
Ưu tiên theo thứ tự: `info.version` trong OpenAPI → prefix trong URL path → hỏi user.
|
|
49
|
+
Version folder: lowercase, không có dot — `v1`, `v2` (không phải `v1.0`).
|
|
50
|
+
|
|
51
|
+
### Bước 5 — Generate Infrastructure (chỉ khi tạo project mới)
|
|
52
|
+
|
|
53
|
+
Đọc `.claude/rules/csharp/api-testing.md` section **Project Structure** và **Config Pattern** để generate:
|
|
54
|
+
- `ApiTests.csproj` với packages chuẩn
|
|
55
|
+
- `appsettings.json` (base) + `appsettings.Test.json` + `appsettings.Staging.json`
|
|
56
|
+
- `Shared/TestBase.cs` — load config, HttpClient, helper methods
|
|
57
|
+
- `Shared/ApiTestSettings.cs` — strongly typed settings
|
|
58
|
+
- `.gitignore` cho `appsettings.*.local.json`
|
|
59
|
+
|
|
60
|
+
### Bước 6 — Generate Test Classes
|
|
61
|
+
|
|
62
|
+
Nhóm endpoints theo resource/tag. Mỗi nhóm → `tests/ApiTests/{version}/{Resource}ApiTests.cs`.
|
|
63
|
+
|
|
64
|
+
Với mỗi endpoint, generate tối thiểu:
|
|
65
|
+
1. Happy path (2xx)
|
|
66
|
+
2. Unauthorized (401) — nếu endpoint yêu cầu auth
|
|
67
|
+
3. Not found (404) — nếu có path param
|
|
68
|
+
4. Validation error (400/422) — nếu có required fields
|
|
69
|
+
|
|
70
|
+
Từ Story ACs: thêm test methods tương ứng, comment rõ `// AC: {AC text}`.
|
|
71
|
+
|
|
72
|
+
Đầu mỗi file: block comment ghi `Spec`, `Generated date`, `Story ID`, và nhắc **APPEND-ONLY rule**.
|
|
73
|
+
|
|
74
|
+
### Bước 7 — Append-Only Guard
|
|
75
|
+
|
|
76
|
+
Trước khi ghi file: kiểm tra file đã tồn tại chưa.
|
|
77
|
+
- File chưa có → tạo mới bình thường.
|
|
78
|
+
- File đã tồn tại trong version folder → **DỪNG**, thông báo tên file cho user tự edit thủ công.
|
|
79
|
+
|
|
80
|
+
### Bước 8 — Post-Generate Review
|
|
81
|
+
|
|
82
|
+
Launch `csharp-reviewer` agent:
|
|
83
|
+
> Review `tests/ApiTests/{version}/`. Đọc `.claude/rules/csharp/testing.md` + `.claude/rules/csharp/api-testing.md`.
|
|
84
|
+
> Tập trung: async/await, HttpClient disposal, assertion completeness, XML doc coverage.
|
|
85
|
+
> Format: Critical / High / Medium / Low với file:line.
|
|
86
|
+
|
|
87
|
+
Gate: Critical/High → fix ngay. Medium/Low → list gợi ý.
|
|
88
|
+
|
|
89
|
+
### Bước 9 — Summary
|
|
90
|
+
|
|
91
|
+
Hiển thị bảng coverage (endpoint × test type: ✓/—) và next steps để chạy tests.
|
|
92
|
+
|
|
93
|
+
## Bước cuối — Token Log
|
|
94
|
+
|
|
95
|
+
Invoke skill `token-logger`: ghi AI Usage Log vào spec file hoặc Story đang làm việc.
|
|
@@ -1,109 +1,113 @@
|
|
|
1
|
-
# /tas-bug $ARGUMENTS
|
|
2
|
-
|
|
3
|
-
Quản lý toàn bộ lifecycle của bug: tạo, phân tích, fix, verify.
|
|
4
|
-
Status của bug xác định bước tiếp theo — không cần khai báo role.
|
|
5
|
-
|
|
6
|
-
## Always / Ask / Never
|
|
7
|
-
|
|
8
|
-
| | Hành động |
|
|
9
|
-
|---|---|
|
|
10
|
-
| **Always** | Hiển thị status hiện tại và action tiếp theo trước khi làm gì |
|
|
11
|
-
| **Always** | Viết regression test TRƯỚC khi fix |
|
|
12
|
-
| **Always** | Launch review agent độc lập sau khi fix — không review trong cùng session |
|
|
13
|
-
| **Ask** | Khi cần đọc thêm file ngoài Bug file (Status = Committed) |
|
|
14
|
-
| **Never** | Patch symptom — phải fix root cause |
|
|
15
|
-
| **Never** | Bỏ qua bước review sau khi fix |
|
|
16
|
-
| **Never** | Tự commit hay push — đợi user test thủ công trước |
|
|
17
|
-
|
|
18
|
-
## Stack Detection
|
|
19
|
-
Đọc `.claude/rules/common/stack-detection.md`.
|
|
20
|
-
|
|
21
|
-
## Hành động
|
|
22
|
-
|
|
23
|
-
### Bước 1 — Xác định chế độ
|
|
24
|
-
|
|
25
|
-
`$ARGUMENTS` là mô tả bug mới → **Chế độ CREATE**
|
|
26
|
-
`$ARGUMENTS` là Bug ID (ví dụ: `Bug-001`) → **Chế độ UPDATE**
|
|
27
|
-
|
|
28
|
-
---
|
|
29
|
-
|
|
30
|
-
### Chế độ CREATE
|
|
31
|
-
|
|
32
|
-
Vai trò: PE hoặc SE (ai phát hiện bug)
|
|
33
|
-
|
|
34
|
-
1. Đọc `project.code` từ root/`tas.yaml`
|
|
35
|
-
2. Hỏi user:
|
|
36
|
-
- Bug thuộc Feature nào?
|
|
37
|
-
- Severity: `Critical` | `High` | `Medium` | `Low`
|
|
38
|
-
- Steps to reproduce
|
|
39
|
-
- Expected vs Actual behavior
|
|
40
|
-
- Môi trường phát hiện: Test | Staging | Production
|
|
41
|
-
3. Tạo `docs/bugs/{code}-Bug-{NNN}-{slug}.md` từ template `.tas/templates/Bug.md`
|
|
42
|
-
4. Bug status ban đầu: `New`
|
|
43
|
-
|
|
44
|
-
---
|
|
45
|
-
|
|
46
|
-
### Chế độ UPDATE
|
|
47
|
-
|
|
48
|
-
Tìm file Bug qua glob `docs/bugs/*-Bug-{ID}-*.md`, đọc status hiện tại.
|
|
49
|
-
|
|
50
|
-
**Hiển thị trước khi làm gì:**
|
|
51
|
-
> "Bug-{NNN} đang ở status: **{status}** — bước tiếp theo là {action}. Tiếp tục không?"
|
|
52
|
-
|
|
53
|
-
---
|
|
54
|
-
|
|
55
|
-
#### Status = `New` — Phân tích (SE)
|
|
56
|
-
|
|
57
|
-
1. Đọc error logs/stack trace từ Bug file
|
|
58
|
-
2. Trace code flow, xác định file và dòng gây lỗi
|
|
59
|
-
3. Ghi Root Cause Analysis vào Bug file
|
|
60
|
-
4. Viết Regression Test Cases (test reproduce bug)
|
|
61
|
-
5. Cập nhật status: `New` → `Committed`
|
|
62
|
-
|
|
63
|
-
---
|
|
64
|
-
|
|
65
|
-
#### Status = `Committed` — Fix (SE)
|
|
66
|
-
|
|
67
|
-
**Quy tắc đọc file:** CHỈ đọc Bug file. KHÔNG đọc PRD, SAD, ADR, Design-Spec, KHÔNG quét thư mục.
|
|
68
|
-
Nếu cần thêm file → hỏi user xác nhận trước.
|
|
69
|
-
|
|
70
|
-
Trước khi fix, đọc:
|
|
71
|
-
- `.claude/rules/common/security.md` — fix không tạo security risk mới
|
|
72
|
-
- `.claude/rules/common/testing.md` — pattern viết regression test
|
|
73
|
-
- `.claude/rules/[lang_agent stack]/coding-style.md` — tuân thủ conventions
|
|
74
|
-
|
|
75
|
-
**Fix workflow:**
|
|
76
|
-
a. Chạy regression test case → xác nhận **FAIL** (reproduce bug)
|
|
77
|
-
b. Fix code đúng root cause
|
|
78
|
-
c. Chạy regression test → xác nhận **PASS**
|
|
79
|
-
d. Chạy toàn bộ test suite → không có regression mới
|
|
80
|
-
→ Nếu build fail hoặc test lỗi compile: launch `build-resolver` agent với error output trước khi tiếp tục.
|
|
81
|
-
|
|
82
|
-
**Sau khi fix — Post-Fix Review (Isolated Agent):**
|
|
83
|
-
|
|
84
|
-
Thực hiện theo `.claude/rules/common/post-review-agent.md`.
|
|
85
|
-
Truyền vào: Bug file path, danh sách changed files, stack (từ CLAUDE.md), lang_agent.
|
|
86
|
-
|
|
87
|
-
Sau khi review pass:
|
|
88
|
-
- Cập nhật status: `Committed` → `Deploy Test`
|
|
89
|
-
- Output commit message gợi ý: `fix: {mô tả ngắn} - resolves Bug-{NNN}`
|
|
90
|
-
- Hỏi: "Bạn đã test thủ công chưa? Muốn commit và deploy lên Test không?"
|
|
91
|
-
|
|
92
|
-
---
|
|
93
|
-
|
|
94
|
-
#### Status = `Verify Test` / `Verify Stag` — Verify (PE)
|
|
95
|
-
|
|
96
|
-
1. PE verify trên môi trường tương ứng:
|
|
97
|
-
- Chạy lại Steps to Reproduce → xác nhận bug không còn
|
|
98
|
-
- Kiểm tra regression test case đã pass
|
|
99
|
-
2. **Pass** → cập nhật status tiếp theo (`Deploy Stag` hoặc `Done`)
|
|
100
|
-
3. **Fail** → ghi lý do, cập nhật status về `Committed`, SE fix lại
|
|
101
|
-
|
|
102
|
-
---
|
|
103
|
-
|
|
104
|
-
## Nguyên tắc
|
|
105
|
-
- KHÔNG patch symptom — phải fix root cause
|
|
106
|
-
- PHẢI có regression test case TRƯỚC khi fix
|
|
107
|
-
- Review phải chạy qua Agent độc lập — không inline trong session hiện tại
|
|
108
|
-
- Bug `Critical`/`High` phải fix trước khi Feature được Verified
|
|
109
|
-
- Flow: `New` → `Committed` → `Deploy Test` → `Verify Test` → `Deploy Stag` → `Verify Stag` → `Deploy Prod` → `Verify Prod` → `Done`
|
|
1
|
+
# /tas-bug $ARGUMENTS
|
|
2
|
+
|
|
3
|
+
Quản lý toàn bộ lifecycle của bug: tạo, phân tích, fix, verify.
|
|
4
|
+
Status của bug xác định bước tiếp theo — không cần khai báo role.
|
|
5
|
+
|
|
6
|
+
## Always / Ask / Never
|
|
7
|
+
|
|
8
|
+
| | Hành động |
|
|
9
|
+
|---|---|
|
|
10
|
+
| **Always** | Hiển thị status hiện tại và action tiếp theo trước khi làm gì |
|
|
11
|
+
| **Always** | Viết regression test TRƯỚC khi fix |
|
|
12
|
+
| **Always** | Launch review agent độc lập sau khi fix — không review trong cùng session |
|
|
13
|
+
| **Ask** | Khi cần đọc thêm file ngoài Bug file (Status = Committed) |
|
|
14
|
+
| **Never** | Patch symptom — phải fix root cause |
|
|
15
|
+
| **Never** | Bỏ qua bước review sau khi fix |
|
|
16
|
+
| **Never** | Tự commit hay push — đợi user test thủ công trước |
|
|
17
|
+
|
|
18
|
+
## Stack Detection
|
|
19
|
+
Đọc `.claude/rules/common/stack-detection.md`.
|
|
20
|
+
|
|
21
|
+
## Hành động
|
|
22
|
+
|
|
23
|
+
### Bước 1 — Xác định chế độ
|
|
24
|
+
|
|
25
|
+
`$ARGUMENTS` là mô tả bug mới → **Chế độ CREATE**
|
|
26
|
+
`$ARGUMENTS` là Bug ID (ví dụ: `Bug-001`) → **Chế độ UPDATE**
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
### Chế độ CREATE
|
|
31
|
+
|
|
32
|
+
Vai trò: PE hoặc SE (ai phát hiện bug)
|
|
33
|
+
|
|
34
|
+
1. Đọc `project.code` từ root/`tas.yaml`
|
|
35
|
+
2. Hỏi user:
|
|
36
|
+
- Bug thuộc Feature nào?
|
|
37
|
+
- Severity: `Critical` | `High` | `Medium` | `Low`
|
|
38
|
+
- Steps to reproduce
|
|
39
|
+
- Expected vs Actual behavior
|
|
40
|
+
- Môi trường phát hiện: Test | Staging | Production
|
|
41
|
+
3. Tạo `docs/bugs/{code}-Bug-{NNN}-{slug}.md` từ template `.tas/templates/Bug.md`
|
|
42
|
+
4. Bug status ban đầu: `New`
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
### Chế độ UPDATE
|
|
47
|
+
|
|
48
|
+
Tìm file Bug qua glob `docs/bugs/*-Bug-{ID}-*.md`, đọc status hiện tại.
|
|
49
|
+
|
|
50
|
+
**Hiển thị trước khi làm gì:**
|
|
51
|
+
> "Bug-{NNN} đang ở status: **{status}** — bước tiếp theo là {action}. Tiếp tục không?"
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
#### Status = `New` — Phân tích (SE)
|
|
56
|
+
|
|
57
|
+
1. Đọc error logs/stack trace từ Bug file
|
|
58
|
+
2. Trace code flow, xác định file và dòng gây lỗi
|
|
59
|
+
3. Ghi Root Cause Analysis vào Bug file
|
|
60
|
+
4. Viết Regression Test Cases (test reproduce bug)
|
|
61
|
+
5. Cập nhật status: `New` → `Committed`
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
#### Status = `Committed` — Fix (SE)
|
|
66
|
+
|
|
67
|
+
**Quy tắc đọc file:** CHỈ đọc Bug file. KHÔNG đọc PRD, SAD, ADR, Design-Spec, KHÔNG quét thư mục.
|
|
68
|
+
Nếu cần thêm file → hỏi user xác nhận trước.
|
|
69
|
+
|
|
70
|
+
Trước khi fix, đọc:
|
|
71
|
+
- `.claude/rules/common/security.md` — fix không tạo security risk mới
|
|
72
|
+
- `.claude/rules/common/testing.md` — pattern viết regression test
|
|
73
|
+
- `.claude/rules/[lang_agent stack]/coding-style.md` — tuân thủ conventions
|
|
74
|
+
|
|
75
|
+
**Fix workflow:**
|
|
76
|
+
a. Chạy regression test case → xác nhận **FAIL** (reproduce bug)
|
|
77
|
+
b. Fix code đúng root cause
|
|
78
|
+
c. Chạy regression test → xác nhận **PASS**
|
|
79
|
+
d. Chạy toàn bộ test suite → không có regression mới
|
|
80
|
+
→ Nếu build fail hoặc test lỗi compile: launch `build-resolver` agent với error output trước khi tiếp tục.
|
|
81
|
+
|
|
82
|
+
**Sau khi fix — Post-Fix Review (Isolated Agent):**
|
|
83
|
+
|
|
84
|
+
Thực hiện theo `.claude/rules/common/post-review-agent.md`.
|
|
85
|
+
Truyền vào: Bug file path, danh sách changed files, stack (từ CLAUDE.md), lang_agent.
|
|
86
|
+
|
|
87
|
+
Sau khi review pass:
|
|
88
|
+
- Cập nhật status: `Committed` → `Deploy Test`
|
|
89
|
+
- Output commit message gợi ý: `fix: {mô tả ngắn} - resolves Bug-{NNN}`
|
|
90
|
+
- Hỏi: "Bạn đã test thủ công chưa? Muốn commit và deploy lên Test không?"
|
|
91
|
+
|
|
92
|
+
---
|
|
93
|
+
|
|
94
|
+
#### Status = `Verify Test` / `Verify Stag` — Verify (PE)
|
|
95
|
+
|
|
96
|
+
1. PE verify trên môi trường tương ứng:
|
|
97
|
+
- Chạy lại Steps to Reproduce → xác nhận bug không còn
|
|
98
|
+
- Kiểm tra regression test case đã pass
|
|
99
|
+
2. **Pass** → cập nhật status tiếp theo (`Deploy Stag` hoặc `Done`)
|
|
100
|
+
3. **Fail** → ghi lý do, cập nhật status về `Committed`, SE fix lại
|
|
101
|
+
|
|
102
|
+
---
|
|
103
|
+
|
|
104
|
+
## Nguyên tắc
|
|
105
|
+
- KHÔNG patch symptom — phải fix root cause
|
|
106
|
+
- PHẢI có regression test case TRƯỚC khi fix
|
|
107
|
+
- Review phải chạy qua Agent độc lập — không inline trong session hiện tại
|
|
108
|
+
- Bug `Critical`/`High` phải fix trước khi Feature được Verified
|
|
109
|
+
- Flow: `New` → `Committed` → `Deploy Test` → `Verify Test` → `Deploy Stag` → `Verify Stag` → `Deploy Prod` → `Verify Prod` → `Done`
|
|
110
|
+
|
|
111
|
+
## Bước cuối — Token Log
|
|
112
|
+
|
|
113
|
+
Invoke skill `token-logger`: ghi AI Usage Log vào file Bug đang làm việc.
|
|
@@ -1,33 +1,37 @@
|
|
|
1
|
-
# /tas-design $ARGUMENTS
|
|
2
|
-
|
|
3
|
-
Vai trò: PE - Product Engineer
|
|
4
|
-
Tạo hoặc cập nhật Design Specification document (UI/UX flows, wireframe descriptions).
|
|
5
|
-
|
|
6
|
-
## Prerequisite
|
|
7
|
-
- docs/prd.md phải tồn tại
|
|
8
|
-
|
|
9
|
-
## Hành động
|
|
10
|
-
1. Cần context từ root/tas.yaml và docs/prd.md
|
|
11
|
-
2. Kiểm tra docs/design-spec.md đã tồn tại chưa:
|
|
12
|
-
|
|
13
|
-
### Chế độ CREATE (file chưa tồn tại):
|
|
14
|
-
3. Cần context từ .tas/templates/Design-Spec.md
|
|
15
|
-
4. $ARGUMENTS là mô tả scope của design. Nếu không có, dựa vào PRD.
|
|
16
|
-
5. Tạo file docs/design-spec.md chứa:
|
|
17
|
-
- User flows (Mermaid flowchart)
|
|
18
|
-
- Screen descriptions
|
|
19
|
-
- Navigation structure
|
|
20
|
-
- Interaction patterns
|
|
21
|
-
- Responsive behavior notes
|
|
22
|
-
6. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm `artifacts.design_spec`.
|
|
23
|
-
|
|
24
|
-
### Chế độ UPDATE (file đã tồn tại):
|
|
25
|
-
3. Cần context từ docs/design-spec.md hiện tại
|
|
26
|
-
4. $ARGUMENTS là mô tả thay đổi. Nếu không có, hỏi user cần cập nhật section nào.
|
|
27
|
-
5. Cập nhật file, thêm changelog
|
|
28
|
-
6. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `artifacts.design_spec`.
|
|
29
|
-
|
|
30
|
-
## Nguyên tắc
|
|
31
|
-
- Focus vào flows và behavior, không vào pixel-perfect design
|
|
32
|
-
- Mỗi screen cần mô tả: purpose, key elements, actions available
|
|
33
|
-
- Mermaid tuân thủ: :::mermaid wrapper, không dùng ()
|
|
1
|
+
# /tas-design $ARGUMENTS
|
|
2
|
+
|
|
3
|
+
Vai trò: PE - Product Engineer
|
|
4
|
+
Tạo hoặc cập nhật Design Specification document (UI/UX flows, wireframe descriptions).
|
|
5
|
+
|
|
6
|
+
## Prerequisite
|
|
7
|
+
- docs/prd.md phải tồn tại
|
|
8
|
+
|
|
9
|
+
## Hành động
|
|
10
|
+
1. Cần context từ root/tas.yaml và docs/prd.md
|
|
11
|
+
2. Kiểm tra docs/design-spec.md đã tồn tại chưa:
|
|
12
|
+
|
|
13
|
+
### Chế độ CREATE (file chưa tồn tại):
|
|
14
|
+
3. Cần context từ .tas/templates/Design-Spec.md
|
|
15
|
+
4. $ARGUMENTS là mô tả scope của design. Nếu không có, dựa vào PRD.
|
|
16
|
+
5. Tạo file docs/design-spec.md chứa:
|
|
17
|
+
- User flows (Mermaid flowchart)
|
|
18
|
+
- Screen descriptions
|
|
19
|
+
- Navigation structure
|
|
20
|
+
- Interaction patterns
|
|
21
|
+
- Responsive behavior notes
|
|
22
|
+
6. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm `artifacts.design_spec`.
|
|
23
|
+
|
|
24
|
+
### Chế độ UPDATE (file đã tồn tại):
|
|
25
|
+
3. Cần context từ docs/design-spec.md hiện tại
|
|
26
|
+
4. $ARGUMENTS là mô tả thay đổi. Nếu không có, hỏi user cần cập nhật section nào.
|
|
27
|
+
5. Cập nhật file, thêm changelog
|
|
28
|
+
6. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `artifacts.design_spec`.
|
|
29
|
+
|
|
30
|
+
## Nguyên tắc
|
|
31
|
+
- Focus vào flows và behavior, không vào pixel-perfect design
|
|
32
|
+
- Mỗi screen cần mô tả: purpose, key elements, actions available
|
|
33
|
+
- Mermaid tuân thủ: :::mermaid wrapper, không dùng ()
|
|
34
|
+
|
|
35
|
+
## Bước cuối — Token Log
|
|
36
|
+
|
|
37
|
+
Invoke skill `token-logger`: ghi AI Usage Log vào `docs/design-spec.md`.
|