@thanhthi2895/luna-ai 2.16.2

package/agentic/antigravity/.agents/skills/plan/references/codebase-understanding.md

@@ -0,0 +1,56 @@
+# Codebase Understanding Phase
+
+**When to skip:** If provided with scout reports, skip this phase.
+
+## Core Activities
+
+### Parallel Scout Agents
+- Start semantic discovery with `ccc search`; use `/lu:scout` for broad discovery only; use `find_by_name + grep_search` for deterministic narrowing
+- Each scout locates files needed for specific task aspects
+- Wait for all scout agents to report back before analysis
+- Efficient for finding relevant code across large codebases
+
+### Essential Documentation Review
+ALWAYS read these files first:
+
+1. **`./docs/code-standards.md`** (IMPORTANT)
+   - File Name Conventions
+   - File Size Management
+   - Development rules and best practices
+   - Code quality standards
+   - Security guidelines
+
+2. **`./docs/codebase-summary.md`**
+   - Project structure and current status
+   - High-level architecture overview
+   - Component relationships
+
+3. **`./docs/system-architecture.md`**
+   - System design and component interactions
+   - Data flows and API contracts
+
+### Environment Analysis
+- Review development environment setup
+- Analyze dotenv files and configuration
+- Identify required dependencies
+- Understand build and deployment processes
+
+### Pattern Recognition
+- Study existing patterns in codebase
+- Identify conventions and architectural decisions
+- Note consistency in implementation approaches
+- Understand error handling patterns
+
+### Integration Planning
+- Identify how new features integrate with existing architecture
+- Map dependencies between components
+- Understand data flow and state management
+- Consider backward compatibility
+
+## Best Practices
+
+- Start with documentation before diving into code
+- Use `ccc search` first, then scouts for broad targeted file discovery
+- Document patterns found for consistency
+- Note any inconsistencies or technical debt
+- Consider impact on existing features

package/agentic/antigravity/.agents/skills/plan/references/output-standards.md

@@ -0,0 +1,111 @@
+# Output Standards & Quality
+
+## Plan File Format
+
+### Phase Heading Format (Required for plan.md)
+
+Use **`## Phase N:` heading** — required for `validate-plan.js` to detect phases correctly.
+
+Do NOT use list-item format `- [ ] **Phase N:**`.
+
+### Auto-Population Rules
+
+When creating plans, auto-populate these fields:
+- **status**: Always `pending` for new plans
+- **priority**: From user request or default `P2`
+- **effort**: Sum of phase estimates
+- **branch**: Current git branch (`git branch --show-current`)
+- **created**: Today's date in YYYY-MM-DD format
+
+### Task Naming Conventions
+
+**subject** (imperative): Action verb + deliverable, <60 chars
+  Examples: "Setup database migrations", "Implement OAuth2 flow"
+
+**activeForm** (continuous): Present participle of subject
+  Examples: "Setting up database", "Implementing OAuth2"
+
+**description**: 1-2 sentences, concrete deliverables, reference phase file
+
+See `task-management.md` for full checkbox sync patterns via `replace_file_content`.
+
+## Task Breakdown
+
+- Transform complex requirements into manageable, actionable tasks
+- Each task independently executable with clear dependencies
+- Prioritize by dependencies, risk, business value
+- Eliminate ambiguity in instructions
+- Include specific file paths for all modifications
+- Provide clear acceptance criteria per task
+
+### File Management
+
+List affected files with:
+- Full paths (not relative)
+- Action type (modify/create/delete)
+- Brief change description
+- Dependencies on other changes
+- Fully respect the `./docs/code-standards.md` file.
+
+## Workflow Process
+
+1. **Initial Analysis** → Read docs, understand context
+2. **Research Phase** → Spawn researchers in parallel, investigate approaches
+3. **Synthesis** → Analyze reports, identify optimal solution
+4. **Design Phase** → Create architecture, implementation design
+5. **Plan Documentation** → Write comprehensive plan in Markdown
+6. **Review & Refine** → Ensure completeness, clarity, actionability
+
+## Output Requirements
+
+### What Planners Do
+- Create plans ONLY (no implementation)
+- Provide plan file path and summary
+- Self-contained plans with necessary context
+- Code snippets/pseudocode when clarifying
+- Multiple options with trade-offs when appropriate
+- Fully respect the `./docs/code-standards.md` file.
+
+### Writing Style
+**IMPORTANT:** Sacrifice grammar for concision
+- Focus clarity over eloquence
+- Use bullets and lists
+- Short sentences
+- Remove unnecessary words
+- Prioritize actionable info
+
+### Unresolved Questions
+**IMPORTANT:** Ask the user directly in your response text for unresolved questions at the end
+- Questions needing clarification
+- Technical decisions requiring input
+- Unknowns impacting implementation
+- Trade-offs requiring business decisions
+Revise the plan and phases based on the answers.
+
+## Quality Standards
+
+### Thoroughness
+- Thorough and specific in research/planning
+- Consider edge cases, failure modes
+- Think through entire user journey
+- Document all assumptions
+
+### Maintainability
+- Consider long-term maintainability
+- Design for future modifications
+- Document decision rationale
+- Avoid over-engineering
+
+### Security & Performance
+- Address all security concerns
+- Identify performance implications
+- Plan for scalability
+- Consider resource constraints
+
+### Implementability
+- Detailed enough for junior developers
+- Validate against existing patterns
+- Ensure codebase standards consistency
+- Provide clear examples
+
+**Remember:** Plan quality determines implementation success. Be comprehensive, consider all solution aspects.

