@leejungkiin/awkit 1.7.7 → 1.7.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/awk.js +169 -69
- package/core/GEMINI.md +8 -0
- package/core/GEMINI.md.bak +18 -5
- package/core/skill-runtime-manifest.json +1 -0
- package/package.json +1 -1
- package/scripts/exec-rtk.js +105 -10
- package/skills/CATALOG.md +1 -1
- package/skills/awf-caveman/SKILL.md +13 -1
- package/skills/code-review/SKILL.md +40 -68
- package/skills/review/SKILL.md +40 -68
- package/workflows/_uncategorized/generate-gui-assets.md +111 -0
- package/workflows/_uncategorized/hatch-pet.md +116 -0
- package/workflows/_uncategorized/office-hours.md +38 -0
- package/workflows/_uncategorized/plan-ceo-review.md +34 -0
- package/workflows/_uncategorized/plan-design-review.md +38 -0
- package/workflows/_uncategorized/plan-eng-review.md +43 -0
- package/workflows/quality/plan-ceo-review.md +34 -0
- package/workflows/quality/plan-design-review.md +38 -0
- package/workflows/quality/plan-eng-review.md +43 -0
- package/workflows/roles/office-hours.md +38 -0
|
@@ -1,87 +1,59 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: code-review
|
|
3
|
-
description: Use when completing tasks, implementing features, or before merging. Dispatch structured code review with severity classification
|
|
3
|
+
description: Use when completing tasks, implementing features, or before merging. Dispatch structured code review with severity classification.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
# Smart Code Review
|
|
6
|
+
# Smart Code Review v2.0 (GStack-Powered)
|
|
9
7
|
|
|
10
8
|
## Overview
|
|
9
|
+
Perform structured code reviews on modified files (using git diff against origin/main or staged changes) to catch issues before they are committed or merged.
|
|
10
|
+
Antigravity uses the `codex` CLI (or active LLM runner) to perform deep, multi-file code reviews across specific safety and quality domains.
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
Antigravity uses `codex` CLI to perform deep, multi-file code reviews across specific domains (Security, Localization, Compliance, Quality).
|
|
14
|
-
|
|
15
|
-
**Core principle:** Actionable, domain-specific feedback via Multi-Agent Flow.
|
|
16
|
-
|
|
17
|
-
## The Review Modules (Execution via Codex CLI)
|
|
12
|
+
## 📋 The Two-Pass Review Rubric
|
|
18
13
|
|
|
19
|
-
|
|
20
|
-
Dưới đây là 5 Module Review Tự Động. Antigravity tự động map intent của User để chọn Module phù hợp:
|
|
14
|
+
Reviews are divided into two distinct passes depending on severity:
|
|
21
15
|
|
|
22
|
-
### 1
|
|
23
|
-
**
|
|
16
|
+
### Pass 1 — CRITICAL (Highest Severity)
|
|
17
|
+
* **SQL & Data Safety:** String interpolation in SQL (require parameterized queries/prepared statements), TOCTOU race conditions (require atomic `WHERE` checks), and bypassing model validations for direct DB writes.
|
|
18
|
+
* **Race Conditions & Concurrency:** Read-check-write patterns without uniqueness constraints, find-or-create without unique DB indices, and status transitions that are not atomic.
|
|
19
|
+
* **LLM Output Trust Boundaries:** Ensure LLM-generated values are type/shape/format checked before saving to database, and external URLs generated by LLM are allowlisted.
|
|
20
|
+
* **Shell Injection:** Variable interpolation in shell execution commands (e.g. `subprocess` with `shell=True` or `exec`/`eval` without sandboxing). Use argument arrays instead.
|
|
21
|
+
* **Enum & Value Completeness:** When a new enum, status string, tier, or type constant is added, trace it through every switch, filter, or conditional block across the entire project. Ensure all consumers handle the new value.
|
|
24
22
|
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
Trả về báo cáo phân loại Critical/High/Low." --approval-mode auto
|
|
33
|
-
```
|
|
23
|
+
### Pass 2 — INFORMATIONAL (Lower Severity)
|
|
24
|
+
* **Async/Sync Mixing:** Running synchronous calls (blocking calls, file I/O, sync requests) inside async event loops.
|
|
25
|
+
* **Column/Field Name Safety:** Verify ORM query columns match actual database schemas.
|
|
26
|
+
* **LLM Prompt Issues:** 0-indexed lists in prompts (LLMs expect 1-indexed) or listing tools/capabilities that don't match the wired array.
|
|
27
|
+
* **Completeness Gaps:** Shortcut implementations where complete versions are achievable within 30 minutes, or missing test paths (negative paths, edge cases).
|
|
28
|
+
* **Time Window Safety:** Date-key lookups assuming 24h coverage without timezone normalization.
|
|
29
|
+
* **Type Coercion:** Values crossing language/JSON boundaries where types change (e.g. numeric vs string).
|
|
34
30
|
|
|
35
|
-
|
|
36
|
-
**Dùng khi User yêu cầu:** *"review đa ngôn ngữ", "check hardcode string", "kiểm tra UI"*
|
|
31
|
+
---
|
|
37
32
|
|
|
38
|
-
|
|
39
|
-
codex -p "Thực hiện Localization Review. Quét các file UI (Views, Components):
|
|
40
|
-
1. Tìm tất cả các string hiển thị cho người dùng bị hardcode mà chưa bọc qua hàm dịch (i18n, LocalizedStringKey, R.string).
|
|
41
|
-
2. Đối chiếu xem các key được gọi trong UI đã tồn tại trong file từ điển (en/vi) chưa.
|
|
42
|
-
Liệt kê chi tiết tên file và số dòng vi phạm." --approval-mode auto
|
|
43
|
-
```
|
|
33
|
+
## ⚡ The Fix-First Heuristic
|
|
44
34
|
|
|
45
|
-
|
|
46
|
-
**Dùng khi User yêu cầu:** *"review appstore", "check compliance", "chuẩn bị submit"*
|
|
35
|
+
When reviewing, classify findings into AUTO-FIX (applied automatically without prompting) or ASK (require user confirmation):
|
|
47
36
|
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
37
|
+
| AUTO-FIX (Apply without asking) | ASK (Needs user confirmation) |
|
|
38
|
+
| :--- | :--- |
|
|
39
|
+
| Dead code & unused variables | Security issues (auth, XSS, injection) |
|
|
40
|
+
| Missing eager loading (N+1 queries) | Race conditions & concurrency |
|
|
41
|
+
| Stale comments contradicting code | Design decisions |
|
|
42
|
+
| Magic numbers → named constants | Large fixes (>20 lines of code) |
|
|
43
|
+
| Missing basic input/regex validation | Enum & value completeness changes |
|
|
44
|
+
| Version/dependency mismatches | Anything changing user-visible behavior |
|
|
55
45
|
|
|
56
|
-
|
|
57
|
-
**Dùng khi User yêu cầu:** *"review kiến trúc", "review logic", "code smell"*
|
|
58
|
-
|
|
59
|
-
```bash
|
|
60
|
-
codex -p "Thực hiện Architecture & Logic Review. Đánh giá:
|
|
61
|
-
1. Vi phạm nguyên tắc SOLID và Clean Architecture (VD: View xử lý Business Logic).
|
|
62
|
-
2. Code duplication (Lặp code) hoặc Hàm quá dài (>50 lines).
|
|
63
|
-
3. Thiếu Error Handling trong các async function / API calls.
|
|
64
|
-
4. Memory Leaks (Retain cycles, forgot to unsubscribe)." --approval-mode auto
|
|
65
|
-
```
|
|
46
|
+
---
|
|
66
47
|
|
|
67
|
-
|
|
68
|
-
|
|
48
|
+
## 🚫 Harmless Noise Suppressions (DO NOT flag)
|
|
49
|
+
* Harmless redundancies that aid readability (e.g., `present?` vs `length > 0`).
|
|
50
|
+
* Harmless no-ops (e.g., `.reject` on an element never present in the array).
|
|
51
|
+
* Requests to add comments explaining "why" a threshold was chosen.
|
|
52
|
+
* Suggestions to write tighter assertions in test cases that are already covering the behavior.
|
|
53
|
+
* Anything already addressed in the diff.
|
|
69
54
|
|
|
55
|
+
## 🛠️ Execution via Codex CLI
|
|
56
|
+
Invoke the review module using the non-interactive Codex CLI or active model runner:
|
|
70
57
|
```bash
|
|
71
|
-
codex -p "
|
|
58
|
+
codex -p "Perform a GStack-style pre-landing review. Highlight Pass 1 (Critical) and Pass 2 (Informational) issues, then apply the Fix-First heuristic." --approval-mode auto
|
|
72
59
|
```
|
|
73
|
-
|
|
74
|
-
---
|
|
75
|
-
|
|
76
|
-
## Cách Xử Lý Output Từ Codex
|
|
77
|
-
1. Fix 🔴 **Critical** issues NGAY LẬP TỨC. (VD: Lộ Key, API chưa chặn rate limit).
|
|
78
|
-
2. Fix 🟡 **Important** issues trước khi kết thúc task hoặc chuyển sang Phase mới. (VD: Quên localize string).
|
|
79
|
-
3. Log 🟢 **Minor** issues để cấu trúc lại sau.
|
|
80
|
-
4. Proceed nếu Subagent Codex báo "LGTM" hoặc không có issue nào nghiêm trọng.
|
|
81
|
-
|
|
82
|
-
## Integration
|
|
83
|
-
|
|
84
|
-
**Used by:**
|
|
85
|
-
- `single-flow-task-execution` — Review sau mỗi task
|
|
86
|
-
- `symphony-enforcer` — Review trước khi `symphony_complete_task`
|
|
87
|
-
- Thay thế hoàn toàn quy trình thủ công của `/audit` workflow.
|
package/skills/review/SKILL.md
CHANGED
|
@@ -1,87 +1,59 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: review
|
|
3
|
-
description: Use when completing tasks, implementing features, or before merging. Dispatch structured code review with severity classification
|
|
3
|
+
description: Use when completing tasks, implementing features, or before merging. Dispatch structured code review with severity classification.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
# Smart Code Review
|
|
6
|
+
# Smart Code Review v2.0 (GStack-Powered)
|
|
9
7
|
|
|
10
8
|
## Overview
|
|
9
|
+
Perform structured code reviews on modified files (using git diff against origin/main or staged changes) to catch issues before they are committed or merged.
|
|
10
|
+
Antigravity uses the `codex` CLI (or active LLM runner) to perform deep, multi-file code reviews across specific safety and quality domains.
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
Antigravity uses `codex` CLI to perform deep, multi-file code reviews across specific domains (Security, Localization, Compliance, Quality).
|
|
14
|
-
|
|
15
|
-
**Core principle:** Actionable, domain-specific feedback via Multi-Agent Flow.
|
|
16
|
-
|
|
17
|
-
## The Review Modules (Execution via Codex CLI)
|
|
12
|
+
## 📋 The Two-Pass Review Rubric
|
|
18
13
|
|
|
19
|
-
|
|
20
|
-
Dưới đây là 5 Module Review Tự Động. Antigravity tự động map intent của User để chọn Module phù hợp:
|
|
14
|
+
Reviews are divided into two distinct passes depending on severity:
|
|
21
15
|
|
|
22
|
-
### 1
|
|
23
|
-
**
|
|
16
|
+
### Pass 1 — CRITICAL (Highest Severity)
|
|
17
|
+
* **SQL & Data Safety:** String interpolation in SQL (require parameterized queries/prepared statements), TOCTOU race conditions (require atomic `WHERE` checks), and bypassing model validations for direct DB writes.
|
|
18
|
+
* **Race Conditions & Concurrency:** Read-check-write patterns without uniqueness constraints, find-or-create without unique DB indices, and status transitions that are not atomic.
|
|
19
|
+
* **LLM Output Trust Boundaries:** Ensure LLM-generated values are type/shape/format checked before saving to database, and external URLs generated by LLM are allowlisted.
|
|
20
|
+
* **Shell Injection:** Variable interpolation in shell execution commands (e.g. `subprocess` with `shell=True` or `exec`/`eval` without sandboxing). Use argument arrays instead.
|
|
21
|
+
* **Enum & Value Completeness:** When a new enum, status string, tier, or type constant is added, trace it through every switch, filter, or conditional block across the entire project. Ensure all consumers handle the new value.
|
|
24
22
|
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
Trả về báo cáo phân loại Critical/High/Low." --approval-mode auto
|
|
33
|
-
```
|
|
23
|
+
### Pass 2 — INFORMATIONAL (Lower Severity)
|
|
24
|
+
* **Async/Sync Mixing:** Running synchronous calls (blocking calls, file I/O, sync requests) inside async event loops.
|
|
25
|
+
* **Column/Field Name Safety:** Verify ORM query columns match actual database schemas.
|
|
26
|
+
* **LLM Prompt Issues:** 0-indexed lists in prompts (LLMs expect 1-indexed) or listing tools/capabilities that don't match the wired array.
|
|
27
|
+
* **Completeness Gaps:** Shortcut implementations where complete versions are achievable within 30 minutes, or missing test paths (negative paths, edge cases).
|
|
28
|
+
* **Time Window Safety:** Date-key lookups assuming 24h coverage without timezone normalization.
|
|
29
|
+
* **Type Coercion:** Values crossing language/JSON boundaries where types change (e.g. numeric vs string).
|
|
34
30
|
|
|
35
|
-
|
|
36
|
-
**Dùng khi User yêu cầu:** *"review đa ngôn ngữ", "check hardcode string", "kiểm tra UI"*
|
|
31
|
+
---
|
|
37
32
|
|
|
38
|
-
|
|
39
|
-
codex -p "Thực hiện Localization Review. Quét các file UI (Views, Components):
|
|
40
|
-
1. Tìm tất cả các string hiển thị cho người dùng bị hardcode mà chưa bọc qua hàm dịch (i18n, LocalizedStringKey, R.string).
|
|
41
|
-
2. Đối chiếu xem các key được gọi trong UI đã tồn tại trong file từ điển (en/vi) chưa.
|
|
42
|
-
Liệt kê chi tiết tên file và số dòng vi phạm." --approval-mode auto
|
|
43
|
-
```
|
|
33
|
+
## ⚡ The Fix-First Heuristic
|
|
44
34
|
|
|
45
|
-
|
|
46
|
-
**Dùng khi User yêu cầu:** *"review appstore", "check compliance", "chuẩn bị submit"*
|
|
35
|
+
When reviewing, classify findings into AUTO-FIX (applied automatically without prompting) or ASK (require user confirmation):
|
|
47
36
|
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
37
|
+
| AUTO-FIX (Apply without asking) | ASK (Needs user confirmation) |
|
|
38
|
+
| :--- | :--- |
|
|
39
|
+
| Dead code & unused variables | Security issues (auth, XSS, injection) |
|
|
40
|
+
| Missing eager loading (N+1 queries) | Race conditions & concurrency |
|
|
41
|
+
| Stale comments contradicting code | Design decisions |
|
|
42
|
+
| Magic numbers → named constants | Large fixes (>20 lines of code) |
|
|
43
|
+
| Missing basic input/regex validation | Enum & value completeness changes |
|
|
44
|
+
| Version/dependency mismatches | Anything changing user-visible behavior |
|
|
55
45
|
|
|
56
|
-
|
|
57
|
-
**Dùng khi User yêu cầu:** *"review kiến trúc", "review logic", "code smell"*
|
|
58
|
-
|
|
59
|
-
```bash
|
|
60
|
-
codex -p "Thực hiện Architecture & Logic Review. Đánh giá:
|
|
61
|
-
1. Vi phạm nguyên tắc SOLID và Clean Architecture (VD: View xử lý Business Logic).
|
|
62
|
-
2. Code duplication (Lặp code) hoặc Hàm quá dài (>50 lines).
|
|
63
|
-
3. Thiếu Error Handling trong các async function / API calls.
|
|
64
|
-
4. Memory Leaks (Retain cycles, forgot to unsubscribe)." --approval-mode auto
|
|
65
|
-
```
|
|
46
|
+
---
|
|
66
47
|
|
|
67
|
-
|
|
68
|
-
|
|
48
|
+
## 🚫 Harmless Noise Suppressions (DO NOT flag)
|
|
49
|
+
* Harmless redundancies that aid readability (e.g., `present?` vs `length > 0`).
|
|
50
|
+
* Harmless no-ops (e.g., `.reject` on an element never present in the array).
|
|
51
|
+
* Requests to add comments explaining "why" a threshold was chosen.
|
|
52
|
+
* Suggestions to write tighter assertions in test cases that are already covering the behavior.
|
|
53
|
+
* Anything already addressed in the active diff.
|
|
69
54
|
|
|
55
|
+
## 🛠️ Execution via Codex CLI
|
|
56
|
+
Invoke the review module using the non-interactive Codex CLI or active model runner:
|
|
70
57
|
```bash
|
|
71
|
-
codex -p "
|
|
58
|
+
codex -p "Perform a GStack-style pre-landing review. Highlight Pass 1 (Critical) and Pass 2 (Informational) issues, then apply the Fix-First heuristic." --approval-mode auto
|
|
72
59
|
```
|
|
73
|
-
|
|
74
|
-
---
|
|
75
|
-
|
|
76
|
-
## Cách Xử Lý Output Từ Codex
|
|
77
|
-
1. Fix 🔴 **Critical** issues NGAY LẬP TỨC. (VD: Lộ Key, API chưa chặn rate limit).
|
|
78
|
-
2. Fix 🟡 **Important** issues trước khi kết thúc task hoặc chuyển sang Phase mới. (VD: Quên localize string).
|
|
79
|
-
3. Log 🟢 **Minor** issues để cấu trúc lại sau.
|
|
80
|
-
4. Proceed nếu Subagent Codex báo "LGTM" hoặc không có issue nào nghiêm trọng.
|
|
81
|
-
|
|
82
|
-
## Integration
|
|
83
|
-
|
|
84
|
-
**Used by:**
|
|
85
|
-
- `single-flow-task-execution` — Review sau mỗi task
|
|
86
|
-
- `symphony-enforcer` — Review trước khi `symphony_complete_task`
|
|
87
|
-
- Thay thế hoàn toàn quy trình thủ công của `/audit` workflow.
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 🎨 GUI Assets Workflow — Quy trình tạo bộ icon, nút bấm, HUD, và ghép atlas GUI đồng bộ chất lượng cao
|
|
3
|
+
alwaysApply: false
|
|
4
|
+
category: workflow
|
|
5
|
+
priority: medium
|
|
6
|
+
---
|
|
7
|
+
triggers:
|
|
8
|
+
- "keywords: generate gui assets, gui icons, app icon set, icon atlas, ui icon pack"
|
|
9
|
+
- "context: UI assets creation, icon generation, atlas assembly"
|
|
10
|
+
version: 1.0.0
|
|
11
|
+
track:
|
|
12
|
+
- quick
|
|
13
|
+
- method
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
# /generate-gui-assets — GUI Asset Pack Generation Workflow
|
|
17
|
+
|
|
18
|
+
Quy trình này hướng dẫn cách lập kế hoạch, tạo hàng loạt và hậu kỳ xử lý bộ GUI assets (nút, icon, status badges, HUD...) đồng bộ phong cách trên một canvas/atlas đồng nhất.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 📋 Chuẩn Bị & Chọn Canvas Grid
|
|
23
|
+
|
|
24
|
+
Trước khi khởi chạy, xác định tổng lượng icon cần tạo để chọn kích thước lưới thích hợp. Lưới đồng nhất giúp AI căn giữa tốt và cho phép cắt ảnh tự động chính xác:
|
|
25
|
+
|
|
26
|
+
- **8x6** (48 slots): Lượng icon lớn nhất, tối ưu chi phí sau khi style đã được duyệt.
|
|
27
|
+
- **6x6** (36 slots): Canvas vuông, thoáng.
|
|
28
|
+
- **4x4** (16 slots): Lựa chọn ưu tiên chất lượng và độ tách biệt cao.
|
|
29
|
+
- **3x3** (9 slots): Phù hợp chạy thử (Preview) hoặc precision fallback.
|
|
30
|
+
|
|
31
|
+
Sử dụng tool gợi ý lưới:
|
|
32
|
+
```bash
|
|
33
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/suggest_grid_options.py \
|
|
34
|
+
--icon-count <lượng_icon> \
|
|
35
|
+
--strategy throughput
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## ⚡ Các Bước Thực Hiện
|
|
41
|
+
|
|
42
|
+
### Bước 1: Chạy Thử Tạo Phong Cách (Preview Phase)
|
|
43
|
+
Luôn khởi chạy một pack nhỏ (Preview) để duyệt phong cách hình ảnh trước khi tạo hàng loạt (Bulk):
|
|
44
|
+
```bash
|
|
45
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/prepare_gui_asset_run.py \
|
|
46
|
+
--run-id gui-v1-preview \
|
|
47
|
+
--output-root "assets/ui/generated" \
|
|
48
|
+
--phase preview \
|
|
49
|
+
--style-notes "cozy mobile wellness garden icons, crisp rounded vector style, soft gradient" \
|
|
50
|
+
--pack "ui_weather_core:3x3:sun,sunCloud,cloud,rain,wind,hot,mild,good,bad"
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
### Bước 2: Sinh Ảnh Preview & Nhận Phản Hồi
|
|
54
|
+
- Đọc file prompt tại `assets/ui/generated/gui-v1-preview/prompts/`.
|
|
55
|
+
- Thực thi `$imagegen` để tạo ảnh atlas thô. Save ảnh vào `raw/` và ghi nhận provenance.
|
|
56
|
+
- Tạo contact sheet để xem trước và QA:
|
|
57
|
+
```bash
|
|
58
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/build_gui_contact_sheet.py \
|
|
59
|
+
--run-dir "assets/ui/generated/gui-v1-preview"
|
|
60
|
+
```
|
|
61
|
+
*(Trong Goal Mode, bước duyệt này sẽ tự động thông qua).*
|
|
62
|
+
|
|
63
|
+
### Bước 3: Tạo Hàng Loạt (Bulk Phase)
|
|
64
|
+
Sau khi style được chấp thuận, khóa ngôn ngữ mô tả style lại và khởi chạy bulk run cho các pack còn lại:
|
|
65
|
+
```bash
|
|
66
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/prepare_gui_asset_run.py \
|
|
67
|
+
--run-id gui-v1-bulk \
|
|
68
|
+
--output-root "assets/ui/generated" \
|
|
69
|
+
--phase bulk \
|
|
70
|
+
--style-notes "<approved preview style notes>" \
|
|
71
|
+
--pack "ui_nav:4x3:home,garden,profile,settings,search,back,next,add,close,alert" \
|
|
72
|
+
--pack "ui_health:4x3:heart,water,sleep,steps,mood,warning,aid,trend"
|
|
73
|
+
```
|
|
74
|
+
- Chạy sinh ảnh hàng loạt qua `$imagegen` và record kết quả.
|
|
75
|
+
- Xác thực catalog:
|
|
76
|
+
```bash
|
|
77
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/validate_gui_catalog.py \
|
|
78
|
+
--run-dir "assets/ui/generated/gui-v1-bulk"
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Bước 4: Tách Icon & Khử Viền Màu Nền (Edge Cleanup)
|
|
82
|
+
Khi đã crop và phân tách các icon thành file ảnh PNG có alpha channel, chạy công cụ khử viền màu nền (thường là màu hồng `#FF00FF` hoặc xanh lá `#00FF00` được dùng làm chroma-key):
|
|
83
|
+
```bash
|
|
84
|
+
# 1. Chạy dry-run kiểm tra
|
|
85
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/clean_chroma_edges.py \
|
|
86
|
+
"assets/ui/generated/gui-v1-bulk/final/icons" --edge-despill
|
|
87
|
+
|
|
88
|
+
# 2. Áp dụng làm sạch
|
|
89
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/clean_chroma_edges.py \
|
|
90
|
+
"assets/ui/generated/gui-v1-bulk/final/icons" --edge-despill --apply
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Bước 5: Đưa Vào Dự Án (Promote)
|
|
94
|
+
Sao chép các icon sạch và manifest sang thư mục chính của dự án:
|
|
95
|
+
```bash
|
|
96
|
+
python ~/.gemini/antigravity/skills/generate-gui-assets/scripts/copy_approved_icons.py \
|
|
97
|
+
--source-dir "assets/ui/generated/gui-v1-bulk/final/icons" \
|
|
98
|
+
--run-dir "assets/ui/generated/gui-v1-bulk" \
|
|
99
|
+
--mapping "assets/ui/generated/gui-v1-bulk/catalog.json"
|
|
100
|
+
```
|
|
101
|
+
Đưa các icon đã phân loại vào `assets/ui/icons/` và dọn dẹp các thư mục staging run.
|
|
102
|
+
|
|
103
|
+
---
|
|
104
|
+
|
|
105
|
+
## 🔍 QA Checklist
|
|
106
|
+
|
|
107
|
+
- [ ] Catalog.json hợp lệ và chứa đủ thông tin nguồn gốc.
|
|
108
|
+
- [ ] Không sử dụng shadow rời, glow loang lổ bên ngoài nét vẽ của icon.
|
|
109
|
+
- [ ] Mọi icon căn giữa tốt, không chạm viền cell, không bị cắt cụt.
|
|
110
|
+
- [ ] Nền trong suốt hoàn toàn, không bám viền màu nền cũ khi hiển thị trên cả nền sáng và tối.
|
|
111
|
+
- [ ] Code ứng dụng tham chiếu đúng đường dẫn canonical (`assets/ui/...`), không trỏ tới run staging.
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 🐣 Hatch Pet Workflow — Quy trình tạo và đóng gói Codex Pet động từ ý tưởng hoặc hình ảnh
|
|
3
|
+
alwaysApply: false
|
|
4
|
+
category: workflow
|
|
5
|
+
priority: medium
|
|
6
|
+
---
|
|
7
|
+
triggers:
|
|
8
|
+
- "keywords: hatch pet, create pet, custom pet, pet spritesheet, animated pet"
|
|
9
|
+
- "context: pet creation, mascot animation, pet bundle"
|
|
10
|
+
version: 1.0.0
|
|
11
|
+
track:
|
|
12
|
+
- quick
|
|
13
|
+
- method
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
# /hatch-pet — Animated Companion Hatching Workflow
|
|
17
|
+
|
|
18
|
+
Quy trình này giúp bạn (hoặc AI) tự động hóa việc tạo một Codex Pet động (spritesheet 8x9) từ ý tưởng, ảnh tham chiếu hoặc grounding images.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 📋 Hướng Dẫn Chuẩn Bị
|
|
23
|
+
|
|
24
|
+
1. **Thông tin cơ bản**:
|
|
25
|
+
- **Tên Pet** (Name): Chọn tên ngắn gọn (ví dụ: `Dewey`, `BSOD`).
|
|
26
|
+
- **Mô tả** (Description): Một câu mô tả tính cách.
|
|
27
|
+
- **Chroma Key**: Màu nền tách (mặc định: `#00FF00` hoặc `#FF00FF`).
|
|
28
|
+
- **Mẫu Thiết Kế**: Phong cách Vector 2D, nét vẽ viền đen dày, bóng đổ phẳng (Cel-shading).
|
|
29
|
+
|
|
30
|
+
2. **Folder Chạy Thử**:
|
|
31
|
+
- Mọi tiến trình chạy sẽ được lưu trữ tại một thư mục tạm thời (staging run), ví dụ: `assets/pets/runs/<pet-name>`.
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## ⚡ Các Bước Thực Hiện
|
|
36
|
+
|
|
37
|
+
### Bước 1: Chuẩn Bị Run Folder & Manifest
|
|
38
|
+
Khởi tạo run folder và tạo danh sách các frame cần sinh (base và các trạng thái động như `idle`, `jumping`, `running-right`, `running-left`, `waving`, `failed`, `review`, `sleeping`, `eating`):
|
|
39
|
+
```bash
|
|
40
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/prepare_pet_run.py \
|
|
41
|
+
--pet-name "<PetName>" \
|
|
42
|
+
--description "<One sentence description>" \
|
|
43
|
+
--reference "/path/to/reference.png" \
|
|
44
|
+
--output-dir "assets/pets/runs/<pet-name>" \
|
|
45
|
+
--pet-notes "<stability notes>" \
|
|
46
|
+
--style-notes "smooth vector-2d, digital chibi mascot, bold outline, cel-shading"
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### Bước 2: Sinh Ảnh Base (Mẫu)
|
|
50
|
+
AI sẽ sử dụng file prompt được sinh ra tại `assets/pets/runs/<pet-name>/prompts/base.txt` kết hợp công cụ `$imagegen` để tạo ảnh mẫu ban đầu.
|
|
51
|
+
Sau khi ảnh mẫu được sinh, record kết quả:
|
|
52
|
+
```bash
|
|
53
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/record_imagegen_result.py \
|
|
54
|
+
--run-dir "assets/pets/runs/<pet-name>" \
|
|
55
|
+
--job-id base \
|
|
56
|
+
--source "/path/to/generated-base.png"
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
### Bước 3: Sinh Các Dãy Trạng Thái Động (Row Strips)
|
|
60
|
+
Với mỗi trạng thái động còn lại, AI chạy subagents song song sử dụng hướng dẫn layout guide và file prompt mẫu tương ứng. Sau khi nhận được ảnh strip thô từ subagent:
|
|
61
|
+
```bash
|
|
62
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/record_imagegen_result.py \
|
|
63
|
+
--run-dir "assets/pets/runs/<pet-name>" \
|
|
64
|
+
--job-id <state-id> \
|
|
65
|
+
--source "/path/to/generated-strip.png"
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
*Mẹo*: Với `running-left`, nếu pet có tính đối xứng cao, có thể tạo nhanh bằng cách lật gương từ `running-right`:
|
|
69
|
+
```bash
|
|
70
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/derive_running_left_from_running_right.py \
|
|
71
|
+
--run-dir "assets/pets/runs/<pet-name>" \
|
|
72
|
+
--confirm-appropriate-mirror \
|
|
73
|
+
--decision-note "Pet is symmetrical and has no text/directional lighting"
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
### Bước 4: Ghép Ảnh Atlas & Validate
|
|
77
|
+
Sau khi tất cả trạng thái đã được record, tiến hành trích xuất frame nhỏ (`192x208`), ghép thành atlas tổng hợp (`1536x1872`), validate hình học và tạo video preview QA:
|
|
78
|
+
```bash
|
|
79
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/finalize_pet_run.py \
|
|
80
|
+
--run-dir "assets/pets/runs/<pet-name>"
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### Bước 5: Khử Viền Màu Nền (Chroma Edge Despill)
|
|
84
|
+
Nếu ảnh spritesheet xuất hiện viền hồng hoặc xanh lá (fringe) do tách nền tự động, thực hiện chạy công cụ khử viền:
|
|
85
|
+
```bash
|
|
86
|
+
# 1. Chạy dry-run kiểm tra số lượng file
|
|
87
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/clean_chroma_edges.py \
|
|
88
|
+
"assets/pets/runs/<pet-name>/frames" --edge-despill
|
|
89
|
+
|
|
90
|
+
# 2. Áp dụng sửa đổi trực tiếp lên các frame
|
|
91
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/clean_chroma_edges.py \
|
|
92
|
+
"assets/pets/runs/<pet-name>/frames" --edge-despill --apply
|
|
93
|
+
|
|
94
|
+
# 3. Ghép lại Atlas từ các frame đã làm sạch
|
|
95
|
+
python ~/.gemini/antigravity/skills/hatch-pet/scripts/compose_atlas.py \
|
|
96
|
+
--frames-root "assets/pets/runs/<pet-name>/frames" \
|
|
97
|
+
--output "assets/pets/runs/<pet-name>/final/spritesheet.png" \
|
|
98
|
+
--webp-output "assets/pets/runs/<pet-name>/final/spritesheet.webp"
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
### Bước 6: Đóng Gói (Package & Promote)
|
|
102
|
+
Chuyển pet đã được kiểm duyệt và làm sạch vào thư mục chính thức của ứng dụng:
|
|
103
|
+
- Sao chép `spritesheet.webp` và `pet.json` sang `assets/pets/<pet-slug>/`
|
|
104
|
+
- Cập nhật file manifest của game/app.
|
|
105
|
+
- Xóa dọn dẹp các thư mục staging run tạm để giữ sạch repository.
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## 🔍 QA Checklist
|
|
110
|
+
|
|
111
|
+
- [ ] Spritesheet có kích thước chuẩn `1536x1872`, định dạng WebP/PNG có alpha channel.
|
|
112
|
+
- [ ] Các cell trống trong grid phải hoàn toàn trong suốt.
|
|
113
|
+
- [ ] Nét vẽ, màu sắc, chi tiết của pet đồng nhất trên tất cả 9 hàng trạng thái.
|
|
114
|
+
- [ ] Video preview trong `qa/videos/*.mp4` chạy mượt mà, không bị rung giật hoặc lệch trục.
|
|
115
|
+
- [ ] Không chứa các hiệu ứng lơ lửng, shadow tách rời hay bụi mù xung quanh.
|
|
116
|
+
- [ ] Không có viền màu xanh lá hoặc hồng trên nền tối (test qua contact sheet).
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 💡 YC Office Hours — Thử thách ý tưởng sản phẩm và tối giản hóa phạm vi (MVP).
|
|
3
|
+
alwaysApply: false
|
|
4
|
+
priority: "high"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# YC Office Hours Workflow
|
|
8
|
+
|
|
9
|
+
## 🎯 Role Purpose
|
|
10
|
+
Act as a YC Partner/Product Advisor. Your goal is to pressure-test the premise of the product, challenge assumptions, find the true value, and ruthlessly cut scope to define a minimal, high-impact V1 (MVP).
|
|
11
|
+
|
|
12
|
+
## 📋 When to Activate
|
|
13
|
+
- When the user starts with a new product idea, draft, or epic.
|
|
14
|
+
- When you hear phrases like "I want to build...", "What should I do next?", or when starting G1 (Brainstorm).
|
|
15
|
+
- Trigger command: `/office-hours`
|
|
16
|
+
|
|
17
|
+
## 🛠️ Workflow Steps
|
|
18
|
+
|
|
19
|
+
### 1. The Core Questions (Founder Mode)
|
|
20
|
+
Ask the user the 3 fundamental YC questions:
|
|
21
|
+
1. **What are you building?** (Describe the product in one simple sentence, no buzzwords).
|
|
22
|
+
2. **Who needs this the most right now?** (Identify the target user/early adopter).
|
|
23
|
+
3. **What is the simplest way to prove they need it?** (Define the MVP).
|
|
24
|
+
|
|
25
|
+
### 2. Ambition & Pressure Testing
|
|
26
|
+
- Challenge assumptions: "Why does it have to be this complex? Can we solve this with static HTML/simple local storage first?"
|
|
27
|
+
- Identify the "10-Star Experience": If money/time were no object, what does a magical experience look like for the user? Now, how do we capture 10% of that magic with 1% of the code?
|
|
28
|
+
|
|
29
|
+
### 3. Ruthless Scope Trimming (YAGNI)
|
|
30
|
+
- Place features into:
|
|
31
|
+
- **Must-Have (V1 Core)**: The single flow that delivers the magic.
|
|
32
|
+
- **Deferred (V2/P2)**: Everything else (multi-user auth, fancy database persistence, complex settings, animations, social sharing).
|
|
33
|
+
- Ensure the user explicitly approves the V1 scope before writing any specs.
|
|
34
|
+
|
|
35
|
+
## 🗣️ Office Hours Persona Guidelines
|
|
36
|
+
- Be direct, pragmatic, and highly collaborative.
|
|
37
|
+
- Push back against "boilerplate" ideas or feature bloat.
|
|
38
|
+
- Keep the discussion centered on the user value and speed-to-market.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 👑 Đánh giá lập kế hoạch dưới vai trò CEO để định vị sản phẩm xuất sắc.
|
|
3
|
+
alwaysApply: false
|
|
4
|
+
priority: "high"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Plan CEO Review Workflow
|
|
8
|
+
|
|
9
|
+
## 🎯 Role Purpose
|
|
10
|
+
Act as the CEO/Founder. Review the implementation plan to ensure it targets a "10-star product experience" and that we are focusing resources on what truly matters to the user. Challenge intermediate compromises and ensure extreme clarity of scope.
|
|
11
|
+
|
|
12
|
+
## 📋 When to Activate
|
|
13
|
+
- When a new draft specification or planning artifact is generated (Gate 1.5/2).
|
|
14
|
+
- When asked to "think bigger", "reread plan", "expand scope", or "strategy review".
|
|
15
|
+
- Trigger command: `/plan-ceo-review`
|
|
16
|
+
|
|
17
|
+
## 🛠️ Workflow Steps
|
|
18
|
+
|
|
19
|
+
### 1. Select the Review Mode
|
|
20
|
+
Select one of the following modes based on the project stage:
|
|
21
|
+
- **SCOPE EXPANSION**: Dream big. Add features that create a 10-star magical product experience.
|
|
22
|
+
- **SELECTIVE EXPANSION**: Hold the main scope, but cherry-pick 1 or 2 small visual/interaction expansions for high user delight.
|
|
23
|
+
- **HOLD SCOPE**: Strictly lock the scope. Maximum rigor on V1/MVP boundaries.
|
|
24
|
+
- **SCOPE REDUCTION**: Strip the plan to its absolute bare essentials. Cut out everything that is not critical path.
|
|
25
|
+
|
|
26
|
+
### 2. The 10-Star Experience Assessment
|
|
27
|
+
- Audit the current plan's features. Rate the plan's user value from 0 to 10.
|
|
28
|
+
- Describe what a "10-star experience" would look like for this specific feature.
|
|
29
|
+
- Highlight the gap between the current plan and the 10-star design, and suggest high-leverage adjustments.
|
|
30
|
+
|
|
31
|
+
### 3. Scope Scrutiny
|
|
32
|
+
- Identify any "future-proofing" boilerplate (e.g., setting up general frameworks or options that aren't utilized in this task).
|
|
33
|
+
- Challenge any dependencies or architectures that add complexity without user value.
|
|
34
|
+
- Mark deferred items clearly as P2/Future work.
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 🎨 Đánh giá thiết kế giao diện UI/UX và chấm điểm chất lượng thiết kế.
|
|
3
|
+
alwaysApply: false
|
|
4
|
+
priority: "high"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Plan Design Review Workflow
|
|
8
|
+
|
|
9
|
+
## 🎯 Role Purpose
|
|
10
|
+
Act as the Principal Product Designer. Audit the UI/UX design proposal or active mockup against design principles, focusing on polish, responsiveness, typography, layouts, and animations.
|
|
11
|
+
|
|
12
|
+
## 📋 When to Activate
|
|
13
|
+
- Prior to implementing frontend code (Gate 2.5 / Visual Design Gate).
|
|
14
|
+
- When asked to "design review", "audit UI", or "check layout".
|
|
15
|
+
- Trigger command: `/plan-design-review`
|
|
16
|
+
|
|
17
|
+
## 🛠️ Workflow Steps
|
|
18
|
+
|
|
19
|
+
### 1. Dimension Scoring (0 to 10)
|
|
20
|
+
Rate the design proposal from 0 to 10 across these key dimensions:
|
|
21
|
+
1. **Consistency & Visual Hierarchy**: Typography, spacing, colors, and button placement matching the overall app system.
|
|
22
|
+
2. **Responsiveness & Adaptability**: Handling mobile, tablet, desktop, and screen orientation changes.
|
|
23
|
+
3. **Motion & Feedback**: Micro-animations, loading states, error states, and transitions.
|
|
24
|
+
4. **Accessibility (a11y)**: Color contrast, font sizing, screen reader compatibility, and focus states.
|
|
25
|
+
|
|
26
|
+
For each dimension, describe:
|
|
27
|
+
- Current state
|
|
28
|
+
- Score (0-10)
|
|
29
|
+
- **What a "10" looks like** for this specific feature
|
|
30
|
+
- Recommended fixes to reach a 10
|
|
31
|
+
|
|
32
|
+
### 2. Apple HIG / Material Design Alignment
|
|
33
|
+
- Check visual assets, margins, safety areas (notch/bottom indicators), and navigation hierarchies.
|
|
34
|
+
- Ensure all interactive elements have sufficient tap targets (minimum 44x44 points/dp).
|
|
35
|
+
|
|
36
|
+
### 3. Grid and Asset Audit
|
|
37
|
+
- Ensure layout utilizes a consistent grid layout (e.g. 8px system).
|
|
38
|
+
- Check that all required icons, companion sprites, buttons, or eggs are identified. Ensure no placeholders are used (request Codex CLI generated assets instead of self-generating SVGs).
|