@torus-engineering/tas-kit 1.5.1 → 1.7.0

package/.claude/skills/browser-qa/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: browser-qa
+description: |
+  Auto-invoke when verifying UI behavior after a frontend feature deploy or PR,
+  running accessibility audits, or doing pre-ship validation of forms, navigation,
+  and critical user journeys. Requires browser automation MCP (claude-in-chrome or Playwright).
+  SKIP if no browser MCP is available — note the dependency gap to user instead.
+origin: ECC
+allowed-tools: Read, Bash
+---
+
+# Browser QA — Automated Visual Testing & Interaction
+
+## When to Use
+
+- After deploying a feature to staging/preview
+- When you need to verify UI behavior across pages
+- Before shipping — confirm layouts, forms, interactions actually work
+- When reviewing PRs that touch frontend code
+- Accessibility audits and responsive testing
+
+## How It Works
+
+Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
+
+### Phase 1: Smoke Test
+```
+1. Navigate to target URL
+2. Check for console errors (filter noise: analytics, third-party)
+3. Verify no 4xx/5xx in network requests
+4. Screenshot above-the-fold on desktop + mobile viewport
+5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
+```
+
+### Phase 2: Interaction Test
+```
+1. Click every nav link — verify no dead links
+2. Submit forms with valid data — verify success state
+3. Submit forms with invalid data — verify error state
+4. Test auth flow: login → protected page → logout
+5. Test critical user journeys (checkout, onboarding, search)
+```
+
+### Phase 3: Visual Regression
+```
+1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
+2. Compare against baseline screenshots (if stored)
+3. Flag layout shifts > 5px, missing elements, overflow
+4. Check dark mode if applicable
+```
+
+### Phase 4: Accessibility
+```
+1. Run axe-core or equivalent on each page
+2. Flag WCAG AA violations (contrast, labels, focus order)
+3. Verify keyboard navigation works end-to-end
+4. Check screen reader landmarks
+```
+
+## Output Format
+
+```markdown
+## QA Report — [URL] — [timestamp]
+
+### Smoke Test
+- Console errors: 0 critical, 2 warnings (analytics noise)
+- Network: all 200/304, no failures
+- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓
+
+### Interactions
+- [✓] Nav links: 12/12 working
+- [✗] Contact form: missing error state for invalid email
+- [✓] Auth flow: login/logout working
+
+### Visual
+- [✗] Hero section overflows on 375px viewport
+- [✓] Dark mode: all pages consistent
+
+### Accessibility
+- 2 AA violations: missing alt text on hero image, low contrast on footer links
+
+### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
+```
+
+## Integration
+
+Works with any browser MCP:
+- `mChild__claude-in-chrome__*` tools (preferred — uses your actual Chrome)
+- Playwright via `mcp__browserbase__*`
+- Direct Puppeteer scripts
+
+Pair with `/canary-watch` for post-deploy monitoring.