package/agentic/antigravity/.agents/skills/plan/references/plan-organization.md

@@ -0,0 +1,127 @@
+# Plan Creation & Organization
+
+## Directory Structure
+
+### Plan Location
+
+Use `Plan dir:` from `## Naming` section injected by hooks. This is the full computed path.
+
+### File Organization
+
+IN CURRENT WORKING PROJECT DIRECTORY:
+```
+{plan-dir}/
+├── research/
+│   ├── researcher-XX-report.md
+│   └── ...
+├── reports/
+│   ├── scout-report.md
+│   ├── researcher-report.md
+│   └── ...
+├── plan.md                                    # Overview access point
+├── phase-01-setup-environment.md
+├── phase-02-implement-database.md
+├── phase-03-implement-api-endpoints.md
+└── ...
+```
+
+### Task Hydration
+
+After creating plan.md and phase files, hydrate tasks (unless `--no-tasks`):
+1. Update `plan.md` and phase checkboxes via `replace_file_content` using a dependency-aware sequence
+2. Add critical step tasks for high-risk items
+3. See `task-management.md` for patterns and cook handoff protocol
+
+### Active Plan State Tracking
+
+See SKILL.md "Active Plan State" section for full rules. Key points:
+- Check `## Plan Context` injected by hooks for active/suggested/none state
+- After creating plan: `node agentic/antigravity/.agents/scripts/set-active-plan.cjs {plan-dir}` (global: `node ~/.gemini/antigravity/scripts/set-active-plan.cjs {plan-dir}`)
+- Active plans use plan-specific reports path; suggested plans use default path
+
+## File Structure
+
+### Overview Plan (plan.md)
+
+Use **`## Phase N:` heading format** — required for `validate-plan.js` to detect phases correctly.
+
+```markdown
+# Feature Implementation Plan
+
+## Overview
+
+Brief description of what this plan accomplishes.
+
+## Phase 1: Setup — one-line description
+
+> [phase-01-setup.md](phase-01-setup.md)
+
+- [ ] Done
+
+## Phase 2: Implementation — one-line description
+
+> [phase-02-impl.md](phase-02-impl.md)
+
+- [ ] Done
+```
+
+**Guidelines:**
+- Keep generic and under 80 lines
+- List each phase with status/progress
+- Link to detailed phase files
+- Key dependencies
+
+### Phase Files (phase-XX-name.md)
+Fully respect the `./docs/code-standards.md` file.
+Use `agentic/antigravity/.agents/templates/plans/phase.md` template.
+
+Each phase file should contain:
+
+**Context Links**
+- Links to related reports, files, documentation
+
+**Overview**
+- Priority
+- Current status
+- Brief description
+
+**Key Insights**
+- Important findings from research
+- Critical considerations
+
+**Requirements**
+- Functional requirements
+- Non-functional requirements
+
+**Architecture**
+- System design
+- Component interactions
+- Data flow
+
+**Related Code Files**
+- List of files to modify
+- List of files to create
+- List of files to delete
+
+**Implementation Steps**
+- Detailed, numbered steps
+- Specific instructions
+
+**Todo List**
+- Checkbox list for tracking
+
+**Success Criteria**
+- Definition of done
+- Validation methods
+
+**Risk Assessment**
+- Potential issues
+- Mitigation strategies
+
+**Security Considerations**
+- Auth/authorization
+- Data protection
+
+**Next Steps**
+- Dependencies
+- Follow-up tasks

package/agentic/antigravity/.agents/skills/plan/references/red-team-personas.md

