@relipa/ai-flow-kit 0.2.0-beta.0 → 0.2.0-beta.1

package/bin/aiflow.js

@@ -22,6 +22,7 @@ const { record }      = require('../scripts/telemetry/record');
 const { updateTaskGateState } = require('../scripts/task');
 const scaffoldPlaywrightCommand = require('../scripts/scaffold-playwright');
 const docsBranchCommand = require('../scripts/docs-branch');
+const ticketWriterCommand = require('../scripts/ticket-writer');
 const semver = require('semver');
 const { execSync: execSyncChild, spawnSync } = require('child_process');
 
@@ -238,6 +239,61 @@ Exit codes:
         }
     });
 
+// ── backlog-projects ─────────────────────────────────────────
+program
+    .command('backlog-projects')
+    .description('List Backlog projects in the configured space, and which one is the default for manually-created tasks')
+    .option('--json', 'output as JSON (for headless callers, e.g. the VS Code extension)')
+    .action((options) => {
+        useCommand.listBacklogProjectsCommand(options);
+    });
+
+// ── backlog-set-default-project ──────────────────────────────
+program
+    .command('backlog-set-default-project <id> <key>')
+    .description('Set the default Backlog project for tasks created manually (ak use --manual)')
+    .action((id, key) => {
+        useCommand.setDefaultBacklogProjectCommand(id, key);
+    });
+
+// ── jira-projects ─────────────────────────────────────────────
+program
+    .command('jira-projects')
+    .description('List Jira projects visible to the configured account, and the default for task-creation')
+    .option('--json', 'output as JSON (for headless callers, e.g. the VS Code extension)')
+    .action((options) => {
+        useCommand.listJiraProjectsCommand(options);
+    });
+
+// ── jira-set-default-project ─────────────────────────────────
+program
+    .command('jira-set-default-project <key>')
+    .description('Set the default Jira project for tasks created from Meeting Minutes/QnA (ingest-data Gate 3)')
+    .action((key) => {
+        useCommand.setDefaultJiraProjectCommand(key);
+    });
+
+// ── tasks (Vấn đề 5 — sinh task từ feedback/meeting minutes) ──
+const tasksCmd = program.command('tasks').description('Turn an AI-proposed, PM-approved task list into real tickets (ingest-data Gate 3)');
+
+tasksCmd
+    .command('create-tickets <file>')
+    .description('Create Backlog/Jira tickets from a JSON task list — see scripts/ticket-writer.js for the input shape')
+    .option('--json', 'machine-readable output only')
+    .action((file, options) => {
+        ticketWriterCommand.createTicketsCommand(file, options);
+    });
+
+// ── credentials ───────────────────────────────────────────────
+const credentialsCmd = program.command('credentials').description('Manage supplementary credentials (WRITE keys, default projects) not covered by `ak init --adapter`');
+
+credentialsCmd
+    .command('set <key> <value>')
+    .description(`Save a credential value (allowed keys: ${ticketWriterCommand.SETTABLE_CREDENTIAL_KEYS.join(', ')})`)
+    .action((key, value) => {
+        ticketWriterCommand.setCredentialCommand(key, value);
+    });
+
 // ── prompt ────────────────────────────────────────────────────
 program
     .command('prompt [type]')

package/custom/rules/output-language.md

@@ -0,0 +1,36 @@
+# Ngôn ngữ Output — Auto-detect theo Input
+
+> File này là quy tắc dùng chung cho **tất cả** các skill trong `custom/skills/` (BA, Dev, QA, ML) có sinh file markdown output (requirement, plan, test-analysis, checklist, testcase, report, review, UC Spec, v.v.).
+> Mọi skill sinh markdown output PHẢI đọc file này trước khi viết, thay cho việc mặc định cố định tiếng Anh hoặc tiếng Việt.
+
+## Quy tắc
+
+Ngôn ngữ của output PHẢI khớp với ngôn ngữ của input — không dùng một ngôn ngữ mặc định cố định cho mọi task.
+
+**Xác định ngôn ngữ input theo thứ tự ưu tiên** (dùng nguồn đầu tiên có sẵn):
+
+1. Tester/dev chỉ định rõ ngôn ngữ output (ví dụ: "viết bằng tiếng Anh giúp tôi") → dùng đúng ngôn ngữ đó, bỏ qua các bước dưới.
+2. Title + description của ticket đang xử lý — từ `.aiflow/context/current.json` (fetch qua Backlog/Jira, hoặc nhập qua `ak use --manual`).
+3. Nếu skill đang mở rộng/tiếp nối một tài liệu đã có sẵn (UC Spec, System Requirement, plan, testcase set của gate trước) và không có ticket text mới — dùng ngôn ngữ của tài liệu đó.
+
+**Kết luận:**
+- Input chủ yếu là **tiếng Việt** (có dấu, từ vựng tiếng Việt) → viết **toàn bộ** output bằng tiếng Việt: heading, mô tả, tóm tắt, câu hỏi clarify, nội dung bảng, v.v.
+- Ngược lại (tiếng Anh hoặc ngôn ngữ khác) → **mặc định tiếng Anh**.
+
+Nếu một task có nhiều gate (Gate 1 → Gate N) hoặc nhiều phase, ngôn ngữ được xác định **một lần** ở bước đầu tiên (đọc ticket/input) và giữ nguyên xuyên suốt các gate/phase sau, trừ khi tester/dev đổi ý.
+
+## Không đổi ngôn ngữ (giữ nguyên bất kể input)
+
+- Code, command, file path, tên biến/hàm/class/API.
+- Table column headers / field keys mang tính cấu trúc, dùng để tham chiếu chéo giữa các gate (ví dụ `TC_ID`, `Priority`, `Status`, `Gate N`) — theo quy ước hiện có ở `custom/skills/test-skills/rules/qa-writing-standards.md`.
+- Từ khóa điều khiển flow: `APPROVED`, `RETEST`, tên skill, tên file/thư mục chuẩn (`test-analysis.md`, `checklist.md`, ...).
+- Ticket ID, YAML frontmatter keys.
+
+## Cách trích dẫn quy tắc này trong một SKILL.md
+
+Thêm 1 dòng ngắn ngay gần bước xác định output đầu tiên của skill:
+
+```
+Output language: auto-detect từ ticket/task input — xem `custom/rules/output-language.md`
+(input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+```

