everything-gemini 0.0.0-stage → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/hooks.json +16 -0
- package/.agents/rules/everything-gemini-dev.md +5 -0
- package/.agents/rules/instincts.md +8 -0
- package/.agents/skills/everything-gemini-maintainer/SKILL.md +22 -0
- package/.github/ISSUE_TEMPLATE/skill_proposal.md +24 -0
- package/.github/pull_request_template.md +9 -0
- package/.github/workflows/ci.yml +35 -0
- package/AGENTS.md +15 -0
- package/CONTRIBUTING.md +114 -0
- package/GEMINI.md +15 -0
- package/LICENSE +176 -0
- package/README.md +310 -2
- package/agents/architect.md +21 -0
- package/agents/browser-qa.md +26 -0
- package/agents/build-repair.md +20 -0
- package/agents/code-reviewer.md +22 -0
- package/agents/planner.md +21 -0
- package/agents/security-auditor.md +21 -0
- package/bin/everything-gemini +514 -0
- package/docs/architecture/cortex-loop.md +57 -0
- package/docs/architecture/memory-and-context.md +50 -0
- package/docs/architecture/progressive-disclosure.md +41 -0
- package/docs/customization/hooks-reference.md +78 -0
- package/docs/ecc-vs-everything-gemini.md +59 -0
- package/docs/surfaces/cli.md +46 -0
- package/docs/surfaces/desktop-2.0.md +30 -0
- package/docs/surfaces/ide.md +29 -0
- package/docs/surfaces/python-sdk.md +53 -0
- package/docs/workflows/slash-commands.md +27 -0
- package/hooks/auto-lint-formatter/hooks.json +16 -0
- package/hooks/auto-lint-formatter/scripts/auto-format.sh +48 -0
- package/hooks/ephemeral-context/hooks.json +11 -0
- package/hooks/ephemeral-context/scripts/inject-context.sh +8 -0
- package/hooks/gemini-shield/hooks.json +16 -0
- package/hooks/gemini-shield/scripts/shield-gate.sh +72 -0
- package/hooks/goal-verifier/hooks.json +11 -0
- package/hooks/goal-verifier/scripts/verify-goal.sh +26 -0
- package/hooks/learned-instincts/hooks.json +11 -0
- package/hooks/learned-instincts/scripts/save-instinct.sh +23 -0
- package/hooks/safety-shield/hooks.json +16 -0
- package/hooks/safety-shield/scripts/safety-gate.sh +64 -0
- package/mcp/README.md +41 -0
- package/mcp/mcp_config.example.json +30 -0
- package/package.json +39 -4
- package/plugins/core/hooks.json +16 -0
- package/plugins/core/plugin.json +3 -0
- package/plugins/core/rules/core-practices.md +5 -0
- package/plugins/python-ai/plugin.json +3 -0
- package/plugins/python-ai/rules/ai-agent-patterns.md +5 -0
- package/plugins/python-ai/skills/antigravity-sdk-orchestrator/SKILL.md +54 -0
- package/plugins/security-shield/hooks.json +16 -0
- package/plugins/security-shield/plugin.json +3 -0
- package/plugins/security-shield/rules/zero-trust.md +5 -0
- package/plugins/web-fullstack/plugin.json +3 -0
- package/plugins/web-fullstack/rules/frontend-standards.md +5 -0
- package/plugins/web-fullstack/skills/responsive-design/SKILL.md +23 -0
- package/rules/common/AGENTS.md +30 -0
- package/rules/common/GEMINI.md +30 -0
- package/rules/languages/golang.md +10 -0
- package/rules/languages/python.md +16 -0
- package/rules/languages/typescript.md +18 -0
- package/rules/paradigms/security-hardened.md +17 -0
- package/rules/paradigms/tdd.md +19 -0
- package/scripts/install.ps1 +26 -0
- package/scripts/install.sh +52 -0
- package/scripts/validate.sh +73 -0
- package/skills/api-craftsman/SKILL.md +45 -0
- package/skills/api-craftsman/examples/openapi-spec.yaml +37 -0
- package/skills/architecture-designer/SKILL.md +33 -0
- package/skills/architecture-designer/examples/c4-architecture.md +33 -0
- package/skills/browser-qa-tester/SKILL.md +43 -0
- package/skills/browser-qa-tester/references/browser-recipes.md +21 -0
- package/skills/context-caching/SKILL.md +48 -0
- package/skills/continuous-learning/SKILL.md +31 -0
- package/skills/database-architect/SKILL.md +26 -0
- package/skills/database-architect/references/migration-checklist.md +9 -0
- package/skills/devops-pipeline/SKILL.md +23 -0
- package/skills/devops-pipeline/templates/github-ci.yml +31 -0
- package/skills/fullstack-nextjs/SKILL.md +27 -0
- package/skills/fullstack-nextjs/references/app-router-patterns.md +46 -0
- package/skills/gemini-multimodal/SKILL.md +43 -0
- package/skills/git-craftsman/SKILL.md +43 -0
- package/skills/performance-profiler/SKILL.md +35 -0
- package/skills/performance-profiler/scripts/profile-node.sh +13 -0
- package/skills/repo-onboarding/SKILL.md +35 -0
- package/skills/repo-onboarding/references/knowledge-item-schema.md +30 -0
- package/skills/root-cause-debugger/SKILL.md +35 -0
- package/skills/root-cause-debugger/scripts/git-bisect-helper.sh +13 -0
- package/skills/security-audit/SKILL.md +29 -0
- package/skills/security-audit/scripts/scan-secrets.sh +26 -0
- package/skills/subagent-handoff/SKILL.md +28 -0
- package/skills/subagent-handoff/references/handoff-patterns.md +30 -0
- package/skills/tdd-workflow/SKILL.md +40 -0
- package/skills/tdd-workflow/references/tdd-patterns.md +23 -0
- package/templates/minimal/GEMINI.md +5 -0
- package/templates/minimal/hooks.json +16 -0
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
openapi: 3.1.0
|
|
2
|
+
info:
|
|
3
|
+
title: Order Management API
|
|
4
|
+
version: 1.0.0
|
|
5
|
+
description: High-performance API contract for orders.
|
|
6
|
+
paths:
|
|
7
|
+
/orders:
|
|
8
|
+
post:
|
|
9
|
+
summary: Create new order
|
|
10
|
+
operationId: createOrder
|
|
11
|
+
requestBody:
|
|
12
|
+
required: true
|
|
13
|
+
content:
|
|
14
|
+
application/json:
|
|
15
|
+
schema:
|
|
16
|
+
type: object
|
|
17
|
+
required: [items, customerId]
|
|
18
|
+
properties:
|
|
19
|
+
customerId:
|
|
20
|
+
type: string
|
|
21
|
+
format: uuid
|
|
22
|
+
items:
|
|
23
|
+
type: array
|
|
24
|
+
items:
|
|
25
|
+
type: object
|
|
26
|
+
required: [productId, quantity]
|
|
27
|
+
properties:
|
|
28
|
+
productId:
|
|
29
|
+
type: string
|
|
30
|
+
quantity:
|
|
31
|
+
type: integer
|
|
32
|
+
minimum: 1
|
|
33
|
+
responses:
|
|
34
|
+
'201':
|
|
35
|
+
description: Order created successfully
|
|
36
|
+
'400':
|
|
37
|
+
description: Validation failure
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architecture-designer
|
|
3
|
+
description: >-
|
|
4
|
+
Creates comprehensive system design architectures, Mermaid diagrams, API contracts, and Architecture Decision Records (ADRs). Use when planning complex software systems or designing net-new components.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Architecture Designer
|
|
8
|
+
|
|
9
|
+
This skill structures software design workflows, creating standardized Architecture Decision Records (ADRs) and Mermaid diagrams.
|
|
10
|
+
|
|
11
|
+
## Design Workflow
|
|
12
|
+
|
|
13
|
+
### 1. Requirements & Constraint Gathering
|
|
14
|
+
- Clarify functional and non-functional requirements (latency, throughput, availability, consistency).
|
|
15
|
+
- Identify existing tech stack dependencies and constraints.
|
|
16
|
+
|
|
17
|
+
### 2. High-Level Diagramming with Mermaid
|
|
18
|
+
Always visualize architectures using GitHub-flavored Mermaid blocks:
|
|
19
|
+
- **System Context (C4 Level 1)**
|
|
20
|
+
- **Container / Service Diagram (C4 Level 2)**
|
|
21
|
+
- **Sequence Diagram (Data Flow)**
|
|
22
|
+
|
|
23
|
+
*Rule*: Quote node labels containing special characters: `id["Service Name (Tech Stack)"]`.
|
|
24
|
+
|
|
25
|
+
### 3. Architecture Decision Record (ADR)
|
|
26
|
+
Structure decisions in this format:
|
|
27
|
+
- **Title**: `ADR-00X: Short descriptive title`
|
|
28
|
+
- **Status**: Proposed / Accepted / Superseded
|
|
29
|
+
- **Context**: Problem statement and forces at play.
|
|
30
|
+
- **Decision**: The architectural choice and implementation strategy.
|
|
31
|
+
- **Consequences**: Positive outcomes and trade-offs.
|
|
32
|
+
|
|
33
|
+
For full examples, see [examples/c4-architecture.md](./examples/c4-architecture.md).
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# C4 Model & Mermaid Diagram Examples
|
|
2
|
+
|
|
3
|
+
## Example: Microservices Architecture
|
|
4
|
+
```mermaid
|
|
5
|
+
graph TD
|
|
6
|
+
Client["Web / Mobile Client"] -->|HTTPS / REST| Gateway["API Gateway (Kong / Envoy)"]
|
|
7
|
+
Gateway -->|gRPC| AuthSvc["Authentication Service (Go)"]
|
|
8
|
+
Gateway -->|gRPC| OrderSvc["Order Processing Service (Node.js)"]
|
|
9
|
+
Gateway -->|gRPC| InventorySvc["Inventory Service (Python)"]
|
|
10
|
+
|
|
11
|
+
OrderSvc --> DB[(PostgreSQL Primary)]
|
|
12
|
+
OrderSvc --> Queue["Kafka Event Bus"]
|
|
13
|
+
Queue --> NotificationSvc["Notification Worker (Go)"]
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Example: Event Sequence Diagram
|
|
17
|
+
```mermaid
|
|
18
|
+
sequenceDiagram
|
|
19
|
+
autonumber
|
|
20
|
+
actor User
|
|
21
|
+
participant Frontend
|
|
22
|
+
participant API as API Gateway
|
|
23
|
+
participant Svc as Payment Service
|
|
24
|
+
participant Stripe as Stripe API
|
|
25
|
+
|
|
26
|
+
User->>Frontend: Click "Pay Now"
|
|
27
|
+
Frontend->>API: POST /api/checkout
|
|
28
|
+
API->>Svc: InitiateCheckout(orderId)
|
|
29
|
+
Svc->>Stripe: CreatePaymentIntent()
|
|
30
|
+
Stripe-->>Svc: clientSecret
|
|
31
|
+
Svc-->>Frontend: 200 OK (clientSecret)
|
|
32
|
+
Frontend->>User: Confirm Payment Modal
|
|
33
|
+
```
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: browser-qa-tester
|
|
3
|
+
description: >-
|
|
4
|
+
Orchestrates automated UI, frontend, and end-to-end testing using Antigravity's native browser subagent with automatic WebP recording. Use when verifying web applications, visual bugs, or UI flows.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Browser QA Tester
|
|
8
|
+
|
|
9
|
+
This skill automates visual testing and end-to-end verification of web applications using Antigravity's native `browser_subagent`.
|
|
10
|
+
|
|
11
|
+
## Why Browser Subagent?
|
|
12
|
+
- **Autonomous Interaction**: Navigates, clicks, fills inputs, and scrolls.
|
|
13
|
+
- **Automatic Recording**: Automatically captures WebP video recordings saved directly into the conversation artifacts directory.
|
|
14
|
+
- **Console & Network Inspection**: Intercepts unhandled errors, failed network requests, and visual layout glitches.
|
|
15
|
+
|
|
16
|
+
## Verification Procedure
|
|
17
|
+
|
|
18
|
+
### 1. Ensure Local Server is Running
|
|
19
|
+
Before launching the browser subagent, ensure the web app is running locally:
|
|
20
|
+
```bash
|
|
21
|
+
# Check if port is open
|
|
22
|
+
lsof -i :3000 || lsof -i :5173
|
|
23
|
+
```
|
|
24
|
+
If not running, launch with `run_command` and `IsDaemon: true`:
|
|
25
|
+
```bash
|
|
26
|
+
npm run dev
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
### 2. Invoke `browser_subagent`
|
|
30
|
+
Formulate a precise task description with explicit stop conditions:
|
|
31
|
+
- Specify target URL (e.g., `http://localhost:3000`).
|
|
32
|
+
- Specify unique element IDs or text labels to click/type.
|
|
33
|
+
- Define what constitutes success (e.g., "Verify dashboard renders after login").
|
|
34
|
+
|
|
35
|
+
### 3. Review Recording Artifacts
|
|
36
|
+
After the subagent finishes:
|
|
37
|
+
- Embed the generated WebP recording into your summary artifact:
|
|
38
|
+
```markdown
|
|
39
|
+

|
|
40
|
+
```
|
|
41
|
+
- Summarize any console warnings or errors detected during the test.
|
|
42
|
+
|
|
43
|
+
For specialized testing recipes (Responsive testing, Form verification), see [references/browser-recipes.md](./references/browser-recipes.md).
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Browser Testing Recipes
|
|
2
|
+
|
|
3
|
+
## Recipe 1: Form Fill and Submit Flow
|
|
4
|
+
```text
|
|
5
|
+
Task: Navigate to http://localhost:3000/contact.
|
|
6
|
+
Locate input with id '#name' and type 'Test User'.
|
|
7
|
+
Locate input with id '#email' and type 'test@example.com'.
|
|
8
|
+
Locate button with text 'Send Message' and click it.
|
|
9
|
+
Verify that the success message 'Thank you for contacting us' appears on screen.
|
|
10
|
+
Stop condition: Success message is visible or error banner appears.
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
## Recipe 2: Responsive Layout Check
|
|
14
|
+
```text
|
|
15
|
+
Task: Open http://localhost:3000.
|
|
16
|
+
Resize browser window to 375x812 (mobile iPhone viewport).
|
|
17
|
+
Verify that the mobile hamburger navigation toggle is visible.
|
|
18
|
+
Click the hamburger icon and verify the drawer menu slides in.
|
|
19
|
+
Resize back to 1440x900 (desktop viewport) and verify desktop navigation links return.
|
|
20
|
+
Stop condition: Both mobile and desktop nav states verified.
|
|
21
|
+
```
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: context-caching
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when managing large-context Gemini operations (1M-2M tokens), architecting prefix-cached repository indexes, optimizing prompt structures for cost and latency, or structuring session memory for long-running agent workflows.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Gemini Context Caching & Large-Context Optimization
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
Gemini's 1M-to-2M token context window combined with explicit and implicit Context Caching allows agents to ingest entire codebases, documentation sets, and transaction logs. This skill outlines architectural strategies to maximize caching efficiency, cut API token costs by up to 75%, and minimize time-to-first-token (TTFT).
|
|
11
|
+
|
|
12
|
+
## Context Architecture: Prefix Optimization
|
|
13
|
+
|
|
14
|
+
Gemini caching relies on **deterministic prefix matching**. To ensure cache hits across agent invocations:
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
18
|
+
│ 1. STATIC PREFIX (Cached - High Hit Rate) │
|
|
19
|
+
│ - System Instructions & Repository Rules (GEMINI.md) │
|
|
20
|
+
│ - Architecture Specs & Database Schemas │
|
|
21
|
+
│ - Base Codebase Index / AST Dump │
|
|
22
|
+
├─────────────────────────────────────────────────────────────┤
|
|
23
|
+
│ 2. DYNAMIC SUFFIX (Uncached - Fast Processing) │
|
|
24
|
+
│ - Current User Prompt / Incremental Task Diff │
|
|
25
|
+
│ - Recent Terminal Command Output │
|
|
26
|
+
│ - Real-Time Conversation Turn │
|
|
27
|
+
└─────────────────────────────────────────────────────────────┘
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
### Golden Rules for Caching
|
|
31
|
+
1. **Never mutate the prefix**: Avoid injecting dynamic timestamps, random IDs, or changing session metadata at the beginning of the context.
|
|
32
|
+
2. **Cluster Static Assets**: Place unchanging documentation, API contracts, and core schemas at the very top of context assemblies.
|
|
33
|
+
3. **Chunking Thresholds**: Context caching provides optimal return on investment when static context exceeds 32k tokens.
|
|
34
|
+
|
|
35
|
+
## Progressive Ingestion Strategies
|
|
36
|
+
|
|
37
|
+
1. **Skeleton First**: Ingest file tree maps and interface definitions before pulling full function implementations.
|
|
38
|
+
2. **Selective Hydration**: Ingest full source files only for components identified during initial skeleton mapping.
|
|
39
|
+
3. **Session Compaction**: When conversation histories grow long, trigger the `Stop` or `PostInvocation` summarizer to compress intermediate thoughts into high-density Knowledge Items (KI).
|
|
40
|
+
|
|
41
|
+
## Cost & Latency Economics
|
|
42
|
+
- **Cached Input Cost**: ~75% cheaper than non-cached input tokens.
|
|
43
|
+
- **Cache Hit Latency**: Reduces initial TTFT from seconds to milliseconds on large contexts.
|
|
44
|
+
|
|
45
|
+
## Verification Checklist
|
|
46
|
+
- [ ] Static instructions positioned consistently at the head of context
|
|
47
|
+
- [ ] No variable timestamps or nonces in the static prefix block
|
|
48
|
+
- [ ] Cache hit rates monitored during multi-turn batch workflows
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: continuous-learning
|
|
3
|
+
description: >-
|
|
4
|
+
Extracts architectural lessons, developer corrections, and project conventions from the current session and records them into permanent rules or Knowledge Items. Activate when the user runs /learn or after resolving a complex issue.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Continuous Learning & Instinct Recording
|
|
8
|
+
|
|
9
|
+
This skill enables Antigravity to retain lessons and developer feedback so mistakes are never repeated.
|
|
10
|
+
|
|
11
|
+
## Learning Workflow
|
|
12
|
+
|
|
13
|
+
### 1. Identify the Core Insight
|
|
14
|
+
Determine what was learned:
|
|
15
|
+
- **Correction**: Did the user correct a style, framework version, or tool choice?
|
|
16
|
+
- **Bug Fix**: Was an obscure bug or configuration issue solved after debugging?
|
|
17
|
+
- **Workflow**: Was an optimal command sequence identified for building/testing?
|
|
18
|
+
|
|
19
|
+
### 2. Format the Instinct
|
|
20
|
+
Formulate a concise, imperative rule:
|
|
21
|
+
- *Bad*: "We had an issue with Docker not starting on port 8080."
|
|
22
|
+
- *Good*: "Always map Docker container port 8080 to host 8081 to avoid conflicting with local proxy."
|
|
23
|
+
|
|
24
|
+
### 3. Persist to `.agents/rules/instincts.md`
|
|
25
|
+
Append the new instinct under the appropriate section in `.agents/rules/instincts.md`:
|
|
26
|
+
```markdown
|
|
27
|
+
- **Topic Name**: Concrete rule statement.
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
### 4. For Major Architectural Changes: Create Knowledge Item
|
|
31
|
+
If the insight affects the broader repository architecture, write a dedicated Knowledge Item in `<appDataDir>/knowledge` with `metadata.json` and artifact details.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: database-architect
|
|
3
|
+
description: >-
|
|
4
|
+
Designs relational and document database schemas, crafts zero-downtime database migrations, optimizes complex queries, and configures ORMs (Prisma, Drizzle, SQLAlchemy).
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Database Architect
|
|
8
|
+
|
|
9
|
+
This skill guides data modeling, schema evolution, index tuning, and zero-downtime migration workflows.
|
|
10
|
+
|
|
11
|
+
## Core Directives
|
|
12
|
+
|
|
13
|
+
### 1. Schema Design Standards
|
|
14
|
+
- **Primary Keys**: Use UUIDv7 or ULIDs for distributed systems, or identity integers for internal lookups.
|
|
15
|
+
- **Foreign Keys**: Always define explicit foreign key constraints with appropriate `ON DELETE` behavior (`CASCADE`, `RESTRICT`, or `SET NULL`).
|
|
16
|
+
- **Timestamps**: Every table must have `created_at TIMESTAMPTZ DEFAULT now()` and `updated_at TIMESTAMPTZ DEFAULT now()`.
|
|
17
|
+
|
|
18
|
+
### 2. Zero-Downtime Migrations (Expand/Contract Pattern)
|
|
19
|
+
- **Never rename or delete a column in a single migration**:
|
|
20
|
+
1. *Phase 1 (Expand)*: Add the new column as nullable or with a default. Deploy code that writes to both columns.
|
|
21
|
+
2. *Phase 2 (Backfill)*: Backfill existing records asynchronously.
|
|
22
|
+
3. *Phase 3 (Switch)*: Deploy code that reads from the new column only.
|
|
23
|
+
4. *Phase 4 (Contract)*: Remove the old column.
|
|
24
|
+
- **Safe Index Creation**: In PostgreSQL, always use `CREATE INDEX CONCURRENTLY` to avoid blocking read/write queries.
|
|
25
|
+
|
|
26
|
+
For the zero-downtime migration checklist, see [references/migration-checklist.md](./references/migration-checklist.md).
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
# Zero-Downtime Migration Checklist
|
|
2
|
+
|
|
3
|
+
Before applying any migration to staging or production:
|
|
4
|
+
|
|
5
|
+
- [ ] **No Exclusive Table Locks**: Are you adding a column with a non-constant default on older Postgres versions?
|
|
6
|
+
- [ ] **Concurrent Indexes**: Are all new indexes declared with `CONCURRENTLY` (or equivalent in your database engine)?
|
|
7
|
+
- [ ] **Reversible / Down Migrations**: Is there a verified `down` migration script in case a rollback is required?
|
|
8
|
+
- [ ] **Idempotent Execution**: Can the migration be safely re-run if interrupted?
|
|
9
|
+
- [ ] **Query Performance Impact**: Has `EXPLAIN (ANALYZE, BUFFERS)` been verified for queries hitting the modified tables?
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: devops-pipeline
|
|
3
|
+
description: >-
|
|
4
|
+
Architects and configures Docker containers, multi-stage Dockerfiles, GitHub Actions CI/CD workflows, and infrastructure automation. Use when building or tuning deployment pipelines.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# DevOps Pipeline Engineering
|
|
8
|
+
|
|
9
|
+
This skill structures Docker containerization, caching, security scanning, and CI/CD automation.
|
|
10
|
+
|
|
11
|
+
## Core Directives
|
|
12
|
+
|
|
13
|
+
### 1. Minimal Multi-Stage Dockerfiles
|
|
14
|
+
- Use multi-stage builds (`AS builder` and `AS runner`) to keep final image sizes minimal (< 100MB).
|
|
15
|
+
- Run applications as a non-root user (`USER node` or `USER appuser`) for defense-in-depth.
|
|
16
|
+
- Order commands to maximize Docker layer cache hits (copy `package.json` / `requirements.txt` before copying source code).
|
|
17
|
+
|
|
18
|
+
### 2. GitHub Actions CI/CD Best Practices
|
|
19
|
+
- Cache dependencies (`actions/cache` or `actions/setup-node` with `cache: 'npm'`).
|
|
20
|
+
- Run linting, typechecking, and unit tests concurrently using GitHub Actions job matrix.
|
|
21
|
+
- Enforce status checks before permitting branch merges into `main`.
|
|
22
|
+
|
|
23
|
+
For complete production CI/CD workflow templates, see [templates/github-ci.yml](./templates/github-ci.yml).
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
name: CI Suite
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
push:
|
|
5
|
+
branches: [main]
|
|
6
|
+
pull_request:
|
|
7
|
+
branches: [main]
|
|
8
|
+
|
|
9
|
+
jobs:
|
|
10
|
+
verify:
|
|
11
|
+
runs-on: ubuntu-latest
|
|
12
|
+
steps:
|
|
13
|
+
- uses: actions/checkout@v4
|
|
14
|
+
|
|
15
|
+
- name: Set up Node.js
|
|
16
|
+
uses: actions/setup-node@v4
|
|
17
|
+
with:
|
|
18
|
+
node-version: 20
|
|
19
|
+
cache: 'npm'
|
|
20
|
+
|
|
21
|
+
- name: Install Dependencies
|
|
22
|
+
run: npm ci
|
|
23
|
+
|
|
24
|
+
- name: Typecheck
|
|
25
|
+
run: npm run typecheck --if-present
|
|
26
|
+
|
|
27
|
+
- name: Lint
|
|
28
|
+
run: npm run lint --if-present
|
|
29
|
+
|
|
30
|
+
- name: Run Test Suite
|
|
31
|
+
run: npm test
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: fullstack-nextjs
|
|
3
|
+
description: >-
|
|
4
|
+
Specialized engineering workflow for Next.js App Router, React Server Components (RSC), Server Actions, and API routes. Use when building or debugging modern Next.js applications.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Fullstack Next.js Engineering
|
|
8
|
+
|
|
9
|
+
This skill provides patterns for Next.js (App Router), React Server Components (RSC), and Server Actions.
|
|
10
|
+
|
|
11
|
+
## Core Directives
|
|
12
|
+
|
|
13
|
+
### 1. Server vs. Client Components
|
|
14
|
+
- **Default to Server Components**: Fetch data directly on the server without `useEffect` or client-side fetch.
|
|
15
|
+
- **`'use client'` Boundary**: Only mark components with `'use client'` when they require browser event listeners (`onClick`, `onChange`), React state (`useState`, `useReducer`), or browser APIs.
|
|
16
|
+
- **Push Client Boundaries Down**: Keep client components at the leaves of the component tree to maximize server-side rendering performance.
|
|
17
|
+
|
|
18
|
+
### 2. Server Actions & Mutations
|
|
19
|
+
- Use `'use server'` functions for mutations.
|
|
20
|
+
- Always validate input arguments using Zod schemas inside Server Actions before performing database queries.
|
|
21
|
+
- Revalidate cache paths using `revalidatePath()` or `revalidateTag()` after data mutations.
|
|
22
|
+
|
|
23
|
+
### 3. Hydration Bug Prevention
|
|
24
|
+
- Avoid accessing `window`, `localStorage`, or `navigator` during initial render.
|
|
25
|
+
- Ensure identical HTML output between SSR and hydration (e.g. avoid rendering random IDs or localized date strings on initial render without a client wrapper).
|
|
26
|
+
|
|
27
|
+
For architectural layouts and route handler patterns, see [references/app-router-patterns.md](./references/app-router-patterns.md).
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# Next.js App Router Architecture & Patterns
|
|
2
|
+
|
|
3
|
+
## 1. Safe Server Action Pattern with Zod
|
|
4
|
+
```typescript
|
|
5
|
+
'use server';
|
|
6
|
+
|
|
7
|
+
import { z } from 'zod';
|
|
8
|
+
import { revalidatePath } from 'next/cache';
|
|
9
|
+
|
|
10
|
+
const CreateTodoSchema = z.object({
|
|
11
|
+
title: z.string().min(1).max(100),
|
|
12
|
+
});
|
|
13
|
+
|
|
14
|
+
export async function createTodo(formData: FormData) {
|
|
15
|
+
const parsed = CreateTodoSchema.safeParse({
|
|
16
|
+
title: formData.get('title'),
|
|
17
|
+
});
|
|
18
|
+
|
|
19
|
+
if (!parsed.success) {
|
|
20
|
+
return { error: 'Invalid input', issues: parsed.error.issues };
|
|
21
|
+
}
|
|
22
|
+
|
|
23
|
+
// Database insert
|
|
24
|
+
// await db.todos.create({ data: { title: parsed.data.title } });
|
|
25
|
+
|
|
26
|
+
revalidatePath('/todos');
|
|
27
|
+
return { success: true };
|
|
28
|
+
}
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## 2. Suspense & Streaming Data Fetching
|
|
32
|
+
```tsx
|
|
33
|
+
import { Suspense } from 'react';
|
|
34
|
+
import { UserProfileSkeleton, UserProfile } from './UserProfile';
|
|
35
|
+
|
|
36
|
+
export default function DashboardPage() {
|
|
37
|
+
return (
|
|
38
|
+
<main className="p-6">
|
|
39
|
+
<h1 className="text-2xl font-bold">Dashboard</h1>
|
|
40
|
+
<Suspense fallback={<UserProfileSkeleton />}>
|
|
41
|
+
<UserProfile />
|
|
42
|
+
</Suspense>
|
|
43
|
+
</main>
|
|
44
|
+
);
|
|
45
|
+
}
|
|
46
|
+
```
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gemini-multimodal
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when analyzing visual mockups, inspecting UI screenshots, converting wireframes to frontend code, extracting architecture from diagrams, or performing visual QA regression checks using Gemini's native multimodal capabilities.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Gemini Multimodal Engineering
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
Gemini 1.5/3.8 models feature native multimodal grounding across images, diagrams, video frames, and audio tokens. This skill guides the agent on how to effectively extract structured specifications from visual assets and translate them into production code.
|
|
11
|
+
|
|
12
|
+
## Procedural Workflow
|
|
13
|
+
|
|
14
|
+
### 1. Visual Intake & Pre-Processing
|
|
15
|
+
- **Aspect Ratio & Resolution**: Gemini processes visual inputs with native resolution preservation.
|
|
16
|
+
- **Reference Assets**: When inspecting diagrams or UI mockups, identify layout hierarchy:
|
|
17
|
+
- Header / Navigation bars
|
|
18
|
+
- Main grid or flex container arrangements
|
|
19
|
+
- Typography weights, line heights, and color hex values
|
|
20
|
+
- Interactive elements (buttons, inputs, carousels, modals)
|
|
21
|
+
|
|
22
|
+
### 2. Mockup-to-Code Translation Pattern
|
|
23
|
+
When converting a visual mockup into web components:
|
|
24
|
+
1. **Layout First**: Implement semantic HTML scaffolding matching visual hierarchy.
|
|
25
|
+
2. **Design Tokens**: Extract exact color palettes, border radiuses, and shadow elevations into CSS variables.
|
|
26
|
+
3. **Responsive Breakpoints**: Infer desktop, tablet, and mobile reflow logic from the visual layout.
|
|
27
|
+
4. **Interactive States**: Emulate hover, focus-visible, and active states visible in the UI.
|
|
28
|
+
|
|
29
|
+
### 3. Diagram & Flowchart Extraction
|
|
30
|
+
When given an architectural whiteboard photo or flowchart:
|
|
31
|
+
1. Transcribe nodes and connections into clean **Mermaid.js** diagrams.
|
|
32
|
+
2. Extract data models, sequence flows, and component boundaries into typed interfaces.
|
|
33
|
+
|
|
34
|
+
### 4. Visual QA & Regression Diffing
|
|
35
|
+
1. Capture screenshots of the rendered application using `browser_subagent`.
|
|
36
|
+
2. Inspect layout anomalies: overlapping text, clipped containers, misalignment across viewports.
|
|
37
|
+
3. Apply surgical CSS adjustments without affecting sibling components.
|
|
38
|
+
|
|
39
|
+
## Verification Checklist
|
|
40
|
+
- [ ] Visual hierarchy precisely reflects the reference asset
|
|
41
|
+
- [ ] No placeholder assets or mock text left in production components
|
|
42
|
+
- [ ] CSS uses fluid units (`rem`, `ch`, `%`) and CSS grid/flexbox
|
|
43
|
+
- [ ] Visual artifacts verified via browser inspection or recording
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: git-craftsman
|
|
3
|
+
description: >-
|
|
4
|
+
Guides atomic commits, conventional commit formatting, clean branch strategies, and pull request walkthrough generation. Use when staging, committing, or preparing a PR.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Git Craftsman
|
|
8
|
+
|
|
9
|
+
This skill enforces clean version control habits, atomic commits, and structured pull request walkthroughs.
|
|
10
|
+
|
|
11
|
+
## Atomic Commit Workflow
|
|
12
|
+
|
|
13
|
+
### 1. Inspect Staged & Unstaged Diff
|
|
14
|
+
Always review changes before staging:
|
|
15
|
+
```bash
|
|
16
|
+
git status -s
|
|
17
|
+
git diff
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
### 2. Craft Conventional Commit Messages
|
|
21
|
+
Format commit messages strictly following the Conventional Commits specification:
|
|
22
|
+
```text
|
|
23
|
+
<type>(<scope>): <short imperative summary>
|
|
24
|
+
|
|
25
|
+
[optional detailed body explaining WHY, not just WHAT]
|
|
26
|
+
|
|
27
|
+
[optional breaking changes or issue references]
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
**Permitted Types**:
|
|
31
|
+
- `feat`: New feature or user-facing functionality.
|
|
32
|
+
- `fix`: Bug fix.
|
|
33
|
+
- `refactor`: Code change that neither fixes a bug nor adds a feature.
|
|
34
|
+
- `perf`: Performance improvement.
|
|
35
|
+
- `test`: Adding or correcting tests.
|
|
36
|
+
- `docs`: Documentation only changes.
|
|
37
|
+
- `chore`: Build system, configuration, or dependency updates.
|
|
38
|
+
|
|
39
|
+
### 3. Pull Request Walkthrough Format
|
|
40
|
+
When authoring a pull request summary, include:
|
|
41
|
+
- **High-Level Objective**: What problem this PR solves.
|
|
42
|
+
- **Key Changes**: Bulleted list of modified modules with clickable file links.
|
|
43
|
+
- **Verification Performed**: Exact commands run (`npm test`, `cargo test`) and results.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: performance-profiler
|
|
3
|
+
description: >-
|
|
4
|
+
Profiles application latency, CPU usage, memory leaks, and database bottlenecks. Use when diagnosing slow response times, high resource consumption, or memory leaks.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Performance Profiler
|
|
8
|
+
|
|
9
|
+
This skill guides the agent through systematic latency and resource bottleneck profiling.
|
|
10
|
+
|
|
11
|
+
## Profiling Workflow
|
|
12
|
+
|
|
13
|
+
### 1. Identify the Bottleneck Metric
|
|
14
|
+
Determine the performance symptom:
|
|
15
|
+
- **High CPU**: Algorithmic complexity ($O(n^2)$), tight loops, excessive JSON serialization.
|
|
16
|
+
- **High Memory / Leak**: Retained closures, unclosed database streams, unbounded in-memory caches.
|
|
17
|
+
- **High Latency (I/O)**: N+1 database queries, unindexed SQL lookups, synchronous blocking disk I/O.
|
|
18
|
+
|
|
19
|
+
### 2. Node.js & V8 Profiling
|
|
20
|
+
Run Node with the V8 sampling profiler:
|
|
21
|
+
```bash
|
|
22
|
+
node --prof app.js
|
|
23
|
+
node --prof-process isolate-*.log > processed.txt
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
### 3. Database Query Analysis
|
|
27
|
+
- **PostgreSQL**: Run `EXPLAIN (ANALYZE, BUFFERS) <query>` to inspect sequential scans, join types, and execution time.
|
|
28
|
+
- **Indexes**: Verify that high-cardinality `WHERE` and `JOIN` columns have appropriate B-Tree or Hash indexes.
|
|
29
|
+
|
|
30
|
+
### 4. Memory Heap Dumps
|
|
31
|
+
Capture heap snapshots or track memory diffs between iterations to isolate leaks:
|
|
32
|
+
```javascript
|
|
33
|
+
const mem = process.memoryUsage();
|
|
34
|
+
console.log(`Heap Used: ${Math.round(mem.heapUsed / 1024 / 1024)} MB`);
|
|
35
|
+
```
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# Quick Node.js CPU profiling helper
|
|
3
|
+
|
|
4
|
+
TARGET="${1:-index.js}"
|
|
5
|
+
DURATION="${2:-10}"
|
|
6
|
+
|
|
7
|
+
echo "Starting CPU profiling for $TARGET ($DURATION seconds)..."
|
|
8
|
+
NODE_V8_COVERAGE=coverage node --cpu-prof "$TARGET" &
|
|
9
|
+
PID=$!
|
|
10
|
+
|
|
11
|
+
sleep "$DURATION"
|
|
12
|
+
kill -SIGINT "$PID" 2>/dev/null || true
|
|
13
|
+
echo "CPU profile generated. Look for CPU.*.cpuprofile in the directory."
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: repo-onboarding
|
|
3
|
+
description: >-
|
|
4
|
+
Rapidly inspects an unfamiliar codebase, maps directory structures, identifies key patterns, and generates a structured Knowledge Item (KI) for permanent repository memory.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Repository Onboarding & Knowledge Item (KI) Indexing
|
|
8
|
+
|
|
9
|
+
When an agent enters a new codebase, this skill provides a structured exploration sequence to index architecture, conventions, and operational runbooks without wasting excessive context.
|
|
10
|
+
|
|
11
|
+
## Onboarding Procedure
|
|
12
|
+
|
|
13
|
+
### 1. Root & Ecosystem Inspection
|
|
14
|
+
1. Read project manifest: `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`.
|
|
15
|
+
2. Check `.gitignore` to identify ignored artifacts, environment configs, and build outputs.
|
|
16
|
+
3. Check `README.md` and docs for local setup and testing scripts.
|
|
17
|
+
|
|
18
|
+
### 2. Architectural Survey
|
|
19
|
+
1. Run `list_dir` on root and top-level directories to understand organizational patterns (e.g. Clean Architecture, Monorepo, MVC).
|
|
20
|
+
2. Identify entry points (e.g., `src/index.ts`, `app/main.py`, `cmd/server/main.go`).
|
|
21
|
+
3. Locate core data models and database schemas (e.g., Prisma schemas, SQLAlchemy models, migrations).
|
|
22
|
+
|
|
23
|
+
### 3. Build & Test Verification
|
|
24
|
+
Run the project's build and test commands to verify environment health:
|
|
25
|
+
```bash
|
|
26
|
+
# E.g.
|
|
27
|
+
npm run build && npm test
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
### 4. Create Repository Knowledge Item (KI)
|
|
31
|
+
Persist findings into the localized Knowledge Items store so subsequent sessions have instant architectural recall:
|
|
32
|
+
- Create `metadata.json` outlining core patterns, key paths, and test instructions.
|
|
33
|
+
- Create an architecture summary artifact in `<appDataDir>/knowledge`.
|
|
34
|
+
|
|
35
|
+
For the schema and structure of Knowledge Items, see [references/knowledge-item-schema.md](./references/knowledge-item-schema.md).
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Knowledge Items (KI) Schema & Reference
|
|
2
|
+
|
|
3
|
+
Knowledge Items are Antigravity's persistent, curated memory units stored in `<appDataDir>/knowledge`.
|
|
4
|
+
|
|
5
|
+
## Structure
|
|
6
|
+
```text
|
|
7
|
+
<appDataDir>/knowledge/<ki-id>/
|
|
8
|
+
├── metadata.json
|
|
9
|
+
└── artifacts/
|
|
10
|
+
├── architecture.md
|
|
11
|
+
└── common-patterns.md
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
## `metadata.json` Format
|
|
15
|
+
```json
|
|
16
|
+
{
|
|
17
|
+
"title": "Repository Architecture & Patterns",
|
|
18
|
+
"summary": "Fullstack Next.js app using PostgreSQL, Prisma, and Tailwind CSS. Tests run via Vitest.",
|
|
19
|
+
"createdAt": "2026-10-15T10:00:00Z",
|
|
20
|
+
"updatedAt": "2026-10-15T10:00:00Z",
|
|
21
|
+
"references": [
|
|
22
|
+
"package.json",
|
|
23
|
+
"prisma/schema.prisma",
|
|
24
|
+
"vitest.config.ts"
|
|
25
|
+
]
|
|
26
|
+
}
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## When to Consult Knowledge Items
|
|
30
|
+
Always check Knowledge Items before performing deep-dive architectural investigations to avoid duplicating work and violating established team conventions.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: root-cause-debugger
|
|
3
|
+
description: >-
|
|
4
|
+
Systematically diagnoses complex regressions, silent data corruptions, race conditions, and elusive bugs using binary search (git bisect), log analysis, and reproduction harnesses.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Root Cause Debugger
|
|
8
|
+
|
|
9
|
+
This skill provides an evidence-based debugging procedure to eliminate guessing and find root causes rapidly.
|
|
10
|
+
|
|
11
|
+
## 5-Step Debugging Protocol
|
|
12
|
+
|
|
13
|
+
### 1. Build a Minimal Reproducer (MRE)
|
|
14
|
+
- Never start guessing fixes without an automated test or minimal script that reliably triggers the failure.
|
|
15
|
+
- Strip away unrelated modules until only the failing component remains.
|
|
16
|
+
|
|
17
|
+
### 2. Formulate & Test Hypotheses
|
|
18
|
+
- List the top 2-3 plausible hypotheses for why the failure occurs.
|
|
19
|
+
- Add targeted debug statements or breakpoints to confirm or falsify each hypothesis sequentially.
|
|
20
|
+
|
|
21
|
+
### 3. Binary Search History with `git bisect`
|
|
22
|
+
If the bug is a regression that didn't exist in an earlier commit:
|
|
23
|
+
```bash
|
|
24
|
+
git bisect start
|
|
25
|
+
git bisect bad HEAD
|
|
26
|
+
git bisect good <known-good-commit>
|
|
27
|
+
git bisect run ./test-runner.sh
|
|
28
|
+
```
|
|
29
|
+
This isolates the exact offending commit in $O(\log n)$ steps.
|
|
30
|
+
|
|
31
|
+
### 4. Implement Minimal Surgical Fix
|
|
32
|
+
- Resolve the root cause directly at its source. Avoid superficial patches that merely silence error messages.
|
|
33
|
+
|
|
34
|
+
### 5. Add Regression Shield Test
|
|
35
|
+
- Commit an automated test that explicitly verifies the regression never recurs.
|