@thanhthi2895/luna-ai 2.16.2

package/agentic/claude/.claude/skills/preview/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: lu:preview
+description: "View files/directories OR generate visual explanations, slides, diagrams."
+argument-hint: "[path] OR --explain|--slides|--diagram|--ascii [topic]"
+---
+
+# Preview
+
+Universal viewer + visual generator. View existing content OR generate new visual explanations.
+
+## Default (No Arguments)
+
+If invoked without arguments, use `AskUserQuestion` to present available preview operations:
+
+| Operation | Description |
+|-----------|-------------|
+| `(view)` | View a file or directory |
+| `--explain` | Generate visual explanation |
+| `--slides` | Generate presentation slides |
+| `--diagram` | Generate architecture diagram |
+| `--ascii` | Terminal-friendly diagram |
+| `--stop` | Stop preview server |
+
+Present as options via `AskUserQuestion` with header "Preview Operation", question "What would you like to do?".
+
+## Usage
+
+### View Mode
+- `/lu:preview <file.md>` - View markdown file in novel-reader UI
+- `/lu:preview <directory/>` - Browse directory contents
+- `/lu:preview --stop` - Stop running server
+
+### Generation Mode
+- `/lu:preview --explain <topic>` - Generate visual explanation (ASCII + Mermaid + prose)
+- `/lu:preview --slides <topic>` - Generate presentation slides (one concept per slide)
+- `/lu:preview --diagram <topic>` - Generate focused diagram (ASCII + Mermaid)
+- `/lu:preview --ascii <topic>` - Generate ASCII-only diagram (terminal-friendly)
+
+## Argument Resolution
+
+When processing arguments, follow this priority order:
+
+1. **`--stop`** → Stop server (exit)
+2. **Generation flags** (`--explain`, `--slides`, `--diagram`, `--ascii`) → Generation mode. Load `references/generation-modes.md`
+3. **Resolve path from argument:**
+   - If argument is an explicit path → use directly
+   - If argument is a contextual reference → resolve from recent conversation context
+4. **Resolved path exists on filesystem** → View mode. Load `references/view-mode.md`
+5. **Path doesn't exist or can't resolve** → Ask user to clarify
+
+**Topic-to-slug conversion:**
+- Lowercase the topic
+- Replace spaces/special chars with hyphens
+- Remove non-alphanumeric except hyphens
+- Collapse multiple hyphens → single hyphen
+- Trim leading/trailing hyphens
+- **Max 80 chars** - truncate at word boundary if longer
+
+**Multiple flags:** If multiple generation flags provided, use first one; remaining treated as topic.
+
+**Placeholder `{topic}`:** Replaced with original user input in title case (not the slug).
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Invalid topic (empty) | Ask user to provide a topic |
+| Flag without topic | Ask user: "Please provide a topic: `/lu:preview --explain <topic>`" |
+| Topic becomes empty after sanitization | Ask for topic with alphanumeric characters |
+| File write failure | Report error, suggest checking permissions |
+| Server startup failure | Check if port in use, try `/lu:preview --stop` first |
+| No generation flag + unresolvable reference | Ask user to clarify which file they meant |
+| Existing file at output path | Overwrite with new content (no prompt) |
+| Server already running | Reuse existing server instance, just open new URL |
+| Parent `plans/` dir missing | Create directories recursively before write |

package/agentic/claude/.claude/skills/preview/references/generation-modes.md

