feat: sg-md-writing và sg-prompt-sharpening v0.2.0 — gọn hơn, có eval

sg-md-writing thành skill bảo trì tri thức dự án cho AI:
- Gộp hướng dẫn viết skill/subagent/hook (từ writing-agent-context) vào.
- Bảng "đặt dòng ở đâu" theo chi phí nạp: root nạp mọi phiên; rule có `paths:`,
  CLAUDE.md của module, skill, docs chỉ nạp khi cần.
- Chế độ sync: tự sửa đúng dòng .md bị sai trong cùng thay đổi, bump Last synced,
  chỉ hỏi ý định code không trả lời được (bỏ cổng xác nhận từng file, phỏng vấn
  từng câu, kiểm tra model yếu mỗi lần).
- Bỏ khẳng định sai "subagent không tự nạp CLAUDE.md" và lối viết in hoa.
  21,6 KB → 9,1 KB.

sg-prompt-sharpening: tự lấp chỗ thiếu từ dự án, hiện bản prompt đã làm rõ
(mục tiêu, ở đâu, xong khi, giả định) rồi làm; chỉ hỏi một câu (có đề xuất)
khi các cách hiểu dẫn tới việc khác nhau; không kích hoạt với yêu cầu đã đủ rõ.

Eval (claude plugin eval, 2 lượt/case, có skill vs không):
- sharpening 3/3 (trước 2/3), Δ +0.67
- md-writing 5/5 (trước 1/5), Δ +0.40

plugins/common/skills/sg-prompt-sharpening/SKILL.md

@@ -1,31 +1,39 @@
 ---
 name: sg-prompt-sharpening
-description: Use when a user's request is short, vague, terse, or could reasonably be interpreted more than one way, before investigating or writing any code — expands the raw ask into an explicit interpretation set, surfaces assumptions, and defines success criteria so execution matches intent on the first try.
+description: Use when a request leaves out what is needed to act on it — the goal, which part of the project, or what "done" looks like — or could mean two different jobs. Typical of short, casual natural-language asks ("thêm xóa nhanh nhé", "làm lại phần thông báo cho đẹp", "làm báo cáo cho sếp"). Not for requests that already name the target and the expected result. Rewrites the ask into a complete prompt, shows it to the user, then acts on it.
 ---
 
 # Prompt Sharpening
 
-## Overview
+People type requests the way they talk: short, without the where, the what-exactly or the finish line. This skill turns such a request into the prompt its author would have written with time to spare, shows it to them, and then works from it. The work matches the intent on the first try, and the team sees what a complete request looks like.
 
-Clear-sounding requests often hide multiple interpretations — silence that ambiguity by running this pass before acting.
+## 1. Fill the gaps yourself first
 
-## The pass (do this before investigating, and again after a first skim)
+Read what the request touches (the conversation, the project's CLAUDE.md, the files and screens it names) before deciding anything is missing. A gap that the code or the conversation answers is not a question: fill it, and say what you filled it with. Look for the project's own obvious candidate as well as the literal words. In a project whose real flagship is a 3D experience behind the homepage, "trang chủ" may mean that experience.
 
-1. **Literal ask** — restate what was actually said, no elaboration.
-2. **Plausible interpretations** — list every reading that changes *what* you'd build or *which* files you'd touch. Actively check: does this specific project have an obvious candidate the words don't rule out but also don't name? (e.g. "trang chủ"/"homepage" in a project whose actual flagship surface is a heavy 3D experience gated behind that homepage — that's a candidate, not a footnote.)
-3. **Diverge or converge?** If the interpretations lead to the same first investigative step (same files, same starting point), proceed and state your assumption inline as you go. If they diverge — different files, meaningfully different effort/risk, or a decision only the user can make — ask ONE targeted question before doing real work (AskUserQuestion if options are enumerable). Don't ask about things that don't change what you'd do.
-4. **Success criteria** — state a concrete, checkable definition of "fixed"/"done" *before* starting, derived from the user's actual complaint. Don't invent metrics after the fact that happen to match whatever you built.
-5. **Scope boundary** — one line on what this will NOT touch, so a small ask doesn't quietly grow.
+## 2. Show the sharpened prompt
 
-## Rationalizations to reject
+Before doing the work, show a short block in the user's language:
 
-| Excuse | Reality |
-|---|---|
-| "The problem statement is clear enough" | Clear-sounding ≠ unambiguous. If 2+ real interpretations lead to different files or effort, it isn't clear. |
-| "Asking wastes time" | One targeted question costs 10 seconds. Building the wrong fix costs a full redo. |
-| "I skimmed and found *a* plausible cause" | Skimming finds A pattern, not THE pattern. Check for the project's own obvious candidate before settling on the generic one. |
-| "I'll define success after I see what I built" | Post-hoc criteria bend to match the output. Define them first, from the complaint as stated. |
+> **Yêu cầu đã làm rõ:** one paragraph with the goal, where it happens (files, screens and endpoints by name), the constraints, and what stays out of scope.
+> **Xong khi:** a checkable finish line, taken from the user's own complaint.
+> **Giả định:** only the assumptions the user might want to change.
+
+Write it as a prompt the user could have sent, not as a plan of your steps. Include only what changes the work.
+
+## 3. Proceed, or ask one question
+
+- **The readings lead to the same work.** Proceed right after the block. The user corrects an assumption if it is wrong.
+- **The readings lead to different work** (different files, much more effort or risk, or a decision only the user can make). Don't start. Ask ONE question that separates the readings, with options and the recommended one first (AskUserQuestion when the options can be listed), and show the sharpened prompt for the recommended reading.
 
 ## Handoff mode
 
-If the sharpened result is meant for a *different* AI/session/agent (not yourself), the bar is higher: the output must be fully self-contained — exact file paths, decisions already made, what's explicitly out of scope, and a concrete success check. No "as discussed above" — the reader has no "above."
+When the sharpened prompt is for another agent or session, it must stand alone: exact paths, the decisions already made, what is out of scope, and how to check the result. The reader has no "above" to refer back to.
+
+## Gotchas
+
+- Short is not the same as vague. "Đổi tên `formatDate` thành `formatIsoDate` và sửa mọi chỗ gọi" is complete: act on it without a block.
+- Words run together or typed without diacritics ("làm lạiphần này") are typing, not ambiguity. Read through them.
+- Define "done" before building. A finish line written afterwards bends to fit whatever got built.
+- One question means one. Don't append a second ask ("and send me the repo path") to it. If the files can't be read, work from what the user described, and note that in the assumptions.
+- Prefer proceeding. When the recommended reading is the small, safe one and the others only add scope, state it as the assumption and start. Ask only when picking wrong would waste real work.