@heyai-rules/pilo-masterkit 2.1.0 → 3.1.0

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

@@ -1,242 +1,242 @@
----
-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
-```
+---
+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/benchmark/SKILL.md

@@ -1,93 +1,93 @@
----
-name: benchmark
-description: Use this skill to measure performance baselines, detect regressions before/after PRs, and compare stack alternatives.
-origin: ECC
----
-
-# Benchmark — Performance Baseline & Regression Detection
-
-## When to Use
-
-- Before and after a PR to measure performance impact
-- Setting up performance baselines for a project
-- When users report "it feels slow"
-- Before a launch — ensure you meet performance targets
-- Comparing your stack against alternatives
-
-## How It Works
-
-### Mode 1: Page Performance
-
-Measures real browser metrics via browser MCP:
-
-```
-1. Navigate to each target URL
-2. Measure Core Web Vitals:
-   - LCP (Largest Contentful Paint) — target < 2.5s
-   - CLS (Cumulative Layout Shift) — target < 0.1
-   - INP (Interaction to Next Paint) — target < 200ms
-   - FCP (First Contentful Paint) — target < 1.8s
-   - TTFB (Time to First Byte) — target < 800ms
-3. Measure resource sizes:
-   - Total page weight (target < 1MB)
-   - JS bundle size (target < 200KB gzipped)
-   - CSS size
-   - Image weight
-   - Third-party script weight
-4. Count network requests
-5. Check for render-blocking resources
-```
-
-### Mode 2: API Performance
-
-Benchmarks API endpoints:
-
-```
-1. Hit each endpoint 100 times
-2. Measure: p50, p95, p99 latency
-3. Track: response size, status codes
-4. Test under load: 10 concurrent requests
-5. Compare against SLA targets
-```
-
-### Mode 3: Build Performance
-
-Measures development feedback loop:
-
-```
-1. Cold build time
-2. Hot reload time (HMR)
-3. Test suite duration
-4. TypeScript check time
-5. Lint time
-6. Docker build time
-```
-
-### Mode 4: Before/After Comparison
-
-Run before and after a change to measure impact:
-
-```
-/benchmark baseline    # saves current metrics
-# ... make changes ...
-/benchmark compare     # compares against baseline
-```
-
-Output:
-```
-| Metric | Before | After | Delta | Verdict |
-|--------|--------|-------|-------|---------|
-| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
-| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
-| Build | 12s | 14s | +2s | WARNING: WARN |
-```
-
-## Output
-
-Stores baselines in `.ecc/benchmarks/` as JSON. Git-tracked so the team shares baselines.
-
-## Integration
-
-- CI: run `/benchmark compare` on every PR
-- Pair with `/canary-watch` for post-deploy monitoring
-- Pair with `/browser-qa` for full pre-ship checklist
+---
+name: benchmark
+description: Use this skill to measure performance baselines, detect regressions before/after PRs, and compare stack alternatives.
+origin: ECC
+---
+
+# Benchmark — Performance Baseline & Regression Detection
+
+## When to Use
+
+- Before and after a PR to measure performance impact
+- Setting up performance baselines for a project
+- When users report "it feels slow"
+- Before a launch — ensure you meet performance targets
+- Comparing your stack against alternatives
+
+## How It Works
+
+### Mode 1: Page Performance
+
+Measures real browser metrics via browser MCP:
+
+```
+1. Navigate to each target URL
+2. Measure Core Web Vitals:
+   - LCP (Largest Contentful Paint) — target < 2.5s
+   - CLS (Cumulative Layout Shift) — target < 0.1
+   - INP (Interaction to Next Paint) — target < 200ms
+   - FCP (First Contentful Paint) — target < 1.8s
+   - TTFB (Time to First Byte) — target < 800ms
+3. Measure resource sizes:
+   - Total page weight (target < 1MB)
+   - JS bundle size (target < 200KB gzipped)
+   - CSS size
+   - Image weight
+   - Third-party script weight
+4. Count network requests
+5. Check for render-blocking resources
+```
+
+### Mode 2: API Performance
+
+Benchmarks API endpoints:
+
+```
+1. Hit each endpoint 100 times
+2. Measure: p50, p95, p99 latency
+3. Track: response size, status codes
+4. Test under load: 10 concurrent requests
+5. Compare against SLA targets
+```
+
+### Mode 3: Build Performance
+
+Measures development feedback loop:
+
+```
+1. Cold build time
+2. Hot reload time (HMR)
+3. Test suite duration
+4. TypeScript check time
+5. Lint time
+6. Docker build time
+```
+
+### Mode 4: Before/After Comparison
+
+Run before and after a change to measure impact:
+
+```
+/benchmark baseline    # saves current metrics
+# ... make changes ...
+/benchmark compare     # compares against baseline
+```
+
+Output:
+```
+| Metric | Before | After | Delta | Verdict |
+|--------|--------|-------|-------|---------|
+| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
+| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
+| Build | 12s | 14s | +2s | WARNING: WARN |
+```
+
+## Output
+
+Stores baselines in `.ecc/benchmarks/` as JSON. Git-tracked so the team shares baselines.
+
+## Integration
+
+- CI: run `/benchmark compare` on every PR
+- Pair with `/canary-watch` for post-deploy monitoring
+- Pair with `/browser-qa` for full pre-ship checklist