@torus-engineering/tas-kit 1.6.0 → 1.8.0

package/.claude/rules/web/performance.md

@@ -55,6 +55,15 @@ const { ScrollTrigger } = await import('gsap/ScrollTrigger');
 - Use `requestAnimationFrame` or established animation libraries for JS motion
 - Avoid scroll handler churn; use IntersectionObserver or well-behaved libraries
 
+## React Performance Anti-Patterns
+
+Avoid these in React and React Native:
+
+- **Unnecessary re-renders**: component re-renders when props haven't changed — add `React.memo`, `useMemo`, `useCallback` at proven bottlenecks (measure first)
+- **Missing code splitting**: large component trees not split with `React.lazy()` — lazy-load routes and heavy components
+- **Missing list virtualization**: rendering large lists without `react-window` (web) or `FlatList`/`FlashList` (RN)
+- **Over-fetching**: requesting full entities when only a few fields are needed — scope API calls to what the component actually renders
+
 ## Performance Checklist
 
 - [ ] All images have explicit dimensions

package/.claude/skills/api-design/SKILL.md

@@ -4,7 +4,9 @@ description: |
   Auto-invoke when designing new REST API endpoints, reviewing existing API contracts,
   planning pagination or filtering strategy, implementing error response formats,
   adding API versioning, or building public/partner-facing APIs.
-  NOT for backend implementation layers (use backend-patterns instead).
+  Used in /tas-plan whenever a Story involves backend API design (any stack) — produces
+  API Spec (URL structure, HTTP methods, status codes, request/response shapes) before implementation.
+  NOT for backend implementation layers (use js-backend-patterns for Node.js instead).
 origin: ECC
 allowed-tools: Read, Grep, Glob
 ---

package/.claude/skills/{backend-patterns → js-backend-patterns}/SKILL.md

@@ -1,9 +1,10 @@
 ---
-name: backend-patterns
+name: js-backend-patterns
 description: |
   Auto-invoke when implementing repository, service, or controller layers on Node.js/Express/Next.js,
   fixing N+1 query problems, setting up Redis caching, adding auth middleware, or structuring
   background job processing. NOT for API contract design (use api-design instead).
+  Specifically for Node.js/Express/Next.js stacks — not for .NET C# or Python.
 origin: ECC
 allowed-tools: Read, Grep, Glob
 ---

package/.claude/skills/tas-implementation-complete/SKILL.md

