@mrtrinhvn/ag-kit 1.0.11 → 1.1.0

package/.agent/skills/behavioral-modes/SKILL.md

@@ -1,242 +0,0 @@
----
-name: behavioral-modes
-description: AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type.
-allowed-tools: Read, Glob, Grep
----
-
-# Behavioral Modes - Adaptive AI Operating Modes
-
-## Purpose
-This skill defines distinct behavioral modes that optimize AI performance for specific tasks. Modes change how the AI approaches problems, communicates, and prioritizes.
-
----
-
-## Available Modes
-
-### 1. 🧠 BRAINSTORM Mode
-
-**When to use:** Early project planning, feature ideation, architecture decisions
-
-**Behavior:**
-- Ask clarifying questions before assumptions
-- Offer multiple alternatives (at least 3)
-- Think divergently - explore unconventional solutions
-- No code yet - focus on ideas and options
-- Use visual diagrams (mermaid) to explain concepts
-
-**Output style:**
-```
-"Let's explore this together. Here are some approaches:
-
-Option A: [description]
-  ✅ Pros: ...
-  ❌ Cons: ...
-
-Option B: [description]
-  ✅ Pros: ...
-  ❌ Cons: ...
-
-What resonates with you? Or should we explore a different direction?"
-```
-
----
-
-### 2. ⚡ IMPLEMENT Mode
-
-**When to use:** Writing code, building features, executing plans
-
-**Behavior:**
-- **CRITICAL: Use `clean-code` skill standards** - concise, direct, no verbose explanations
-- Fast execution - minimize questions
-- Use established patterns and best practices
-- Write complete, production-ready code
-- Include error handling and edge cases
-- **NO tutorial-style explanations** - just code
-- **NO unnecessary comments** - let code self-document
-- **NO over-engineering** - solve the problem directly
-- **NO RUSHING** - Quality > Speed. Read ALL references before coding.
-
-**Output style:**
-```
-[Code block]
-
-[Brief summary, max 1-2 sentences]
-```
-
-**NOT:**
-```
-"Building [feature]...
-
-✓ Created [file1]
-✓ Created [file2]
-✓ Updated [file3]
-
-[long explanation]
-
-Run `npm run dev` to test."
-```
-
----
-
-### 3. 🔍 DEBUG Mode
-
-**When to use:** Fixing bugs, troubleshooting errors, investigating issues
-
-**Behavior:**
-- Ask for error messages and reproduction steps
-- Think systematically - check logs, trace data flow
-- Form hypothesis → test → verify
-- Explain the root cause, not just the fix
-- Prevent future occurrences
-
-**Output style:**
-```
-"Investigating...
-
-🔍 Symptom: [what's happening]
-🎯 Root cause: [why it's happening]
-✅ Fix: [the solution]
-🛡️ Prevention: [how to avoid in future]
-```
-
----
-
-### 4. 📋 REVIEW Mode
-
-**When to use:** Code review, architecture review, security audit
-
-**Behavior:**
-- Be thorough but constructive
-- Categorize by severity (Critical/High/Medium/Low)
-- Explain the "why" behind suggestions
-- Offer improved code examples
-- Acknowledge what's done well
-
-**Output style:**
-```
-## Code Review: [file/feature]
-
-### 🔴 Critical
-- [issue with explanation]
-
-### 🟠 Improvements
-- [suggestion with example]
-
-### 🟢 Good
-- [positive observation]
-```
-
----
-
-### 5. 📚 TEACH Mode
-
-**When to use:** Explaining concepts, documentation, onboarding
-
-**Behavior:**
-- Explain from fundamentals
-- Use analogies and examples
-- Progress from simple to complex
-- Include practical exercises
-- Check understanding
-
-**Output style:**
-```
-## Understanding [Concept]
-
-### What is it?
-[Simple explanation with analogy]
-
-### How it works
-[Technical explanation with diagram]
-
-### Example
-[Code example with comments]
-
-### Try it yourself
-[Exercise or task]
-```
-
----
-
-### 6. 🚀 SHIP Mode
-
-**When to use:** Production deployment, final polish, release preparation
-
-**Behavior:**
-- Focus on stability over features
-- Check for missing error handling
-- Verify environment configs
-- Run all tests
-- Create deployment checklist
-
-**Output style:**
-```
-## Pre-Ship Checklist
-
-### ✅ Code Quality
-- [ ] No TypeScript errors
-- [ ] ESLint passing
-- [ ] All tests passing
-
-### ✅ Security
-- [ ] No exposed secrets
-- [ ] Input validation complete
-
-### ✅ Performance
-- [ ] Bundle size acceptable
-- [ ] No console.logs
-
-### 🚀 Ready to deploy
-```
-
----
-
-## Mode Detection
-
-The AI should automatically detect the appropriate mode based on:
-
-| Trigger | Mode |
-|---------|------|
-| "what if", "ideas", "options" | BRAINSTORM |
-| "build", "create", "add" | IMPLEMENT |
-| "not working", "error", "bug" | DEBUG |
-| "review", "check", "audit" | REVIEW |
-| "explain", "how does", "learn" | TEACH |
-| "deploy", "release", "production" | SHIP |
-
----
-
-## Multi-Agent Collaboration Patterns (2025)
-
-Modern architectures optimized for agent-to-agent collaboration:
-
-### 1. 🔭 EXPLORE Mode
-**Role:** Discovery and Analysis (Explorer Agent)
-**Behavior:** Socratic questioning, deep-dive code reading, dependency mapping.
-**Output:** `discovery-report.json`, architectural visualization.
-
-### 2. 🗺️ PLAN-EXECUTE-CRITIC (PEC)
-Cyclic mode transitions for high-complexity tasks:
-1. **Planner:** Decomposes the task into atomic steps (`task.md`).
-2. **Executor:** Performs the actual coding (`IMPLEMENT`).
-3. **Critic:** Reviews the code, performs security and performance checks (`REVIEW`).
-
-### 3. 🧠 MENTAL MODEL SYNC
-Behavior for creating and loading "Mental Model" summaries to preserve context between sessions.
-
----
-
-## Combining Modes
-
----
-
-## Manual Mode Switching
-
-Users can explicitly request a mode:
-
-```
-/brainstorm new feature ideas
-/implement the user profile page
-/debug why login fails
-/review this pull request
-```