package/custom/skills/automation-testing/SKILL.md

@@ -235,5 +235,5 @@ Xem report:
 
 - **Gate trước khi sinh code** (Phase 2) là bắt buộc — tránh sinh sai hàng loạt.
 - **Selector phải đến từ DOM thật** (Phase 3) — đây là lý do tồn tại của skill này.
-- Viết test case, tên test, comment bằng **tiếng Việt** cho khớp draft của tester.
+- Tên test, comment viết theo ngôn ngữ của draft test case của tester (xem `custom/rules/output-language.md`) — draft tiếng Việt → tiếng Việt, draft tiếng Anh → tiếng Anh.
 - Nếu app yêu cầu đăng nhập trước, hỏi tester credentials test (đừng hardcode tài khoản thật).

package/custom/skills/ba-skills/skill-ba-build-business-rules-v1.md

@@ -3,6 +3,8 @@
 ## 1. Mục đích (Purpose)
 Kỹ năng này giúp BA bóc tách, chuẩn hóa và đặc tả các quy tắc nghiệp vụ (Business Rules - BR) của hệ thống một cách chặt chẽ nhất. Các quy tắc nghiệp vụ được định nghĩa chi tiết tại đây sẽ là căn cứ trực tiếp để lập trình viên viết code logic (backend/frontend) và kiểm thử viên viết các kịch bản kiểm thử (Test Cases), đảm bảo bao phủ toàn bộ các trường hợp biên và ngoại lệ.
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+
 ## 2. Kiến thức cần có (Prerequisite Knowledge)
 - **Các loại Business Rules phổ biến:**
   - *Validation Rules (Quy tắc kiểm tra dữ liệu):* Bao gồm kiểm tra rỗng (Required), kiểm tra định dạng (Format - Regex, Email, số điện thoại), kiểm tra độ dài/giới hạn (Length/Range), và kiểm tra ràng buộc chéo giữa các trường (Dependency validation - ví dụ: Ngày kết thúc phải sau Ngày bắt đầu).

package/custom/skills/ba-skills/skill-ba-initial-analysis-v1.md

@@ -3,6 +3,8 @@
 ## 1. Mục đích (Purpose)
 Kỹ năng này giúp Business Analyst (hoặc Agent) quét, đọc hiểu và cấu trúc hóa các yêu cầu thô được cung cấp bởi khách hàng hoặc các stakeholders. Mục tiêu là phân tách rõ ràng giữa các thông tin thực tế (Facts) và các giả định (Assumptions), phát hiện các khoảng trống nghiệp vụ (Gaps), và tạo cơ sở cho việc lập danh sách câu hỏi làm rõ (Q&A) cũng như dự thảo spec ban đầu.
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+
 ## 2. Kiến thức cần có (Prerequisite Knowledge)
 - **Tư duy phân tích (Analytical Thinking):** Khả năng chia nhỏ một yêu cầu lớn thành các luồng nghiệp vụ nhỏ và các thành phần cấu thành.
 - **Phân biệt Fact vs. Assumption:**

package/custom/skills/ba-skills/skill-ba-mermaid-flowchart-v1.md

@@ -3,6 +3,8 @@
 ## 1. Mục đích (Purpose)
 Kỹ năng này giúp BA chuyển đổi các đặc tả luồng nghiệp vụ văn bản (Main flow, Alternative flows, Exception flows) thành một sơ đồ hoạt động trực quan (Activity Diagram) sử dụng mã nguồn Mermaid. Sơ đồ này giúp lập trình viên nắm bắt luồng đi tổng thể của hệ thống một cách tức thì và giúp kiểm thử viên xác minh các nhánh rẽ của kịch bản.
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+
 ## 2. Kiến thức cần có (Prerequisite Knowledge)
 - **Cấu trúc biểu đồ Flowchart trong Mermaid:**
   - Khai báo hướng biểu đồ: Dùng `graph TD` (Top-Down - từ trên xuống) hoặc `graph LR` (Left-to-Right - từ trái sang phải). Đối với quy trình nghiệp vụ phần mềm, khuyến nghị dùng `graph TD`.

package/custom/skills/ba-skills/skill-ba-qna-v1.md

