@leejungkiin/awkit 1.1.4 → 1.1.6

package/VERSION

@@ -1 +1 @@
-1.1.1
+1.1.6

package/bin/awk.js

@@ -274,40 +274,16 @@ function syncGeminiMd() {
 // ─── Commands ────────────────────────────────────────────────────────────────
 
 /**
- * Ensure Symphony is available. Install via Homebrew if missing.
- * Returns true if bd is available after the call.
+ * Check if Symphony is available.
  */
-function installSymphony({ silent = false } = {}) {
-    // Check if bd already installed
+function checkSymphony({ silent = false } = {}) {
     try {
-        execSync('which bd', { stdio: 'ignore' });
-        if (!silent) ok('Symphony already installed');
+        execSync('which symphony', { stdio: 'ignore' });
+        if (!silent) ok('Symphony CLI is installed');
         return true;
-    } catch (_) { /* not installed */ }
-
-    if (!silent) info('Symphony not found — installing via Homebrew...');
-
-    // Check if brew is available
-    let brewAvailable = false;
-    try { execSync('which brew', { stdio: 'ignore' }); brewAvailable = true; } catch (_) { }
-
-    if (!brewAvailable) {
-        warn('Homebrew not found. Please install bd manually:');
-        dim('  npm install -g @anthropic/symphony');
-        dim('  or visit: https://github.com/anthropic/symphony');
-        return false;
-    }
-
-    try {
-        if (!silent) info('Running: npm install -g @anthropic/symphony');
-        execSync('npm install -g @anthropic/symphony', { stdio: silent ? 'pipe' : 'inherit' });
-        // Verify install
-        execSync('which bd', { stdio: 'ignore' });
-        if (!silent) ok('Symphony installed successfully ✨');
-        return true;
-    } catch (e) {
-        warn(`Failed to install bd via brew: ${e.message}`);
-        dim('Try manually: npm install -g @anthropic/symphony');
+    } catch (_) {
+        if (!silent) warn('Symphony CLI not found. Please install it manually:');
+        if (!silent) dim('  npm install -g awkit-symphony');
         return false;
     }
 }
@@ -336,9 +312,9 @@ function cmdInstall(platformArg) {
     info(`Installing for ${C.bold}${plat.name}${C.reset}...`);
     log('');
 
-    // 0. Install Symphony if missing (shared dependency)
+    // 0. Check Symphony dependency
     info('Checking dependencies...');
-    installSymphony();
+    checkSymphony();
 
     // 1. Ensure target dirs exist
     info('Creating directories...');
@@ -1808,30 +1784,20 @@ function cmdInit(forceFlag = false) {
         ok('CODEBASE.md created');
     }
 
-    // ── 5. Symphony init ─────────────────────────────────────────────────────────
+    // ── 5. Symphony folder ───────────────────────────────────────────────────────
     const symphonyDir = path.join(cwd, '.symphony');
     if (fs.existsSync(symphonyDir) && !forceFlag) {
-        warn('.symphony/ already exists — skipping');
+        warn('.symphony/ folder already exists');
     } else {
-        info('Initializing Symphony task database...');
-        // Ensure bd is installed (auto-install silently if missing)
-        const bdReady = installSymphony({ silent: true });
-        if (!bdReady) {
-            warn('bd not available — skipping bd init');
-            dim('Install manually: npm install -g @anthropic/symphony');
-        } else {
-            try {
-                execSync('bd init', { cwd, stdio: 'pipe' });
-                ok('Symphony initialized (.symphony/)');
-            } catch (e) {
-                const msg = (e.stderr || e.stdout || e.message || '').toString().trim();
-                if (msg.includes('already')) {
-                    warn('Symphony already initialized — skipping');
-                } else {
-                    warn(`bd init failed: ${msg || e.message}`);
-                    dim('Try manually: cd <project> && bd init');
-                }
-            }
+        info('Creating .symphony/ folder to mark project context...');
+        fs.mkdirSync(symphonyDir, { recursive: true });
+        // Create an empty .gitignore just in case
+        fs.writeFileSync(path.join(symphonyDir, '.gitignore'), '*\n');
+        ok('Symphony project marker created (.symphony/)');
+        
+        const symReady = checkSymphony({ silent: true });
+        if (!symReady) {
+            dim('Symphony CLI is not installed. Run: npm i -g awkit-symphony');
         }
     }
 
@@ -1847,7 +1813,7 @@ function cmdInit(forceFlag = false) {
     log('');
     log(`${C.cyan}👉 Open ${workspaceName} in VS Code to get started.${C.reset}`);
     log(`${C.cyan}👉 Run '/codebase-sync' in AI chat to keep CODEBASE.md updated.${C.reset}`);
-    log(`${C.cyan}👉 Run 'bd list' to manage tasks.${C.reset}`);
+    log(`${C.cyan}👉 Run 'symphony task list' to manage tasks.${C.reset}`);
     log('');
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leejungkiin/awkit",
-  "version": "1.1.4",
+  "version": "1.1.6",
   "description": "Antigravity Workflow Kit. Unified AI agent orchestration system.",
   "main": "bin/awk.js",
   "bin": {
@@ -38,4 +38,4 @@
     "CHANGELOG.md",
     "VERSION"
   ]
-}
+}

package/skills/CATALOG.md

@@ -34,10 +34,18 @@
 
 ---
 
-## Superpowers Skill Pack (Optional)
+## Quality & Discipline Skills (Superpowers-Inspired)
+
+> Skills ported and adapted from [obra/superpowers](https://github.com/obra/superpowers) framework.
+> Integrated into AWKit with NeuralMemory + Symphony extensions.
+
+| # | Skill | Type | Trigger | Priority | Status |
+|---|-------|------|---------|----------|--------|
+| 14 | `verification-gate` | `auto` | Task completion, commit, deploy | 1 | ✅ Active |
+| 15 | `systematic-debugging` | `auto` | `/debug`, error detected, test failures | 2 | ✅ Active |
+| 16 | `code-review` | `auto` | Task completion, before merge | 3 | ✅ Active |
+| 17 | `writing-skills` | `manual` | Creating/modifying skills | — | ✅ Active |
 
-> `awk enable-pack superpowers` — 13 structured dev workflow skills ported from Claude Code.
-> See [`skill-packs/superpowers/README.md`](../skill-packs/superpowers/README.md) for full details.
 
 ---
 

package/skills/code-review/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: code-review
+description: Use when completing tasks, implementing features, or before merging. Dispatch structured code review with severity classification. Auto-triggers after task completion in subagent-driven or single-flow execution.
+---
+
+# Code Review
+
+## Overview
+
+Review early, review often. Catch issues before they cascade.
+
+**Core principle:** Structured review with actionable, severity-classified feedback.
+
+## When to Request Review
+
+**Mandatory:**
+- After completing each task in execution flow
+- After implementing major feature or fix
+- Before merge to main branch
+- Before deploy to production
+
+**Optional but valuable:**
+- When stuck (fresh perspective helps)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## The Review Process
+
+### Step 1: Prepare Context
+
+Gather what the reviewer needs:
+
+```bash
+# Get the diff scope
+git diff main..HEAD --stat
+git log main..HEAD --oneline
+
+# OR for specific task
+git diff HEAD~1..HEAD --stat
+```
+
+### Step 2: Construct Review Request
+
+Every review request needs:
+
+| Field | Description | Example |
+|-------|-------------|---------|
+| **WHAT** | What was implemented | "Water reminder notification system" |
+| **SPEC** | What it should do | "Send notification every 2h between 8am-10pm" |
+| **FILES** | Changed files | `WaterReminderManager.swift`, `NotificationService.swift` |
+| **SCOPE** | Review focus | "Logic correctness + thread safety" |
+
+### Step 3: Classify Findings
+
+| Severity | Action | Example |
+|----------|--------|---------|
+| 🔴 **Critical** | BLOCK — fix immediately | Thread-unsafe shared state, data loss risk |
+| 🟡 **Important** | Fix before proceeding | Missing error handling, incomplete validation |
+| 🟢 **Minor** | Note for later | Naming convention, code style preference |
+| ℹ️ **Suggestion** | Consider but optional | Performance optimization, alternative approach |
+
+### Step 4: Act on Feedback
+
+1. Fix 🔴 Critical issues IMMEDIATELY
+2. Fix 🟡 Important issues before proceeding to next task
+3. Log 🟢 Minor issues — fix in refactoring pass
+4. Evaluate ℹ️ Suggestions — adopt if clear improvement
+
+## Two-Stage Review (Subagent-Driven)
+
+For automated execution, run TWO separate review passes:
+
+### Stage 1: Spec Compliance Review
+```
+- Does the code implement ALL requirements from the spec/plan?
+- Is anything MISSING from the spec?
+- Is anything EXTRA that wasn't specified (scope creep)?
+- Does behavior match expected output for each requirement?
+```
+
+### Stage 2: Code Quality Review
+```
+- Is the code clean, readable, and well-structured?
+- Are there any thread safety issues?
+- Is error handling comprehensive?
+- Are there performance concerns?
+- Does it follow project coding conventions?
+- Are there any security vulnerabilities?
+```
+
+**Order matters:** Spec compliance FIRST, then code quality. No point reviewing quality of wrong code.
+
+## Self-Review Checklist (Before Requesting External Review)
+
+Before asking for review, verify yourself:
+
+- [ ] All requirements from plan/spec addressed
+- [ ] No TODO/FIXME/HACK left unresolved  
+- [ ] Error handling for all failure paths
+- [ ] No hardcoded values that should be configurable
+- [ ] Thread safety for shared state
+- [ ] Localization for user-facing strings
+- [ ] No print/debugPrint left in production code
+- [ ] File sizes < 500 lines
+
+## Integration
+
+**Used by:**
+- `single-flow-task-execution` — Review after each task
+- `symphony-enforcer` — Review before `symphony_complete_task`
+
+**Related skills:**
+- `verification-gate` — Run tests BEFORE requesting review
+- `systematic-debugging` — If review reveals bugs
+
+## Anti-Rationalization Table
+
+| Excuse | Reality |
+|--------|---------|
+| "It's a small change" | Small changes cause big bugs |
+| "Tests pass so it's correct" | Tests ≠ requirements. Review catches logic gaps |
+| "I'm confident in this code" | Confidence ≠ correctness |
+| "No time for review" | 5 min review saves 2 hours debugging |
+| "I'll review it later" | Later never comes. Review now |
+| "Only I understand this code" | That's exactly why someone else should review |

package/skills/codex-conductor/SKILL.md

@@ -0,0 +1,337 @@
+---
+name: codex-conductor
+description: >-
+  Three-Agent Flow — Antigravity proactively invokes Codex CLI (headless)
+  for debugging, code review, logic verification, and plan auditing.
+  Codex is READ-ONLY: it inspects and reports to .md files, never edits code.
+metadata:
+  stage: core
+  version: "1.0"
+  requires: codex (npm i -g @openai/codex)
+  tags: [conductor, codex, debug, review, logic, verification, delegation]
+agent: Inspector
+trigger: conditional
+invocation-type: auto
+priority: 5
+---
+
+# 🔍 Codex Conductor Skill
+
+> **Purpose:** Antigravity gọi Codex CLI qua terminal khi cần rà soát logic, debug, hoặc review code chuyên sâu.
+> **Key Benefit:** Codex cực mạnh rule compliance + logic analysis. Output = báo cáo `.md`, KHÔNG sửa code.
+
+---
+
+## ⚠️ Core Principle
+
+```
+Antigravity (IDE) = Executor — code, implement, create
+Gemini CLI        = Strategist — analysis, architecture, planning
+Codex CLI         = Inspector — debug, review, verify, test
+
+   ┌──────────────────────────────────────────────┐
+   │  Codex CHỈ RÀ SOÁT + TẠO BÁO CÁO (.md)     │
+   │  TUYỆT ĐỐI KHÔNG ĐƯỢC SỬA CODE              │
+   └──────────────────────────────────────────────┘
+```
+
+---
+
+## 🔧 Prerequisites
+
+Trước khi gọi Codex CLI, kiểm tra:
+
+```bash
+# Check if codex is installed
+which codex || command -v codex
+```
+
+```yaml
+if_not_installed:
+  option_1: "npm i -g @openai/codex"
+  option_2: Ask user to install manually
+  message: "⚠️ Codex CLI chưa cài. Chạy: npm i -g @openai/codex"
+```
+
+---
+
+## 🎯 Trigger Conditions
+
+Kích hoạt khi Antigravity nhận diện task cần thế mạnh Codex:
+
+```yaml
+auto_trigger:
+  high_confidence:
+    - Bug report from user (crash, unexpected behavior)
+    - Pre-commit code review (>3 files changed)
+    - Logic verification (race conditions, edge cases)
+    - Implementation plan review (find holes in plan)
+    - Refactor verification (ensure no regression)
+
+  medium_confidence (confirm before invoking):
+    - Test case generation for new feature
+    - Security audit
+    - Performance bottleneck analysis
+
+  never_trigger:
+    - Simple questions / explanations
+    - UI-only changes (styling, layout)
+    - Documentation edits
+    - Tasks Antigravity can handle alone easily
+```
+
+---
+
+## 🔧 CLI Invocation Pattern
+
+### Mode 1: Quick Analysis (read + stream response)
+
+```bash
+cd <PROJECT_ROOT> && timeout 120 codex \
+  "<PROMPT>. DO NOT edit any files. Output your analysis as text." \
+  --approval-mode suggest \
+  -q 2>/dev/null
+```
+
+| Flag | Purpose |
+|------|---------|
+| `"prompt"` | Single-prompt mode — reads cwd, streams response, exits |
+| `--approval-mode suggest` | Read-only: can browse files, won't make changes |
+| `-q` | Quiet mode — no TUI, output to stdout |
+
+### Mode 2: Deep Inspection (exec with JSON output)
+
+```bash
+cd <PROJECT_ROOT> && timeout 180 codex exec \
+  "<PROMPT>. DO NOT edit any files. Output your findings as structured text." \
+  --json 2>/dev/null
+```
+
+| Flag | Purpose |
+|------|---------|
+| `exec` | Non-interactive scripting mode |
+| `--json` | Structured JSON output for parsing |
+
+### Safety Rules
+
+```yaml
+safety:
+  - Codex TUYỆT ĐỐI KHÔNG ĐƯỢC sửa code. CHỈ đọc + báo cáo.
+  - ALWAYS use --approval-mode suggest (read-only mode).
+  - ALWAYS inject "DO NOT edit any files" in every prompt.
+  - Timeout: 120s for quick analysis, 180s for deep inspection.
+  - If CLI fails → gracefully fallback to Antigravity-only mode.
+  - NEVER pass secrets/tokens in prompt.
+  - Working directory: ALWAYS set to project root.
+  - Output: ALWAYS save to .md report file.
+```
+
+---
+
+## 📋 Use Cases & Prompt Templates
+
+### 1. Bug Root Cause Analysis
+
+```bash
+codex "A bug was reported: <BUG_DESCRIPTION>. \
+Analyze the codebase to find the root cause. \
+List: (1) most likely root cause with file:line, \
+(2) contributing factors, (3) suggested fix approach. \
+DO NOT edit any files." \
+--approval-mode suggest -q
+```
+
+**When:** User reports a bug, crash, or unexpected behavior.
+**Report to:** `codex-reports/bug-analysis-<date>.md`
+
+### 2. Pre-Commit Code Review
+
+```bash
+codex "Review the uncommitted changes in this repo. \
+Check for: bugs, logic errors, edge cases, thread safety, \
+security issues, performance problems, naming inconsistencies. \
+Rank issues by severity (critical/warning/info). \
+DO NOT edit any files." \
+--approval-mode suggest -q
+```
+
+**When:** Before committing changes across >3 files.
+**Report to:** `codex-reports/review-<date>.md`
+
+### 3. Logic & Edge Case Analysis
+
+```bash
+codex "Analyze <FILE_OR_MODULE> for logic correctness. \
+Focus on: edge cases (null, empty, boundary), race conditions, \
+error handling gaps, unreachable code, off-by-one errors. \
+List each issue with file:line and severity. \
+DO NOT edit any files." \
+--approval-mode suggest -q
+```
+
+**When:** Complex logic that needs verification.
+**Report to:** `codex-reports/logic-analysis-<date>.md`
+
+### 4. Test Case Generation
+
+```bash
+codex "Analyze <FILE_OR_MODULE> and generate a comprehensive \
+list of test cases. Include: happy path, edge cases, error cases, \
+boundary values, concurrent scenarios. Format as markdown table. \
+DO NOT edit any files." \
+--approval-mode suggest -q
+```
+
+**When:** New feature needs test coverage planning.
+**Report to:** `codex-reports/test-cases-<date>.md`
+
+### 5. Implementation Plan Review
+
+```bash
+codex "Review this implementation plan: <PLAN_CONTENT>. \
+Find: logic holes, missing error handling, security risks, \
+race conditions, scalability issues, missing edge cases. \
+Rate each issue by severity. \
+DO NOT edit any files." \
+--approval-mode suggest -q
+```
+
+**When:** After Antigravity creates an implementation plan.
+**Report to:** `codex-reports/plan-review-<date>.md`
+
+### 6. Refactor Verification
+
+```bash
+codex "Compare the recent changes in this repo against the \
+original code. Verify: (1) no behavioral regression, \
+(2) all original edge cases still handled, \
+(3) no new bugs introduced. List any regressions found. \
+DO NOT edit any files." \
+--approval-mode suggest -q
+```
+
+**When:** After refactoring to ensure no regression.
+**Report to:** `codex-reports/refactor-verify-<date>.md`
+
+---
+
+## 🔄 Integration Flow
+
+```
+1. Antigravity detects trigger condition
+2. Check Codex CLI: which codex || prompt install
+3. Thông báo user: "🔍 Đang gọi Codex CLI để [mục đích]..."
+4. Build prompt with project context
+5. Run: run_command("cd <ROOT> && timeout 120 codex '<prompt>' --approval-mode suggest -q")
+6. Capture output
+7. Save report to codex-reports/<type>-<date>.md
+8. Summarize key findings for user
+9. Act on findings (Antigravity executes fixes if needed)
+```
+
+### Output Handling
+
+```yaml
+on_success:
+  - Parse Codex output (text or JSON)
+  - Save full report to codex-reports/<type>-<date>.md
+  - Extract key findings + severity
+  - Present summary to user
+  - If critical issues found → suggest fixes
+
+on_timeout:
+  - Log: "⏳ Codex analysis timed out (>120s), proceeding with Antigravity"
+  - Fall back to Antigravity-only analysis
+
+on_error:
+  - Log: "⚠️ Codex CLI invocation failed"
+  - Check: "codex --version" → suggest install if missing
+  - Fall back gracefully — CLI is enhancement, not dependency
+
+on_not_installed:
+  - Ask user: "Codex CLI chưa cài. Cài bằng: npm i -g @openai/codex?"
+  - If yes → run install → retry
+  - If no → fall back to Antigravity-only
+```
+
+---
+
+## 📁 Report Output Structure
+
+```
+<project_root>/
+└── codex-reports/          # Gitignored recommended
+    ├── bug-analysis-2026-03-21.md
+    ├── review-2026-03-21.md
+    ├── logic-analysis-2026-03-21.md
+    ├── test-cases-2026-03-21.md
+    ├── plan-review-2026-03-21.md
+    └── refactor-verify-2026-03-21.md
+```
+
+---
+
+## 🚫 Anti-Patterns
+
+```yaml
+never_do:
+  - Let Codex edit source code (EVER)
+  - Use --approval-mode auto or full-access (ALWAYS use suggest)
+  - Pass sensitive data (API keys, tokens) in prompts
+  - Block on CLI response indefinitely (always use timeout)
+  - Call CLI more than 3 times per task (diminishing returns)
+  - Ignore CLI output — if you called it, use the result
+  - Call Codex for tasks Antigravity handles well alone
+
+always_do:
+  - Mention to user: "🔍 Đang gọi Codex CLI [mục đích]..."
+  - Include "DO NOT edit any files" in EVERY prompt
+  - Use --approval-mode suggest (read-only)
+  - Save reports to codex-reports/ directory
+  - Summarize findings before acting on them
+  - Fall back gracefully if CLI unavailable
+  - Check codex installation before first use
+```
+
+---
+
+## 🤝 Three-Agent Collaboration
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                    User Request                          │
+└─────────────┬───────────────────────────────────────────┘
+              │
+              ▼
+    ┌─────────────────┐
+    │   Antigravity    │ ← Primary: plan, code, implement
+    │   (IDE Agent)    │
+    └───┬─────────┬───┘
+        │         │
+   Strategy?   Debug/Review?
+        │         │
+        ▼         ▼
+  ┌──────────┐ ┌──────────┐
+  │ Gemini   │ │ Codex    │
+  │ CLI      │ │ CLI      │
+  │ ────────── │ ────────── │
+  │ Architect │ │ Inspector│
+  │ .md only  │ │ .md only │
+  └──────────┘ └──────────┘
+```
+
+---
+
+## 🧩 Skill Relationships
+
+```
+Uses:      run_command (to invoke codex CLI)
+Enhances:  /debug, /code, /refactor, /plan workflows
+Saves to:  codex-reports/*.md
+Parallel:  gemini-conductor (different role, can coexist)
+Independent of: NeuralMemory (CLI has its own context)
+```
+
+---
+
+*codex-conductor v1.0 — Three-Agent Flow Inspector for Antigravity*

package/skills/symphony-enforcer/SKILL.md

@@ -181,9 +181,20 @@ Signal 4: Verification pass (tests OK, build OK)
 
 **Action:**
 ```
+0. ⚡ VERIFICATION GATE (BẮT BUỘC — Iron Law):
+   - IDENTIFY: What command proves this task is done?
+   - RUN: Execute verification (build, test, lint)
+   - READ: Full output, check exit code
+   - VERIFY: Does output confirm completion?
+   - If NO → FIX trước, KHÔNG complete task
+   - If YES → Proceed with evidence
+   ⛔ Skip verification = VI PHẠM (xem verification-gate skill)
+
 1. symphony_complete_task(
      task_id=current_task,
-     summary="mô tả ngắn kết quả"
+     summary="mô tả ngắn + VERIFICATION EVIDENCE"
+     // ✅ "Implemented X. Build: ✅ exit 0. Tests: ✅ 47/47. Lint: ✅ 0 errors."
+     // ❌ "Implemented X" (không evidence)
    )
 2. Hiển thị: "✅ SYM #sym-XYZ — Done"
 3. → TRIGGER TP2.5 (Atomic Git Commit)

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: systematic-debugging
+description: Use for ANY technical issue - bugs, test failures, build errors, crashes. Enforces 4-phase root cause process before any fix attempts. Auto-triggers on /debug, error detection, test failures.
+---
+
+# Systematic Debugging
+
+## Overview
+
+Random fixes waste time and create new bugs. Quick patches mask underlying issues.
+
+**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
+
+## The Iron Law
+
+```
+NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+```
+
+If you haven't completed Phase 1, you CANNOT propose fixes.
+
+## When to Use
+
+Use for ANY technical issue:
+- Test failures
+- Runtime crashes / EXC_BAD_ACCESS / ANR
+- Unexpected behavior
+- Performance problems
+- Build failures (Xcode, Gradle, npm)
+- Integration issues (API, SDK, Firebase)
+
+**Use this ESPECIALLY when:**
+- Under time pressure (emergencies make guessing tempting)
+- "Just one quick fix" seems obvious
+- You've already tried multiple fixes
+- Previous fix didn't work
+- You don't fully understand the issue
+
+## The Four Phases
+
+You MUST complete each phase before proceeding to the next.
+
+### Phase 1: Root Cause Investigation (BEFORE ANY FIX)
+
+1. **Read Error Messages Carefully**
+   - Don't skip past errors or warnings
+   - Read stack traces COMPLETELY — they often contain the exact answer
+   - Note line numbers, file paths, error codes
+   - For iOS: read the full crash log, not just the top frame
+   - For Android: read logcat with proper filters
+
+2. **Reproduce Consistently**
+   - Can you trigger it reliably? What are the exact steps?
+   - If not reproducible → gather more data, DON'T guess
+   - For intermittent: add diagnostic logging at component boundaries
+
+3. **Check Recent Changes**
+   - `git diff` — what changed?
+   - Recent commits, new dependencies, config changes
+   - Environmental differences (device, OS version, network)
+
+4. **Gather Evidence in Multi-Component Systems**
+   ```
+   For EACH component boundary:
+     - Log what data enters component
+     - Log what data exits component  
+     - Verify environment/config propagation
+     - Check state at each layer
+   
+   Run once to gather evidence showing WHERE it breaks
+   THEN analyze evidence to identify failing component
+   THEN investigate that specific component
+   ```
+
+5. **Trace Data Flow**
+   - Where does the bad value originate?
+   - What called this with the bad value?
+   - Keep tracing UP until you find the source
+   - **Fix at source, not at symptom**
+
+### Phase 2: Pattern Analysis
+
+1. **Find Working Examples** — Locate similar working code in same codebase
+2. **Compare Against References** — Read reference implementation COMPLETELY (don't skim)
+3. **Identify Differences** — List EVERY difference, however small
+4. **Understand Dependencies** — What components, settings, config does this need?
+
+### Phase 3: Hypothesis & Testing
+
+1. **Form Single Hypothesis** — "I think X is the root cause because Y"
+2. **Test Minimally** — SMALLEST possible change. One variable at a time
+3. **Verify Before Continuing** — Worked? → Phase 4. Didn't? → NEW hypothesis
+4. **When You Don't Know** — Say "I don't understand X". Don't pretend. Research more
+
+### Phase 4: Implementation
+
+1. **Create Failing Test Case** — Simplest possible reproduction. MUST have before fixing
+2. **Implement Single Fix** — ONE change at a time. No "while I'm here" improvements
+3. **Verify Fix** — Test passes? No other tests broken? Issue actually resolved?
+
+## The 3-Fix Rule
+
+```
+If 3+ fixes have FAILED → STOP
+
+This is NOT a failed hypothesis.
+This is a WRONG ARCHITECTURE.
+```
+
+**After 3 failed fixes:**
+- Is this pattern fundamentally sound?
+- Are we sticking with it through sheer inertia?
+- Should we refactor architecture vs. continue fixing symptoms?
+- **DISCUSS with user before attempting more fixes**
+
+**Pattern indicating architectural problem:**
+- Each fix reveals new shared state/coupling
+- Fixes require "massive refactoring" to implement
+- Each fix creates new symptoms elsewhere
+
+## Red Flags — STOP and Return to Phase 1
+
+If you catch yourself thinking:
+- "Quick fix for now, investigate later"
+- "Just try changing X and see if it works"
+- "It's probably X, let me fix that"
+- "I don't fully understand but this might work"
+- "Here are the main problems: [lists fixes without investigation]"
+- Proposing solutions before tracing data flow
+- **"One more fix attempt" (when already tried 2+)**
+- **Each fix reveals new problem in different place**
+
+**ALL of these mean: STOP. Return to Phase 1.**
+
+## Anti-Rationalization Table
+
+| Excuse | Reality |
+|--------|---------|
+| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs |
+| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check |
+| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start |
+| "I'll write test after confirming fix" | Untested fixes don't stick. Test first proves it |
+| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs |
+| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause |
+| "One more fix attempt" (after 2+) | 3+ failures = architectural problem. Question pattern |
+| "Reference too long, I'll adapt" | Partial understanding guarantees bugs. Read completely |
+
+## Quick Reference
+
+| Phase | Key Activities | Success Criteria |
+|-------|---------------|------------------|
+| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
+| **2. Pattern** | Find working examples, compare | Identify differences |
+| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
+| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass |
+
+## NeuralMemory Integration
+
+After fixing a bug:
+1. `nmem_remember` the root cause, fix, and pattern — tag with projectId
+2. Before debugging NEW bugs: `nmem_recall` for similar past issues
+3. Saves hours on recurring patterns
+
+## Integration
+
+**Related skills:**
+- **verification-gate** — Verify fix worked before claiming success
+- **single-flow-task-execution** — For structured task execution
+- **symphony-enforcer** — Report debug progress to Symphony
+
+**Related workflows:**
+- `/debug` — Primary trigger workflow
+- `/bug-hunter` — Automated bug hunting
+- `/hotfix` — Production emergency (still follows 4-phase!)

package/skills/verification-gate/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: verification-gate
+description: Use BEFORE claiming any work is complete, fixed, or passing. Requires running verification commands and confirming output before making success claims. Evidence before assertions, always. Auto-triggers on task completion, commit, deploy, or any positive status claim.
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## When to Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction ("Done!", "Fixed!", "Works!")
+- Committing, PR creation, task completion
+- `symphony_complete_task` calls
+- Moving to next task
+- Deploying or pushing code
+
+## Verification Requirements by Claim Type
+
+| Claim | Requires | NOT Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, looks good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Feature works | Demo/run showing behavior | Code written, assumed works |
+| Requirements met | Line-by-line checklist | Tests passing |
+| Deploy succeeded | Health check: 200 OK | Deploy command completed |
+
+## Red Flags — STOP
+
+If you catch yourself thinking any of these, STOP and run verification:
+
+- Using "should", "probably", "seems to", "looks correct"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!")
+- About to commit/push without verification
+- Relying on partial verification
+- Thinking "just this once I can skip"
+- Tired and wanting work to be over
+- **ANY wording implying success without having run verification**
+
+## Anti-Rationalization Table
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler ≠ runtime |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Build passed so tests pass" | Build ≠ tests |
+| "I just changed one line" | One line can break everything |
+| "It's a trivial change" | Trivial changes have the sneakiest bugs |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] → [See: 34/34 pass] → "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Build:**
+```
+✅ [Run build] → [See: BUILD SUCCEEDED] → "Build passes"
+❌ "Linter passed so build is fine"
+```
+
+**Bug Fix:**
+```
+✅ Write regression test → Run (FAIL) → Fix → Run (PASS) → "Bug is fixed"
+❌ "I've changed the code, bug should be fixed"
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, so requirements are met"
+```
+
+## Symphony Integration
+
+When calling `symphony_complete_task`:
+1. Run ALL relevant verification commands FIRST
+2. Include verification evidence in the `summary` parameter
+3. Include `files_changed` list with ACTUAL changed files
+
+```
+❌ symphony_complete_task(summary="Implemented feature X")
+✅ symphony_complete_task(summary="Implemented feature X. Build: ✅ (exit 0). Tests: ✅ 47/47 pass. Lint: ✅ 0 errors.")
+```
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/skills/writing-skills/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: writing-skills
+description: Use when creating or modifying AWKit skills and workflows. Applies TDD methodology to process documentation. Ensures skills are testable, anti-rationalization-proof, and follow consistent structure.
+---
+
+# Writing Skills
+
+## Overview
+
+Writing skills IS Test-Driven Development applied to process documentation.
+
+**Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing.
+
+## What is a Skill?
+
+A **skill** is a reference guide for proven techniques, patterns, or tools.
+
+**Skills ARE:** Reusable techniques, patterns, tools, reference guides
+**Skills are NOT:** Narratives about how you solved a problem once
+
+## Standard Skill Structure
+
+Every AWKit skill MUST follow this structure:
+
+```markdown
+---
+name: skill-name
+description: When to use + auto-trigger description (for CATALOG.md matching)
+---
+
+# Skill Title
+
+## Overview (1-2 sentences — what + why)
+## The Iron Law (core rule, no exceptions — for discipline skills)
+## When to Use / When NOT to Use
+## The Process (step by step)
+## Red Flags — STOP (catch rationalization)
+## Anti-Rationalization Table (excuse → reality)
+## Integration (related skills + workflows)
+```
+
+**Required sections:** Overview, When to Use, The Process
+**Recommended for discipline skills:** Iron Law, Red Flags, Anti-Rationalization Table
+
+## When to Create a Skill
+
+**Create when:**
+- Technique wasn't intuitively obvious
+- You'd reference this again across projects
+- Pattern applies broadly (not project-specific)
+- An agent repeatedly makes the same mistake
+
+**Don't create for:**
+- One-off solutions
+- Standard practices well-documented elsewhere
+- Project-specific conventions (put in GEMINI.md or docs/specs/)
+
+## Skill Types
+
+### Rigid Skills (Follow Exactly)
+- `verification-gate` — No shortcuts for verification
+- `systematic-debugging` — 4-phase process mandatory
+- TDD enforcement — RED-GREEN-REFACTOR cycle
+
+### Flexible Skills (Adapt Principles)
+- `brainstorm-agent` — Adapt questions to context
+- `ios-engineer` — Apply patterns per project needs
+
+**The skill itself tells you which type it is.**
+
+## Key Writing Principles
+
+### 1. Token Efficiency (Critical)
+- Every token competes for agent context
+- Use tables over paragraphs for rules
+- Use bullet points over prose
+- Eliminate redundancy ruthlessly
+
+### 2. Bulletproofing Against Rationalization
+- Agents are smart and WILL find loopholes under pressure
+- Close every loophole explicitly
+- Build rationalization table with common excuses
+- Create Red Flags list
+
+### 3. Cross-Referencing
+- Link related skills: `**Related:** verification-gate, systematic-debugging`
+- Note integration points: "Used by single-flow-task-execution"
+- Reference workflows: `/debug`, `/code`, `/deploy`
+
+## Checklist: Before Publishing Skill
+
+- [ ] SKILL.md follows standard structure
+- [ ] `name` and `description` in frontmatter
+- [ ] When to Use is clear and specific
+- [ ] Process steps are numbered and unambiguous
+- [ ] Anti-rationalization table covers common excuses
+- [ ] Integration section lists related skills/workflows
+- [ ] File < 500 lines
+- [ ] No narrative/story sections — only reference content
+- [ ] Updated CATALOG.md entry
+
+## Integration
+
+**Related:**
+- `awf-version-tracker` — Auto-snapshot skill changes
+- CATALOG.md — Skill registry
+
+**Workflows:**
+- `/skill-health` — Check skill system health
+- `/skill-rollback` — Rollback broken skill changes

package/workflows/conductor-codex.md

@@ -0,0 +1,125 @@
+---
+description: 🔍 Codex Conductor — Gọi Codex CLI rà soát code, debug, review logic, và verify refactor
+---
+
+# /conductor-codex — Three-Agent Inspector Workflow
+
+> Antigravity gọi Codex CLI (headless, read-only) khi cần rà soát chuyên sâu.
+> Codex CHỈ ĐỌC + TẠO BÁO CÁO `.md`. KHÔNG BAO GIỜ sửa code.
+
+// turbo-all
+
+---
+
+## Prerequisites
+
+1. Kiểm tra Codex CLI:
+```bash
+which codex || echo "NOT_INSTALLED"
+```
+2. Nếu chưa cài → đề xuất cài:
+```bash
+npm i -g @openai/codex
+```
+3. Tạo thư mục report nếu chưa có:
+```bash
+mkdir -p codex-reports
+```
+
+---
+
+## Sub-commands
+
+### `/conductor-codex:debug` — Phân tích root cause bug
+
+1. User mô tả bug (crash, lỗi logic, unexpected behavior)
+2. Thông báo: "🔍 Đang gọi Codex CLI phân tích bug..."
+3. Gọi CLI:
+```bash
+cd <PROJECT_ROOT> && timeout 120 codex "A bug was reported: <BUG_DESCRIPTION>. Analyze the codebase to find the root cause. List: (1) most likely root cause with file:line, (2) contributing factors, (3) suggested fix approach. DO NOT edit any files." --approval-mode suggest -q 2>/dev/null
+```
+4. Parse output → lưu vào `codex-reports/bug-analysis-<DATE>.md`
+5. Tóm tắt findings cho user
+6. Nếu critical → Antigravity thực hiện fix
+
+### `/conductor-codex:review` — Pre-commit code review
+
+1. Kiểm tra có uncommitted changes: `git diff --stat`
+2. Thông báo: "🔍 Đang gọi Codex CLI review code..."
+3. Gọi CLI:
+```bash
+cd <PROJECT_ROOT> && timeout 120 codex "Review the uncommitted changes in this repo. Check for: bugs, logic errors, edge cases, thread safety, security issues, performance problems. Rank issues by severity (critical/warning/info). DO NOT edit any files." --approval-mode suggest -q 2>/dev/null
+```
+4. Parse output → lưu vào `codex-reports/review-<DATE>.md`
+5. Tóm tắt: issues found + severity
+6. Nếu clean → suggest `git commit`
+
+### `/conductor-codex:logic` — Phân tích logic & edge cases
+
+1. Xác định file/module cần kiểm tra
+2. Thông báo: "🔍 Đang gọi Codex CLI kiểm tra logic..."
+3. Gọi CLI:
+```bash
+cd <PROJECT_ROOT> && timeout 120 codex "Analyze <FILE_OR_MODULE> for logic correctness. Focus on: edge cases (null, empty, boundary), race conditions, error handling gaps, unreachable code, off-by-one errors. List each issue with file:line and severity. DO NOT edit any files." --approval-mode suggest -q 2>/dev/null
+```
+4. Parse output → lưu vào `codex-reports/logic-analysis-<DATE>.md`
+5. Tóm tắt findings cho user
+
+### `/conductor-codex:test` — Generate test cases
+
+1. Xác định feature/module cần test
+2. Thông báo: "🔍 Đang gọi Codex CLI generate test cases..."
+3. Gọi CLI:
+```bash
+cd <PROJECT_ROOT> && timeout 120 codex "Analyze <FILE_OR_MODULE> and generate a comprehensive list of test cases. Include: happy path, edge cases, error cases, boundary values. Format as markdown table with columns: Test Name | Input | Expected Output | Type. DO NOT edit any files." --approval-mode suggest -q 2>/dev/null
+```
+4. Parse output → lưu vào `codex-reports/test-cases-<DATE>.md`
+5. Trình bày test plan cho user
+
+### `/conductor-codex:plan-review` — Review implementation plan
+
+1. Đọc `implementation_plan.md` hiện tại
+2. Thông báo: "🔍 Đang gọi Codex CLI review plan..."
+3. Gọi CLI:
+```bash
+cd <PROJECT_ROOT> && timeout 120 codex "Review this implementation plan in the current directory. Find: logic holes, missing error handling, security risks, race conditions, scalability issues, missing edge cases. Rate each issue by severity (critical/warning/info). DO NOT edit any files." --approval-mode suggest -q 2>/dev/null
+```
+4. Parse output → lưu vào `codex-reports/plan-review-<DATE>.md`
+5. Tóm tắt issues → Antigravity cập nhật plan
+
+---
+
+## Fallback Rules
+
+```yaml
+cli_not_installed:
+  - "⚠️ Codex CLI chưa cài. Chạy: npm i -g @openai/codex"
+  - Offer to install automatically
+
+cli_unavailable:
+  - "⚠️ Codex CLI không khả dụng, tiếp tục với Antigravity-only"
+  - Do NOT block workflow
+
+cli_timeout:
+  - "⏳ Codex phân tích quá lâu (>120s), bỏ qua và tiếp tục"
+
+cli_error:
+  - Log error
+  - Fall back gracefully
+  - Suggest: "codex --version" to check installation
+```
+
+---
+
+## Communication
+
+Mỗi khi gọi CLI, LUÔN thông báo user:
+```
+🔍 Đang gọi Codex CLI để [mục đích]...
+```
+
+Sau khi nhận kết quả:
+```
+✅ Codex rà soát xong. Báo cáo: codex-reports/<file>.md
+📊 Tóm tắt: [key findings]
+```

package/workflows/lifecycle/code.md

@@ -291,6 +291,29 @@ Khi user gõ `/code all-phases`:
 *   Cài thêm thư viện mới → Hỏi trước
 *   Deploy/Push code → **LUÔN LUÔN** hỏi trước
 
+### 5. TDD ENFORCEMENT (Superpowers-Inspired)
+
+> **Iron Law:** Write failing test FIRST, then implement. RED → GREEN → REFACTOR.
+> Ref: `~/.gemini/antigravity/skills/systematic-debugging/SKILL.md` Phase 4.
+
+**For PRODUCTION and ENTERPRISE quality levels:**
+```
+1. Write failing test for the feature/fix
+2. Run test → MUST FAIL (RED)
+3. Write MINIMAL code to make test pass
+4. Run test → MUST PASS (GREEN)
+5. Refactor if needed, tests still pass
+6. Commit
+```
+
+**Anti-Rationalization:**
+| Excuse | Reality |
+|--------|--------|
+| "I'll write tests after" | Untested code = unknown state |
+| "Too simple for tests" | Simple code breaks most |
+| "Tests slow me down" | Tests prevent 2h debug sessions |
+| "MVP doesn't need tests" | Even MVP needs syntax/build check |
+
 ---
 
 ## Giai đoạn 2: Hidden Requirements (Tự động thêm)
@@ -401,9 +424,13 @@ Test FAIL
 [Lần 3] Rollback + Approach khác → Test lại
     ↓
 ├── PASS → Thoát loop, tiếp tục
-└── FAIL → Hỏi User
+└── FAIL → ⚠️ 3-Fix Rule: Question architecture!
+         → Hỏi User + gợi ý /debug --systematic
 ```
 
+> **3-Fix Rule (from Superpowers):** Nếu 3 lần fix fail → đây KHÔNG phải bug đơn giản.
+> Đây là vấn đề kiến trúc. DỪNG fix symptoms, thảo luận root cause với user.
+
 ### 4.3. Khi fix loop thất bại
 
 ```

package/workflows/lifecycle/debug.md

@@ -9,6 +9,18 @@ description: 🐞 Sửa lỗi & Debug (Dual-Mode v5.0)
 
 ---
 
+## ⚠️ Iron Law (from systematic-debugging skill)
+
+```
+NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+```
+
+> Bắt buộc: Đọc `~/.gemini/antigravity/skills/systematic-debugging/SKILL.md` trước khi debug.
+> 4 phases: Root Cause → Pattern Analysis → Hypothesis → Implementation
+> 3-Fix Rule: Sau 3 fix thất bại → question architecture, discuss with user.
+
+---
+
 ## 🅰️ Expert Mode (Direct Execution)
 
 **Usage:**
@@ -16,20 +28,28 @@ description: 🐞 Sửa lỗi & Debug (Dual-Mode v5.0)
 /debug --auto-fix --file src/components/Cart.tsx
 ```
 
-**Logic:**
-1.  **Auto-Detect:**
-    -   Đọc logs gần nhất.
-    -   Parse error stack trace.
-    -   Identify file & line number.
-2.  **Root Cause Analysis:**
-    -   Phân tích code tại vị trí lỗi.
-    -   Đưa ra 1-2 giả thuyết.
-3.  **Auto-Fix (Safe Only):**
-    -   Lỗi *Safe-to-fix*: Missing import, typo, undefined check -> Sửa ngay.
-    -   Lỗi *Logic*: Báo cáo và đề xuất (không tự ý sửa).
-4.  **Symphony Sync:**
-    -   Nếu lỗi Critical và không thể auto-fix -> `symphony_create_task(title="Fix Critical Bug in Cart.tsx")`.
-5.  **Report:** "✅ Fixed 1 issue. ⚠️ Created task #456 for manual review."
+**Logic (follows 4-phase systematic debugging):**
+1.  **Phase 1 — Root Cause Investigation:**
+    -   Đọc error messages/stack traces HOÀN TOÀN (không skip).
+    -   Reproduce consistently — exact steps.
+    -   `git diff` — check recent changes.
+    -   Multi-component: add diagnostic logging ở mỗi boundary.
+    -   Trace data flow backward đến source.
+2.  **Phase 2 — Pattern Analysis:**
+    -   Find similar WORKING code in codebase.
+    -   Compare: list EVERY difference.
+3.  **Phase 3 — Hypothesis:**
+    -   "I think X is root cause because Y"
+    -   Test minimally — ONE variable at a time.
+4.  **Phase 4 — Implementation:**
+    -   Create failing test FIRST.
+    -   Implement single fix.
+    -   Verify: tests pass, no regressions.
+5.  **Symphony Sync:**
+    -   Nếu lỗi Critical và không thể auto-fix → `symphony_create_task(title="Fix Critical Bug in Cart.tsx")`.
+6.  **NeuralMemory:**
+    -   `nmem_remember` root cause + fix + pattern (cho future recall).
+7.  **Report:** "✅ Fixed 1 issue. Evidence: [test output]. ⚠️ Created task #456 for manual review."
 
 ---