everything-gemini 1.0.1 → 1.2.0

package/examples/python-sdk/orchestrate_subagents.py

@@ -0,0 +1,59 @@
+#!/usr/bin/env python3
+"""
+Everything Gemini (everything-gemini) Python SDK Example
+Demonstrates programmatic multi-agent orchestration using the official google-antigravity SDK.
+"""
+
+import asyncio
+import sys
+from google.antigravity import Agent, LocalAgentConfig, CapabilitiesConfig
+
+async def run_pipeline():
+    print("🪐 Initializing Everything Gemini Multi-Agent Orchestrator...")
+
+    # 1. Spawn Planner Subagent
+    planner_config = LocalAgentConfig(
+        system_instructions=(
+            "You are the Strategic Planner agent from everything-gemini. "
+            "Analyze the codebase, break the feature into phased milestones, and map architectural risks."
+        ),
+        capabilities=CapabilitiesConfig(allow_network=False),
+    )
+
+    async with Agent(planner_config) as planner:
+        print("\n[Phase 1] 🤖 Executing Planner Subagent...")
+        planner_response = await planner.chat(
+            "Draft an architecture plan to add Redis caching to the API service."
+        )
+
+        plan_output = []
+        async for token in planner_response:
+            sys.stdout.write(token)
+            sys.stdout.flush()
+            plan_output.append(token)
+        
+        plan_text = "".join(plan_output)
+
+    # 2. Handoff Plan to Code Reviewer Subagent
+    reviewer_config = LocalAgentConfig(
+        system_instructions=(
+            "You are the Code Reviewer agent from everything-gemini. "
+            "Audit the architectural plan for edge cases, failure modes, and security vulnerabilities."
+        ),
+        capabilities=CapabilitiesConfig(allow_network=False),
+    )
+
+    async with Agent(reviewer_config) as reviewer:
+        print("\n\n[Phase 2] 🛡️ Handing off to Code Reviewer Subagent...")
+        review_response = await reviewer.chat(
+            f"Review this architectural proposal and list all potential edge cases:\n\n{plan_text}"
+        )
+
+        async for token in review_response:
+            sys.stdout.write(token)
+            sys.stdout.flush()
+
+    print("\n\n✨ Multi-agent orchestration completed successfully!")
+
+if __name__ == "__main__":
+    asyncio.run(run_pipeline())

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "everything-gemini",
-  "version": "1.0.1",
+  "version": "1.2.0",
   "description": "Everything Gemini (everything-gemini) - The Ultimate Agent Harness, Multi-Agent Orchestrator & Performance Suite for Gemini & Google Antigravity",
   "main": "bin/everything-gemini",
   "bin": {
@@ -35,6 +35,7 @@
     "type": "git",
     "url": "git+https://github.com/salmandev/everything-gemini.git"
   },
+  "homepage": "https://salmandev.github.io/everything-gemini/",
   "engines": {
     "node": ">=18.0.0"
   }

