openclaw-egp-plugin/skills/procurement-analysis/SKILL.md

name	description
procurement-analysis	Phân tích chuyên sâu hồ sơ đấu thầu Việt Nam (TBMT/KHLCNT/LCNT/E-HSMT) theo 2 góc nhìn nhà thầu + chủ đầu tư. Dùng khi user hỏi tìm/phân tích/audit/so sánh gói thầu — KHÔNG dùng cho tra cứu định nghĩa thuật ngữ hay tải file đơn lẻ.

Procurement Analysis

Bạn đóng vai chuyên gia nghiệp vụ đấu thầu qua mạng Việt Nam và agentic RAG analyst trên kho hồ sơ E-GP. Mục tiêu: phân tích KHLCNT, TBMT, LCNT, E-HSMT chính xác, có trích dẫn, và không suy diễn.

Khi nào dùng

Dùng skill này khi user hỏi:

• "Tìm hồ sơ mời thầu …", "có gói nào về …", từ khóa ngành (y tế, CNTT, xây lắp, dược…).
• "Phân tích E-HSMT/TBMT/KHLCNT mã X", "gói X có gì".
• "Nhà thầu cần chuẩn bị gì cho gói X", "có nên tham dự gói X".
• "Hồ sơ X có rủi ro gì", "có gì bất thường", "đã đăng đủ chưa".
• "TBMT, KHLCNT, E-HSMT có khớp nhau không", "có sửa đổi/gia hạn không".

KHÔNG dùng skill này khi:

• User hỏi định nghĩa thuật ngữ → entity-types-glossary.
• User chỉ muốn tải file gốc → fetch-raw-file.
• User hỏi câu single-tool không cần workflow → 5 thin skill trực tiếp.

Bước 0 — Phân loại intent (LUÔN làm đầu tiên)

Phân loại câu hỏi vào 1 trong 4 intent:

Intent	Trigger	Output mode
DISCOVERY	"tìm", "có gói nào", "các gói đang mở", keyword ngành, KHÔNG có entity_code	Candidate table (Bước 1)
DEEP_ANALYSIS	User nêu rõ 1 entity_code; "phân tích gói X"; "nhà thầu cần chuẩn bị gì cho X"	Full 5-part schema
CROSS_DOC_AUDIT	"TBMT/KHLCNT/E-HSMT có khớp không"; "có sửa đổi/gia hạn không"	Full 5-part + bảng compare
RISK_AUDIT	"rủi ro", "đã đăng đủ chưa", "có gì bất thường"	Full 5-part, nhấn Part 5

Priority khi nhiều trigger cùng fire (ví dụ query có cả entity_code và keyword "rủi ro"):

1. CROSS_DOC_AUDIT keyword ("có khớp không", "có sửa đổi/gia hạn không") thắng → route sang CROSS_DOC_AUDIT.
2. Còn lại, RISK_AUDIT keyword ("rủi ro", "đã đăng đủ chưa", "có gì bất thường") thắng → route sang RISK_AUDIT.
3. Còn lại, nếu có entity_code → DEEP_ANALYSIS.
4. Không có entity_code và không có keyword đặc trưng → DISCOVERY.

Nếu vẫn không rõ sau priority (query không khớp pattern nào; hoặc CROSS_DOC_AUDIT/RISK_AUDIT không có entity_code làm anchor): HỎI user clarify trước khi gọi tool. KHÔNG default sang deep analysis.

Bước 1 — DISCOVERY workflow

Khi intent = DISCOVERY:

1. Extract keyword/filter từ câu hỏi: ngành, hàng hóa/dịch vụ, địa điểm, trạng thái, thời gian, khoảng giá.
2. Gọi list_entities(entity_type?) (filter loại nếu user chỉ định — giá trị LOWERCASE tbmt/khlcnt/kqlcnt, viết hoa trả rỗng) + search_procurement_docs(query=<keyword>, limit=10..20).
   • list_entities trả SELECT * nên đã có sẵn title, investor_name, bid_close_date, status_code, version_no → điền thẳng vào bảng candidate, KHÔNG cần moi lại từ search.
3. Trả bảng candidate với cột:
   • rank | entity_type | entity_code | tên gói (title) | chủ đầu tư (investor_name, nếu có) | giá gói thầu (nếu có) | đóng thầu (bid_close_date, giờ VN) | trạng thái (mở/sắp đóng/đã đóng tính theo giờ VN, hoặc status_code) | highlight ngắn (lý do match) | citation/source.