@@ -0,0 +1,69 @@
+# Red Team Personas
+
+## Available Lenses
+
+| Reviewer | Lens | Focus |
+|----------|------|-------|
+| **Security Adversary** | Attacker mindset | Auth bypass, injection, data exposure, privilege escalation, supply chain, OWASP top 10 |
+| **Failure Mode Analyst** | Murphy's Law | Race conditions, data loss, cascading failures, recovery gaps, deployment risks, rollback holes |
+| **Assumption Destroyer** | Skeptic | Unstated dependencies, false "will work" claims, missing error paths, scale assumptions, integration assumptions |
+| **Scope & Complexity Critic** | YAGNI enforcer | Over-engineering, premature abstraction, unnecessary complexity, missing MVP cuts, scope creep, gold plating |
+
+## Reviewer Prompt Template
+
+Each reviewer prompt MUST include:
+
+1. This override: `"IGNORE your default code-review instructions. You are reviewing a PLAN DOCUMENT, not code. There is no code to lint, build, or test. Focus exclusively on plan quality."`
+2. Their specific adversarial lens and persona
+3. The plan file paths so they can read original files directly
+4. These instructions:
+
+```
+You are a hostile reviewer. Your job is to DESTROY this plan.
+Adopt the {LENS_NAME} perspective. Find every flaw you can.
+
+Rules:
+- Be specific: cite exact phase/section where the flaw lives
+- Be concrete: describe the failure scenario, not just "could be a problem"
+- Rate severity: Critical (blocks success) | High (significant risk) | Medium (notable concern)
+- Skip trivial observations (style, naming, formatting)
+- No praise. No "overall looks good". Only findings.
+- 5-10 findings per reviewer. Quality over quantity.
+
+Output format per finding:
+## Finding {N}: {title}
+- **Severity:** Critical | High | Medium
+- **Location:** Phase {X}, section "{name}"
+- **Flaw:** {what's wrong}
+- **Failure scenario:** {concrete description of how this fails}
+- **Evidence:** {quote from plan or missing element}
+- **Suggested fix:** {brief recommendation}
+```
+
+## Adjudication Format
+
+```markdown
+## Red Team Findings
+
+### Finding 1: {title} — {SEVERITY}
+**Reviewer:** {lens name}
+**Location:** {phase/section}
+**Flaw:** {description}
+**Failure scenario:** {concrete scenario}
+**Disposition:** Accept | Reject
+**Rationale:** {why accept/reject — be specific}
+```
+
+## Plan.md Section Format
+
+```markdown
+## Red Team Review
+
+### Session — {YYYY-MM-DD}
+**Findings:** {total} ({accepted} accepted, {rejected} rejected)
+**Severity breakdown:** {N} Critical, {N} High, {N} Medium
+
+| # | Finding | Severity | Disposition | Applied To |
+|---|---------|----------|-------------|------------|
+| 1 | {title} | Critical | Accept | Phase 2 |
+```

package/agentic/antigravity/.agents/skills/plan/references/red-team-workflow.md

@@ -0,0 +1,77 @@
+# Red Team Review
+
+Adversarially review an implementation plan by spawning parallel reviewer subagents that try to tear it apart. Each reviewer adopts a different hostile lens. You then adjudicate findings, and the user decides which to apply.
+
+**Mindset:** Like hiring someone who hates the implementer to destroy their work.
+
+## Plan Resolution
+
+1. If `$ARGUMENTS` provided → Use that path
+2. Else check `## Plan Context` section → Use active plan path
+3. If no plan found → Ask user to specify path or run `/lu:plan` first
+
+## Workflow
+
+### Step 1: Read Plan Files
+Read the plan directory:
+- `plan.md` — Overview, phases, dependencies
+- `phase-*.md` — All phase files (full content)
+
+### Step 2: Scale Reviewer Count
+
+| Phase Count | Reviewers | Lenses Selected |
+|-------------|-----------|-----------------|
+| 1-2 phases | 2 | Security Adversary + Assumption Destroyer |
+| 3-5 phases | 3 | + Failure Mode Analyst |
+| 6+ phases | 4 | + Scope & Complexity Critic (all lenses) |
+
+### Step 3: Define Adversarial Lenses
+Load: `references/red-team-personas.md`
+
+### Step 4: Spawn Reviewers
+Launch reviewers simultaneously via Task tool with `subagent_type: "code-reviewer"`.
+Each reviewer prompt MUST include override, persona, plan file paths, and hostile instructions.
+Load: `references/red-team-personas.md` for reviewer prompt template.
+
+### Step 5: Collect, Deduplicate & Cap
+1. Collect all findings
+2. Deduplicate overlapping findings
+3. Sort by severity: Critical → High → Medium
+4. Cap at 15 findings
+
+### Step 6: Adjudicate
+For each finding, evaluate and propose: **Accept** or **Reject**.
+
+### Step 7: User Review
+Ask in your response:
+- "Looks good, apply accepted findings"
+- "Let me review each one"
+- "Reject all, plan is fine"
+
+**If "Let me review each one":**
+For each finding marked Accept, ask in your response:
+- Options: "Yes, apply" | "No, reject" | "Modify suggestion"
+
+**If "Modify suggestion":**
+Ask in your response: "Describe your modification to this finding's suggested fix:"
+(user provides free text via "Other" option)
+Record the modified suggestion. Set disposition to "Accept (modified)" in the Red Team Review table.
+
+### Step 8: Apply to Plan
+For accepted findings, edit target phase files inline with marker.
+Add `## Red Team Review` section to `plan.md`.
+
+## Output
+- Total findings by severity
+- Accepted vs rejected count
+- Files modified
+- Key risks addressed
+
+## Next Steps (MANDATORY)
+Remind user to run `/lu:plan validate` then `/lu:cook --auto`.
+
+## Important Notes
+- Reviewers must be HOSTILE, not helpful
+- Deduplicate aggressively
+- Adjudication must be evidence-based
+- Reviewers read plan files directly

