@leejungkiin/awkit 1.7.1 → 1.7.4

package/skills/app-store-review-agent/references/rules/privacy/privacy_manifest.md

@@ -0,0 +1,84 @@
+# Rule: Missing Privacy Manifest
+- **Guideline**: 5.1.1 – Legal – Privacy (Spring 2024 requirement)
+- **Severity**: REJECTION
+- **Category**: privacy
+
+## What to Check
+Starting Spring 2024, apps must include a **Privacy Manifest** (`PrivacyInfo.xcprivacy`) if they use any of Apple's "Required Reason APIs". Apple will reject apps that use these APIs without declaring the reason.
+
+### Required Reason API Categories
+
+| Category | Common APIs | Example Reason Code |
+|----------|------------|-------------------|
+| **File Timestamp** | `NSFileCreationDate`, `NSFileModificationDate`, `stat()`, `getattrlist()` | `DDA9.1` – Display to user |
+| **User Defaults** | `UserDefaults` (NSUserDefaults) | `CA92.1` – App-specific data |
+| **System Boot Time** | `systemUptime`, `mach_absolute_time()` | `35F9.1` – Measure time intervals |
+| **Disk Space** | `volumeAvailableCapacityKey`, `statfs()` | `E174.1` – Check for writes |
+
+### What to Declare in the Manifest
+- **NSPrivacyTracking**: Whether the app uses data for tracking (true/false)
+- **NSPrivacyTrackingDomains**: List of tracking domains (if any)
+- **NSPrivacyCollectedDataTypes**: What data types are collected
+- **NSPrivacyAccessedAPITypes**: Required reason APIs used, with reason codes
+
+## How to Detect
+
+### Check for Privacy Manifest existence
+```bash
+# Look for PrivacyInfo.xcprivacy in the project
+find . -name "PrivacyInfo.xcprivacy" -not -path "./.build/*"
+```
+
+### Check for Required Reason API usage
+```bash
+# UserDefaults (most common)
+grep -rn "UserDefaults\|NSUserDefaults\|standardUserDefaults" --include="*.swift" --include="*.m" .
+
+# File Timestamps
+grep -rn "NSFileCreationDate\|NSFileModificationDate\|creationDate\|modificationDate" --include="*.swift" --include="*.m" .
+
+# System Boot Time
+grep -rn "systemUptime\|mach_absolute_time\|ProcessInfo.*systemUptime" --include="*.swift" --include="*.m" .
+
+# Disk Space
+grep -rn "volumeAvailableCapacity\|statfs\|statvfs" --include="*.swift" --include="*.m" .
+```
+
+### Check third-party SDK manifests
+Many popular SDKs (Firebase, Analytics, etc.) now bundle their own `PrivacyInfo.xcprivacy`. Ensure your app's manifest covers APIs used in **your own code**.
+
+## Resolution
+1. Create `PrivacyInfo.xcprivacy` in your Xcode project root
+2. Add it to your app target's "Copy Bundle Resources" build phase
+3. Declare all Required Reason APIs with appropriate reason codes
+4. For Flutter apps, place the manifest in `ios/Runner/PrivacyInfo.xcprivacy`
+
+### Minimal Example
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+    <key>NSPrivacyTracking</key>
+    <false/>
+    <key>NSPrivacyAccessedAPITypes</key>
+    <array>
+        <dict>
+            <key>NSPrivacyAccessedAPIType</key>
+            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
+            <key>NSPrivacyAccessedAPITypeReasons</key>
+            <array>
+                <string>CA92.1</string>
+            </array>
+        </dict>
+    </array>
+</dict>
+</plist>
+```
+
+## Example Rejection
+> Your app uses APIs that require a Privacy Manifest. Please add a PrivacyInfo.xcprivacy file to your app that includes the required reason codes for the APIs used by your app.
+>
+> The following APIs require reasons:
+> - NSPrivacyAccessedAPICategoryUserDefaults
+> - NSPrivacyAccessedAPICategoryFileTimestamp

package/skills/app-store-review-agent/references/rules/privacy/unnecessary_data.md

@@ -0,0 +1,60 @@
+# Rule: Requiring Unnecessary Personal Data
+- **Guideline**: 5.1.1 – Legal – Privacy – Data Collection and Storage
+- **Severity**: REJECTION
+- **Category**: privacy
+
+## What to Check
+Apps must only require personal information that is **directly relevant** to the app's core functionality. If information is useful but not essential, it must be **optional**.
+
+### Commonly Flagged Required Fields
+- **Phone number** — unless the app's core function requires calling/SMS
+- **Gender** — unless medically or fitness-relevant
+- **Marital status** — rarely relevant
+- **Date of birth** — unless age-gating is legally required
+- **Home address** — unless shipping or location-specific services are core
+
+### Context Matters
+- A fitness app may reasonably require gender (for calorie calculations)
+- A dating app may reasonably require age and gender
+- A shopping app should NOT require marital status
+- A note-taking app should NOT require phone number
+
+## How to Detect
+
+### Code Inspection
+```bash
+# Find registration/onboarding/profile forms
+grep -rn "phone\|gender\|marital\|birthdate\|date.of.birth\|address\|registration\|onboarding\|signup\|sign.up\|profile" --include="*.swift" --include="*.dart" .
+
+# Check if fields are marked as required vs optional
+grep -rn "required\|validator\|isRequired\|optional" --include="*.swift" --include="*.dart" .
+```
+
+### UI Inspection
+1. Run the app and complete the onboarding/registration flow
+2. For each personal data field, check:
+   - Is it required (blocks progress if empty)?
+   - Is it relevant to the app's core feature?
+3. Flag any required field that isn't directly relevant to what the app does
+
+## Resolution
+1. Make non-essential personal data fields **optional** (remove validation requirements)
+2. Add "Skip" or "Not now" options for optional profile information
+3. If collecting data for personalization, clearly explain why and make it opt-in
+4. Review the App Privacy label in App Store Connect to ensure it matches what you actually collect
+
+## Example Rejection
+> **Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage**
+>
+> Issue Description
+>
+> The app requires users to provide personal information that is not directly relevant to the app's core functionality.
+>
+> Apps should only require users to provide information that is necessary for the app to function. If information is useful for a non-essential feature, apps may request the information but make it optional.
+>
+> Next Steps
+>
+> Update the app to not require users to provide the following personal information:
+>
+> - Phone number
+> - Gender

package/skills/app-store-review-agent/references/rules/subscription/misleading_pricing.md

@@ -0,0 +1,63 @@
+# Rule: Misleading Subscription Pricing Display
+- **Guideline**: 3.1.2 – Business – Payments – Subscriptions
+- **Severity**: REJECTION
+- **Category**: subscription
+
+## What to Check
+The subscription purchase flow must display the **actual billed amount** as the most prominent pricing element. Calculated/derived pricing (e.g., "only $2.50/month" for an annual plan billed at $29.99/year) must be **subordinate** in:
+
+- Font size
+- Font weight
+- Color contrast
+- Position/layout
+
+### Common Violations
+- Showing "$2.50/mo" in large bold text while "$29.99/year" is in small gray text
+- Using a bright accent color for the calculated monthly price but muted text for the real billed amount
+- Placing the per-month breakdown above or more prominently than the actual charge
+- Free trial text overshadowing the post-trial billed price
+
+## How to Detect
+
+### Code Inspection
+```bash
+# Find subscription UI code
+grep -rn "paywall\|subscribe\|pricing\|subscription" --include="*.swift" --include="*.dart" .
+
+# Look for calculated pricing patterns
+grep -rn "perMonth\|per_month\|monthly.*price\|price.*month\|calculated\|divided" --include="*.swift" --include="*.dart" .
+```
+
+### Visual Inspection
+1. Run the app and navigate to the subscription purchase screen
+2. Compare the visual hierarchy of:
+   - The calculated price (per month/week breakdown)
+   - The actual billed amount (what Apple will charge)
+   - Free trial or introductory pricing text
+3. The **billed amount** must be the largest, boldest, most visible price
+
+### Checklist
+- [ ] Billed amount uses the largest font size among all pricing elements
+- [ ] Billed amount has the highest contrast color
+- [ ] Billed amount is positioned prominently (not buried below other pricing)
+- [ ] Calculated/broken-down pricing uses smaller, lighter text
+- [ ] Free trial terms do not overshadow the post-trial price
+
+## Resolution
+1. Make the total billed amount the most prominent pricing text
+2. Show calculated pricing (per month / per week) in smaller, subordinate text
+3. Ensure free trial duration is visible but does not overshadow the billing amount
+4. Follow [Apple HIG guidance for subscription purchase flows](https://developer.apple.com/design/human-interface-guidelines/in-app-purchase)
+
+## Example Rejection
+> **Guideline 3.1.2 - Business - Payments - Subscriptions**
+>
+> One or more auto-renewable subscriptions are marketed in the purchase flow in a way that may mislead or confuse users about the subscription terms or pricing. Specifically:
+>
+> - The auto-renewable subscription displays the monthly calculated pricing for the subscription more clearly and conspicuously than the billed amount.
+>
+> Next Steps
+>
+> To resolve this issue, it would be appropriate to:
+>
+> - Revise the auto-renewable subscription purchase flow to ensure that the billed amount is the most clear and conspicuous pricing element in the layout. Any other pricing elements, including free trial, introductory pricing, and calculated pricing information, must be displayed in a subordinate position and size to the total billed amount.

package/skills/app-store-review-agent/references/rules/subscription/missing_tos_pp.md

@@ -0,0 +1,54 @@
+# Rule: Missing Terms of Use and Privacy Policy for Subscriptions
+- **Guideline**: 3.1.2 – Business – Payments – Subscriptions
+- **Severity**: REJECTION
+- **Category**: subscription
+
+## What to Check
+The in-app subscription purchase flow and the app itself must include:
+
+1. **Title** of the auto-renewing subscription
+2. **Length** of subscription (e.g., 1 month, 1 year)
+3. **Price** of subscription (and price per unit if appropriate)
+4. **Functional link** to Privacy Policy
+5. **Functional link** to Terms of Use (EULA)
+
+And the App Store metadata must include:
+- Privacy Policy URL in the Privacy Policy field in App Store Connect
+- Terms of Use (EULA) link in either the app description or the EULA field
+
+## How to Detect
+
+### Check in-app subscription screens
+Search the codebase for subscription paywall / purchase views:
+```bash
+# Find subscription-related UI files
+grep -rn "subscribe\|paywall\|purchase\|StoreKit\|RevenueCat\|Superwall" --include="*.swift" --include="*.dart" .
+
+# Check if terms/privacy links exist in those files
+grep -rn "terms\|privacy\|eula\|TermsOfService\|PrivacyPolicy" --include="*.swift" --include="*.dart" .
+```
+
+### Check metadata descriptions
+```bash
+# Verify ToS/PP links in descriptions
+grep -i "terms\|privacy\|eula" ./metadata/*/description.txt
+```
+
+### Check App Store Connect
+- App Information → Privacy Policy URL field must not be empty
+- App Information → EULA field should have custom EULA or description should reference Apple's standard EULA
+
+## Resolution
+1. Add tappable Terms of Use and Privacy Policy links to every subscription paywall screen
+2. Add links to the app description in all locales
+3. Set the Privacy Policy URL field in App Store Connect
+4. If using a custom EULA, upload it in the EULA field
+
+## Example Rejection
+> **Guideline 3.1.2 - Business - Payments - Subscriptions**
+>
+> The submission did not include all the required information for apps offering auto-renewable subscriptions.
+>
+> The following information needs to be included in the App Store metadata:
+>
+> - A functional link to the Terms of Use (EULA). If you are using the standard Apple Terms of Use (EULA), include a link to the Terms of Use in the App Description. If you are using a custom EULA, add it in App Store Connect.

package/skills/awf-ponytail/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: awf-ponytail
+description: >-
+  Lazy senior dev mode. Enforces the simplest, shortest solution that works:
+  YAGNI, stdlib first, native platform features before dependencies, one line
+  before fifty. Checks .project-identity for automation.ponytailMode config.
+  Default: enabled=true, level=full.
+version: 1.0.0
+---
+
+# AWF Ponytail — Lazy Dev Mode
+
+You are a lazy senior developer. Lazy means efficient, not careless. You have
+seen every over-engineered codebase and been paged at 3am for one. The best
+code is the code never written.
+
+> Adapted from [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail) (MIT).
+> Reference copy: `backup/ponytail/`
+
+## Trigger Conditions
+
+**Auto-active skill** — Activates at session start based on `.project-identity`.
+
+**Check Configuration:**
+```
+config = read(".project-identity")
+ponytail = config?.automation?.ponytailMode
+enabled = ponytail?.enabled ?? true   // default ON
+level   = ponytail?.level ?? "full"   // default FULL
+```
+
+If `enabled` is `false`, this skill is **inactive**. Do not apply.
+
+## The Ladder
+
+Before writing ANY code, stop at the first rung that holds:
+
+1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
+2. **Stdlib does it?** Use the standard library.
+3. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
+4. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
+5. **Can it be one line?** One line.
+6. **Only then:** the minimum code that works.
+
+The ladder is a reflex, not a research project. Two rungs work → take the
+higher one and move on.
+
+## Rules
+
+- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
+- No boilerplate, no scaffolding "for later" — later can scaffold for itself.
+- Deletion over addition. Boring over clever — clever is what someone decodes at 3am.
+- Fewest files possible. Shortest working diff wins.
+- Complex request? Ship the lazy version and question it: "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Two stdlib options, same size? Take the one correct on edge cases. Lazy = less code, not flimsier algorithm.
+- Mark deliberate simplifications with a `ponytail:` comment. If the shortcut has a known ceiling, the comment names the ceiling and the upgrade path: `// ponytail: global lock, per-account locks if throughput matters`.
+
+## Intensity Levels
+
+| Level | Behavior |
+|-------|----------|
+| **lite** | Build what's asked, but name the lazier alternative in one line. User picks. |
+| **full** | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. **Default.** |
+| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement. |
+
+## When NOT to Be Lazy
+
+Never simplify away:
+- Input validation at trust boundaries
+- Error handling that prevents data loss
+- Security measures
+- Accessibility basics
+- Anything explicitly requested by the user
+
+User insists on the full version → build it, no re-arguing.
+
+Lazy code without its check is unfinished. Non-trivial logic leaves ONE
+runnable check behind (an `assert`-based self-check or one small test file).
+Trivial one-liners need no test — YAGNI applies to tests too.
+
+## Integration with AWKit Gates
+
+- **Gate 4 Phase B/C**: Apply the ladder before writing any implementation code.
+- **Gate 5 (Verification)**: Before commit, self-audit for over-engineering. If ≥10% lines can be cut while preserving logic and safety → refactor immediately.
+- **Mandatory Check-Then-Act**: Add to the `<thought>` checklist: "Ponytail ladder applied?"
+
+## Boundaries
+
+Ponytail governs **what you build**, not how you talk (Caveman handles prose).
+"stop ponytail" / "normal mode" from user → deactivate for the session.
+Level persists until changed or session end.

package/skills/awf-ponytail-review/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: awf-ponytail-review
+description: >-
+  Code review focused exclusively on over-engineering. Finds what to delete:
+  reinvented stdlib, unneeded dependencies, speculative abstractions, dead
+  flexibility. One line per finding. Use when user says "review for
+  over-engineering", "what can we delete", "simplify review", or invokes
+  /ponytail-review. Complements correctness-focused review — this one only
+  hunts complexity.
+version: 1.0.0
+---
+
+# AWF Ponytail Review
+
+Review diffs or directories for unnecessary complexity. One line per finding:
+location, what to cut, what replaces it. The diff's best outcome is getting shorter.
+
+> Adapted from [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail) (MIT).
+> Reference copy: `backup/ponytail/skills/ponytail-review/SKILL.md`
+
+## Trigger Conditions
+
+**Manual skill** — Activates when:
+- User invokes `/ponytail-review`
+- User says: "review for over-engineering", "what can we delete", "is this over-engineered?", "simplify review"
+- Gate 5 verification (if ponytailMode enabled)
+
+## Format
+
+`L<line>: <tag> <what>. <replacement>.`, or `<file>:L<line>: ...` for
+multi-file diffs.
+
+### Tags
+
+- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
+- `stdlib:` hand-rolled thing the standard library ships. Name the function.
+- `native:` dependency or code doing what the platform already does. Name the feature.
+- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
+- `shrink:` same logic, fewer lines. Show the shorter form.
+
+## Examples
+
+❌ "This EmailValidator class might be more complex than necessary, have you
+considered whether all these validation rules are needed at this stage?"
+
+✅ `L12-38: stdlib: 27-line validator class. "@" in email, 1 line, real validation is the confirmation mail.`
+
+✅ `L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.`
+
+✅ `repo.py:L88: yagni: AbstractRepository with one implementation. Inline it until a second one exists.`
+
+✅ `L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.`
+
+✅ `L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.`
+
+## Scoring
+
+End with the only metric that matters: `net: -<N> lines possible.`
+
+If there is nothing to cut, say `Lean already. Ship.` and stop.
+
+## Boundaries
+
+- Complexity only — correctness bugs, security holes, and performance go to a normal review pass, not this one.
+- A single smoke test or `assert`-based self-check is the ponytail minimum, not bloat — never flag it for deletion.
+- Does not apply the fixes, only lists them.
+- "stop ponytail-review" or "normal mode": revert to verbose review style.

package/skills/awf-session-restore/SKILL.md

@@ -61,11 +61,11 @@ symphony-enforcer      (Gate 2: Project → Brain → Task → Confirmation bloc
 ### Step 1: Fetch Project Identity (CHẠY ĐẦU TIÊN)
 
 ```bash
-cat .project-identity 2>/dev/null || echo "NO_PROJECT"
+awkit identity --json 2>/dev/null || echo "NO_PROJECT"
 ```
 
-**Nếu tìm thấy:** Extract `projectId` và `projectName` từ JSON.
-**Cache Mindful Config:** Extract `mindfulCheckpoint` và `mindfulCheckpointConfig` (defaults: enabled=true, threshold=3, scopeGuard=true, milestoneRest=true).
+**Nếu tìm thấy:** Extract `projectName` (và `projectId` nếu dự án có định nghĩa).
+**Cache Mindful Config:** Extract các cấu hình (defaults: enabled=true, threshold=3, scopeGuard=true, milestoneRest=true) từ JSON.
 **Nếu không:** Ghi nhận `raw mode` — các bước sau vẫn chạy nhưng không scope theo project. Mindful defaults vẫn ON.
 
 ### Step 2: Switch NeuralMemory Brain (CHẠY THỨ HAI)

package/skills/brainstorm-agent/SKILL.md

@@ -60,9 +60,16 @@ skip_if: Đang debug | Đang code cụ thể | .kiro/specs/ có requirements.md
 - Check existing BRIEF.md, active_plans.json
 - Set mode based on context
 
-### Phase 2: Idea Exploration (1 question at a time)
+### Phase 2: Idea Exploration & Behavioral Check (1 question at a time)
 - Hỏi **một câu mỗi lần** — không overwhelm
-- **CHỦ ĐỘNG khai thác & mở rộng** (Socratic questioning)
+- **CHỦ ĐỘNG khai thác & phản biện** (Socratic questioning + Hooked Model)
+- **Tâm lý học Hành vi & Mô hình Hooked (Dẫn dắt người dùng):**
+  - Trong `<thought>`, rà soát ý tưởng dựa trên 4 thành tố: **Trigger** (Kích hoạt), **Action** (Hành động), **Variable Reward** (Phần thưởng biến thiên), **Investment** (Sự đầu tư).
+  - Tự suy luận và đưa ra câu hỏi phản biện sâu sắc để giúp người dùng làm rõ:
+    - *Trigger:* Nỗi đau/Cảm xúc tiêu cực nào thúc đẩy người dùng sử dụng? (Internal Trigger) & Kích hoạt nào từ ngoài dẫn họ tới? (External Trigger)
+    - *Action:* Hành động đơn giản nhất để nhận phần thưởng là gì? Làm sao tối ưu hóa B = MAP (Motivation, Ability, Prompt)?
+    - *Variable Reward:* Phần thưởng có thỏa mãn nhu cầu nhưng vẫn tạo tò mò không? (Bộ lạc, Săn mồi, Bản thân)
+    - *Investment:* Người dùng đầu tư công sức/dữ liệu gì để tích lũy giá trị và "nạp đạn" cho trigger tiếp theo?
 - Active listening: "Em hiểu là anh muốn [X] để giải quyết [Y], đúng không?"
 
 ### Phase 3: Idea Expansion & Alternatives
@@ -100,6 +107,8 @@ never_do:
 
 always_do:
   - Tóm tắt lại ý hiểu trước khi đề xuất
+  - Luôn suy luận trong `<thought>` theo Mô hình Hooked và Tâm lý học Hành vi trước khi phản hồi
+  - Đề xuất các giải pháp tăng tính giữ chân (retention) và thiết lập thói quen cho người dùng
   - Đề xuất 2-3 hướng, không chỉ 1
   - Hỏi confirm trước khi output BRIEF
 ```

package/skills/brainstorm-agent/templates/brief-template.md

@@ -14,6 +14,14 @@
 ## 2. GIẢI PHÁP ĐỀ XUẤT
 [Hướng đi được chọn + lý do]
 
+## 2.5. THIẾT KẾ HÀNH VI (MÔ HÌNH HOOKED)
+- **Kích hoạt (Trigger):**
+  - *Internal (Bên trong):* [Cảm xúc tiêu cực/nhu cầu kích hoạt sử dụng]
+  - *External (Bên ngoài):* [Tác nhân bên ngoài đưa người dùng trở lại]
+- **Hành động (Action):** [Hành vi đơn giản nhất người dùng thực hiện để nhận phần thưởng & tối giản hóa ma sát]
+- **Phần thưởng biến thiên (Variable Reward):** [Phần thưởng tạo sự thỏa mãn và tò mò (Bộ lạc, Săn mồi, Bản thân)]
+- **Sự đầu tư (Investment):** [Người dùng đầu tư gì để tích lũy giá trị và kích hoạt trigger tiếp theo]
+
 ## 3. ĐỐI TƯỢNG SỬ DỤNG
 - **Primary:** [...]
 - **Secondary:** [...]

package/skills/claude-planner/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: claude-planner
+description: |
+  Gate 2 planning delegate via Claude Code CLI.
+  Handles preparation of context, calling the helper script, and graceful
+  fallback to the local model if Claude CLI is unavailable.
+metadata:
+  stage: core
+  version: "1.0"
+  tags: [gate, planning, architecture, multi-model]
+  requires: spec-gate
+agent: Architect
+trigger: conditional
+invocation-type: auto
+priority: 2
+---
+
+# Claude Planner Skill
+
+## Purpose
+Directs the AI agent to orchestrate the Gate 2 architecture/implementation planning by delegating it to Claude Opus via Claude CLI, with a strict, graceful fallback logic.
+
+## Usage Protocol
+
+### 1. Verify and Execute Claude CLI Planning
+When Gate 2 (Spec/Architecture Planning) triggers for MODERATE or COMPLEX tasks:
+1. Prepare the planning prompt file at `brain/<projectId>/plan_prompt.md`.
+2. Run the helper script to attempt Claude planning:
+   ```bash
+   node scripts/claude-plan.js --prompt-file brain/<projectId>/plan_prompt.md --output brain/<projectId>/implementation_plan.md
+   ```
+3. If the script succeeds (Exit code `0`), read `brain/<projectId>/implementation_plan.md` to review the plan and present it to the user.
+
+### 2. Graceful Fallback Protocol
+If the helper script fails (Exit code !== 0, e.g. code `127` for missing CLI, or `2` for unauthenticated CLI):
+1. **Do not crash or alert the user with command failures.**
+2. Immediately fallback to generating the `implementation_plan.md` using the local active model in the IDE.
+3. Follow the normal planning template from `templates/design-templates.md` and write it directly to `brain/<projectId>/implementation_plan.md`.
+
+## Planning Prompt Guidelines
+When writing `brain/<projectId>/plan_prompt.md`, ensure it contains:
+1. Target architecture files.
+2. The current `docs/specs/<feature>_spec.md` or `docs/BRIEF.md`.
+3. Project info from `.project-identity`.
+4. NeuralMemory relevant constraints.
+5. Symphony tasks.
+6. The target format instructions for `implementation_plan.md`.

package/skills/code-review/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: code-review
+description: Use when completing tasks, implementing features, or before merging. Dispatch structured code review with severity classification via Codex CLI.
+---
+
+<!-- ⚠️ SMART REVIEW AGENT — Intelligent routing for Security, Localization, Compliance, and Quality -->
+
+# Smart Code Review
+
+## Overview
+
+Review early, review often. Catch issues before they cascade.
+Antigravity uses `codex` CLI to perform deep, multi-file code reviews across specific domains (Security, Localization, Compliance, Quality). 
+
+**Core principle:** Actionable, domain-specific feedback via Multi-Agent Flow.
+
+## The Review Modules (Execution via Codex CLI)
+
+Thay vì tự đọc diff và đánh giá, Antigravity **BẮT BUỘC** gọi `codex` CLI để thực hiện Code Review nhằm mở rộng Context Window và sử dụng subagent chuyên dụng.
+Dưới đây là 5 Module Review Tự Động. Antigravity tự động map intent của User để chọn Module phù hợp:
+
+### 1. 🛡️ Security & Privacy Review (Thay thế `/audit`)
+**Dùng khi User yêu cầu:** *"review bảo mật", "check security", "kiểm tra an toàn"*
+
+```bash
+codex -p "Thực hiện Security & Privacy Review. Hãy quét khắt khe các điểm sau:
+1. Hardcoded API Keys/Secrets trong code hoặc file config.
+2. Dữ liệu PII (Personal Identifiable Information) có bị log ra console không (print, console.log).
+3. Lỗ hổng OWASP (SQL Injection, XSS, thiếu Rate Limiting, CORS/Headers lỏng lẻo).
+4. Kiểm tra việc sử dụng Secure Storage (Keychain/EncryptedSharedPreferences).
+5. Phân tích file Privacy Policy có khớp với dữ liệu thực tế thu thập không.
+Trả về báo cáo phân loại Critical/High/Low." --approval-mode auto
+```
+
+### 2. 🌐 Localization & UI Review
+**Dùng khi User yêu cầu:** *"review đa ngôn ngữ", "check hardcode string", "kiểm tra UI"*
+
+```bash
+codex -p "Thực hiện Localization Review. Quét các file UI (Views, Components):
+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).
+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.
+Liệt kê chi tiết tên file và số dòng vi phạm." --approval-mode auto
+```
+
+### 3. 🍏 Store Compliance Review
+**Dùng khi User yêu cầu:** *"review appstore", "check compliance", "chuẩn bị submit"*
+
+```bash
+codex -p "Thực hiện App Store / Play Store Compliance Review. Đánh giá:
+1. Info.plist / AndroidManifest: Các chuỗi giải thích quyền (NSCameraUsageDescription...) có đầy đủ ý nghĩa không.
+2. App Tracking Transparency (ATT): Đã cấu hình và gọi khi cần chưa.
+3. Background Modes: Có khai báo thừa thãi không.
+4. Kiểm tra mã nguồn có API riêng tư (Private APIs) hoặc code tải logic động trái phép không." --approval-mode auto
+```
+
+### 4. 🧠 Architecture & Logic Review
+**Dùng khi User yêu cầu:** *"review kiến trúc", "review logic", "code smell"*
+
+```bash
+codex -p "Thực hiện Architecture & Logic Review. Đánh giá:
+1. Vi phạm nguyên tắc SOLID và Clean Architecture (VD: View xử lý Business Logic).
+2. Code duplication (Lặp code) hoặc Hàm quá dài (>50 lines).
+3. Thiếu Error Handling trong các async function / API calls.
+4. Memory Leaks (Retain cycles, forgot to unsubscribe)." --approval-mode auto
+```
+
+### 5. ⚡ Auto Diff Review (Mặc định)
+**Dùng khi User yêu cầu:** *"review", "review diff", "check code vừa viết"* hoặc khi hoàn thành Task.
+
+```bash
+codex -p "Review các thay đổi hiện tại (git diff/staged). Đảm bảo code mới viết đáp ứng Spec, không phá vỡ logic cũ và tuân thủ Coding Convention của dự án. Nếu an toàn, hãy trả về LGTM (Looks Good To Me)." --approval-mode auto
+```
+
+---
+
+## Cách Xử Lý Output Từ Codex
+1. Fix 🔴 **Critical** issues NGAY LẬP TỨC. (VD: Lộ Key, API chưa chặn rate limit).
+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).
+3. Log 🟢 **Minor** issues để cấu trúc lại sau.
+4. Proceed nếu Subagent Codex báo "LGTM" hoặc không có issue nào nghiêm trọng.
+
+## Integration
+
+**Used by:**
+- `single-flow-task-execution` — Review sau mỗi task
+- `symphony-enforcer` — Review trước khi `symphony_complete_task`
+- Thay thế hoàn toàn quy trình thủ công của `/audit` workflow.