anchi-kit 1.2.0 → 1.2.2

package/.antigravity/skills/planning/references/output-standards.md

@@ -1,87 +0,0 @@
-# Output Standards & Quality
-
-## 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/development-rules.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/development-rules.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:** List unresolved questions at end
-- Questions needing clarification
-- Technical decisions requiring input
-- Unknowns impacting implementation
-- Trade-offs requiring business decisions
-
-## 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
-- Fully respect the `./docs/development-rules.md` file.
-
-### Research Depth
-- When uncertain, research more
-- Multiple options with clear trade-offs
-- Validate against best practices
-- Consider industry standards
-
-### 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/.antigravity/skills/planning/references/plan-organization.md

@@ -1,123 +0,0 @@
-# Plan Creation & Organization
-
-## Directory Structure
-
-### Plan Location
-Save plans in `./plans` directory with timestamp and descriptive name.
-
-**Format:** `plans/YYYYMMDD-HHmm-your-plan-name/`
-
-**Example:** `plans/20251101-1505-authentication-and-profile-implementation/`
-
-### File Organization
-
-```
-plans/
-├── 20251101-1505-authentication-and-profile-implementation/
-    ├── research/
-    │   ├── researcher-XX-report.md
-    │   └── ...
-│   ├── reports/
-│   │   ├── scout-report.md
-│   │   ├── researcher-report.md
-│   │   └── ...
-│   ├── plan.md                                # Overview access point
-│   ├── phase-01-setup-environment.md          # Setup environment
-│   ├── phase-02-implement-database.md         # Database models
-│   ├── phase-03-implement-api-endpoints.md    # API endpoints
-│   ├── phase-04-implement-ui-components.md    # UI components
-│   ├── phase-05-implement-authentication.md   # Auth & authorization
-│   ├── phase-06-implement-profile.md          # Profile page
-│   └── phase-07-write-tests.md                # Tests
-└── ...
-```
-
-### Active Plan State Tracking
-
-**State File:** `<WORKING-DIR>/.cursor/active-plan`
-
-`<WORKING-DIR>` = current project's working directory (where Claude was launched or `pwd`).
-
-- Contains path to current working plan (e.g., `plans/20251128-1654-feature-name`)
-- All agents read this file to determine report output location
-- Commands check this file before creating new plan folders
-
-**Pre-Creation Check:**
-```bash
-# Before creating any plan folder:
-if [ -f "<WORKING-DIR>/.cursor/active-plan" ]; then
-  ACTIVE=$(cat <WORKING-DIR>/.cursor/active-plan)
-  if [ -d "$ACTIVE" ]; then
-    # Ask user: "Continue with existing plan? [Y/n]"
-    # Y → reuse $ACTIVE
-    # n → create new, update active-plan
-  fi
-fi
-```
-
-**Report Output Rules:**
-1. Read `<WORKING-DIR>/.cursor/active-plan` to get plan path
-2. Write reports to `{plan-path}/reports/`
-3. Use naming: `{agent}-{YYMMDD}-{slug}.md`
-4. Fallback: `plans/reports/` if no active-plan exists
-
-## File Structure
-
-### Overview Plan (plan.md)
-- 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/development-rules.md` file.
-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/.antigravity/skills/planning/references/research-phase.md

@@ -1,49 +0,0 @@
-# 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 `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 `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
-
-### Remote Repository Analysis
-When given GitHub repository URL, generate fresh codebase summary:
-```bash
-# usage: 
-repomix --remote <github-repo-url>
-# example: 
-repomix --remote https://github.com/mrgoonie/human-mcp
-```
-
-### 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/.antigravity/skills/planning/references/solution-design.md

@@ -1,63 +0,0 @@
-# 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
-- Plan for load distribution
-- 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
-- Consider microservices vs monolith trade-offs
-- 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/.antigravity/skills/problem-solving/references/attribution.md

@@ -1,69 +0,0 @@
-# Problem-Solving Skills - Attribution
-
-These skills were derived from agent patterns in the Microsoft Amplifier project.
-
-## Source Repository
-
-- **Name:** Amplifier
-- **URL:** https://github.com/microsoft/amplifier
-- **Commit:** 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
-- **Date:** 2025-10-10
-
-## Skills Derived from Amplifier Agents
-
-### From insight-synthesizer agent:
-- **simplification-cascades** - Finding insights that eliminate multiple components
-- **collision-zone-thinking** - Forcing unrelated concepts together for breakthroughs
-- **meta-pattern-recognition** - Spotting patterns across 3+ domains
-- **inversion-exercise** - Flipping assumptions to reveal alternatives
-- **scale-game** - Testing at extremes to expose fundamental truths
-
-### From ambiguity-guardian agent:
-- **preserving-productive-tensions** - Preserving multiple valid approaches (in architecture skill)
-
-### From knowledge-archaeologist agent:
-- **tracing-knowledge-lineages** - Understanding how ideas evolved (in research skill)
-
-### Dispatch pattern:
-- **when-stuck** - Maps stuck-symptoms to appropriate technique
-
-## What Was Adapted
-
-The Amplifier agents are specialized long-lived agents with structured JSON output. These skills extract the core problem-solving techniques and adapt them as:
-
-- **Scannable quick-reference guides** (~60-80 lines each)
-- **Symptom-based discovery** via when_to_use descriptions
-- **Immediate application** without special tooling
-- **Composable patterns** through dispatch system
-- **Progressive disclosure** via SKILL.md + references structure
-
-## Core Insight
-
-Agent capabilities are domain-agnostic patterns. Whether packaged as "amplifier agent" or "problem-solving skill", the underlying technique is the same.
-
-We extracted the techniques and made them:
-- Portable across contexts
-- Immediately applicable
-- Token-efficient through progressive disclosure
-- Discoverable through symptom-matching
-- Combinable for complex problems
-
-## License
-
-Original Amplifier project uses MIT License. These adapted skills maintain attribution and follow the same open spirit.
-
-## Adaptation Notes
-
-**Changes from original:**
-- Converted from long-lived agent to scannable reference
-- Added symptom-based dispatch system
-- Removed JSON output requirements
-- Focused on immediate application
-- Added concrete examples
-- Structured for progressive disclosure
-
-**Preserved from original:**
-- Core problem-solving techniques
-- Recognition patterns
-- Application processes
-- Fundamental insights

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

@@ -1,79 +0,0 @@
-# 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/.antigravity/skills/problem-solving/references/inversion-exercise.md

@@ -1,91 +0,0 @@
-# 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/.antigravity/skills/problem-solving/references/meta-pattern-recognition.md

@@ -1,87 +0,0 @@
-# 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