package/.claude/skills/canary-watch/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: canary-watch
+description: |
+  Auto-invoke after deploying to production or staging, after merging a risky PR,
+  after dependency upgrades, or when monitoring a URL for regressions during a launch window.
+  Requires HTTP access to the target URL or browser MCP.
+  SKIP if target URL is not accessible — note the gap to user.
+origin: ECC
+allowed-tools: Read, Bash
+---
+
+# Canary Watch — Post-Deploy Monitoring
+
+## When to Use
+
+- After deploying to production or staging
+- After merging a risky PR
+- When you want to verify a fix actually fixed it
+- Continuous monitoring during a launch window
+- After dependency upgrades
+
+## How It Works
+
+Monitors a deployed URL for regressions. Runs in a loop until stopped or until the watch window expires.
+
+### What It Watches
+
+```
+1. HTTP Status — is the page returning 200?
+2. Console Errors — new errors that weren't there before?
+3. Network Failures — failed API calls, 5xx responses?
+4. Performance — LCP/CLS/INP regression vs baseline?
+5. Content — did key elements disappear? (h1, nav, footer, CTA)
+6. API Health — are critical endpoints responding within SLA?
+```
+
+### Watch Modes
+
+**Quick check** (default): single pass, report results
+```
+/canary-watch https://myapp.com
+```
+
+**Sustained watch**: check every N minutes for M hours
+```
+/canary-watch https://myapp.com --interval 5m --duration 2h
+```
+
+**Diff mode**: compare staging vs production
+```
+/canary-watch --compare https://staging.myapp.com https://myapp.com
+```
+
+### Alert Thresholds
+
+```yaml
+critical:  # immediate alert
+  - HTTP status != 200
+  - Console error count > 5 (new errors only)
+  - LCP > 4s
+  - API endpoint returns 5xx
+
+warning:   # flag in report
+  - LCP increased > 500ms from baseline
+  - CLS > 0.1
+  - New console warnings
+  - Response time > 2x baseline
+
+info:      # log only
+  - Minor performance variance
+  - New network requests (third-party scripts added?)
+```
+
+### Notifications
+
+When a critical threshold is crossed:
+- Desktop notification (macOS/Linux)
+- Optional: Slack/Discord webhook
+- Log to `~/logs/canary-watch.log`
+
+## Output
+
+```markdown
+## Canary Report — myapp.com — 2026-03-23 03:15 PST
+
+### Status: HEALTHY ✓
+
+| Check | Result | Baseline | Delta |
+|-------|--------|----------|-------|
+| HTTP | 200 ✓ | 200 | — |
+| Console errors | 0 ✓ | 0 | — |
+| LCP | 1.8s ✓ | 1.6s | +200ms |
+| CLS | 0.01 ✓ | 0.01 | — |
+| API /health | 145ms ✓ | 120ms | +25ms |
+
+### No regressions detected. Deploy is clean.
+```
+
+## Integration
+
+Pair with:
+- `/browser-qa` for pre-deploy verification
+- Hooks: add as a PostToolUse hook on `git push` to auto-check after deploys
+- CI: run in GitHub Actions after deploy step

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

@@ -9,9 +9,57 @@ allowed-tools: Read, Grep, Glob
 
 # TAS Conventions
 
-Khi generate hoặc review code, PHẢI tuân thủ conventions được định nghĩa trong CLAUDE.md của project.
+Khi generate hoặc review code, PHẢI tuân thủ conventions được định nghĩa trong `CLAUDE.md` của project.
+
+## When to Use
+
+- Trước khi generate code mới (check conventions)
+- Khi review code của user (verify compliance)
+- Khi user hỏi "đặt tên thế nào?", "format như thế nào?"
+- KHÔNG invoke khi: đọc file thuần, không liên quan đến code output
+
+## Always / Ask / Never
+
+| | Hành động |
+|---|---|
+| **Always** | Đọc `CLAUDE.md` trước khi áp dụng convention |
+| **Always** | Chỉ ra file:line cụ thể khi phát hiện vi phạm |
+| **Ask** | Khi convention trong CLAUDE.md mơ hồ hoặc có conflict |
+| **Never** | Hardcode convention (naming, format) mà không đọc CLAUDE.md trước |
+| **Never** | Áp dụng convention từ project khác vào project hiện tại |
 
 ## Checklist
-- Đọc CLAUDE.md để lấy naming conventions, branching, commit format
+
+- Đọc `CLAUDE.md` để lấy naming conventions, branching, commit format, stack rules
 - Enforce các conventions đó trong code output