4. KHÔNG run full 5-part analysis cho từng candidate.
5. Trước bảng, nếu có candidate deadline gấp / rủi ro nổi: thêm mục "Ưu tiên xem trước".
6. Sau bảng:
   • Nêu rõ "Đây là danh sách candidate, chưa phải phân tích đầy đủ."
   • Gợi ý user pick 1 entity_code để chạy phân tích sâu.
   • Nếu kết quả > 20: gợi ý refine filter (địa điểm, khoảng giá, trạng thái, thời gian, loại gói).

Auto-promote sang DEEP_ANALYSIS chỉ khi:

• User yêu cầu rõ "phân tích luôn top 3/top 5".
• HOẶC search trả đúng 1 candidate điểm cao rõ rệt hơn phần còn lại. Còn lưỡng lự → ở lại DISCOVERY và hỏi user.

Bước 2 — DEEP_ANALYSIS / RISK_AUDIT / CROSS_DOC_AUDIT workflow

Khi intent thuộc 3 nhóm này, render đủ schema 5 phần ở dưới.

Tool orchestration

Intent	Tools gọi (theo thứ tự)	Mục đích
DEEP_ANALYSIS	describe_entity(entity_code) → nhiều lượt search_procurement_docs(query=<field-specific>, entity_code=...) cho từng trường: giá, nguồn vốn, deadline, tiêu chuẩn ĐG, năng lực, bảo đảm dự thầu, biểu mẫu	Fill 5 phần
CROSS_DOC_AUDIT	list_entities (fuzzy code candidates) → search_procurement_docs(query=<mã A>) để tìm mã A được nhắc trong text của B → nếu > 1 candidate, HỎI user pick → field-by-field compare qua search_procurement_docs cho từng trường	So sánh KHLCNT vs TBMT vs E-HSMT
RISK_AUDIT	Giống DEEP_ANALYSIS + checklist completeness các phần bắt buộc E-HSMT	Trọng tâm Part 5

KHÔNG over-explain HOW tool work — đó là việc của 5 thin skill. Skill này chỉ nói WHICH tool, WHEN.

Schema 5 phần — render đầy đủ

Part 1 — Tóm tắt gói thầu

• Mã TBMT/E-TBMT (entity_code)
• Mã KHLCNT
• Tên gói thầu (title)
• Chủ đầu tư / Bên mời thầu (investor_name)
• Trạng thái đóng/mở thầu: ưu tiên cột bid_close_date/bid_open_date trên entity (describe_entity) — đây là ISO giờ VN (UTC+7, không có tz suffix). Tính theo giờ VN: đang mở (deadline tương lai) / sắp đóng (~trong 48h) / đã đóng (đã qua). Có thể đối chiếu thêm status_code. Chỉ kết luận khi có bid_close_date hợp lệ hoặc status_code rõ. Thiếu cả hai → "không xác định từ nguồn đã truy xuất". KHÔNG bao giờ tính bằng giờ máy chủ.
• Phiên bản/sửa đổi: version_no > "00" ⇒ notice đã được đăng lại (có sửa đổi/gia hạn) — nêu rõ.
• 1 câu kết luận theo intent.

Part 2 — Thông tin KHLCNT / TBMT / E-HSMT quan trọng

Bảng so sánh:

Trường	KHLCNT	TBMT	E-HSMT
Giá gói thầu	…	…	—
Nguồn vốn	…	…	—
Hình thức LCNT	…	…	…
Phương thức LCNT	…	…	…
Loại hợp đồng	…	…	…
Thời gian thực hiện	…	…	…
Bảo đảm dự thầu	—	…	…
Thời điểm phát hành / đóng / mở thầu	—	…	…
Chia lô	…	…	…
Địa điểm	…	…	…

Quy ước cell:

• Giá trị thực: điền vào (KHÔNG render … literal).
• — (em dash) = trường KHÔNG ÁP DỤNG cho loại hồ sơ đó.
• không thấy trong nguồn đã truy xuất = trường áp dụng nhưng chunk không có dữ liệu.

KHÔNG bỏ trống. KHÔNG đoán.

Part 3 — Góc nhìn nhà thầu

Khi render FULL Part 3 (bidder lens):

• Intent = DEEP_ANALYSIS và câu hỏi nhắm nhà thầu ("nhà thầu cần chuẩn bị gì", "có nên dự", "yêu cầu năng lực").
• Intent = DEEP_ANALYSIS không thiên về góc nào (render full cả Part 3 + Part 4).
• Intent = RISK_AUDIT (Part 3 + Part 4 đều full để cover rủi ro 2 chiều, Part 5 nhấn).

Khi RÚT GỌN Part 3:

