​
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ập nhật bộ mới: Khi phát hiện bug khó, dùng /investigate để tìm root cause. Khi muốn tự động verify + fix + PR, dùng /vibe --ship #issue.

​
Cú pháp

​
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:Output mẫu per-TC:
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

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ế

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

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

​
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
Prefix: /vibe --ship #issueChạy toàn bộ pipeline: verify issue → phát hiện bug → fix → test → tạo PR → merge tự động.
Khi dùng: Muốn verify + tự động fix bug một lúc (tiết kiệm hơn verify → nói bug → /cook fix → PR)
Prefix: /investigate <bug-description>Dùng iron law: không fix gì cả khi chưa tìm được root cause. Phân tích stack trace, logs, code, data flow.
Khi dùng: TC verify phát hiện bug phức tạp, cần đào sâu nguyên nhân trước khi fix