package/skills/agent-evals/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: agent-evals
+description: Designs, executes, and benchmarks AI agent evaluation pipelines, LLM-as-a-judge scoring rubrics, golden test datasets, and prompt regression testing harnesses.
+---
+
+# Agent Evals & LLM Benchmark Playbook
+
+This skill guides the creation of automated evaluation harnesses, LLM-as-a-judge scoring pipelines, and regression testing suites for AI agents and LLM applications.
+
+---
+
+## 1. Core Principles
+
+1. **Deterministic Assertions First**:
+   - Prefer deterministic, unit-testable assertions (schema validation, regex matching, exit codes, latency limits) before falling back to subjective LLM judges.
+2. **Golden Datasets with Ground Truth**:
+   - Maintain versioned golden evaluation datasets (`evals/golden.jsonl`) pairing input prompts with expected outputs or behavioral criteria.
+3. **Regression Containment**:
+   - Any prompt revision or model switch must run against the baseline eval suite to measure accuracy deltas, token consumption, and latency shifts.
+
+---
+
+## 2. Evaluation Dimensions
+
+When assessing agent output quality, evaluate across four standardized vectors:
+
+| Dimension | Metric | Measurement Method |
+| :--- | :--- | :--- |
+| **Accuracy / Correctness** | Factual precision, task fulfillment | LLM-as-a-judge with binary pass/fail rubric |
+| **Safety & Alignment** | Injection vulnerability, secret leakage | Automated static analysis & safety classifiers |
+| **Schema Compliance** | Valid JSON, Pydantic type conformance | Deterministic parser validation (`json.loads`, Pydantic) |
+| **Context Economics** | Token count, time-to-first-token (TTFT) | Profiler logs & Gemini metadata tokens |
+
+---
+
+## 3. LLM-as-a-Judge Scoring Template
+
+When using Gemini as an automated evaluator, structure the prompt with strict zero-shot rubrics and JSON output:
+
+```python
+EVAL_SYSTEM_PROMPT = """You are an impartial, expert evaluation judge. 
+Assess the candidate agent response against the provided Reference Criteria.
+Provide a structured JSON evaluation adhering to the schema:
+{
+  "score": <float 0.0 to 1.0>,
+  "reasoning": "<concise explanation of strengths and shortcomings>",
+  "violations": ["<list of any missed constraints>"]
+}
+Only output valid JSON.
+"""
+```
+
+---
+
+## 4. Eval Runner Execution Flow
+
+1. **Load Test Suite**: Ingest test cases from `evals/test_cases.jsonl`.
+2. **Execute Candidate Prompt**: Query the model with temperature=0.0 for reproducible benchmarking.
+3. **Run Deterministic Checks**: Validate JSON schema, required keys, and formatting constraints.
+4. **Run LLM Judge**: Pass model output + reference criteria to the evaluator.
+5. **Aggregate Metrics**: Calculate overall pass rate, p95 latency, and token cost per run.

package/skills/ai-first-engineering/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: ai-first-engineering
+description: Decomposes ambiguous software requirements into deterministic milestones, executable acceptance criteria, and test-backed delivery pipelines for AI agent development.
+---
+
+# AI-First Engineering Principles & Delivery Playbook
+
+This skill establishes best practices for orchestrating high-velocity software engineering tasks with AI agents. It bridges the gap between human product intent and deterministic, zero-hallucination agent execution.
+
+---
+
+## 1. Core Directives
+
+1. **Deterministic Specification Before Code**:
+   - Never write production code based on vague requirements.
+   - Deconstruct high-level prompts into verifiable acceptance criteria (Given/When/Then).
+2. **Blast Radius Minimization**:
+   - Scope code modifications strictly to the files necessary to satisfy the feature.
+   - Guard against accidental refactoring of unrelated subsystems or styles.
+3. **Continuous Verification Loop**:
+   - Every modification must be coupled with automated validation (unit tests, integration suites, linters, or visual browser assertions).
+   - If tests fail, diagnose the root cause from the error log before modifying code.
+
+---
+
+## 2. Requirement Decomposition Matrix
+
+When given an ambiguous task (e.g., *"Make user onboarding faster"* or *"Add subscription billing"*), follow this three-stage breakdown:
+
+```
+[Ambiguous Goal] ──► [Milestone Decomposition] ──► [Executable Criteria] ──► [Zero-Regression Delivery]
+```
+
+### Stage 1: Milestone Decomposition
+Break large tasks into discrete, independently testable phases:
+- **Phase 1: Contracts & Schema**: Types, interfaces, database schemas, and API contracts.
+- **Phase 2: Failing Assertions (Red)**: Unit / integration tests validating expected behavior.
+- **Phase 3: Implementation (Green)**: Minimal surgical code satisfying the tests.
+- **Phase 4: Hardening & Docs (Refactor)**: Error handling, edge cases, logging, and documentation.
+
+### Stage 2: Executable Acceptance Criteria
+Formulate specifications using the standard Gherkin / BDD structure:
+- **Given**: Initial system state and prerequisites.
+- **When**: Specific user or API action occurs.
+- **Then**: Measurable system response, database state, or error envelope.
+
+---
+
+## 3. Risk Radius & Boundary Containment
+
+Before modifying core abstractions, evaluate the **Risk Radius**:
+
+| Radius Tier | Scope | Required Precautions |
+| :--- | :--- | :--- |
+| **Tier 1: Leaf Node** | Isolated helper functions, standalone components | Standard unit test verification |
+| **Tier 2: Service / Store** | State management, database queries, shared services | Integration tests + typechecking |
+| **Tier 3: Core Abstraction**| DB migrations, auth middleware, global config | Migration rollback plan + full test suite run |
+
+---
+
+## 4. Autonomous Debugging Protocol
+
+When encountering unexpected test failures or runtime regressions:
+
+1. **Read Full Error Trace**: Never guess or apply speculative patches without inspecting the actual stack trace.
+2. **Reproduce in Isolation**: Create a minimal reproduction test or script before touching implementation files.
+3. **Binary Search (Bisect)**: If behavior unexpectedly changed, identify the breaking commit or input change systematically.
+4. **Surgical Fix**: Apply the smallest possible fix that resolves the issue while preserving surrounding code formatting and comments.