@@ -0,0 +1,95 @@
+# Generation Modes
+
+## Step 1: Determine Output Location
+
+1. Check if there's an active plan context (from `## Plan Context` in hook injection)
+2. If active plan exists: save to `{plan_dir}/visuals/{topic-slug}.md`
+3. If no active plan: save to `plans/visuals/{topic-slug}.md`
+4. Create `visuals/` directory if it doesn't exist
+
+## Step 2: Generate Content
+
+**Mermaid Diagram Syntax:**
+When generating mermaid code blocks, use `/lu:mermaidjs-v11` skill for v11 syntax rules.
+
+**Essential rules (always apply):**
+- Quote node text with special characters: `A["text with /slashes"]`
+- Escape brackets in labels: `A["array[0]"]`
+
+Use the appropriate template based on flag:
+
+### --explain (Visual Explanation)
+```markdown
+# Visual Explanation: {topic}
+
+## Overview
+Brief description of what we're explaining.
+
+## Quick View (ASCII)
+[ASCII diagram of component relationships]
+
+## Detailed Flow
+[Mermaid sequence/flowchart diagram]
+
+## Key Concepts
+1. **Concept A** - Explanation
+2. **Concept B** - Explanation
+
+## Code Example (if applicable)
+[Relevant code snippet with comments]
+```
+
+### --slides (Presentation Format)
+```markdown
+# {Topic} - Visual Presentation
+
+---
+## Slide 1: Introduction
+- One concept per slide
+- Bullet points only
+
+---
+## Slide 2: The Problem
+[Mermaid flowchart]
+
+---
+## Slide 3: The Solution
+- Key point 1
+- Key point 2
+
+---
+## Slide 4: Summary
+Key takeaways...
+```
+
+### --diagram (Focused Diagram)
+```markdown
+# Diagram: {topic}
+
+## ASCII Version
+[ASCII architecture diagram]
+
+## Mermaid Version
+[Mermaid flowchart/graph]
+```
+
+### --ascii (Terminal-Friendly Only)
+```
+[ASCII-only box diagram with legend]
+```
+
+## Step 3: Save and Preview
+
+1. Write generated content to determined path
+2. Start preview server with the generated file:
+```bash
+node .claude/skills/markdown-novel-viewer/scripts/server.cjs \
+  --file "<generated-file-path>" --host 0.0.0.0 --open --foreground
+```
+
+## Step 4: Report to User
+
+Report:
+- Generated file path
+- Preview URL (local + network)
+- Remind: file saved in plan's `visuals/` folder for future reference

package/agentic/claude/.claude/skills/preview/references/view-mode.md

@@ -0,0 +1,42 @@
+# View Mode
+
+## Execution
+
+**IMPORTANT:** Run server as Claude Code background task using `run_in_background: true` with the Bash tool.
+
+The skill is located at `.claude/skills/markdown-novel-viewer/`.
+
+### Stop Server
+
+If `--stop` flag is provided:
+
+```bash
+node .claude/skills/markdown-novel-viewer/scripts/server.cjs --stop
+```
+
+### Start Server
+
+Run the `markdown-novel-viewer` server as CC background task with `--foreground` flag:
+
+```bash
+INPUT_PATH="<resolved-path>"
+if [[ -d "$INPUT_PATH" ]]; then
+  node .claude/skills/markdown-novel-viewer/scripts/server.cjs \
+    --dir "$INPUT_PATH" --host 0.0.0.0 --open --foreground
+else
+  node .claude/skills/markdown-novel-viewer/scripts/server.cjs \
+    --file "$INPUT_PATH" --host 0.0.0.0 --open --foreground
+fi
+```
+
+**Critical:** When calling the Bash tool:
+- Set `run_in_background: true`
+- Set `timeout: 300000` (5 minutes)
+- Parse JSON output and report URL to user
+
+After starting, report:
+- Local URL for browser access
+- Network URL for remote device access
+- Inform user that server is now running as CC background task (visible in `/tasks`)
+
+**CRITICAL:** MUST display the FULL URL including path and query string. NEVER truncate to just `host:port`.

