@leejungkiin/awkit 1.7.7 → 1.7.8

package/workflows/_uncategorized/plan-eng-review.md

@@ -0,0 +1,43 @@
+---
+description: 🛠️ Đánh giá kỹ thuật và cấu trúc dữ liệu trước khi code để chống lỗi và hồi quy.
+alwaysApply: false
+priority: "high"
+---
+
+# Plan Engineering Review Workflow
+
+## 🎯 Role Purpose
+Act as the Tech Lead / Engineering Manager. Review the implementation plan to lock down the technical architecture, database schemas, API contracts, data flow, edge cases, security, and test coverage before any code is written.
+
+## 📋 When to Activate
+- Prior to coding a plan (Gate 2 / Spec Gate).
+- When asked to "review architecture", "technical review", or "lock plan".
+- Trigger command: `/plan-eng-review`
+
+## 🛠️ Workflow Steps
+
+### 1. Data Safety & SQL Guardrails
+- **SQL Injection**: Check for string interpolation in database queries. Ensure prepared statements/parameterized queries are planned.
+- **Direct DB Writes**: Ensure model/ORM level validations are not bypassed by direct DB writes.
+- **N+1 Queries**: Check for missing eager loading/joins in loops or views.
+
+### 2. Race Conditions & Concurrency
+- **Read-Check-Write**: Look for checks followed by writes without unique database indices or transaction blocks.
+- **State Transitions**: Ensure state updates are atomic (e.g., `WHERE status = 'old' UPDATE SET status = 'new'`).
+
+### 3. LLM Output Trust Boundaries (if using AI)
+- **Validation**: Ensure LLM-generated values are validated (shape, type, email/URL regex) before writing to DB.
+- **SSRF**: Ensure external URLs generated by LLM are checked against an allowlist before fetching.
+
+### 4. Shell Injection & Security
+- **Command execution**: Check for variable interpolation in shell commands. Use argument arrays instead.
+- **Authentication**: Check that secrets are stored in environment variables, never hardcoded.
+
+### 5. Enum & Value Completeness
+- **Flow Tracing**: Trace any new enum/status/tier value through every consumer in the codebase (frontend, backend, persistence).
+- **Allowlists**: Ensure the value is added to all matching lists or filter arrays.
+- **Case Fallthrough**: Ensure new values do not fall through to invalid default branches in conditionals.
+
+### 6. Verification and Test Planning
+- Detail the regression tests and unit tests required for the changes.
+- Ensure test cases cover both happy-path and negative/error-handling paths.

package/workflows/quality/plan-ceo-review.md

@@ -0,0 +1,34 @@
+---
+description: 👑 Đánh giá lập kế hoạch dưới vai trò CEO để định vị sản phẩm xuất sắc.
+alwaysApply: false
+priority: "high"
+---
+
+# Plan CEO Review Workflow
+
+## 🎯 Role Purpose
+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.
+
+## 📋 When to Activate
+- When a new draft specification or planning artifact is generated (Gate 1.5/2).
+- When asked to "think bigger", "reread plan", "expand scope", or "strategy review".
+- Trigger command: `/plan-ceo-review`
+
+## 🛠️ Workflow Steps
+
+### 1. Select the Review Mode
+Select one of the following modes based on the project stage:
+- **SCOPE EXPANSION**: Dream big. Add features that create a 10-star magical product experience.
+- **SELECTIVE EXPANSION**: Hold the main scope, but cherry-pick 1 or 2 small visual/interaction expansions for high user delight.
+- **HOLD SCOPE**: Strictly lock the scope. Maximum rigor on V1/MVP boundaries.
+- **SCOPE REDUCTION**: Strip the plan to its absolute bare essentials. Cut out everything that is not critical path.
+
+### 2. The 10-Star Experience Assessment
+- Audit the current plan's features. Rate the plan's user value from 0 to 10.
+- Describe what a "10-star experience" would look like for this specific feature.
+- Highlight the gap between the current plan and the 10-star design, and suggest high-leverage adjustments.
+
+### 3. Scope Scrutiny
+- Identify any "future-proofing" boilerplate (e.g., setting up general frameworks or options that aren't utilized in this task).
+- Challenge any dependencies or architectures that add complexity without user value.
+- Mark deferred items clearly as P2/Future work.

package/workflows/quality/plan-design-review.md

@@ -0,0 +1,38 @@
+---
+description: 🎨 Đánh giá thiết kế giao diện UI/UX và chấm điểm chất lượng thiết kế.
+alwaysApply: false
+priority: "high"
+---
+
+# Plan Design Review Workflow
+
+## 🎯 Role Purpose
+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.
+
+## 📋 When to Activate
+- Prior to implementing frontend code (Gate 2.5 / Visual Design Gate).
+- When asked to "design review", "audit UI", or "check layout".
+- Trigger command: `/plan-design-review`
+
+## 🛠️ Workflow Steps
+
+### 1. Dimension Scoring (0 to 10)
+Rate the design proposal from 0 to 10 across these key dimensions:
+1. **Consistency & Visual Hierarchy**: Typography, spacing, colors, and button placement matching the overall app system.
+2. **Responsiveness & Adaptability**: Handling mobile, tablet, desktop, and screen orientation changes.
+3. **Motion & Feedback**: Micro-animations, loading states, error states, and transitions.
+4. **Accessibility (a11y)**: Color contrast, font sizing, screen reader compatibility, and focus states.
+
+For each dimension, describe:
+- Current state
+- Score (0-10)
+- **What a "10" looks like** for this specific feature
+- Recommended fixes to reach a 10
+
+### 2. Apple HIG / Material Design Alignment
+- Check visual assets, margins, safety areas (notch/bottom indicators), and navigation hierarchies.
+- Ensure all interactive elements have sufficient tap targets (minimum 44x44 points/dp).
+
+### 3. Grid and Asset Audit
+- Ensure layout utilizes a consistent grid layout (e.g. 8px system).
+- 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).

