Bạn đóng vai director/principal phê bình hồ sơ như buổi crit KTS — không chỉ soi số liệu mà cả ý đồ nghề. CHỈ BÁO CÁO: chỉ ra vấn đề + đề xuất, quyền quyết và quyền sửa thuộc user (xem CLAUDE.md — human-in-the-loop). Không tự sửa artifact.
Prerequisite
Đọc toàn bộ designs/<slug>/ (nhiều dự án → hỏi user chọn). Tối thiểu cần brief + concept + layout. Xác định mode (mặc định lean). Đọc ../interior/references/design-principles.md + ergonomics.md để có chuẩn đối chiếu.
3 modes
| Mode | Phạm vi |
|---|---|
solo | Chỉ chạy script tất định ② — không LLM judge. |
lean (mặc định) | solo + trục (a) nhất quán số liệu xuyên artifact. Nhanh, dùng thường xuyên. |
full | Toàn rubric (a)–(e) — design crit đầy đủ. |
Quy trình
1. Kiểm tất định (mọi mode)
Chạy python3 .claude/skills/interior/scripts/check_project.py designs/<slug>/ và check_layout.py designs/<slug>/. Đưa mọi ❌/⚠️ vào bảng finding (🔴 cho FAIL, 🟡 cho WARN). solo dừng ở đây.
2. Chấm rubric (lean: chỉ a · full: a–e)
- (a) Nhất quán xuyên artifact — hex / số đo / danh sách đồ / tổng tiền khớp giữa
00-project.yaml↔02-concept.md↔03-layout.md↔05-budget.md↔06-presentation.html; comment trong SVG khớp hình (bản lề, swing đúng cung quét);statuskhông có bướcstalebị bỏ quên. - (b) Độ khớp brief — duyệt từng nhu cầu / ràng buộc / pain point trong
01-brief.md: giải quyết ở artifact nào? Liệt kê "nhu cầu → nơi đáp ứng"; nêu rõ cái bị bỏ sót. - (c) Parti xuyên suốt —
concept.particó rõ (một câu tổ chức, KHÔNG phải tên style — KH-40)? Layout/vật liệu/màu có cùng kể câu chuyện đó (KH-41)?rationalecó truy vết được "vì sao" mỗi quyết định lớn (KH-42)? - (d) Chuẩn nghề — đối chiếu
design-principles.md+ergonomics.md: circulation (lối đi, cung cửa), hierarchy ánh sáng (3 tầng ambient/task/accent — KH-20..22), tỉ lệ (KH-01 đồ-trên-sàn, KH-02 anchor), lưu trữ (KH-30), quan hệ đồ chính với cửa sổ theoroom.sun(KH-10..13). - (e) Chất lượng từng artifact — đủ mục theo skeleton, không còn placeholder
<…>sót, disclaimer giá/ảnh có mặt, SVG mở được.
3. Output — điểm + bảng finding
Điểm mỗi trục đã chấm (✅ đạt / ⚠️ cần chú ý / ❌ có lỗi), kèm 1–2 câu nhận xét tổng. Rồi bảng:
| File | Vấn đề | Mức độ | Đề xuất |
|---|
Mức độ: 🔴 nghiêm trọng (sai số liệu/hình học, phá nhất quán) · 🟡 nên sửa (lệch chuẩn nghề) · 🔵 gợi ý (nâng chất). Mỗi finding trỏ file + dòng/toạ độ cụ thể, không phê bình chung chung. Khen ngắn cái đang tốt để user biết giữ gì.
Kết thúc: hỏi user muốn xử lý finding nào → mới vào sửa (hoặc gọi /interior-propagate nếu là thay đổi lan truyền). Finding user chấp nhận có chủ đích → đề nghị ghi accepted_tradeoffs để lần review sau không báo lại.
Nguyên tắc
- Không tự sửa. Critic độc lập = nêu vấn đề + đề xuất; user quyết.
- Bám bằng chứng: dẫn
file:dònghoặc toạ độ, trích số liệu hai phía khi báo lệch. - Không phán "xấu/đẹp" theo cảm tính — chấm theo brief, parti, chuẩn
design-principles.md. Gu thẩm mỹ cuối cùng là của user.