​
Verify Issue — /qa-full:verify-issue

Lệnh dùng nhiều nhất hàng ngày. Tự động verify GitHub issues trên staging theo 7 bước: đọc issue, tìm TC, gap analysis (gọi ck:scenario 12 chiều), verify, comment, label, push.

​
Cú pháp

/qa-full:verify-issue #66                    # Verify 1 issue
/qa-full:verify-issue #66,#67,#68            # Verify nhiều issues
/qa-full:verify-issue --feature F05          # Verify tất cả issues của feature

​
Luồng hoạt động bên trong

1

Bước 1: Đọc Issue — Extract ACs

Chạy gh issue view {number} --json title,body để lấy nội dung. Parse tất cả Acceptance Criteria blocks (GIVEN/WHEN/THEN/AND). Liệt kê từng THEN condition riêng biệt.Output: Bảng ACs với THEN conditions.
2

Bước 2: Tìm TC-IDs từ QA doc

Grep docs/qa/F*.md để map mỗi AC → TC-IDs tương ứng.Output: Bảng TC-IDs per AC.
3

Bước 3: Gap Analysis — BẮT BUỘC gọi ck:scenario

So sánh AC THEN conditions vs TC-IDs hiện có → tìm gap.BẮT BUỘC gọi skill ck:scenario phân tích 12 chiều: User Types, Input Extremes, Timing, Scale, State Transitions, Environment, Error Cascades, Authorization, Data Integrity, Integration, Compliance, Business Logic.Quy tắc:
  • Chỉ analyze dimensions relevant (skip irrelevant + ghi “N/A”)
  • Mỗi dimension → 2-3 scenarios (không quá 5)
  • Tổng TC mới <= 10 per issue (chọn highest severity trước)
  • Mỗi scenario PHẢI có severity: Critical / High / Medium / Low
Output: List TC mới tạo + severity breakdown.
4

Bước 4: Verify từng TC trên Staging

Verify từng TC theo thứ tự ưu tiên:
Ưu tiênPhương phápKhi nào dùng
1Unit testTìm trong src/__tests__/
2API callcurl staging/api/...
3Source codeGrep confirm logic exists
4Playwright E2EChạy E2E test nếu có
5Browser testDùng ck:chrome-devtools
6Cần QCCHỈ khi thật sự cần người
Output mẫu per-TC:
TC-IDTypeResultEvidence
TC-F05.06UI/DBPassUnit test PASS page-manager.test.tsx:56
TC-F05.07FuncBugAPI POST /api/sites/2/pages → HTTP 500
TC-F05.10dUXPassSource: PageManagerPanel.tsx:350
TC-F05.06cUXCần QCCần QC: loading skeleton CSS animation
5

Bước 5: Comment trên Issue

Tự động post comment lên GitHub issue với format chuẩn team: per-AC per-TC table + bug report (Steps, Expected, Actual, Evidence).
6

Bước 6: Update Label

Điều kiệnHành động
All TC pass (hoặc chỉ còn Cần QC visual)qa:passed + close issue
Any TC bug (500, wrong behavior)qa:failed + keep open
Missing implementationqa:failed + note
7

Bước 7: Push TC Supplements

Commit TC mới vào docs/qa/ và push.

​
Quy tắc bắt buộc

  1. KHÔNG đánh qa:passed nếu chưa verify từng TC-ID
  2. KHÔNG đánh “Cần QC” nếu có thể verify qua API/source code
  3. Bug report theo chuẩn team (Steps, Expected, Actual, Evidence)
  4. Nếu bug duplicate với comment trước → update comment cũ
  5. BẮT BUỘC gọi ck:scenario ở Bước 3

​
Ví dụ thực tế

/qa-full:verify-issue #66

​
So sánh với chat trực tiếp

Tiêu chí/qa-full:verify-issueChat trực tiếp
AC parsingTự động parse GIVEN/WHEN/THENĐọc thủ công
TC mappingTự động map AC → TC-IDsPhải tìm tay
Gap analysisck:scenario 12 chiều, severityTự nghĩ edge cases
Verify method6 phương pháp ưu tiênThường chỉ test browser
Comment formatChuẩn team: per-AC per-TC tableText tự do
Label updateTự động qa:passed/qa:failedPhải làm tay
TC supplementTự động commit + pushKhông tạo TC mới

​
Khi nào dùng / không dùng

DùngKhông dùng
Verify issue dev assign cho QAKhi chưa có GitHub issue
Hàng ngày verify issues mớiKhi cần QA toàn bộ project (dùng /qa-full:full)
Verify batch cuối sprintKhi cần viết tests mới (dùng /qa-full:check)

​
Batch Mode

Khi verify nhiều issues cùng lúc:
  1. List issues: gh issue list --label "qa:pending" --label "feature:F05"
  2. Gom TC supplements cho cùng feature → 1 commit
  3. Verify song song cho independent issues
  4. Comment + label từng issue riêng