-- Nếu code vi phạm conventions, chỉ ra cụ thể
+- Nếu code vi phạm conventions, chỉ ra cụ thể: file:line + convention bị vi phạm + cách sửa
+
+## Common Conventions (Default — override bằng CLAUDE.md)
+
+Các conventions mặc định này chỉ áp dụng khi `CLAUDE.md` không định nghĩa khác:
+
+- Variables/functions: `camelCase`
+- Types/Interfaces/Components: `PascalCase`
+- Constants: `UPPER_SNAKE_CASE`
+- Boolean vars: prefix `is`, `has`, `should`, `can`
+- File naming: kebab-case cho files, PascalCase cho components
+- Commit format: `<type>: <description>` (feat, fix, refactor, docs, test, chore)
+
+## Red Flags
+
+- Magic numbers trong code (e.g. `if (count > 50)`) → phải dùng named constant
+- Deep nesting >4 levels → dùng early return hoặc extract method
+- Function >50 lines → extract thành functions nhỏ hơn
+- File >800 lines → extract thành modules
+- Variable tên 1-2 ký tự (`x`, `t`, `d`) trong production code → đặt tên mô tả
+- `any` type trong TypeScript → dùng type cụ thể hoặc generic
+- Commented-out code block lớn → xóa nếu không cần, dùng git history thay thế
+
+## Verification
+
+- [ ] CLAUDE.md đã được đọc trước khi review/generate code
+- [ ] Naming tuân thủ conventions trong CLAUDE.md
+- [ ] Không có magic numbers
+- [ ] Không có deep nesting (>4 levels)
+- [ ] Functions < 50 lines, files < 800 lines
+- [ ] Commit message theo format đã định nghĩa

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

@@ -0,0 +1,97 @@
+---
+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 |

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

@@ -1,26 +1,82 @@
----
+---
 name: tas-tdd
 description: |
-  TDD workflow. Auto-invoke khi implement feature, 
-  write tests, hoặc khi use_tdd=true trong tas.yaml.
+  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 Red-Green-Refactor cycle:
+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 Phase
-1. Viết test case TRƯỚC dựa trên acceptance criteria trong Story
-2. Chạy test, xác nhận FAIL
-3. KHÔNG viết implementation code ở phase này
+- [ ] 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
 
-## Green Phase
-1. Viết code TỐI THIỂU để pass tests
-2. Chạy test, xác nhận PASS
-3. KHÔNG refactor ở phase này
+## Anti-Rationalization
 
-## Refactor Phase
-1. Clean up code, loại bỏ duplication
-2. Chạy test, xác nhận vẫn PASS
-3. Commit sau mỗi refactor thành công
+| 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/.tas/README.md

@@ -38,11 +38,14 @@ your-project/
 │   │   ├── tas-story.md               # /tas-story - Tạo hoặc cập nhật Story
 │   │   ├── tas-sad.md                 # /tas-sad - Tạo hoặc cập nhật SAD
 │   │   ├── tas-adr.md                 # /tas-adr - Tạo hoặc cập nhật ADR
-│   │   ├── tas-dev-story.md           # /tas-dev-story - Implement story
-│   │   ├── tas-review-code.md         # /tas-review-code
+│   │   ├── tas-spec.md                # /tas-spec - Lightweight spec (solo/prototype)
+│   │   ├── tas-plan.md                # /tas-plan - Technical implementation plan
+│   │   ├── tas-dev.md                 # /tas-dev - Implement story
+│   │   ├── tas-fix.md                 # /tas-fix - Quick fix without full story flow
+│   │   ├── tas-review.md              # /tas-review - Code review with checklist
 │   │   ├── tas-brainstorm.md          # /tas-brainstorm
 │   │   ├── tas-bug.md                 # /tas-bug - Bug lifecycle
-│   │   ├── tas-security-check.md      # /tas-security-check
+│   │   ├── tas-security.md            # /tas-security - Security review
 │   │   ├── tas-verify.md              # /tas-verify - PE verify Feature trên Staging
 │   │   ├── ado-create.md              # /ado-create - Tạo work item trên ADO
 │   │   ├── ado-get.md                 # /ado-get - Pull work item từ ADO
@@ -250,13 +253,15 @@ models:
     tas-epic: sonnet
     tas-feature: sonnet
     tas-story: sonnet