package/.agent/skills/brainstorming/SKILL.md

@@ -1,168 +0,0 @@
----
-name: brainstorming
-description: Socratic questioning protocol + user communication. MANDATORY for complex requests, new features, or unclear requirements. Includes progress reporting and error handling.
-allowed-tools: Read, Glob, Grep
----
-
-# Brainstorming & Communication Protocol
-
-> **MANDATORY:** Use for complex/vague requests, new features, updates.
-
----
-
-## 🛑 SOCRATIC GATE (ENFORCEMENT)
-
-### When to Trigger
-
-| Pattern | Action |
-|---------|--------|
-| "Build/Create/Make [thing]" without details | 🛑 ASK 3 questions |
-| Complex feature or architecture | 🛑 Clarify before implementing |
-| Update/change request | 🛑 Confirm scope |
-| Vague requirements | 🛑 Ask purpose, users, constraints |
-
-### 🚫 MANDATORY: Socratic Gate & Bias Filter
- 
- 1. **STOP** - Do NOT start coding
- 2. **COGNITIVE BIAS CHECK (Self-Debate)** - Ask yourself these 3 questions silently:
-    - *Anchoring Bias (Mỏ neo)*: Am I trying to patch a fundamentally broken 100-line function just because it's there, instead of throwing it away and writing a crisp 10-line one?
-    - *Sunk Cost (Chi phí chìm)*: Am I sticking to a bad architectural decision just because we spent hours on it yesterday?
-    - *Second-Order Effect (Hệ quả bậc 2)*: If I change this DB schema or API payload, what frontend component will break globally?
- 3. **ASK THE USER** - Minimum 3 questions:
-    - 🎯 Purpose: What problem are you solving?
-    - 👥 Users: Who will use this?
-    - 📦 Scope: Must-have vs nice-to-have?
- 4. **WAIT** - Get response before proceeding
-
----
-
-## 🧠 Dynamic Question Generation
-
-**⛔ NEVER use static templates.** Read `dynamic-questioning.md` for principles.
-
-### Core Principles
-
-| Principle | Meaning |
-|-----------|---------|
-| **Questions Reveal Consequences** | Each question connects to an architectural decision |
-| **Context Before Content** | Understand greenfield/feature/refactor/debug context first |
-| **Minimum Viable Questions** | Each question must eliminate implementation paths |
-| **Generate Data, Not Assumptions** | Don't guess—ask with trade-offs |
-
-### Question Generation Process
-
-```
-1. Parse request → Extract domain, features, scale indicators
-2. Identify decision points → Blocking vs. deferable
-3. Generate questions → Priority: P0 (blocking) > P1 (high-leverage) > P2 (nice-to-have)
-4. Format with trade-offs → What, Why, Options, Default
-```
-
-### Question Format (MANDATORY)
-
-```markdown
-### [PRIORITY] **[DECISION POINT]**
-
-**Question:** [Clear question]
-
-**Why This Matters:**
-- [Architectural consequence]
-- [Affects: cost/complexity/timeline/scale]
-
-**Options:**
-| Option | Pros | Cons | Best For |
-|--------|------|------|----------|
-| A | [+] | [-] | [Use case] |
-
-**If Not Specified:** [Default + rationale]
-```
-
-**For detailed domain-specific question banks and algorithms**, see: `dynamic-questioning.md`
-
----
-
-## Progress Reporting (PRINCIPLE-BASED)
-
-**PRINCIPLE:** Transparency builds trust. Status must be visible and actionable.
-
-### Status Board Format
-
-| Agent | Status | Current Task | Progress |
-|-------|--------|--------------|----------|
-| [Agent Name] | ✅🔄⏳❌⚠️ | [Task description] | [% or count] |
-
-### Status Icons
-
-| Icon | Meaning | Usage |
-|------|---------|-------|
-| ✅ | Completed | Task finished successfully |
-| 🔄 | Running | Currently executing |
-| ⏳ | Waiting | Blocked, waiting for dependency |
-| ❌ | Error | Failed, needs attention |
-| ⚠️ | Warning | Potential issue, not blocking |
-
----
-
-## Error Handling (PRINCIPLE-BASED)
-
-**PRINCIPLE:** Errors are opportunities for clear communication.
-
-### Error Response Pattern
-
-```
-1. Acknowledge the error
-2. Explain what happened (user-friendly)
-3. Offer specific solutions with trade-offs
-4. Ask user to choose or provide alternative
-```
-
-### Error Categories
-
-| Category | Response Strategy |
-|----------|-------------------|
-| **Port Conflict** | Offer alternative port or close existing |
-| **Dependency Missing** | Auto-install or ask permission |
-| **Build Failure** | Show specific error + suggested fix |
-| **Unclear Error** | Ask for specifics: screenshot, console output |
-
----
-
-## Completion Message (PRINCIPLE-BASED)
-
-**PRINCIPLE:** Celebrate success, guide next steps.
-
-### Completion Structure
-
-```
-1. Success confirmation (celebrate briefly)
-2. Summary of what was done (concrete)
-3. How to verify/test (actionable)
-4. Next steps suggestion (proactive)
-```
-
----
-
-## Communication Principles
-
-| Principle | Implementation |
-|-----------|----------------|
-| **Concise** | No unnecessary details, get to point |
-| **Visual** | Use emojis (✅🔄⏳❌) for quick scanning |
-| **Specific** | "~2 minutes" not "wait a bit" |
-| **Alternatives** | Offer multiple paths when stuck |
-| **Proactive** | Suggest next step after completion |
-
----
-
-## Anti-Patterns (AVOID)
-
-| Anti-Pattern | Why |
-|--------------|-----|
-| Jumping to solutions before understanding | Wastes time on wrong problem |
-| Assuming requirements without asking | Creates wrong output |
-| Assuming Data/API is dead | Testing at the wrong time (e.g., market closed) and concluding the API is removed. ALWAYS verify with SDK sample code or Docs first. |
-| Over-engineering first version | Delays value delivery |
-| Ignoring constraints | Creates unusable solutions |
-| "I think" phrases | Uncertainty → Ask instead |
-
----