package/skills/docker-compose-orchestrator/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: docker-compose-orchestrator
+description: Architects, configures, and troubleshoots multi-container Docker Compose environments, database services (Postgres, pgvector, Redis), healthchecks, and local dev networking.
+---
+
+# Docker Compose Multi-Service Orchestrator
+
+This skill guides the design, hardening, and troubleshooting of multi-container local and staging environments using Docker Compose v2.
+
+---
+
+## 1. Core Principles
+
+1. **Deterministic Healthchecks**:
+   - Always define explicit `healthcheck` blocks for stateful services (databases, caches, message brokers).
+   - Use `depends_on: { condition: service_healthy }` to prevent app containers from starting before databases are ready.
+2. **Persistent Named Volumes**:
+   - Store persistent data (e.g., PostgreSQL data, Redis dumps, uploaded media) in named volumes, never in ephemeral container layers.
+3. **Environment Isolation**:
+   - Use `.env.example` templates with sensible local defaults; never hardcode production secrets in compose files.
+
+---
+
+## 2. Production-Grade Compose Blueprint
+
+Example architecture pairing an application server with PostgreSQL (pgvector enabled) and Redis caching:
+
+```yaml
+version: '3.8'
+
+services:
+  db:
+    image: pgvector/pgvector:pg16
+    container_name: app_db
+    environment:
+      POSTGRES_USER: ${POSTGRES_USER:-postgres}
+      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres}
+      POSTGRES_DB: ${POSTGRES_DB:-app_dev}
+    ports:
+      - "5432:5432"
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+    networks:
+      - app-net
+
+  redis:
+    image: redis:7-alpine
+    container_name: app_redis
+    ports:
+      - "6379:6379"
+    volumes:
+      - redisdata:/data
+    healthcheck:
+      test: ["CMD", "redis-cli", "ping"]
+      interval: 5s
+      timeout: 3s
+      retries: 5
+    networks:
+      - app-net
+
+volumes:
+  pgdata:
+  redisdata:
+
+networks:
+  app-net:
+    driver: bridge
+```
+
+---
+
+## 3. Common Operations & Diagnostics
+
+| Command | Action |
+| :--- | :--- |
+| `docker compose up -d` | Start all services in the background |
+| `docker compose ps` | Inspect service health and exposed ports |
+| `docker compose logs -f <service>` | Stream logs for a specific container |
+| `docker compose down -v` | Tear down containers and wipe persistent volumes |
+| `docker compose exec <service> sh` | Open an interactive shell inside a container |