@@ -1,97 +1,99 @@
----
-name: tas-implementation-complete
-description: |
-  Auto-invoke khi user báo hiệu đã hoàn thành implement: "done", "xong", "finished",
-  "đã xong", "đã implement xong", "implementation complete", "code xong rồi",
-  "viết xong rồi", "đã code xong". Trigger parallel post-implementation review gate.
-allowed-tools: Read, Bash, Grep, Glob, Agent
----
-
-# TAS Implementation Complete
-
-Khi user báo hiệu implementation xong, tự động trigger post-implementation review gate.
-Không chờ user chạy `/tas-review-code` thủ công.
-
-## When to Use
-
-- User vừa implement xong một Story hoặc một feature
-- User nói "xong", "done", "finished" sau khi viết code
-- KHÔNG invoke khi: user đang hỏi về trạng thái, hỏi về plan, hay chưa có code thay đổi
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Xác nhận scope với user trước khi launch agents |
-| **Always** | Launch code-reviewer + security-reviewer đồng thời |
-| **Always** | Báo cáo gate result rõ ràng: pass hoặc block với lý do |
-| **Ask** | Khi không chắc scope review là gì (file path? git diff? Story?) |
-| **Ask** | Khi có >5 files thay đổi — confirm user muốn review toàn bộ |
-| **Never** | Tự động commit sau khi review pass |
-| **Never** | Skip review và báo "looks good" mà không chạy agents |
-
-## Process
-
-### Bước 1 — Xác định scope
-Hỏi user hoặc tự suy luận từ context:
-- Có Story ID? → lấy danh sách files từ Story
-- Không có? → dùng `git diff HEAD --name-only` để lấy files vừa thay đổi
-
-### Bước 2 — Stack Detection
-Đọc `CLAUDE.md` tại root, tìm section `## Tech Stack`:
-- Backend chứa `.NET` / `C#` → `lang_agent = csharp-reviewer`
-- Backend chứa `Node.js` / `TypeScript` → `lang_agent = typescript-reviewer`
-- Backend chứa `Python` / `FastAPI` / `Django` → `lang_agent = python-reviewer`
-- Frontend chứa `React` → bổ sung `typescript-reviewer`
-
-### Bước 3 — Launch Parallel Review Gate
-
-Launch các agents ĐỒNG THỜI:
-
-**Agent 1 — `code-reviewer`** (luôn chạy):
-> Review [scope]. Đọc `.tas/checklists/code-review.md`.
-> Tập trung: acceptance criteria compliance, naming, error handling, test coverage, DRY.
-> Format: Critical / High / Medium / Low với file:line và fix cụ thể.
-
-**Agent 2 — `security-reviewer`** (luôn chạy):
-> Security audit [scope]. Đọc `.claude/rules/common/security.md`.
-> Tập trung: user input handling, SQL injection, hardcoded secrets, auth checks.
-> Format: Critical / High / Medium / Low với file:line và remediation.
-
-**Agent 3 — Language reviewer** (theo stack detection):
-> Language-specific review [scope].
-> Đọc `.claude/rules/[stack]/coding-style.md` và `.claude/rules/[stack]/patterns.md`.
-> Format: Critical / High / Medium / Low với file:line.
-
-Chờ TẤT CẢ agents hoàn thành.
-
-### Bước 4 — Gate Decision
-
-**Có Critical/High findings:**
-→ Liệt kê rõ từng finding, DỪNG, yêu cầu fix trước khi tiếp tục.
-→ Không tick Definition of Done.
-
-**Chỉ có Medium/Low:**
-→ List gợi ý, hỏi user có muốn fix không.
-→ Sau khi user confirm: nhắc chạy `/tas-review-code` để review đầy đủ (hygiene scan + test run).
-
-## Red Flags
-
-- User nói "xong" nhưng không có file nào thay đổi trong git diff → hỏi lại
-- Review gate bị skip vì "code đơn giản" → không có ngoại lệ, luôn chạy gate
-- Agent trả về "No issues found" trên codebase lớn → verify agent đã đọc đúng files
-
-## Verification
-
-- [ ] `git diff HEAD --name-only` có ít nhất 1 file thay đổi
-- [ ] Tất cả agents đã chạy và trả về kết quả (không timeout)
-- [ ] Gate decision được đưa ra rõ ràng: pass hoặc block
-- [ ] Nếu pass: user biết bước tiếp theo là `/tas-review-code`
-
-## Anti-Rationalization
-
-| Rationalization | Counter |
-|---|---|
-| "Code đơn giản, không cần review" | Review gate luôn chạy — đây là safety net, không phải quality judgment |
-| "Security reviewer sẽ slow down workflow" | Parallel execution — 3 agents chạy cùng lúc, không cộng thêm thời gian |
-| "User chưa hỏi về review" | Skill auto-invoke khi user nói "done" — đây là expected behavior |
+---
+name: tas-implementation-complete
+description: |
+  Auto-invoke khi user báo hiệu đã hoàn thành implement: "done", "xong", "finished",
+  "đã xong", "đã implement xong", "implementation complete", "code xong rồi",
+  "viết xong rồi", "đã code xong". Trigger parallel post-implementation review gate.
+allowed-tools: Read, Bash, Grep, Glob, Agent
+---
+
+# TAS Implementation Complete
+
+Khi user báo hiệu implementation xong, tự động trigger post-implementation review gate.
+Không chờ user chạy `/tas-review-code` thủ công.
+
+## When to Use
+
+- User vừa implement xong một Story hoặc một feature
+- User nói "xong", "done", "finished" sau khi viết code
+- KHÔNG invoke khi: user đang hỏi về trạng thái, hỏi về plan, hay chưa có code thay đổi
+
+## Always / Ask / Never
+
+| | Hành động |
+|---|---|
+| **Always** | Xác nhận scope với user trước khi launch agents |
+| **Always** | Launch code-reviewer + security-reviewer đồng thời |
+| **Always** | Báo cáo gate result rõ ràng: pass hoặc block với lý do |
+| **Ask** | Khi không chắc scope review là gì (file path? git diff? Story?) |
+| **Ask** | Khi có >5 files thay đổi — confirm user muốn review toàn bộ |
+| **Never** | Tự động commit sau khi review pass |
+| **Never** | Skip review và báo "looks good" mà không chạy agents |
+
+## Process
+
+### Bước 1 — Xác định scope
+Hỏi user hoặc tự suy luận từ context:
+- Có Story ID? → lấy danh sách files từ Story
+- Không có? → dùng `git diff HEAD --name-only` để lấy files vừa thay đổi
+
+### Bước 2 — Stack Detection
+Đọc `CLAUDE.md` tại root, tìm section `## Tech Stack`:
+- Backend chứa `.NET` / `C#` → `lang_agent = csharp-reviewer`
+- Backend chứa `Node.js` / `TypeScript` → `lang_agent = typescript-reviewer`
+- Backend chứa `Python` / `FastAPI` / `Django` → `lang_agent = python-reviewer`
+- Frontend chứa `React` → bổ sung `typescript-reviewer`
+
+### Bước 3 — Launch Parallel Review Gate
+
+Launch các agents ĐỒNG THỜI:
+
+**Agent 1 — `code-reviewer`** (luôn chạy):
+> Review [scope]. Đọc `.tas/checklists/code-review.md`.
+> Tập trung: acceptance criteria compliance, naming, error handling, test coverage, DRY.
+> Format: Critical / High / Medium / Low với file:line và fix cụ thể.
+
+**Agent 2 — `security-reviewer`** (luôn chạy):
+> Security audit [scope]. Đọc `.claude/rules/common/security.md`.
+> Nếu stack đã xác định, đọc thêm `.claude/rules/[stack]/security.md`.
+> Tập trung: user input handling, SQL injection, hardcoded secrets, auth checks.
+> Format: Critical / High / Medium / Low với file:line và remediation.
+
+**Agent 3 — Language reviewer** (theo stack detection):
+> Language-specific review [scope].
+> Đọc `.claude/rules/[stack]/coding-style.md`, `.claude/rules/[stack]/patterns.md`, `.claude/rules/[stack]/testing.md`.
+> Nếu stack có React: đọc thêm `.claude/rules/web/design-quality.md`, `.claude/rules/web/testing.md`, `.claude/rules/web/performance.md`.
+> Format: Critical / High / Medium / Low với file:line.
+
+Chờ TẤT CẢ agents hoàn thành.
+
+### Bước 4 — Gate Decision
+
+**Có Critical/High findings:**
+→ Liệt kê rõ từng finding, DỪNG, yêu cầu fix trước khi tiếp tục.
+→ Không tick Definition of Done.
+
+**Chỉ có Medium/Low:**
+→ List gợi ý, hỏi user có muốn fix không.
+→ Sau khi user confirm: nhắc chạy `/tas-review-code` để review đầy đủ (hygiene scan + test run).
+
+## Red Flags
+
+- User nói "xong" nhưng không có file nào thay đổi trong git diff → hỏi lại
+- Review gate bị skip vì "code đơn giản" → không có ngoại lệ, luôn chạy gate
+- Agent trả về "No issues found" trên codebase lớn → verify agent đã đọc đúng files
+
+## Verification
+
+- [ ] `git diff HEAD --name-only` có ít nhất 1 file thay đổi
+- [ ] Tất cả agents đã chạy và trả về kết quả (không timeout)
+- [ ] Gate decision được đưa ra rõ ràng: pass hoặc block
+- [ ] Nếu pass: user biết bước tiếp theo là `/tas-review-code`
+
+## Anti-Rationalization
+
+| Rationalization | Counter |
+|---|---|
+| "Code đơn giản, không cần review" | Review gate luôn chạy — đây là safety net, không phải quality judgment |
+| "Security reviewer sẽ slow down workflow" | Parallel execution — 3 agents chạy cùng lúc, không cộng thêm thời gian |
+| "User chưa hỏi về review" | Skill auto-invoke khi user nói "done" — đây là expected behavior |