package/agentic/claude/.claude/skills/problem-solving/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: lu:problem-solving
+author: luna
+description: "Apply systematic problem-solving techniques when stuck. Use for complexity spirals, innovation blocks, recurring patterns, assumption constraints, simplification cascades, scale uncertainty."
+version: 1.0.0
+argument-hint: "[problem description]"
+---
+
+# Problem-Solving Techniques
+
+Systematic approaches for different types of stuck-ness. Each technique targets specific problem patterns.
+
+## When to Use
+
+Apply when encountering:
+- **Complexity spiraling** - Multiple implementations, growing special cases, excessive branching
+- **Innovation blocks** - Conventional solutions inadequate, need breakthrough thinking
+- **Recurring patterns** - Same issue across domains, reinventing solutions
+- **Assumption constraints** - Forced into "only way", can't question premise
+- **Scale uncertainty** - Production readiness unclear, edge cases unknown
+- **General stuck-ness** - Unsure which technique applies
+
+## Quick Dispatch
+
+| Stuck Symptom | Technique | Reference |
+|---------------|-----------|-----------|
+| Same thing implemented 5+ ways, growing special cases | **Simplification Cascades** | `references/simplification-cascades.md` |
+| Conventional solutions inadequate, need breakthrough | **Collision-Zone Thinking** | `references/collision-zone-thinking.md` |
+| Same issue in different places, reinventing wheels | **Meta-Pattern Recognition** | `references/meta-pattern-recognition.md` |
+| Solution feels forced, "must be done this way" | **Inversion Exercise** | `references/inversion-exercise.md` |
+| Will this work at production? Edge cases unclear? | **Scale Game** | `references/scale-game.md` |
+| Unsure which technique to use | **When Stuck** | `references/when-stuck.md` |
+
+## Core Techniques
+
+### 1. Simplification Cascades
+Find one insight eliminating multiple components. "If this is true, we don't need X, Y, Z."
+**Red flag:** "Just need to add one more case..." (repeating forever)
+
+### 2. Collision-Zone Thinking
+Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"
+**Red flag:** "I've tried everything in this domain"
+
+### 3. Meta-Pattern Recognition
+Spot patterns appearing in 3+ domains to find universal principles.
+**Red flag:** "This problem is unique" (probably not)
+
+### 4. Inversion Exercise
+Flip core assumptions to reveal hidden constraints. "What if the opposite were true?"
+**Red flag:** "There's only one way to do this"
+
+### 5. Scale Game
+Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths.
+**Red flag:** "Should scale fine" (without testing)
+
+## Application Process
+
+1. **Identify stuck-type** - Match symptom to technique above
+2. **Load detailed reference** - Read specific technique from `references/`
+3. **Apply systematically** - Follow technique's process
+4. **Combine if needed** - Some problems need multiple techniques
+
+## References
+
+- `references/when-stuck.md` - Dispatch flowchart and decision tree
+- `references/simplification-cascades.md` - Cascade detection and extraction
+- `references/collision-zone-thinking.md` - Metaphor collision process
+- `references/meta-pattern-recognition.md` - Pattern abstraction techniques
+- `references/inversion-exercise.md` - Assumption flipping methodology
+- `references/scale-game.md` - Extreme testing procedures

package/agentic/claude/.claude/skills/problem-solving/references/collision-zone-thinking.md