@@ -3,6 +3,8 @@
 ## 1. Mục đích (Purpose)
 Kỹ năng này giúp BA thiết kế các câu hỏi rõ ràng, khách quan và chuyên nghiệp để gửi tới khách hàng/stakeholders nhằm làm rõ các khoảng trống nghiệp vụ (Gaps). Đồng thời, hướng dẫn cách tiếp nhận câu trả lời để cập nhật tài liệu phân tích một cách nhất quán, tránh hiểu sai hoặc tự ý giả định thông tin.
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+
 ## 2. Kiến thức cần có (Prerequisite Knowledge)
 - **Kỹ năng giao tiếp bằng văn bản (Written Communication):** Sử dụng câu từ ngắn gọn, lịch sự, đi thẳng vào vấn đề.
 - **Kỹ thuật đặt câu hỏi mở và đóng:**

package/custom/skills/ba-skills/skill-ba-ui-prototype-v1.md

@@ -3,6 +3,8 @@
 ## 1. Mục đích (Purpose)
 Kỹ năng này hướng dẫn BA thiết kế và hiện thực hóa giao diện người dùng (UI mockup/prototype) dưới dạng mã nguồn HTML/CSS tự chứa (self-contained). Prototype giúp khách hàng hình dung trực quan luồng đi của màn hình, đồng thời giúp lập trình viên và kiểm thử viên xác định chính xác cấu trúc trang, ID của các phần tử và vị trí hiển thị lỗi.
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+
 ## 2. Kiến thức cần có (Prerequisite Knowledge)
 - **HTML5 Semantic Tags:** Sử dụng các thẻ ngữ nghĩa như `<header>`, `<main>`, `<section>`, `<nav>`, `<form>`, `<input>`, `<button>`, `<label>` để trang web có cấu trúc chuẩn SEO và dễ kiểm thử.
 - **Vanilla CSS Layouts:** Thành thạo Flexbox và CSS Grid để dựng bố cục nhanh chóng, đáp ứng tốt trên các kích thước màn hình khác nhau (Responsive).

package/custom/skills/ba-skills/skill-ba-write-uc-spec-v1.md

@@ -3,6 +3,8 @@
 ## 1. Mục đích (Purpose)
 Kỹ năng này giúp BA chuyển hóa toàn bộ các thông tin yêu cầu nghiệp vụ đã được thống nhất sau quá trình Q&A thành một tài liệu Đặc tả Use Case (Use Case Spec) hoàn chỉnh. Tài liệu này là "nguồn sự thật duy nhất" (Single Source of Truth) giúp đội ngũ Dev lập trình chính xác và đội ngũ Test thiết kế toàn bộ kịch bản kiểm thử (Test Cases/Scripts).
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+
 ## 2. Kiến thức cần có (Prerequisite Knowledge)
 - **Cấu trúc Use Case chuẩn:** Hiểu rõ các thành phần của một Use Case Spec bao gồm: Thông tin chung, Mô tả màn hình, Mô tả thành phần UI, Luồng hoạt động (Activity Flow) và Quy tắc nghiệp vụ (Business Rules).
 - **Cách mô tả Luồng xử lý (Flow):** 

package/custom/skills/coverage-check/SKILL.md