-    tas-dev-story: sonnet      # Code generation, Sonnet đủ tốt
-    tas-review-code: opus      # Review cần phân tích sâu
+    tas-dev: sonnet      # Code generation, Sonnet đủ tốt
+    tas-spec: sonnet
+    tas-fix: sonnet
+    tas-review: opus      # Review cần phân tích sâu
     tas-brainstorm: opus       # Suy luận đa chiều
     tas-bug: sonnet             # Fix code, Sonnet đủ tốt
     tas-verify: haiku          # Chủ yếu đọc checklist, hỏi pass/fail
     tas-status: haiku          # Chỉ đọc và format
-    tas-security-check: opus   # Security cần kỹ
+    tas-security: opus   # Security cần kỹ
 ```
 
 ---
@@ -340,7 +345,7 @@ epics:
 ## 3. Chi tiết từng Command
 
 > **Quy tắc Context-Aware (áp dụng cho TẤT CẢ commands):**
-> Mỗi command phase code (/tas-dev-story, /tas-bug fix) PHẢI chạy trong session mới. Story.md đã chứa đủ context (Acceptance Criteria, Technical Notes, Unit Test Cases, references SAD/ADR) — KHÔNG cần đọc PRD, SAD, ADR, Feature trong session implement. Chỉ đọc thêm khi user yêu cầu cụ thể. Nguyên tắc này tránh phình Window Context do tích lũy artifact từ session cũ.
+> Mỗi command phase code (/tas-dev, /tas-bug fix) PHẢI chạy trong session mới. Story.md đã chứa đủ context (Acceptance Criteria, Technical Notes, Unit Test Cases, references SAD/ADR) — KHÔNG cần đọc PRD, SAD, ADR, Feature trong session implement. Chỉ đọc thêm khi user yêu cầu cụ thể. Nguyên tắc này tránh phình Window Context do tích lũy artifact từ session cũ.
 
 > **Quy tắc Project Status (áp dụng cho TẤT CẢ commands có thay đổi artifact hoặc status):**
 > Sau khi hoàn thành tạo/cập nhật artifact hoặc thay đổi status, PHẢI cập nhật file `root/project-status.yaml` ngay lập tức. Cụ thể:
@@ -355,10 +360,10 @@ epics:
 > | /tas-epic | epics.Epic-{NNN}: title + status + path, tạo features rỗng |
 > | /tas-feature | epics.Epic-{NNN}.features.Feature-{NNN}: title + status + path, tạo stories rỗng |
 > | /tas-story | epics...stories.Story-{NNN}: title + status + assigned |
-> | /tas-dev-story | Story status: Committed → In Progress → (done) cập nhật theo progress |
+> | /tas-dev | Story status: Committed → In Progress → (done) cập nhật theo progress |
 > | /tas-verify | Feature status: Ready To Verify → Verified (hoặc giữ nguyên nếu fail). Story status cập nhật tương ứng. |
 > | /tas-bug | Tạo mới: thêm bug entry trong Feature. Update: cập nhật bug status theo lifecycle. |
-> | /tas-security-check | artifacts.security_report: status + path + last_scan date |
+> | /tas-security | artifacts.security_report: status + path + last_scan date |
 >
 > Luôn cập nhật `last_updated` timestamp. Quy tắc này đảm bảo /tas-status chỉ cần đọc 1 file duy nhất thay vì quét toàn bộ thư mục.
 
@@ -661,10 +666,10 @@ Tạo mới hoặc cập nhật User Story document.
 - Story status: New → Committed → In Progress → Deploy Test → Verify Test → Deploy Stag → Verify Stag → Deploy Prod → Verify Prod → Done
 ```
 
-### 3.9 /tas-dev-story - Implement Story
+### 3.9 /tas-dev - Implement Story
 
 ```markdown
-# /tas-dev-story $ARGUMENTS
+# /tas-dev $ARGUMENTS
 
 Vai trò: SE - Software Engineer
 Implement một User Story.
@@ -703,10 +708,10 @@ c. Chạy tests, fix nếu fail
 - Mỗi public method PHẢI có XML doc comment
 ```
 