@@ -0,0 +1,79 @@
+# Collision-Zone Thinking
+
+Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"
+
+## Core Principle
+
+Revolutionary insights from deliberate metaphor-mixing. Treat X like Y and see what emerges.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| Stuck in conventional thinking | Force wild domain collision |
+| Solutions feel incremental | Need breakthrough, not optimization |
+| "Tried everything in this domain" | Import concepts from elsewhere |
+| Need innovation, not iteration | Deliberately mix unrelated ideas |
+
+## Quick Reference Collisions
+
+| Treat This | Like This | Discovers |
+|------------|-----------|-----------|
+| Code organization | DNA/genetics | Mutation testing, evolutionary algorithms |
+| Service architecture | Lego bricks | Composable microservices, plug-and-play |
+| Data management | Water flow | Streaming, data lakes, flow-based systems |
+| Request handling | Postal mail | Message queues, async processing |
+| Error handling | Circuit breakers | Fault isolation, graceful degradation |
+
+## Process
+
+1. **Pick two unrelated concepts** from different domains
+2. **Force combination** - "What if we treated [A] like [B]?"
+3. **Explore emergent properties** - What new capabilities appear?
+4. **Test boundaries** - Where does the metaphor break?
+5. **Extract insight** - What did we learn?
+
+## Detailed Example
+
+**Problem:** Complex distributed system with cascading failures
+
+**Collision:** "What if we treated services like electrical circuits?"
+
+**Emergent properties:**
+- Circuit breakers (disconnect on overload)
+- Fuses (one-time failure protection)
+- Ground faults (error isolation)
+- Load balancing (current distribution)
+- Voltage regulation (rate limiting)
+
+**Where it works:** Preventing cascade failures, fault isolation
+
+**Where it breaks:** Circuits don't have retry logic, healing mechanisms
+
+**Insight gained:** Failure isolation patterns from electrical engineering
+
+## Best Source Domains
+
+Rich domains for concept mining:
+- **Physics** - Forces, thermodynamics, relativity
+- **Biology** - Evolution, ecosystems, immune systems
+- **Economics** - Markets, incentives, game theory
+- **Psychology** - Cognition, behavior, motivation
+- **Architecture** - Structure, flow, space utilization
+
+## Red Flags
+
+You need collision-zone thinking when:
+- "I've tried everything in this domain"
+- Solutions feel incremental, not breakthrough
+- Stuck in conventional thinking
+- Need innovation, not optimization
+- "Standard approach isn't working"
+
+## Remember
+
+- Wild combinations often yield best insights
+- Test metaphor boundaries rigorously
+- Document even failed collisions (they teach)
+- Breakthrough > incremental improvement
+- Question: "What would [domain expert] do?"

package/agentic/claude/.claude/skills/problem-solving/references/inversion-exercise.md

@@ -0,0 +1,91 @@
+# Inversion Exercise
+
+Flip core assumptions to reveal hidden constraints and alternative approaches. "What if the opposite were true?"
+
+## Core Principle
+
+**Inversion exposes hidden assumptions.** Sometimes the opposite reveals the truth.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| "There's only one way" | Flip the assumption |
+| Solution feels forced | Invert the constraints |
+| Can't articulate why necessary | Question the "must" |
+| "This is just how it's done" | Try the opposite |
+
+## Quick Reference
+
+| Normal Assumption | Inverted | What It Reveals |
+|-------------------|----------|-----------------|
+| Cache to reduce latency | Add latency to enable caching | Debouncing patterns |
+| Pull data when needed | Push data before needed | Prefetching, eager loading |
+| Handle errors when occur | Make errors impossible | Type systems, contracts |
+| Build features users want | Remove features users don't need | Simplicity >> addition |
+| Optimize for common case | Optimize for worst case | Resilience patterns |
+
+## Process
+
+1. **List core assumptions** - What "must" be true?
+2. **Invert each systematically** - "What if opposite were true?"
+3. **Explore implications** - What would we do differently?
+4. **Find valid inversions** - Which actually work somewhere?
+5. **Document insights** - What did we learn?
+
+## Detailed Example
+
+**Problem:** Users complain app is slow
+
+**Normal approach:** Make everything faster
+- Add caching
+- Optimize queries
+- Use CDN
+- Reduce bundle size
+
+**Inverted approach:** Make things intentionally slower in some places
+- **Debounce search** - Add latency → enable better results (wait for full query)
+- **Rate limit requests** - Add friction → prevent abuse, improve for others
+- **Lazy load content** - Delay loading → reduce initial load time
+- **Progressive rendering** - Show slower → perceived performance
+
+**Insight:** Strategic slowness can improve UX
+
+## Valid vs Invalid Inversions
+
+**Valid inversion example:**
+- Normal: "Store data in database"
+- Inverted: "Derive data on-demand instead of storing"
+- Valid when: Computation cheaper than storage, data changes frequently
+
+**Invalid inversion example:**
+- Normal: "Validate user input"
+- Inverted: "Trust all user input"
+- Invalid because: Security vulnerability, not context-dependent
+
+**Test validity:** Does the inversion work in ANY context? If yes, it's valid somewhere.
+
+## Common Inversions
+
+- **Eager → Lazy** (or vice versa)
+- **Push → Pull** (or vice versa)
+- **Store → Compute** (or vice versa)
+- **Optimize → Simplify** (or vice versa)
+- **Add features → Remove features** (or vice versa)
+
+## Red Flags
+
+You need inversion exercise when:
+- "There's only one way to do this"
+- Forcing solution that feels wrong
+- Can't articulate why approach is necessary
+- "This is just how it's done"
+- Stuck on unquestioned assumptions
+
+## Remember
+
+- Not all inversions work (test boundaries)
+- Valid inversions reveal context-dependence
+- Sometimes opposite is the answer
+- Question "must be" statements
+- Document both successful and failed inversions