@@ -93,6 +93,8 @@ Consolidate toàn bộ TCs (sau khi apply actions) vào **1 file duy nhất**:
 
 Lưu `test-plan/test-cases/final-testcases.md`:
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).
+
 ```markdown
 # Final Test Cases — [Feature Name]
 

package/custom/skills/create-system-requirement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: create-system-requirement
-description: Bridges UC Spec (BA, Gate 4) to Dev — investigates source code and translates the UC into System Requirement (Functional/Non-Functional Requirements, Business Rules → Validation Rules, Exception/Error Handling, Acceptance Tests). Runs once per functionId per UC Spec version, BEFORE the first coding ticket. Blocks Gate 1 (`read-study-requirement`) if missing or out of sync with the current UC Spec version.
+description: Bridges UC Spec (BA, Gate 4) to Dev — investigates source code and translates the UC into System Requirement (Functional/Non-Functional Requirements, Business Rules → Validation Rules, Exception/Error Handling, Acceptance Tests). Runs once per functionId per UC Spec version, ideally BEFORE the first coding ticket. Gate 1 (`read-study-requirement`) warns (non-blocking) if this is missing or out of sync with the current UC Spec version — this skill is how DEV closes that gap.
 keywords: system requirement, uc spec, functionId, trace, acceptance test, exception handling, business rule, matching, version sync
 ---
 
@@ -21,9 +21,10 @@ keywords: system requirement, uc spec, functionId, trace, acceptance test, excep
 
 **Hand-off from coding Gate 1 Pre-flight** (`read-study-requirement`, Step 0) when:
 - No `System-Requirement_v*.md` exists yet for this `functionId`, **or**
-- The existing one's `UC-Spec-Version` header does not match the UC Spec's current version.
+- The existing one's `UC-Spec-Version` header does not match the UC Spec's current version, **or**
+- It exists and matches but its `Status` header is not `✅ Approved`.
 
-Either condition → **the coding Gate 1 session is cancelled.** Tell DEV: start a new task with `ak use`, pick **"📐 Create System Requirement"** at the Task type prompt, run it through both gates to APPROVED, then resume the original ticket.
+Any of these → coding Gate 1 shows a ⚠️ non-blocking warning and **continues** (it does not cancel). DEV can close the gap at any point — before or after the current ticket — by starting a new task with `ak use`, picking **"📐 Create System Requirement"** at the Task type prompt, and running it through both gates to APPROVED.
 
 ---
 
@@ -179,6 +180,8 @@ Save to `AK-Docs/02.BA-Specs/00.Requirements/[functionId]/System-Requirement_v{N
 | [YYYY-MM-DD] | — | Initial creation from UC Spec v{N} | |
 ```
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ---
 
 ### Step 7: Present for Approval [Gate 2]
@@ -198,11 +201,12 @@ Coverage:
   Open Gaps:                [N]  ← must be 0 to approve
 
 Please review — matching 1-1 with UC Spec v{N} is the point of this document.
-  → Type APPROVED (then run `aiflow task next`) to close this task and unlock
-    coding Gate 1 for tickets on this functionId
+  → Type APPROVED (then run `aiflow task next`) to close this task and clear
+    the Gate 1 warning for tickets on this functionId
   → Or provide feedback to update
 
-⚠️  Coding Gate 1 for this functionId stays cancelled until this task is APPROVED.
+⚠️  Until this task is APPROVED, coding Gate 1 for this functionId will keep
+    showing a non-blocking warning (it does not cancel).
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -245,4 +249,4 @@ This does not bump `System-Requirement-Version` — the version stays tied to th
 - ✅ **MUST** read the full UC Spec (Step 1) before drafting anything.
 - ✅ **MUST** investigate source code (Step 2) before drafting Exception/Error Handling or Existing System Context.
 - ✅ **MUST** carry the mandatory `UC-Spec-Version` header on the master file.
-- ✅ **MUST** block/cancel Gate 1 until this skill reaches APPROVED, when triggered by the Gate 1 Pre-flight check.
+- ✅ **MUST** surface a ⚠️ non-blocking warning (never a cancel) from the Gate 1 Pre-flight check until this skill reaches APPROVED.

package/custom/skills/deploy-model/SKILL.md

@@ -73,6 +73,8 @@ Update the model card drafted at Gate 4 with:
 
 The model card is the primary audit document for the deployed model.
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ### 6. Create the PR
 
 Invoke `superpowers:requesting-code-review`. Open a PR that includes: serving code, model card, monitoring plan, and any pipeline changes. Link the ticket. Reference the eval report and the registered artifact version in the PR description.

package/custom/skills/design-experiment/SKILL.md

@@ -73,6 +73,8 @@ An open-ended experiment loop with no stopping rule is out of scope for a gated
 
 Write all of the above to `AK-Docs/04.Coding/02.Plans/[functionId]/[ticketId].md` (see `custom/rules/ml-conventions.md` — do NOT use the legacy `plan/[ticket-id]/` path). The document must be self-contained: a developer who did not attend the framing discussion should be able to reproduce the full experiment sequence from the plan alone.
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ---
 
 ## Completion Checklist

package/custom/skills/evaluate-model/SKILL.md

@@ -78,6 +78,8 @@ Output `AK-Docs/04.Coding/04.Reviews/[functionId]/[ticketId].md` (see `custom/ru
 
 Draft a model card covering: intended use, training data description, evaluation metrics and their context, known limitations, and owner/contact.
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ---
 
 ## Completion Checklist

package/custom/skills/evidence-aggregation/SKILL.md

@@ -83,6 +83,8 @@ evidence/
 
 Với mỗi TC, tạo `evidence/TC_[ID]-[scenario]/result.md`:
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).
+
 **Template khi PASS:**
 
 ```markdown

package/custom/skills/execute-flow/SKILL.md

@@ -213,6 +213,8 @@ Với mỗi TC:
 
 Với `kebab-scenario` = Test Case Name lowercase, dấu cách thành `-`, bỏ ký tự đặc biệt.
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).
+
 **Copy files từ Playwright output:**
 - Screenshots → `step-NN-{desc}.png`
 - Trace file → `trace.zip`

package/custom/skills/explore-data/SKILL.md

@@ -71,6 +71,8 @@ Write the EDA results into the `ml-problem.md` file created by `frame-ml-problem
 - Leakage assessment — one paragraph per leakage type stating what was checked and what was found
 - Cleaning actions required before training (drop columns, impute, clip outliers, re-encode)
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ---
 
 ## Completion Checklist

package/custom/skills/frame-ml-problem/SKILL.md

@@ -86,3 +86,5 @@ If any of the above cannot be answered from the ticket, ask exactly **one questi
 - [ ] Success threshold quantified (not "as high as possible")
 - [ ] Constraints listed (latency, memory, interpretability, data volume, compliance)
 - [ ] Findings written to `AK-Docs/04.Coding/01.Requirements/[functionId]/[ticketId].md` (see `custom/rules/ml-conventions.md` — do NOT use the legacy `plan/[ticket-id]/` path)
+
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).

package/custom/skills/gate-review/SKILL.md

@@ -57,6 +57,8 @@ When generating the output for a gate (e.g. `requirement.md` or `plan.md`), foll
 ### Step 2: Write the gate output file
 Write the gate output file (e.g. `AK-Docs/04.Coding/01.Requirements/[functionId]/[ticketId].md`, `AK-Docs/04.Coding/02.Plans/[functionId]/[ticketId].md`, or `docs/ak-[project]/...`) as specified by the gate instructions.
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ### Step 3: Display gate pause message
 
 Instruct the user to review the generated document. Tell them that they can hover over any line and add inline comments in VS Code using the native commenting UI, or edit the file to add standard HTML comments `<!-- comment -->` if they are not using the VS Code extension.