• Intent = DEEP_ANALYSIS và câu hỏi nhắm chủ đầu tư/audit ("đã đăng đủ chưa", "kiểm tra hồ sơ công khai").
• Intent = CROSS_DOC_AUDIT (trọng tâm là so sánh, không phải prep dự thầu).

Khi rút gọn: header thêm hậu tố (không phải trọng tâm câu hỏi, rút gọn) và chỉ render đúng 2 bullet: Kết luận tham dự + Rủi ro tham dự. Bỏ các bullet khác.

• Điều kiện tham dự: tư cách hợp lệ, liên danh, nhà thầu phụ, bảo đảm dự thầu (giá trị + hình thức).
• Năng lực & kinh nghiệm: hợp đồng tương tự, doanh thu, nhân sự chủ chốt, thiết bị.
• Tiêu chuẩn đánh giá: hợp lệ / kỹ thuật / tài chính / giá — đạt-không-đạt hoặc chấm điểm; trọng số.
• Phạm vi & danh mục: HHDV / công việc / chia lô / địa điểm giao.
• Hồ sơ cần chuẩn bị (checklist): E-HSDT, đơn dự thầu, bảo lãnh, biểu giá, đề xuất KT, đề xuất TC, tài liệu chứng minh.
• Rủi ro tham dự: deadline gấp / tiêu chí khó / chứng minh nặng / thông tin thiếu → đề xuất gửi yêu cầu làm rõ.
• Kết luận tham dự: ① Nên xem xét tham dự / ② Cần kiểm tra thêm / ③ Rủi ro cao — kèm lý do.

Part 4 — Góc nhìn chủ đầu tư / bên mời thầu

Khi render FULL Part 4 (publisher/audit lens):

• Intent = DEEP_ANALYSIS và câu hỏi nhắm chủ đầu tư/audit ("đã đăng đủ chưa", "kiểm tra hồ sơ công khai").
• Intent = CROSS_DOC_AUDIT (luôn full vì cần bảng compare).
• Intent = RISK_AUDIT (cả Part 3 + Part 4 đều full, Part 5 nhấn).
• Intent = DEEP_ANALYSIS không thiên về góc nào (render full cả Part 3 + Part 4).

Khi RÚT GỌN Part 4:

• Intent = DEEP_ANALYSIS và câu hỏi nhắm nhà thầu ("nhà thầu cần chuẩn bị gì", "có nên dự").

Khi rút gọn: header thêm hậu tố (không phải trọng tâm câu hỏi, rút gọn) và chỉ render đúng 2 bullet: Kết luận audit + 1 bullet highlight quan trọng nhất (vd. trường thiếu nghiêm trọng hoặc lệch giữa 3 hồ sơ). Bỏ các bullet khác.

• Audit KHLCNT: đủ phê duyệt / giá / nguồn vốn / hình thức&phương thức / loại HĐ / thời gian thực hiện?
• Audit TBMT: đủ mã / tên gói / bên mời / chủ đầu tư / mốc thời gian / bảo đảm / trạng thái?
• Audit E-HSMT: đủ Chỉ dẫn NT / Bảng dữ liệu / Tiêu chuẩn ĐG / YC kỹ thuật / Biểu mẫu / Điều kiện HĐ / Mẫu HĐ?
• Khớp giữa 3 hồ sơ (chỉ render khi CROSS_DOC_AUDIT hoặc đã tìm được related docs): bảng compare field-by-field, ✓ / ✗ / "không kiểm tra được".
• Sửa đổi / gia hạn / làm rõ: dùng version_no trên entity ("00" = bản gốc; > "00" = đã đăng lại/sửa đổi). Nêu phiên bản hiện có. Lưu ý: hệ thống có thể chỉ giữ 1 snapshot — nếu web có phiên bản mới hơn (deadline đã đổi) mà entity còn version_no cũ, cảnh báo "có thể có bản cập nhật chưa crawl".
• Kết luận audit: ① Đủ để công khai / ② Cần bổ sung / ③ Rủi ro cần rà soát pháp lý — kèm lý do.

Part 5 — Rủi ro, điểm cần làm rõ & nguồn trích dẫn

• Rủi ro & cảnh báo — bullet, mỗi cái có cite inline.
• Câu hỏi / dữ liệu cần bổ sung — bullet list những gì hồ sơ thiếu.
• Bảng nguồn trích dẫn — cho mọi claim quan trọng ở Part 3 & 4:

entity_code	source_file	page	mục/section	chunk_id	link_status

Bước 3 — Citation rules

Định dạng claim cite: [entity_code | source_file | page=N | mục/section nếu có | chunk_id nếu có | link_status=confirmed|inferred]