package/agentic/claude/.claude/skills/problem-solving/references/meta-pattern-recognition.md

@@ -0,0 +1,87 @@
+# Meta-Pattern Recognition
+
+Spot patterns appearing in 3+ domains to find universal principles.
+
+## Core Principle
+
+**Find patterns in how patterns emerge.** When the same pattern appears in 3+ domains, it's likely a universal principle worth extracting.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| Same issue in different places | Extract the abstract form |
+| Déjà vu in problem-solving | Find the universal pattern |
+| Reinventing wheels across domains | Identify the meta-pattern |
+| "Haven't we done this before?" | Yes, find and reuse it |
+
+## Quick Reference
+
+| Pattern Appears In | Abstract Form | Where Else? |
+|-------------------|---------------|-------------|
+| CPU/DB/HTTP/DNS caching | Store frequently-accessed data closer | LLM prompt caching, CDN |
+| Layering (network/storage/compute) | Separate concerns into abstraction levels | Architecture, org structure |
+| Queuing (message/task/request) | Decouple producer from consumer with buffer | Event systems, async |
+| Pooling (connection/thread/object) | Reuse expensive resources | Memory mgmt, governance |
+
+## Process
+
+1. **Spot repetition** - See same shape in 3+ places
+2. **Extract abstract form** - Describe independent of any domain
+3. **Identify variations** - How does it adapt per domain?
+4. **Check applicability** - Where else might this help?
+5. **Document pattern** - Make it reusable
+
+## Detailed Example
+
+**Pattern spotted:** Rate limiting appears in:
+- API throttling (requests per minute)
+- Traffic shaping (packets per second)
+- Circuit breakers (failures per window)
+- Admission control (concurrent connections)
+
+**Abstract form:** Bound resource consumption to prevent exhaustion
+
+**Variation points:**
+- What resource (requests, packets, failures, connections)
+- What limit (per time window, concurrent, cumulative)
+- What happens when exceeded (reject, queue, degrade)
+
+**New application:** LLM token budgets
+- Same pattern: prevent context window exhaustion
+- Resource: tokens
+- Limit: context window size
+- Action: truncate or reject
+
+## 3+ Domain Rule
+
+**Why 3 domains?**
+- 1 occurrence = coincidence
+- 2 occurrences = possible pattern
+- 3+ occurrences = likely universal
+
+**Domain independence test:**
+Can you describe the pattern without mentioning specific domains?
+
+## Red Flags
+
+Signs you're missing meta-patterns:
+- "This problem is unique" (probably not)
+- Multiple teams solving "different" problems identically
+- Reinventing wheels across domains
+- "Haven't we done something like this?" (yes, find it)
+
+## Benefits of Meta-Patterns
+
+- **Battle-tested** - Proven across multiple domains
+- **Reusable** - Apply to new situations
+- **Universal** - Domain-independent solutions
+- **Documented** - Known variations and trade-offs
+
+## Remember
+
+- 3+ domains = likely universal
+- Abstract form reveals new applications
+- Variations show adaptation points
+- Universal patterns save time
+- Document for future reuse