package/custom/skills/generate-spec/SKILL.md

@@ -75,6 +75,8 @@ Create a detailed step-by-step plan based on the requirement document:
 ```
 ```
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 > For UI tasks, reference the exact node/component from `design-context.md` in the Task column
 > (e.g. "Build UserCard — nodeId 78-910"). Add an image-copy task when the Image Map is non-empty.
 >

package/custom/skills/generate-test-report/SKILL.md

@@ -61,6 +61,8 @@ Tổng hợp per module theo format template (R1/R2 tracking từ testcase files
 
 Output: `test-plan/test-report.md`
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).
+
 ---
 
 ## Gate 4 Display

package/custom/skills/generate-testcase/SKILL.md

@@ -65,6 +65,8 @@ Xác định phạm vi ảnh hưởng thật từ code dev **trước khi** gene
 
 Liệt kê scenarios theo nhóm, output vào `test-plan/checklist.md`:
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).
+
 | ID | Scenario/Checklist Item | Mục đích kiểm tra | Expected Result |
 
 **Nhóm cần cover:**

package/custom/skills/impact-analysis/SKILL.md

@@ -91,6 +91,8 @@ List all:
 [Specific points QA should pay attention to]
 ```
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ---
 
 ## Completion Checklist

package/custom/skills/improve-algorithm/SKILL.md

@@ -61,6 +61,8 @@ Revert if it does not satisfy the above. Log the failure reason; failed experime
 
 Repeat steps 3–5 for the next bottleneck. Log every attempt — including reversions — so the improvement story is fully reproducible. The final state must be explainable: "we tried X (failed because Y), then tried Z (improved metric by W%)."
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 ---
 
 ## Completion Checklist

package/custom/skills/ingest-data/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ingest-data
-description: Use when taskType is "ingest-data" — PM/BrSE/Comtor ingesting customer communication (Backlog ticket/comment/Document/Wiki link, Jira link, SharePoint link, or pasted text) into AK-Docs/01.QnA/ logs. Covers fetching the source, classifying it into QnA-Log/Meetings-Log/Confirmations-Log, and drafting the entry for self-review before Gate 2 opens the MR.
-keywords: ingest data, comtor, brse, pm workflow, meeting minutes, qna log, confirmations log, backlog document, backlog wiki, sharepoint, gate 1, gate 2
+description: Use when taskType is "ingest-data" — PM/BrSE/Comtor ingesting customer communication (Backlog ticket/comment/Document/Wiki link, Jira link, SharePoint link, or pasted text) into AK-Docs/01.QnA/ logs. Covers fetching the source, classifying it into QnA-Log/Meetings-Log/Confirmations-Log, drafting the entry for self-review before Gate 2 opens the MR, and — auto right after Gate 2 — analyzing the entry to propose a PM-approved task list that gets created as real Backlog/Jira tickets.
+keywords: ingest data, comtor, brse, pm workflow, meeting minutes, qna log, confirmations log, backlog document, backlog wiki, sharepoint, gate 1, gate 2, gate 3, sinh task, tạo ticket
 ---
 
 # Ingest Data — Gate 1 (fetch/classify/draft)
@@ -110,3 +110,117 @@ Sau khi fetch + phân loại, soạn đúng 1 entry theo template tương ứng
 **Không tự ghi file, không tự tạo branch** ở bước này — chỉ hiển thị draft trong hội thoại. Việc ghi file + branch + MR chỉ chạy ở Gate 2, sau khi người dùng gõ **APPROVED**.
 
 Nếu người dùng yêu cầu sửa (thêm/bớt ý, đổi log đích, sửa functionId...) → cập nhật lại draft, hiển thị lại toàn bộ, chờ APPROVED lại — lặp cho tới khi được duyệt.
+
+---
+
+## 5. Gate 3 — Sinh & Duyệt Task List, Tạo Ticket (auto, ngay sau Gate 2)
+
+> Implement "Vấn đề 5" trong `docs/internal/PM Workflow_v1.0.md`. **Trigger đã chốt: TỰ ĐỘNG** — chạy ngay tiếp theo Gate 2 (MR ingest vừa mở xong), không cần lệnh riêng, không chờ PM merge MR trước (merge MR là việc của PM ở luồng riêng, không block bước này).
+> Gate mechanics chi tiết (khi nào gọi lệnh nào) nằm ở `custom/templates/shared/gate-workflow.md` § "ingest-data Task Type" → GATE 3. File này chỉ mô tả **cách phân tích và đề xuất**.
+
+### 5.1 Bước 1 — Đọc lại entry + điều tra phạm vi ảnh hưởng
+
+Đọc lại đúng entry vừa ghi ở Gate 2 (Meetings-Log.md / QnA-Log.md / Confirmations-Log.md — nguyên văn nội dung người dùng đã input ở Gate 1, không phải bản tóm tắt). Sau đó:
+
+1. Xác định `functionId` liên quan (đã có trong entry, hoặc `general`).
+2. Đọc source code + tài liệu hiện có liên quan đến `functionId` đó (UC Spec ở `AK-Docs/02.BA-Specs/04.UC-Specs/[functionId]/`, code trong repo source, `AK-Docs/04.Coding/00.Overview/_Index.md`) để hiểu **hệ thống hiện tại đang làm gì**, từ đó đánh giá nội dung mới vừa ingest tác động tới đâu.
+3. Nếu nội dung có Action items rõ ràng trong template Meeting Minutes (mục 3.2) — đây là gợi ý mạnh cho danh sách task, không bỏ qua.
+
+### 5.2 Bước 2 — Quyết định: có cần task hay không
+
+**Không phải mọi entry đều sinh ra task.** Trước khi đề xuất bất kỳ task nào, tự hỏi: nội dung này có yêu cầu một hành động cụ thể (thay đổi spec, code, test, tài liệu...) hay chỉ là thông tin tham khảo/FYI (cập nhật tiến độ, thông tin không đổi hành vi hệ thống, trả lời một câu hỏi đã đóng)?
+
+- **Chỉ là tham khảo** → hiển thị: `ℹ️ Nội dung này không phát sinh task — chỉ lưu làm tài liệu tham khảo. Gate 3 kết thúc.` rồi dừng, không hỏi thêm, không chạy `ak gate 3 start`.
+- **Có hành động cụ thể** → tiếp tục Bước 3. Khi không chắc (ví dụ nội dung vừa có FYI vừa có 1 ý cần sửa code) — nghiêng về đề xuất task cho phần cần hành động, bỏ qua phần FYI, không tự bịa task cho phần không rõ.
+
+### 5.3 Bước 3 — Đề xuất danh sách task
+
+Mỗi task gồm:
+
+| Trường | Ghi chú |
+|---|---|
+| `type` | `spec` (tạo/update UC Spec) · `coding` · `test` · `other` (update tài liệu không thuộc BA/QA/Dev, vd Rules) |
+| `title` | Ngắn, hành động rõ (vd "Cập nhật flow OTP theo feedback khách — tăng thời hạn 30s → 90s") |
+| `track` | BA / Dev / QA — để PM biết ai sẽ nhận task này |
+| `description` | Theo đúng template mục 6.1 `PM Workflow_v1.0.md`: |
+
+```text
+## Nội dung task
+[Mô tả task do AI đề xuất]
+
+## Nguồn tham chiếu
+- Văn bản gốc: [<mô tả ngắn>](<url hoặc "pasted text">)
+- Log AK-Docs: AK-Docs/01.QnA/[QnA-Log.md | Meetings-Log.md | Confirmations-Log.md] (entry ngày <ngày>)
+```
+
+Riêng task `type: "spec"` — thêm 2 mục bắt buộc theo mục 6.1, và **hỏi PM xin link hồ sơ cam kết thay đổi nếu chưa có sẵn** (không tự suy luận):
+
+```text
+## Tổng quan nội dung thay đổi
+[Tóm tắt: thay đổi gì, vì sao thay đổi]
+
+## Nguồn tham chiếu
+- Hồ sơ cam kết thay đổi: [<mô tả ngắn>](<URL do PM cung cấp>)
+- Log AK-Docs (nếu có): AK-Docs/01.QnA/Meetings-Log.md (entry ngày <ngày>)
+```
+
+Hiển thị toàn bộ danh sách cho PM xem — đủ cả `type`/`title`/`track`/`description`, không tóm tắt.
+
+### 5.4 Bước 4 — PM review, sửa trực tiếp trong hội thoại
+
+PM có thể **thêm / sửa / xoá từng task** ngay trong lượt review này (không phải chỉ APPROVED/reject toàn bộ) — cập nhật lại danh sách theo đúng yêu cầu, hiển thị lại toàn bộ, lặp lại cho tới khi PM hài lòng. Task nào type là `spec` mà thiếu "Nguồn tham chiếu" (hồ sơ cam kết thay đổi) → coi như chưa đủ điều kiện, phải hỏi PM bổ sung trước khi cho vào vòng xác nhận tạo ticket ở Bước 5.
+
+### 5.5 Bước 5 — Điểm dừng xác nhận tạo ticket
+
+Hỏi đúng 1 câu, không tự thêm `--yes`:
+
+```text
+Danh sách task như trên (N task) — đồng ý tạo trên [Backlog/Jira]?
+```
+
+- Xác định target `backlog`/`jira` theo đúng adapter của ticket/document gốc đã ingest ở Gate 1/2 (Backlog → target backlog; Jira → target jira). Nếu nguồn là pasted text/SharePoint (không rõ adapter) → hỏi PM muốn tạo trên hệ thống nào.
+- **KHÔNG ĐỒNG Ý** → dừng, để PM tự chỉnh sửa rồi yêu cầu lại (quay lại Bước 4).
+- **ĐỒNG Ý** → sang Bước 6.
+
+### 5.6 Bước 6 — Xác định project đích
+
+Check LOCAL trước, chỉ hỏi khi thật sự chưa biết (Vấn đề 5.1):
+
+1. Backlog: kiểm tra `BACKLOG_DEFAULT_PROJECT_ID` đã lưu chưa (chạy `ak backlog-projects --json`, đọc field `defaultProjectId`). Jira: `ak jira-projects --json`, đọc `defaultProjectKey`.
+2. Đã có → dùng luôn, hiển thị rõ cho PM biết đang dùng project nào + nguồn (đã lưu từ lần trước).
+3. Chưa có → hiển thị danh sách project vừa fetch được, PM chọn 1 → lưu lại bằng `ak backlog-set-default-project <id> <key>` hoặc `ak jira-set-default-project <key>` — để lần sau không hỏi lại.
+
+### 5.7 Bước 7 — Tạo ticket
+
+1. Ghi danh sách task đã duyệt ra 1 file JSON tạm (vd `.aiflow/tmp/tasks-[ticketId].json`), đúng shape mà `ak tasks create-tickets` đọc (xem `scripts/ticket-writer.js`):
+   ```json
+   {
+     "target": "backlog",
+     "tasks": [
+       { "type": "coding", "title": "...", "description": "..." }
+     ]
+   }
+   ```
+2. Chạy `ak tasks create-tickets <file> --json`.
+3. Đọc kết quả JSON trả về:
+   - `{"error":"missing-write-credentials", "field": "...", "message": "..."}` → **đây không phải lỗi hệ thống** — hiển thị đúng `message` cho PM, hỏi PM nhập giá trị key ngay trong hội thoại (dùng luôn khung chat làm nơi PM "nhập & submit"), nhận giá trị → chạy `ak credentials set <field> "<giá trị PM vừa nhập>"` → chạy lại bước 2 (retry đúng 1 lần; nếu vẫn lỗi, báo PM key có thể sai/chưa đủ quyền, không tự thử lại vô hạn).
+   - `{"error":"missing-project", ...}` → quay lại Bước 6 (chưa xác định được project).
+   - Thành công (`ok: true`) → mỗi task có `ticketId` + `url` riêng; task nào `ok: false` (lỗi phía Backlog/Jira, vd thiếu field) → báo rõ cho PM, các task khác đã tạo vẫn giữ nguyên (không rollback).
+
+### 5.8 Bước 8 — Ghi ngược liên kết + đóng Gate
+
+1. Append vào cuối đúng entry gốc (Meetings-Log/QnA-Log/Confirmations-Log) 1 dòng:
+   ```text
+   → Tasks created: TICKET-101 (coding), TICKET-102 (test)
+   ```
+   Việc sửa file này đi qua đúng branch đang dùng ở Gate 2 (không tạo MR riêng — gộp vào cùng thay đổi, hoặc nếu MR đã mở/merge thì tạo 1 commit nhỏ tiếp theo trên cùng branch/1 MR mới tuỳ trạng thái branch lúc đó).
+2. Hiển thị tổng kết:
+   ```text
+   ✅ GATE 3 DONE — Đã tạo N/N ticket trên [Backlog/Jira]:
+     - TICKET-101 (coding) — <url>
+     - TICKET-102 (test) — <url>
+   → Dev/QA chạy `ak use TICKET-XXX` trên từng ticket để bắt đầu Gate tương ứng (Coding/QA workflow hiện có).
+   ```
+3. Run: `ak gate 3 approved --ticket [ticket-id]`.
+
+> **Telemetry:** Run `ak gate 3 start --ticket [ticket-id]` khi bắt đầu Bước 1 (bỏ qua nếu Bước 2 kết luận không cần task — không start gate cho trường hợp "chỉ tham khảo"). Run `ak gate 3 approved --ticket [ticket-id]` khi Bước 8 xong.

package/custom/skills/log-bug/SKILL.md

@@ -44,6 +44,8 @@ Thu thập ngay khi test fail:
 **File naming:** `bugs/BUG-[số thứ tự 3 chữ số]-[tên ngắn kebab-case].md`
 **Ví dụ:** `bugs/BUG-001-login-button-not-disabled-on-submit.md`
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).
+
 **Dùng template bên dưới.**
 
 ### Bước 4 — Thông báo TESTER

package/custom/skills/pr-impact-analysis/SKILL.md

@@ -142,6 +142,8 @@ Ngoài TCs gốc của feature, cần test thêm:
 | Verify Admin User list không bị cache stale | Shared service thay đổi |
 ```
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).
+
 ---
 
 ## Guard Rails (bắt buộc)