-### 3.10 /tas-review-code - Review Code
+### 3.10 /tas-review - Review Code
 
 ```markdown
-# /tas-review-code $ARGUMENTS
+# /tas-review $ARGUMENTS
 
 Vai trò: SE - Software Engineer
 Review code thay đổi gần nhất hoặc một file/PR cụ thể.
@@ -820,10 +825,10 @@ Tìm file Bug trong cây docs/epics/ (dùng glob), detect status hiện tại:
 - Bug Critical/High phải fix trước khi Feature được Verified
 ```
 
-### 3.13 /tas-security-check - Security Check
+### 3.13 /tas-security - Security Check
 
 ```markdown
-# /tas-security-check $ARGUMENTS
+# /tas-security $ARGUMENTS
 
 Vai trò: DSE - DevSecOps Engineer
 Kiểm tra bảo mật codebase, lưu báo cáo vào docs/security-report.md.
@@ -1388,9 +1393,9 @@ This project uses Torus-Agentic-SDLC (TAS) kit.
 ## Commands
 Type /tas-status to see current project state.
 Type /tas-[artifact] to create or update artifacts (prd, sad, adr, epic, feature, story, design).
-Type /tas-dev-story to implement a story.
+Type /tas-dev to implement a story.
 Type /tas-verify to verify a Feature on Staging (Phase 2).
-Type /tas-review-code, /tas-brainstorm, /tas-bug, /tas-security-check for dev workflows.
+Type /tas-review, /tas-brainstorm, /tas-bug, /tas-security for dev workflows.
 ```
 
 ---
@@ -1412,8 +1417,8 @@ Phase 0: Discovery & Design (Human-led, AI-powered)
     ↓ Gate: PE confirm "Ready for Development"
 
 Phase 1: Develop (Orchestrated Agentic) → Test
-├── /tas-dev-story (implement each story, TDD)
-├── /tas-review-code (auto hoặc manual)
+├── /tas-dev (implement each story, TDD)
+├── /tas-review (auto hoặc manual)
 └── /tas-bug (nếu phát sinh)
     ↓ Per Feature completed:
 
@@ -1421,7 +1426,7 @@ Phase 2: Verify (Agentic + PE Review) → Staging
 ├── /tas-verify (PE verify per Feature)
 ├── Integration test chạy trên Staging
 ├── PE verify acceptance criteria per Feature
-└── /tas-security-check
+└── /tas-security
     ↓ Gate: PE approved
 
 Phase 3: Deploy with Feature Flag → Production
@@ -1459,9 +1464,9 @@ Phase 0: Discovery & Design
     ↓ Gate: PE confirm "Ready for Development"
 
 Phase 1: Develop → Test
-├── /tas-dev-story
+├── /tas-dev
 ├── /tas-bug (bug fixes không cần full Phase 0)
-└── /tas-review-code
+└── /tas-review
     ↓ Per Feature:
 
 Phase 2 → 3 → 4: Giống Greenfield Flow
@@ -1548,12 +1553,12 @@ parent_ado_id: 456
 - Tất cả templates + tas.yaml config
 
 ### Triển khai Phase 2 - Phase 1 commands (Tuần 3-4)
-- tas-dev-story, tas-review-code, tas-bug
+- tas-dev, tas-review, tas-bug
 - Checklists: code-review, story-done
 - Skills: tas-conventions, tas-tdd
 
 ### Triển khai Phase 3 - Phase 2+3 commands (Tuần 5)
-- tas-security-check
+- tas-security
 - Checklist: security
 - ADO integration: auto update work items
 

package/.tas/tas-example.yaml

@@ -11,6 +11,7 @@ project:
 
 # Azure DevOps integration
 ado:
+  enabled: true                 # false nếu project không dùng ADO
   organization: "https://dev.azure.com/torus-bellesoft"
   project_id: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
 
@@ -99,7 +100,7 @@ models:
     tas-epic: sonnet
     tas-feature: sonnet
     tas-story: sonnet
-    tas-dev-story: sonnet
+    tas-dev: sonnet
     tas-review-code: opus
     tas-brainstorm: opus
     tas-bug: sonnet