package/skills/gemini-function-calling/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: gemini-function-calling
+description: >-
+  Designs, validates, and tests production Gemini function calling schemas, structured outputs with Pydantic/JSON Schema, parallel tool dispatch, and error recovery loops.
+---
+
+# Gemini Function Calling & Structured Outputs
+
+## Overview
+Gemini models support native, high-precision function calling and constrained JSON output schemas. This skill outlines best practices for defining deterministic tool declarations, handling parallel tool invocations, enforcing response schemas, and recovering gracefully from tool execution exceptions.
+
+## Core Capabilities
+
+### 1. Function Declarations (Tools)
+Define tools with clear semantics, parameter types, descriptions, and required constraints:
+
+```python
+from google.genai import types
+
+def get_db_schema_declaration() -> types.FunctionDeclaration:
+    return types.FunctionDeclaration(
+        name="query_database",
+        description="Executes a read-only SQL query against the application replica.",
+        parameters=types.Schema(
+            type=types.Type.OBJECT,
+            properties={
+                "query": types.Schema(
+                    type=types.Type.STRING,
+                    description="The SQL query to execute. Must be a SELECT statement."
+                ),
+                "limit": types.Schema(
+                    type=types.Type.INTEGER,
+                    description="Maximum number of rows to return (default: 50, max: 200)."
+                )
+            },
+            required=["query"]
+        )
+    )
+```
+
+### 2. Structured JSON Outputs (`response_schema`)
+When an application requires guaranteed JSON outputs matching a domain model, configure `response_mime_type="application/json"` and supply a `response_schema` (or Pydantic class):
+
+```python
+from pydantic import BaseModel, Field
+
+class CodeAnalysisReport(BaseModel):
+    summary: str = Field(description="High-level architecture assessment")
+    vulnerabilities: list[str] = Field(description="List of identified security vulnerabilities")
+    risk_score: int = Field(description="Risk rating from 1 (lowest) to 10 (critical)", ge=1, le=10)
+
+config = types.GenerateContentConfig(
+    response_mime_type="application/json",
+    response_schema=CodeAnalysisReport,
+    temperature=0.1
+)
+```
+
+### 3. Parallel & Multi-Turn Function Calling
+- **Parallel Dispatch**: Gemini can return multiple function calls in a single response turn. Process independent read operations concurrently using `asyncio.gather` or `Promise.all`.
+- **Function Response Envelope**: Return the results of each tool back to the model with matching tool names and execution status:
+
+```python
+tool_response_part = types.Part.from_function_response(
+    name="query_database",
+    response={"status": "success", "rows": rows, "count": len(rows)}
+)
+```
+
+### 4. Error Recovery & Defensive Handling
+When a tool execution fails (e.g., database timeout or syntax error):
+1. **Never suppress the error silently**: Feed the error back to Gemini in the function response envelope.
+2. **Include Contextual Remediation**: Inform the model why the call failed so it can self-correct in the next turn:
+
+```python
+error_part = types.Part.from_function_response(
+    name="query_database",
+    response={
+        "status": "error",
+        "error_code": "SYNTAX_ERROR",
+        "message": "Column 'user_id' does not exist in table 'accounts'. Available columns: [id, account_number, balance]."
+    }
+)
+```
+
+## Verification Checklist
+- [ ] Tool parameters have unambiguous `description` fields
+- [ ] `required` fields explicitly defined
+- [ ] Read-only vs destructive operations strictly separated
+- [ ] Tool execution errors safely fed back to model for autonomous self-correction