package/agentic/antigravity/.agents/skills/plan/references/research-phase.md

@@ -0,0 +1,40 @@
+# Research & Analysis Phase
+
+**When to skip:** If provided with researcher reports, skip this phase.
+
+## Core Activities
+
+### Parallel Researcher Agents
+- Spawn multiple `researcher` agents in parallel to investigate different approaches
+- Wait for all researcher agents to report back before proceeding
+- Each researcher investigates a specific aspect or approach
+
+### Sequential Thinking
+- Use `lu:sequential-thinking` skill for dynamic and reflective problem-solving
+- Structured thinking process for complex analysis
+- Enables multi-step reasoning with revision capability
+
+### Documentation Research
+- Use `lu:docs-seeker` skill to read and understand documentation
+- Research plugins, packages, and frameworks
+- Find latest technical documentation using llms.txt standard
+
+### GitHub Analysis
+- Use `gh` command to read and analyze:
+  - GitHub Actions logs
+  - Pull requests
+  - Issues and discussions
+- Extract relevant technical context from GitHub resources
+
+### Debugger Delegation
+- Delegate to `debugger` agent for root cause analysis
+- Use when investigating complex issues or bugs
+- Debugger agent specializes in diagnostic tasks
+
+## Best Practices
+
+- Research breadth before depth
+- Document findings for synthesis phase
+- Identify multiple approaches for comparison
+- Consider edge cases during research
+- Note security implications early

package/agentic/antigravity/.agents/skills/plan/references/solution-design.md