package/agentic/claude/.claude/skills/problem-solving/references/scale-game.md

@@ -0,0 +1,95 @@
+# Scale Game
+
+Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales.
+
+## Core Principle
+
+**Extremes expose fundamentals.** What works at one scale fails at another.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| "Should scale fine" (without testing) | Test at extremes |
+| Uncertain about production behavior | Scale up 1000x |
+| Edge cases unclear | Test minimum and maximum |
+| Architecture validation needed | Extreme testing |
+
+## Quick Reference
+
+| Scale Dimension | Test At Extremes | What It Reveals |
+|-----------------|------------------|-----------------|
+| **Volume** | 1 item vs 1B items | Algorithmic complexity limits |
+| **Speed** | Instant vs 1 year | Async requirements, caching needs |
+| **Users** | 1 user vs 1B users | Concurrency issues, resource limits |
+| **Duration** | Milliseconds vs years | Memory leaks, state growth |
+| **Failure rate** | Never fails vs always fails | Error handling adequacy |
+
+## Process
+
+1. **Pick dimension** - What could vary extremely?
+2. **Test minimum** - What if 1000x smaller/faster/fewer?
+3. **Test maximum** - What if 1000x bigger/slower/more?
+4. **Note what breaks** - Where do limits appear?
+5. **Note what survives** - What's fundamentally sound?
+6. **Design for reality** - Use insights to validate architecture
+
+## Detailed Examples
+
+### Example 1: Error Handling
+- **Normal scale:** "Handle errors when they occur" works fine
+- **At 1B scale:** Error volume overwhelms logging, crashes system
+- **Reveals:** Need to make errors impossible (type systems) or expect them (chaos engineering)
+- **Action:** Design error handling for volume, not just occurrence
+
+### Example 2: Synchronous APIs
+- **Normal scale:** Direct function calls work, < 100ms latency
+- **At global scale:** Network latency makes synchronous unusable (200-500ms)
+- **Reveals:** Async/messaging becomes survival requirement, not optimization
+- **Action:** Design async-first from start
+
+### Example 3: In-Memory State
+- **Normal duration:** Works for hours/days in development
+- **At years:** Memory grows unbounded, eventual crash (weeks → months → years)
+- **Reveals:** Need persistence or periodic cleanup, can't rely on memory forever
+- **Action:** Design for stateless or externalized state
+
+### Example 4: Single vs Million Users
+- **Normal scale:** Session in memory works for 100 users
+- **At 1M scale:** Memory exhausted, server crashes
+- **Reveals:** Need distributed session store (Redis, database)
+- **Action:** Design for horizontal scaling from start
+
+## Both Directions Matter
+
+**Test smaller too:**
+- What if only 1 user? Does complexity make sense?
+- What if only 10 items? Is optimization premature?
+- What if instant response? What becomes unnecessary?
+
+Often reveals over-engineering or premature optimization.
+
+## Red Flags
+
+You need scale game when:
+- "It works in dev" (but will it work in production?)
+- No idea where limits are
+- "Should scale fine" (without evidence)
+- Surprised by production behavior
+- Architecture feels arbitrary
+
+## Success Metrics
+
+After scale game, you should know:
+- Where system breaks (exact limits)
+- What survives (fundamentally sound parts)
+- What needs redesign (scale-dependent)
+- Production readiness (validated architecture)
+
+## Remember
+
+- Extremes reveal fundamentals hidden at normal scales
+- What works at one scale fails at another
+- Test BOTH directions (bigger AND smaller)
+- Use insights to validate architecture early
+- Don't guess - test at extremes