package/custom/skills/read-study-requirement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: read-study-requirement
-description: Gate 1 — AI reads ticket from Backlog/Jira + reads source code, then uses collaborative Q&A and solution proposal. Adds impact analysis and effort estimate. Outputs requirement.md for DEV to approve. Requires System Requirement (bridged from UC Spec via `create-system-requirement`) to exist and match the current UC Spec version — cancels and hands off otherwise.
+description: Gate 1 — AI reads ticket from Backlog/Jira + reads source code, then uses collaborative Q&A and solution proposal. Adds impact analysis and effort estimate. Outputs requirement.md for DEV to approve. Checks that System Requirement (bridged from UC Spec via `create-system-requirement`) exists and matches the current UC Spec version — shows a non-blocking ⚠️ warning and continues otherwise.
 keywords: ticket, requirement, study, read, context, backlog, jira, analyze, understand, solution, estimate, system requirement, uc spec
 ---
 
@@ -12,16 +12,20 @@ keywords: ticket, requirement, study, read, context, backlog, jira, analyze, und
 
 ---
 
-## Step 0: System Requirement Gate (Pre-flight, blocking — runs before Mode Selection)
+## Step 0: System Requirement Check (Pre-flight, non-blocking warning — runs before Mode Selection)
 
-Before reading the ticket in depth, verify the bridge document from UC Spec exists — this applies to **every mode**, including Fast Track (it's a 2-file header check, not a heavy investigation):
+Before reading the ticket in depth, verify the bridge document from UC Spec — this applies to **every mode**, including Fast Track (it's a 2-file header check, not a heavy investigation). **This check never cancels Gate 1** — any gap only produces a ⚠️ yellow warning; Gate 1 always continues with whatever context is available:
 
 1. Resolve `functionId` from `.aiflow/context/current.json` (or ask DEV once if absent).
 2. Locate the current UC Spec: `AK-Docs/02.BA-Specs/04.UC-Specs/[functionId]/UC-Spec_v{N}.md` (highest non-archived version).
-   - **Not found** → notify DEV: `⚠️ No UC Spec found for [functionId] — Gate 1 requires a BA-signed-off UC Spec before coding starts.` STOP.
+   - **Not found** → `⚠️ CẢNH BÁO: Không tìm thấy UC Spec cho [functionId] — Gate 1 tiếp tục chỉ dựa trên ticket/source code, thiếu ngữ cảnh nghiệp vụ BA đã chốt.` Continue to step 3.
 3. Check `AK-Docs/02.BA-Specs/00.Requirements/[functionId]/System-Requirement_v*.md`:
-   - **Missing, or its `UC-Spec-Version` header doesn't match the UC Spec found in step 2** → **CANCEL Gate 1 immediately.** `create-system-requirement` is a separate task type (2 gates), not an inline sub-skill — tell DEV: `⏸️ Gate 1 cancelled — run "ak use" and pick "📐 Create System Requirement" for [functionId] first, complete both its gates to APPROVED, then resume this ticket.`
-   - **Exists and matches** → continue below. Keep this file's path — Step 1 must read it as mandatory input.
+   - **Missing** → `⚠️ CẢNH BÁO: Không tìm thấy System Requirement cho [functionId]. Khuyến nghị chạy "ak use" → "📐 Create System Requirement" trước ticket kế tiếp — Gate 1 vẫn tiếp tục ngay bây giờ dựa trên UC Spec/ticket.`
+   - **Exists, but its `UC-Spec-Version` header doesn't match the UC Spec found in step 2** → `⚠️ CẢNH BÁO: System Requirement đang trace theo UC Spec v[X], UC Spec hiện tại là v[Y] — nội dung có thể lỗi thời.` Treat its items as Assumption rather than Fact in Step 1.75.
+   - **Exists, matches, but its `Status` header is not `✅ Approved`** → `⚠️ CẢNH BÁO: System Requirement cho [functionId] chưa Approved (Status: [giá trị hiện tại]) — nội dung có thể còn thay đổi.`
+   - **Exists, matches, and Approved** → continue silently. Keep this file's path — Step 1 must read it as mandatory input.
+
+Any warning raised above must also be written into this ticket's requirement doc (Section 1, Facts/Assumptions/Gaps in Step 4) — not just printed and forgotten. If DEV wants the gap closed properly, they can run `ak use` → "📐 Create System Requirement" for `[functionId]` at any point (before or after this ticket) — it's a separate 2-gate task type, not an inline sub-skill here.
 
 ---
 
@@ -88,6 +92,8 @@ When creating `AK-Docs/04.Coding/04.Reviews/[functionId]/[ticketId].md` during G
 | **Total** | **S/M/L** |
 ```
 
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).
+
 5. Display Gate 1 prompt and wait for `APPROVED`.
 
 > After APPROVED, proceed to Gate 2.
@@ -466,7 +472,7 @@ Please review the requirement document.
 
 ## Mandatory Rules
 
-- ✅ **MUST** verify System Requirement exists and matches the current UC Spec version (Step 0) before proceeding — cancel Gate 1 and hand off to the `create-system-requirement` task type otherwise.
+- ✅ **MUST** verify System Requirement exists and matches the current UC Spec version (Step 0) before proceeding — show a ⚠️ non-blocking warning and continue otherwise (never cancels Gate 1); record the gap in the requirement doc (Step 4).
 - ✅ **MUST** read System Requirement as mandatory input (Step 1) — not optional context.
 - ❌ **DO NOT** restate content already covered in System Requirement — reference its item ID instead.
 - ❌ **DO NOT** silently accept ticket scope that doesn't trace to System Requirement or UC Spec (Step 3.5) — stop and ask instead of guessing.

package/custom/skills/report-customer/SKILL.md

@@ -31,7 +31,11 @@ Fill in the structure below. **Use simple language, avoiding technical jargon.**
 
 ---
 
-## Standard Structure (English)
+## Standard Structure
+
+Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md`
+(Vietnamese ticket → Vietnamese report; otherwise English). CS can request a specific language
+explicitly, which overrides auto-detect. Structure below is shown in English.
 
 ```markdown
 ## 📋 Incident Verification Report
@@ -92,4 +96,4 @@ If problems persist, please contact our support hotline..."]
 - ❌ Do not blame third parties unless certain
 - ❌ Do not commit to specific deadlines unless certain
 
-Present clearly and professionally. Default is English unless otherwise requested.
+Present clearly and professionally, in the language determined above.

package/custom/skills/retest-orchestration/SKILL.md

@@ -84,6 +84,8 @@ BASE_URL=<baseUrl> npx playwright test --grep "AD10_002|AD10_005" --headed
 
 Invoke `evidence-aggregation` skill cho RETEST results:
 
+Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).
+
 **Không xóa evidence cũ** — tạo subfolder theo run:
 
 ```