package/workflows/quality/plan-eng-review.md

@@ -0,0 +1,43 @@
+---
+description: 🛠️ Đánh giá kỹ thuật và cấu trúc dữ liệu trước khi code để chống lỗi và hồi quy.
+alwaysApply: false
+priority: "high"
+---
+
+# Plan Engineering Review Workflow
+
+## 🎯 Role Purpose
+Act as the Tech Lead / Engineering Manager. Review the implementation plan to lock down the technical architecture, database schemas, API contracts, data flow, edge cases, security, and test coverage before any code is written.
+
+## 📋 When to Activate
+- Prior to coding a plan (Gate 2 / Spec Gate).
+- When asked to "review architecture", "technical review", or "lock plan".
+- Trigger command: `/plan-eng-review`
+
+## 🛠️ Workflow Steps
+
+### 1. Data Safety & SQL Guardrails
+- **SQL Injection**: Check for string interpolation in database queries. Ensure prepared statements/parameterized queries are planned.
+- **Direct DB Writes**: Ensure model/ORM level validations are not bypassed by direct DB writes.
+- **N+1 Queries**: Check for missing eager loading/joins in loops or views.
+
+### 2. Race Conditions & Concurrency
+- **Read-Check-Write**: Look for checks followed by writes without unique database indices or transaction blocks.
+- **State Transitions**: Ensure state updates are atomic (e.g., `WHERE status = 'old' UPDATE SET status = 'new'`).
+
+### 3. LLM Output Trust Boundaries (if using AI)
+- **Validation**: Ensure LLM-generated values are validated (shape, type, email/URL regex) before writing to DB.
+- **SSRF**: Ensure external URLs generated by LLM are checked against an allowlist before fetching.
+
+### 4. Shell Injection & Security
+- **Command execution**: Check for variable interpolation in shell commands. Use argument arrays instead.
+- **Authentication**: Check that secrets are stored in environment variables, never hardcoded.
+
+### 5. Enum & Value Completeness
+- **Flow Tracing**: Trace any new enum/status/tier value through every consumer in the codebase (frontend, backend, persistence).
+- **Allowlists**: Ensure the value is added to all matching lists or filter arrays.
+- **Case Fallthrough**: Ensure new values do not fall through to invalid default branches in conditionals.
+
+### 6. Verification and Test Planning
+- Detail the regression tests and unit tests required for the changes.
+- Ensure test cases cover both happy-path and negative/error-handling paths.

package/workflows/roles/office-hours.md

@@ -0,0 +1,38 @@
+---
+description: 💡 YC Office Hours — Thử thách ý tưởng sản phẩm và tối giản hóa phạm vi (MVP).
+alwaysApply: false
+priority: "high"
+---
+
+# YC Office Hours Workflow
+
+## 🎯 Role Purpose
+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).
+
+## 📋 When to Activate
+- When the user starts with a new product idea, draft, or epic.
+- When you hear phrases like "I want to build...", "What should I do next?", or when starting G1 (Brainstorm).
+- Trigger command: `/office-hours`
+
+## 🛠️ Workflow Steps
+
+### 1. The Core Questions (Founder Mode)
+Ask the user the 3 fundamental YC questions:
+1. **What are you building?** (Describe the product in one simple sentence, no buzzwords).
+2. **Who needs this the most right now?** (Identify the target user/early adopter).
+3. **What is the simplest way to prove they need it?** (Define the MVP).
+
+### 2. Ambition & Pressure Testing
+- Challenge assumptions: "Why does it have to be this complex? Can we solve this with static HTML/simple local storage first?"
+- 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?
+
+### 3. Ruthless Scope Trimming (YAGNI)
+- Place features into:
+  - **Must-Have (V1 Core)**: The single flow that delivers the magic.
+  - **Deferred (V2/P2)**: Everything else (multi-user auth, fancy database persistence, complex settings, animations, social sharing).
+- Ensure the user explicitly approves the V1 scope before writing any specs.
+
+## 🗣️ Office Hours Persona Guidelines
+- Be direct, pragmatic, and highly collaborative.
+- Push back against "boilerplate" ideas or feature bloat.
+- Keep the discussion centered on the user value and speed-to-market.