package/skills/github-ops/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: github-ops
+description: Orchestrates GitHub workflows, automated Pull Request generation, code review triage, release management, and issue automation using GitHub MCP and the gh CLI.
+---
+
+# GitHub Ops & Repository Lifecycle Automation
+
+This skill guides the agent in managing end-to-end GitHub workflows, creating production-grade Pull Requests, performing automated multi-file code reviews, orchestrating releases, and triaging issues.
+
+---
+
+## 1. Operating Principles
+
+1. **Atomic & Linear Commits**:
+   - Keep Pull Requests focused on a single logical change or feature.
+   - Use Conventional Commits (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`).
+2. **Deterministic Verification Before PR**:
+   - Always run the local test suite and lint verification before creating or updating a PR.
+   - Never push failing code or uncommitted working trees.
+3. **Traceability**:
+   - Every PR must link back to an issue or feature specification (`Closes #123` or `Refs #456`).
+   - Every release tag must be accompanied by an auto-generated or structured changelog.
+
+---
+
+## 2. GitHub CLI (`gh`) & MCP Integration
+
+When interacting with GitHub, use either the configured **GitHub MCP Server** or the standard **`gh` CLI**.
+
+### Essential `gh` Command Patterns
+
+| Task | Command |
+| :--- | :--- |
+| **Check Auth Status** | `gh auth status` |
+| **Inspect Open Issues** | `gh issue list --limit 10` |
+| **View Issue Details** | `gh issue view <issue-number>` |
+| **Create Pull Request** | `gh pr create --title "..." --body "..."` |
+| **View PR Status & Checks** | `gh pr status` / `gh pr checks` |
+| **View PR Diff** | `gh pr diff <pr-number>` |
+| **Add PR Comment/Review** | `gh pr review <pr-number> --comment -b "..."` |
+| **Merge Pull Request** | `gh pr merge <pr-number> --squash --delete-branch` |
+| **Create Release Tag** | `gh release create v1.1.0 --title "v1.1.0" --notes "..."` |
+
+---
+
+## 3. Pull Request Generation Workflow
+
+When authoring a Pull Request on behalf of the user, follow this structured template:
+
+```markdown
+## 🎯 Overview
+<!-- 1-2 concise sentences summarizing the problem solved or capability introduced -->
+
+## 🛠️ Changes Implemented
+- **Component / File**: High-level explanation of modification.
+- **Architectural Decision**: Rationale for design choices or trade-offs.
+
+## 🧪 Verification & Testing
+- [x] Unit / Integration tests pass (`npm test`, `pytest`, or `cargo test`).
+- [x] Linters and typecheckers pass (`npm run lint`, `tsc --noEmit`).
+- [x] Verified zero breaking changes to existing public APIs.
+
+## 🔗 Related Issues
+Closes #<issue-number>
+```
+
+---
+
+## 4. Automated PR Review Protocol
+
+When performing automated reviews on a GitHub PR:
+
+1. **Fetch & Inspect Diff**:
+   ```bash
+   gh pr diff <pr-number>
+   ```
+2. **Review Checklist**:
+   - **Correctness**: Does the code satisfy the acceptance criteria without subtle edge-case failures?
+   - **Security**: Are there unsanitized inputs, hardcoded secrets, or privilege escalations?
+   - **Performance**: Are there N+1 database queries, unmemoized expensive loops, or memory leaks?
+   - **Style & Standards**: Does it adhere to the repository's established conventions?
+3. **Submitting Feedback**:
+   - Use `gh pr review <pr-number> --comment` for non-blocking suggestions.
+   - Use `gh pr review <pr-number> --request-changes` for critical bugs or regressions.
+   - Use `gh pr review <pr-number> --approve` once all checks pass.
+
+---
+
+## 5. Release Automation
+
+To publish a clean semantic release:
+1. Verify `package.json` / version files are updated.
+2. Ensure working tree is clean (`git status`).
+3. Create and push git tag:
+   ```bash
+   git tag vX.Y.Z
+   git push origin vX.Y.Z
+   ```
+4. Generate release notes with GitHub CLI:
+   ```bash
+   gh release create vX.Y.Z --generate-notes
+   ```

package/skills/graphql-architect/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: graphql-architect
+description: Designs, specifies, and implements production GraphQL APIs, DataLoader N+1 query batching, Relay-style cursor pagination, and schema federation.
+---
+
+# GraphQL Architecture & API Craftsmanship
+
+This skill guides the design, schema modeling, query optimization, and implementation of production-grade GraphQL APIs.
+
+---
+
+## 1. Core Principles
+
+1. **Schema-First Design**:
+   - Model client domain requirements into a declarative Schema Definition Language (SDL) before implementing resolvers.
+2. **Defeat the N+1 Problem**:
+   - Never query database tables inside nested resolvers without a batching mechanism (e.g., `DataLoader`).
+3. **Cursor-Based Pagination**:
+   - For real-time or dynamic lists, implement Relay-compliant cursor pagination (`Connection`, `Edge`, `PageInfo`) rather than offset/limit pagination.
+
+---
+
+## 2. Relay-Compliant Cursor Pagination Pattern
+
+```graphql
+type PageInfo {
+  hasNextPage: Boolean!
+  hasPreviousPage: Boolean!
+  startCursor: String
+  endCursor: String
+}
+
+type UserEdge {
+  cursor: String!
+  node: User!
+}
+
+type UserConnection {
+  edges: [UserEdge!]!
+  pageInfo: PageInfo!
+  totalCount: Int!
+}
+
+type Query {
+  users(first: Int, after: String): UserConnection!
+}
+```
+
+---
+
+## 3. DataLoader Batching Blueprint
+
+Prevent database query fan-out by batching IDs into a single SQL `IN` query per event loop tick:
+
+```typescript
+import DataLoader from 'dataloader';
+
+// Batch function loading users by array of IDs
+const batchUsers = async (userIds: readonly string[]): Promise<(User | Error)[]> => {
+  const users = await db.user.findMany({
+    where: { id: { in: [...userIds] } },
+  });
+  
+  // Map results back to exact input order
+  const userMap = new Map(users.map(u => [u.id, u]));
+  return userIds.map(id => userMap.get(id) || new Error(`User ${id} not found`));
+};
+
+export const createUserDataLoader = () => new DataLoader(batchUsers);
+```
+
+---
+
+## 4. Query Complexity & Depth Limiting
+
+To prevent Denial-of-Service attacks through cyclic or deeply nested queries:
+- Enforce maximum query depth (e.g., max 6 levels).
+- Assign cost multipliers to nested connections to reject queries exceeding complexity thresholds.

package/skills/rag-architect/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: rag-architect
+description: >-
+  Designs retrieval-augmented generation (RAG) pipelines, semantic chunking strategies, hybrid keyword-vector search, re-ranking, and pgvector embeddings using Gemini models.
+---
+
+# RAG Architecture & Vector Retrieval with Gemini
+
+## Overview
+Retrieval-Augmented Generation (RAG) equips Gemini with localized repository context, enterprise documentation, and proprietary knowledge bases. This skill outlines production architectures for dense embeddings, semantic chunking, hybrid search (keyword + vector), and Gemini-powered re-ranking.
+
+## Core RAG Pipeline
+
+```
+[Documents] ──► [Semantic Chunker] ──► [text-embedding-004] ──► [Vector DB / pgvector]
+                                                                        │
+[User Query] ──► [Hybrid Retrieval: BM25 + Dense Vector] ───────────────┤
+                                                                        ▼
+                                                         [Gemini Reranker & Filter]
+                                                                        ▼
+                                                         [Context Window (Cached)]
+                                                                        ▼
+                                                          [Grounded Synthesis]
+```
+
+## Architectural Guidelines
+
+### 1. Embedding Model Selection
+- Use **`text-embedding-004`** (768 dimensions) for semantic vector representations.
+- Apply task types appropriately when generating embeddings:
+  - `RETRIEVAL_DOCUMENT`: For indexing documents into the knowledge store.
+  - `RETRIEVAL_QUERY`: For embedding the user's incoming query.
+  - `SEMANTIC_SIMILARITY`: For clustering and duplicate detection.
+
+### 2. Semantic Chunking Strategies
+- **Code Repositories**: Chunk by syntax boundaries (AST classes, functions, modules) rather than fixed token lengths.
+- **Documentation**: Chunk by markdown headers (`##`, `###`) preserving title hierarchy as chunk metadata.
+- **Overlap**: Maintain a 10-15% token overlap across sliding windows to prevent boundary truncation of critical concepts.
+
+### 3. Hybrid Retrieval (Sparse + Dense)
+Never rely exclusively on vector distance. Combine:
+- **Dense Vector Search**: Cosine or inner product similarity via `pgvector` or Qdrant for semantic meaning.
+- **Sparse Keyword Search**: Full-text search (BM25 or PostgreSQL `tsvector`) for exact identifier matches, error codes, and function names.
+- Combine scores using Reciprocal Rank Fusion (RRF):
+  $$RRF(d) = \sum \frac{1}{60 + r_i(d)}$$
+
+### 4. Gemini Two-Stage Reranking
+1. Retrieve top 50 candidates from hybrid search.
+2. Pass the top 50 candidate snippets to `gemini-1.5-flash` or `gemini-3.8` for high-speed relevance scoring and deduplication.
+3. Inject the top 5-10 highest-scoring excerpts into the reasoning context window.
+
+### 5. Context Injection & Static Prefix Caching
+- Structure prompt templates with static instruction prefixes placed before retrieved dynamic context to maximize Gemini's automatic **Prefix Context Caching**.
+- Tag all retrieved chunks with clickable source links: `[source.py:L10-L45](file:///path/to/source.py#L10-L45)`.
+
+## Verification Checklist
+- [ ] Appropriate embedding task types specified (`RETRIEVAL_DOCUMENT` vs `RETRIEVAL_QUERY`)
+- [ ] Chunks respect syntax and AST boundaries
+- [ ] Hybrid search active for exact symbol matching
+- [ ] Clickable `file://` citations attached to synthesized outputs

package/templates/full-power/AGENTS.md

@@ -0,0 +1,12 @@
+# Antigravity Enterprise Standards (Full-Power Profile)
+
+## 1. Prime Directives
+1. **Zero Hallucination & Evidence-First**: Never speculate on APIs, schemas, or dependencies. Always view code before proposing edits.
+2. **Subagent Delegation Discipline**: Defer heavy multi-file exploration to `planner`, adversarial audits to `security-auditor`, and UI verification to `browser-qa`.
+3. **Progressive Disclosure**: Keep prompt context lean (<3,500 tokens). Pull skills and schemas into context strictly on-demand.
+4. **Deterministic Verification Loop**: Code changes require passing automated tests (`npm test` / pytest) before concluding.
+5. **Continuous Learning**: When errors or user corrections occur, record the insight using `/learn` into permanent Knowledge Items.
+
+## 2. Security & Operational Policy
+- Strict zero-trust command execution: All raw shell commands must pass GeminiShield gating.
+- Webhooks, tokens, and credentials must be read from environment variables with no hardcoding.

package/templates/full-power/GEMINI.md

@@ -0,0 +1,12 @@
+# Antigravity Enterprise Standards (Full-Power Profile)
+
+## 1. Prime Directives
+1. **Zero Hallucination & Evidence-First**: Never speculate on APIs, schemas, or dependencies. Always view code before proposing edits.
+2. **Subagent Delegation Discipline**: Defer heavy multi-file exploration to `planner`, adversarial audits to `security-auditor`, and UI verification to `browser-qa`.
+3. **Progressive Disclosure**: Keep prompt context lean (<3,500 tokens). Pull skills and schemas into context strictly on-demand.
+4. **Deterministic Verification Loop**: Code changes require passing automated tests (`npm test` / pytest) before concluding.
+5. **Continuous Learning**: When errors or user corrections occur, record the insight using `/learn` into permanent Knowledge Items.
+
+## 2. Security & Operational Policy
+- Strict zero-trust command execution: All raw shell commands must pass GeminiShield gating.
+- Webhooks, tokens, and credentials must be read from environment variables with no hardcoding.