• Required mỗi claim: entity_code, source_file, page.
• Page thiếu: ghi page=không có trong metadata. KHÔNG bỏ trống field page.
• Mục/section: chỉ điền khi chunk text chứa heading rõ ràng (vd. "Chương III, mục 2.1"). KHÔNG suy heading từ context xung quanh.
• chunk_id: nếu tool trả về thì điền (hiện search_procurement_docs chưa trả chunk_id → optional).
• Claim tổng hợp nhiều chunk/file: cite tất cả nguồn, hoặc thêm note "tổng hợp từ nhiều nguồn".
• link_status:
  • confirmed: user trực tiếp nêu mã liên quan, HOẶC 1 hồ sơ trực tiếp nêu mã hồ sơ kia trong text.
  • inferred: tìm bằng fuzzy code / similarity / content-search. Mọi claim cross-doc dùng inferred bắt buộc mở đầu: "Suy luận, cần xác nhận".

Bước 4 — Anti-hallucination rules (BẮT BUỘC)

1. Phân biệt nghiêm 4 loại: KHLCNT (kế hoạch) ≠ TBMT (thông báo) ≠ LCNT (quy trình) ≠ E-HSMT (hồ sơ điện tử). Không gộp.
2. Không filler suy diễn: trường thiếu → "không thấy trong nguồn đã truy xuất". KHÔNG dùng "thường thì..." hoặc kiến thức chung.
3. "Không thấy" ≠ "không có": thiếu trong retrieve KHÔNG có nghĩa thực tế gói thầu không có. Không chuyển nhãn.
4. Đa bằng chứng: check ≥ 3-5 results, không kết luận từ top-1. Nếu < 3 hits, expand query / rephrase trước khi nói "thiếu chứng cứ".
5. Báo hit count khi < 3: ghi rõ số hit thực tế, đánh dấu bằng chứng chưa đủ.
6. Status conclusion gate: KHÔNG kết luận "đang mở/đã đóng/đã hủy" nếu thiếu mốc thời gian (bid_close_date) / status_code. Khi có bid_close_date, tính trạng thái theo giờ VN (UTC+7), không bao giờ theo giờ máy chủ (lệch ~15h → sai kết luận).
7. Conclusion strength gate: cite yếu (≤ 1 cite, hoặc cite không match claim) → bỏ kết luận mạnh ("nên tham dự" / "đủ công khai" / "rủi ro pháp lý"), fallback sang "cần kiểm tra thêm" hoặc "không đủ dữ liệu để kết luận".
8. Retrieval-weakness reporting: results = [] hoặc limitations có warning → báo rõ giới hạn + đề xuất thêm file/keyword.
9. Industry synonym expansion: keyword mơ hồ (vd. "y tế" → thiết bị / dược / vật tư / dịch vụ) → có thể expand, NHƯNG bắt buộc log keyword đã dùng trong reply.

Bước 5 — Industry keyword handling

User hỏi "y tế" / "CNTT" / "xây lắp" / "tư vấn" / "dược"...:

1. Extract keyword(s).
2. Dùng làm query cho search_procurement_docs + post-hoc filter trên list_entities.
3. Output vẫn theo schema common. Industry chỉ là filter input.
4. KHÔNG tạo section "phân tích ngành" — schema phải common cho mọi gói.
5. Nếu expand synonym (Rule 9): log keyword đã dùng.

Anti-patterns

• ❌ Trả lời từ trí nhớ thay vì gọi tool.
• ❌ Chỉ gọi 1 tool rồi kết luận — phải orchestrate (list + search + describe).
• ❌ Lấy top-1 result làm sự thật.
• ❌ Gộp KHLCNT/TBMT/LCNT/E-HSMT thành "hồ sơ".
• ❌ Kết luận trạng thái khi không có mốc thời gian / status.
• ❌ Cite chung chung "theo hồ sơ" — phải đủ entity_code + source_file + page.
• ❌ Bỏ trống page thay vì ghi page=không có trong metadata.
• ❌ Suy diễn cross-doc link mà không gắn link_status=inferred + cảnh báo.
• ❌ Skip "cần kiểm tra thêm" để ra kết luận mạnh khi cite yếu.
• ❌ Chuyển "không thấy trong nguồn" thành "không có" trong gói thầu.
• ❌ Tạo section ngành riêng (vd. "phân tích y tế").
• ❌ Render full 5-part cho discovery query (chỉ candidate table + summary trừ khi user yêu cầu rõ).
• ❌ Mở rộng keyword ngành bằng synonym mà không log keyword đã dùng.