package/.claude/skills/tas-tdd/SKILL.md

@@ -1,82 +1,123 @@
----
-name: tas-tdd
-description: |
-  TDD workflow. Auto-invoke khi: user implement feature mới, viết tests,
-  hoặc khi use_tdd=true trong tas.yaml. Enforce Red-Green-Refactor cycle
-  với verification gates giữa mỗi phase.
-allowed-tools: Read, Write, Edit, Bash, Grep
----
-
-# TAS TDD Workflow
-
-Khi `use_tdd=true` trong `tas.yaml`, enforce strict Red-Green-Refactor cycle.
-Không có ngoại lệ — mọi feature đều bắt đầu từ test.
-
-## When to Use
-
-- Implement feature mới theo Story với acceptance criteria rõ ràng
-- Bug fix: viết regression test trước khi fix
-- Refactor: đảm bảo test coverage trước khi thay đổi code
-- KHÔNG dùng TDD cho: config changes, documentation, migration scripts thuần data
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Viết test TRƯỚC, chạy để xác nhận FAIL, sau đó mới viết code |
-| **Always** | Commit sau mỗi Green phase thành công |
-| **Always** | Chạy full test suite sau Refactor phase |
-| **Ask** | Khi acceptance criteria mơ hồ — làm rõ trước khi viết test |
-| **Ask** | Khi test quá khó viết — có thể interface/design cần cải thiện |
-| **Never** | Viết implementation trước test (dù "chỉ để thử") |
-| **Never** | Bỏ qua Red phase vì "test rõ ràng sẽ fail" |
-| **Never** | Viết nhiều hơn code tối thiểu cần thiết để pass test ở Green phase |
-
-## Process
-
-### Red Phase — Viết Test Trước
-
-1. Đọc acceptance criteria trong Story
-2. Viết test cases cover từng criteria
-3. Chạy tests: `npm test` / `dotnet test` / `python -m pytest`
-4. **Verify**: tests PHẢI FAIL — nếu pass ngay → test sai, viết lại
-
-### Green Phase — Code Tối Thiểu
-
-1. Viết code tối thiểu để pass tests
-2. Không refactor, không optimize ở phase này
-3. Chạy tests: xác nhận PASS
-4. **Verify**: tất cả tests mới phải pass, không có regression
-
-### Refactor Phase — Clean Up
-
-1. Loại bỏ duplication, cải thiện naming, giảm complexity
-2. KHÔNG thay đổi behavior — tests là safety net
-3. Chạy full test suite sau mỗi refactor step
-4. **Verify**: coverage >= 80%, tất cả tests vẫn pass
-5. Commit sau khi refactor thành công
-
-## Red Flags
-
-- Test pass ngay lần đầu khi chưa viết implementation → test không test đúng thứ cần test
-- Test quá broad ("everything works") → không có giá trị, viết test cụ thể hơn
-- Green phase code quá nhiều logic → chỉ viết đủ để pass, không hơn
-- Refactor phase làm test fail → refactor sai, roll back từng bước
-- Viết nhiều test cùng lúc trước khi fix từng cái → chỉ fix một test tại một thời điểm
-
-## Verification
-
-- [ ] Red: test file tồn tại và chạy ra FAIL output
-- [ ] Green: test output chuyển từ FAIL → PASS sau khi thêm implementation
-- [ ] Refactor: `npm test` / `dotnet test` / `pytest` toàn bộ suite PASS
-- [ ] Coverage report: >= 80% cho files vừa thay đổi
-- [ ] Không có test nào bị skip hay comment out
-
-## Anti-Rationalization
-
-| Rationalization | Counter |
-|---|---|
-| "Test rõ ràng sẽ fail, không cần chạy" | Bỏ qua Red phase làm mất điểm kiểm chứng — luôn chạy |
-| "Viết test sau nhanh hơn" | TDD tiết kiệm debugging time nhiều hơn thời gian viết test trước |
-| "Code này quá đơn giản cần test" | Đơn giản hôm nay, phức tạp sau refactor — test bảo vệ future changes |
-| "Interface chưa clear, viết code trước cho rõ" | Test khó viết là signal interface cần cải thiện — Ask, không skip |
+---
+name: tas-tdd
+description: |
+  TDD workflow. Auto-invoke khi: user implement feature mới, viết tests,
+  hoặc khi use_tdd=true trong tas.yaml. Enforce Red-Green-Refactor cycle
+  với verification gates giữa mỗi phase.
+allowed-tools: Read, Write, Edit, Bash, Grep
+---
+
+# TAS TDD Workflow
+
+Khi `use_tdd=true` trong `tas.yaml`, enforce strict Red-Green-Refactor cycle.
+Không có ngoại lệ — mọi feature đều bắt đầu từ test.
+
+## When to Use
+
+- Implement feature mới theo Story với acceptance criteria rõ ràng
+- Bug fix: viết regression test trước khi fix
+- Refactor: đảm bảo test coverage trước khi thay đổi code
+- KHÔNG dùng TDD cho: config changes, documentation, migration scripts thuần data
+
+## Always / Ask / Never
+
+| | Hành động |
+|---|---|
+| **Always** | Viết test TRƯỚC, chạy để xác nhận FAIL, sau đó mới viết code |
+| **Always** | Commit sau mỗi Green phase thành công |
+| **Always** | Chạy full test suite sau Refactor phase |
+| **Ask** | Khi acceptance criteria mơ hồ — làm rõ trước khi viết test |
+| **Ask** | Khi test quá khó viết — có thể interface/design cần cải thiện |
+| **Never** | Viết implementation trước test (dù "chỉ để thử") |
+| **Never** | Bỏ qua Red phase vì "test rõ ràng sẽ fail" |
+| **Never** | Viết nhiều hơn code tối thiểu cần thiết để pass test ở Green phase |
+
+## Process
+
+### Red Phase — Viết Test Trước
+
+1. Đọc acceptance criteria trong Story
+2. Viết test cases cover từng criteria theo platform:
+
+   **Mobile (React Native)**:
+   - **Unit Tests (REQUIRED)**: Jest + React Testing Library
+     - Components: `render`, `fireEvent`, `screen` queries
+     - Hooks: `renderHook` từ `@testing-library/react-hooks`
+     - Services/API: Jest mocks + MSW
+     - Utils: Pure function testing
+     - Zustand stores: Test actions + selectors
+   - **E2E Tests**: Detox
+
+   **Web (React + Node)**:
+   - **Unit Tests (REQUIRED)**: Vitest/Jest + React Testing Library
+     - Components: `render`, `fireEvent`, `screen` queries
+     - Hooks: `renderHook`
+     - Services: Vitest/Jest mocks + MSW
+     - Backend services: Jest
+   - **E2E Tests**: Playwright (Chromium, Firefox, WebKit)
+
+   **Backend (.NET)**:
+   - **Unit Tests**: xUnit cho services, repositories
+   - **Integration Tests**: xUnit + TestServer
+   - **API Tests**: xUnit + WebApplicationFactory
+
+3. Chạy tests: `npm test` / `yarn test` / `dotnet test` / `python -m pytest`
+4. **Verify**: tests PHẢI FAIL — nếu pass ngay → test sai, viết lại
+
+### Green Phase — Code Tối Thiểu
+
+1. Viết code tối thiểu để pass tests
+2. Không refactor, không optimize ở phase này
+3. Chạy tests: xác nhận PASS
+4. **Verify**: tất cả tests mới phải pass, không có regression
+
+### Refactor Phase — Clean Up
+
+1. Loại bỏ duplication, cải thiện naming, giảm complexity
+2. KHÔNG thay đổi behavior — tests là safety net
+3. Chạy full test suite sau mỗi refactor step
+4. **Verify**: coverage >= 80%, tất cả tests vẫn pass
+5. Commit sau khi refactor thành công
+
+## Red Flags
+
+- Test pass ngay lần đầu khi chưa viết implementation → test không test đúng thứ cần test
+- Test quá broad ("everything works") → không có giá trị, viết test cụ thể hơn
+- Green phase code quá nhiều logic → chỉ viết đủ để pass, không hơn
+- Refactor phase làm test fail → refactor sai, roll back từng bước
+- Viết nhiều test cùng lúc trước khi fix từng cái → chỉ fix một test tại một thời điểm
+
+## Verification
+
+- [ ] Red: test file tồn tại và chạy ra FAIL output
+- [ ] Green: test output chuyển từ FAIL → PASS sau khi thêm implementation
+- [ ] Refactor: `npm test` / `dotnet test` / `pytest` toàn bộ suite PASS
+- [ ] Coverage report: >= 80% cho files vừa thay đổi
+- [ ] Không có test nào bị skip hay comment out
+
+## Test Naming Convention
+
+```
+{PROJECT}_E{EPIC}_F{FEATURE}_S{STORY}_{TYPE}_{NUMBER}_{MODIFIER}
+```
+
+| TYPE | Ý nghĩa | Layer |
+|------|---------|-------|
+| UT | Unit Test | 1 |
+| IT | Integration Test | 1 |
+| API | API Test | 1 |
+| FT | Functional Test | 2 |
+| E2E | End-to-End Test | 3 |
+
+MODIFIER: `H` (Happy), `N` (Negative), `E` (Edge), `S` (Security), `P` (Performance)
+
+---
+
+## Anti-Rationalization
+
+| Rationalization | Counter |
+|---|---|
+| "Test rõ ràng sẽ fail, không cần chạy" | Bỏ qua Red phase làm mất điểm kiểm chứng — luôn chạy |
+| "Viết test sau nhanh hơn" | TDD tiết kiệm debugging time nhiều hơn thời gian viết test trước |
+| "Code này quá đơn giản cần test" | Đơn giản hôm nay, phức tạp sau refactor — test bảo vệ future changes |
+| "Interface chưa clear, viết code trước cho rõ" | Test khó viết là signal interface cần cải thiện — Ask, không skip |

package/.claude/skills/token-logger/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: token-logger
+description: |
+  Invoke khi TAS command hoàn thành để ghi AI Usage Log vào artifact file.
+  Auto-invoke sau /tas-* commands khi có Write/Edit vào docs/.
+  KHÔNG invoke khi user tự tay edit file hoặc dùng non-TAS commands.
+allowed-tools: Read, Edit, Write
+---
+
+# Token Logger
+
+Ghi `## AI Usage Log` vào artifact file sau khi TAS command hoàn thành.
+
+## Process
+
+1. Xác định artifact file: từ lời gọi (nếu được chỉ định) hoặc file `docs/` cuối cùng được Write/Edit trong session.
+2. Đọc `.claude/rules/common/token-logging.md` để lấy format và update rules.
+3. Đọc artifact file — kiểm tra `## AI Usage Log` đã tồn tại chưa.
+4. Ghi hoặc cập nhật section. Silent on success — không output ra conversation.