@@ -0,0 +1,61 @@
+# Solution Design
+
+## Core Principles
+
+Follow these fundamental principles:
+- **YAGNI** (You Aren't Gonna Need It) - Don't add functionality until necessary
+- **KISS** (Keep It Simple, Stupid) - Prefer simple solutions over complex ones
+- **DRY** (Don't Repeat Yourself) - Avoid code duplication
+
+## Design Activities
+
+### Technical Trade-off Analysis
+- Evaluate multiple approaches for each requirement
+- Compare pros and cons of different solutions
+- Consider short-term vs long-term implications
+- Balance complexity with maintainability
+- Assess development effort vs benefit
+- Recommend optimal solution based on current best practices
+
+### Security Assessment
+- Identify potential vulnerabilities during design phase
+- Consider authentication and authorization requirements
+- Assess data protection needs
+- Evaluate input validation requirements
+- Plan for secure configuration management
+- Address OWASP Top 10 concerns
+- Consider API security (rate limiting, CORS, etc.)
+
+### Performance & Scalability
+- Identify potential bottlenecks early
+- Consider database query optimization needs
+- Plan for caching strategies
+- Assess resource usage (memory, CPU, network)
+- Design for horizontal/vertical scaling
+- Consider asynchronous processing where appropriate
+
+### Edge Cases & Failure Modes
+- Think through error scenarios
+- Plan for network failures
+- Consider partial failure handling
+- Design retry and fallback mechanisms
+- Plan for data consistency
+- Consider race conditions
+- Design for graceful degradation
+
+### Architecture Design
+- Create scalable system architectures
+- Design for maintainability
+- Plan component interactions
+- Design data flow
+- Plan API contracts
+- Design state management
+
+## Best Practices
+
+- Document design decisions and rationale
+- Consider both technical and business requirements
+- Think through the entire user journey
+- Plan for monitoring and observability
+- Design with testing in mind
+- Consider deployment and rollback strategies

package/agentic/antigravity/.agents/skills/plan/references/task-management.md

@@ -0,0 +1,54 @@
+# Plan File Operations — Task Management
+
+## Read Plan State
+
+```
+view_file("plans/260205-auth/plan.md")
+view_file("plans/260205-auth/phase-02-api.md")
+```
+
+## Mark Phase Complete
+
+```
+replace_file_content(
+  filePath: "plans/260205-auth/phase-01-setup.md",
+  oldString: "- [ ] Setup environment and dependencies",
+  newString: "- [x] Setup environment and dependencies"
+)
+```
+
+## Update Plan Status
+
+After all phase checkboxes resolved, sync `plan.md` frontmatter:
+
+```
+replace_file_content(
+  filePath: "plans/260205-auth/plan.md",
+  oldString: "status: in-progress",
+  newString: "status: completed"
+)
+```
+
+## Cook Handoff
+
+### Same-Session
+
+1. Cook reads plan.md → finds unchecked `[ ]` phases → begins implementation
+
+### Cross-Session (resume)
+
+1. Cook reads plan files → scans unchecked `[ ]` items
+2. Skip `[x]` items (already done)
+
+### Sync-Back (finalize)
+
+1. Sweep all `phase-XX-*.md` in plan directory
+2. Backfill `[ ]` → `[x]` for delivered work via `replace_file_content`
+3. Update `plan.md` `status` frontmatter
+
+## Cross-Phase Reconciliation
+
+1. Sweep all `phase-XX-*.md` in the plan directory
+2. Backfill stale `[ ]` → `[x]` for already delivered work
+3. Recompute `status` from checkbox counts
+4. Update `plan.md` frontmatter to match actual completion

package/agentic/antigravity/.agents/skills/plan/references/validate-question-framework.md

@@ -0,0 +1,80 @@
+# Validation Question Framework
+
+## Question Categories
+
+| Category | Keywords to detect |
+|----------|-------------------|
+| **Architecture** | "approach", "pattern", "design", "structure", "database", "API" |
+| **Assumptions** | "assume", "expect", "should", "will", "must", "default" |
+| **Tradeoffs** | "tradeoff", "vs", "alternative", "option", "choice", "either/or" |
+| **Risks** | "risk", "might", "could fail", "dependency", "blocker", "concern" |
+| **Scope** | "phase", "MVP", "future", "out of scope", "nice to have" |
+
+## Question Format Rules
+
+- Each question must have 2-4 concrete options
+- Mark recommended option with "(Recommended)" suffix
+- "Other" option is automatic
+- Questions should surface implicit decisions
+
+## Example Questions
+
+Category: Architecture
+Question: "How should the validation results be persisted?"
+Options:
+1. Save to plan.md frontmatter (Recommended)
+2. Create validation-answers.md
+3. Don't persist
+
+Category: Assumptions
+Question: "The plan assumes API rate limiting is not needed. Is this correct?"
+Options:
+1. Yes, not needed for MVP
+2. No, add basic rate limiting now (Recommended)
+3. Defer to Phase 2
+
+## Validation Log Format
+
+```markdown
+## Validation Log
+
+### Session {N} — {YYYY-MM-DD}
+**Trigger:** {what prompted this validation}
+**Questions asked:** {count}
+
+#### Questions & Answers
+
+1. **[{Category}]** {full question text}
+   - Options: {A} | {B} | {C}
+   - **Answer:** {user's choice}
+   - **Custom input:** {verbatim "Other" text if applicable}
+   - **Rationale:** {why this decision matters}
+
+#### Confirmed Decisions
+- {decision}: {choice} — {brief why}
+
+#### Action Items
+- [ ] {specific change needed}
+
+#### Impact on Phases
+- Phase {N}: {what needs updating and why}
+```
+
+## Recording Rules
+
+- **Full question text**: exact question, not summary
+- **All options**: every option presented
+- **Verbatim custom input**: record "Other" text exactly
+- **Rationale**: explain why decision affects implementation
+- **Session numbering**: increment from last session
+- **Trigger**: state what prompted validation
+
+## Section Mapping for Phase Propagation
+
+| Change Type | Target Section |
+|-------------|----------------|
+| Requirements | Requirements |
+| Architecture | Architecture |
+| Scope | Overview / Implementation Steps |
+| Risk | Risk Assessment |
+| Unknown | Key Insights (new subsection) |