everything-gemini 1.0.1 → 1.1.1
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/.github/workflows/release.yml +7 -0
- package/CHANGELOG.md +36 -0
- package/README.md +33 -9
- package/assets/banner.jpg +0 -0
- package/bin/everything-gemini +194 -3
- package/docs/LAUNCH_KIT.md +156 -0
- package/docs/index.html +555 -0
- package/examples/python-sdk/README.md +36 -0
- package/examples/python-sdk/orchestrate_subagents.py +59 -0
- package/package.json +2 -1
- package/skills/ai-first-engineering/SKILL.md +68 -0
- package/skills/gemini-function-calling/SKILL.md +90 -0
- package/skills/github-ops/SKILL.md +102 -0
- package/skills/rag-architect/SKILL.md +60 -0
- package/templates/full-power/AGENTS.md +12 -0
- package/templates/full-power/GEMINI.md +12 -0
- package/templates/full-power/hooks.json +56 -0
- package/templates/full-power/mcp_config.json +15 -0
- package/templates/recommended/AGENTS.md +11 -0
- package/templates/recommended/GEMINI.md +11 -0
- package/templates/recommended/hooks.json +43 -0
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ai-first-engineering
|
|
3
|
+
description: Decomposes ambiguous software requirements into deterministic milestones, executable acceptance criteria, and test-backed delivery pipelines for AI agent development.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# AI-First Engineering Principles & Delivery Playbook
|
|
7
|
+
|
|
8
|
+
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.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. Core Directives
|
|
13
|
+
|
|
14
|
+
1. **Deterministic Specification Before Code**:
|
|
15
|
+
- Never write production code based on vague requirements.
|
|
16
|
+
- Deconstruct high-level prompts into verifiable acceptance criteria (Given/When/Then).
|
|
17
|
+
2. **Blast Radius Minimization**:
|
|
18
|
+
- Scope code modifications strictly to the files necessary to satisfy the feature.
|
|
19
|
+
- Guard against accidental refactoring of unrelated subsystems or styles.
|
|
20
|
+
3. **Continuous Verification Loop**:
|
|
21
|
+
- Every modification must be coupled with automated validation (unit tests, integration suites, linters, or visual browser assertions).
|
|
22
|
+
- If tests fail, diagnose the root cause from the error log before modifying code.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 2. Requirement Decomposition Matrix
|
|
27
|
+
|
|
28
|
+
When given an ambiguous task (e.g., *"Make user onboarding faster"* or *"Add subscription billing"*), follow this three-stage breakdown:
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
[Ambiguous Goal] ──► [Milestone Decomposition] ──► [Executable Criteria] ──► [Zero-Regression Delivery]
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
### Stage 1: Milestone Decomposition
|
|
35
|
+
Break large tasks into discrete, independently testable phases:
|
|
36
|
+
- **Phase 1: Contracts & Schema**: Types, interfaces, database schemas, and API contracts.
|
|
37
|
+
- **Phase 2: Failing Assertions (Red)**: Unit / integration tests validating expected behavior.
|
|
38
|
+
- **Phase 3: Implementation (Green)**: Minimal surgical code satisfying the tests.
|
|
39
|
+
- **Phase 4: Hardening & Docs (Refactor)**: Error handling, edge cases, logging, and documentation.
|
|
40
|
+
|
|
41
|
+
### Stage 2: Executable Acceptance Criteria
|
|
42
|
+
Formulate specifications using the standard Gherkin / BDD structure:
|
|
43
|
+
- **Given**: Initial system state and prerequisites.
|
|
44
|
+
- **When**: Specific user or API action occurs.
|
|
45
|
+
- **Then**: Measurable system response, database state, or error envelope.
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## 3. Risk Radius & Boundary Containment
|
|
50
|
+
|
|
51
|
+
Before modifying core abstractions, evaluate the **Risk Radius**:
|
|
52
|
+
|
|
53
|
+
| Radius Tier | Scope | Required Precautions |
|
|
54
|
+
| :--- | :--- | :--- |
|
|
55
|
+
| **Tier 1: Leaf Node** | Isolated helper functions, standalone components | Standard unit test verification |
|
|
56
|
+
| **Tier 2: Service / Store** | State management, database queries, shared services | Integration tests + typechecking |
|
|
57
|
+
| **Tier 3: Core Abstraction**| DB migrations, auth middleware, global config | Migration rollback plan + full test suite run |
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
## 4. Autonomous Debugging Protocol
|
|
62
|
+
|
|
63
|
+
When encountering unexpected test failures or runtime regressions:
|
|
64
|
+
|
|
65
|
+
1. **Read Full Error Trace**: Never guess or apply speculative patches without inspecting the actual stack trace.
|
|
66
|
+
2. **Reproduce in Isolation**: Create a minimal reproduction test or script before touching implementation files.
|
|
67
|
+
3. **Binary Search (Bisect)**: If behavior unexpectedly changed, identify the breaking commit or input change systematically.
|
|
68
|
+
4. **Surgical Fix**: Apply the smallest possible fix that resolves the issue while preserving surrounding code formatting and comments.
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gemini-function-calling
|
|
3
|
+
description: >-
|
|
4
|
+
Designs, validates, and tests production Gemini function calling schemas, structured outputs with Pydantic/JSON Schema, parallel tool dispatch, and error recovery loops.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Gemini Function Calling & Structured Outputs
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
## Core Capabilities
|
|
13
|
+
|
|
14
|
+
### 1. Function Declarations (Tools)
|
|
15
|
+
Define tools with clear semantics, parameter types, descriptions, and required constraints:
|
|
16
|
+
|
|
17
|
+
```python
|
|
18
|
+
from google.genai import types
|
|
19
|
+
|
|
20
|
+
def get_db_schema_declaration() -> types.FunctionDeclaration:
|
|
21
|
+
return types.FunctionDeclaration(
|
|
22
|
+
name="query_database",
|
|
23
|
+
description="Executes a read-only SQL query against the application replica.",
|
|
24
|
+
parameters=types.Schema(
|
|
25
|
+
type=types.Type.OBJECT,
|
|
26
|
+
properties={
|
|
27
|
+
"query": types.Schema(
|
|
28
|
+
type=types.Type.STRING,
|
|
29
|
+
description="The SQL query to execute. Must be a SELECT statement."
|
|
30
|
+
),
|
|
31
|
+
"limit": types.Schema(
|
|
32
|
+
type=types.Type.INTEGER,
|
|
33
|
+
description="Maximum number of rows to return (default: 50, max: 200)."
|
|
34
|
+
)
|
|
35
|
+
},
|
|
36
|
+
required=["query"]
|
|
37
|
+
)
|
|
38
|
+
)
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### 2. Structured JSON Outputs (`response_schema`)
|
|
42
|
+
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):
|
|
43
|
+
|
|
44
|
+
```python
|
|
45
|
+
from pydantic import BaseModel, Field
|
|
46
|
+
|
|
47
|
+
class CodeAnalysisReport(BaseModel):
|
|
48
|
+
summary: str = Field(description="High-level architecture assessment")
|
|
49
|
+
vulnerabilities: list[str] = Field(description="List of identified security vulnerabilities")
|
|
50
|
+
risk_score: int = Field(description="Risk rating from 1 (lowest) to 10 (critical)", ge=1, le=10)
|
|
51
|
+
|
|
52
|
+
config = types.GenerateContentConfig(
|
|
53
|
+
response_mime_type="application/json",
|
|
54
|
+
response_schema=CodeAnalysisReport,
|
|
55
|
+
temperature=0.1
|
|
56
|
+
)
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
### 3. Parallel & Multi-Turn Function Calling
|
|
60
|
+
- **Parallel Dispatch**: Gemini can return multiple function calls in a single response turn. Process independent read operations concurrently using `asyncio.gather` or `Promise.all`.
|
|
61
|
+
- **Function Response Envelope**: Return the results of each tool back to the model with matching tool names and execution status:
|
|
62
|
+
|
|
63
|
+
```python
|
|
64
|
+
tool_response_part = types.Part.from_function_response(
|
|
65
|
+
name="query_database",
|
|
66
|
+
response={"status": "success", "rows": rows, "count": len(rows)}
|
|
67
|
+
)
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### 4. Error Recovery & Defensive Handling
|
|
71
|
+
When a tool execution fails (e.g., database timeout or syntax error):
|
|
72
|
+
1. **Never suppress the error silently**: Feed the error back to Gemini in the function response envelope.
|
|
73
|
+
2. **Include Contextual Remediation**: Inform the model why the call failed so it can self-correct in the next turn:
|
|
74
|
+
|
|
75
|
+
```python
|
|
76
|
+
error_part = types.Part.from_function_response(
|
|
77
|
+
name="query_database",
|
|
78
|
+
response={
|
|
79
|
+
"status": "error",
|
|
80
|
+
"error_code": "SYNTAX_ERROR",
|
|
81
|
+
"message": "Column 'user_id' does not exist in table 'accounts'. Available columns: [id, account_number, balance]."
|
|
82
|
+
}
|
|
83
|
+
)
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## Verification Checklist
|
|
87
|
+
- [ ] Tool parameters have unambiguous `description` fields
|
|
88
|
+
- [ ] `required` fields explicitly defined
|
|
89
|
+
- [ ] Read-only vs destructive operations strictly separated
|
|
90
|
+
- [ ] Tool execution errors safely fed back to model for autonomous self-correction
|
|
@@ -0,0 +1,102 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: github-ops
|
|
3
|
+
description: Orchestrates GitHub workflows, automated Pull Request generation, code review triage, release management, and issue automation using GitHub MCP and the gh CLI.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# GitHub Ops & Repository Lifecycle Automation
|
|
7
|
+
|
|
8
|
+
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.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. Operating Principles
|
|
13
|
+
|
|
14
|
+
1. **Atomic & Linear Commits**:
|
|
15
|
+
- Keep Pull Requests focused on a single logical change or feature.
|
|
16
|
+
- Use Conventional Commits (`feat:`, `fix:`, `refactor:`, `docs:`, `chore:`).
|
|
17
|
+
2. **Deterministic Verification Before PR**:
|
|
18
|
+
- Always run the local test suite and lint verification before creating or updating a PR.
|
|
19
|
+
- Never push failing code or uncommitted working trees.
|
|
20
|
+
3. **Traceability**:
|
|
21
|
+
- Every PR must link back to an issue or feature specification (`Closes #123` or `Refs #456`).
|
|
22
|
+
- Every release tag must be accompanied by an auto-generated or structured changelog.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 2. GitHub CLI (`gh`) & MCP Integration
|
|
27
|
+
|
|
28
|
+
When interacting with GitHub, use either the configured **GitHub MCP Server** or the standard **`gh` CLI**.
|
|
29
|
+
|
|
30
|
+
### Essential `gh` Command Patterns
|
|
31
|
+
|
|
32
|
+
| Task | Command |
|
|
33
|
+
| :--- | :--- |
|
|
34
|
+
| **Check Auth Status** | `gh auth status` |
|
|
35
|
+
| **Inspect Open Issues** | `gh issue list --limit 10` |
|
|
36
|
+
| **View Issue Details** | `gh issue view <issue-number>` |
|
|
37
|
+
| **Create Pull Request** | `gh pr create --title "..." --body "..."` |
|
|
38
|
+
| **View PR Status & Checks** | `gh pr status` / `gh pr checks` |
|
|
39
|
+
| **View PR Diff** | `gh pr diff <pr-number>` |
|
|
40
|
+
| **Add PR Comment/Review** | `gh pr review <pr-number> --comment -b "..."` |
|
|
41
|
+
| **Merge Pull Request** | `gh pr merge <pr-number> --squash --delete-branch` |
|
|
42
|
+
| **Create Release Tag** | `gh release create v1.1.0 --title "v1.1.0" --notes "..."` |
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## 3. Pull Request Generation Workflow
|
|
47
|
+
|
|
48
|
+
When authoring a Pull Request on behalf of the user, follow this structured template:
|
|
49
|
+
|
|
50
|
+
```markdown
|
|
51
|
+
## 🎯 Overview
|
|
52
|
+
<!-- 1-2 concise sentences summarizing the problem solved or capability introduced -->
|
|
53
|
+
|
|
54
|
+
## 🛠️ Changes Implemented
|
|
55
|
+
- **Component / File**: High-level explanation of modification.
|
|
56
|
+
- **Architectural Decision**: Rationale for design choices or trade-offs.
|
|
57
|
+
|
|
58
|
+
## 🧪 Verification & Testing
|
|
59
|
+
- [x] Unit / Integration tests pass (`npm test`, `pytest`, or `cargo test`).
|
|
60
|
+
- [x] Linters and typecheckers pass (`npm run lint`, `tsc --noEmit`).
|
|
61
|
+
- [x] Verified zero breaking changes to existing public APIs.
|
|
62
|
+
|
|
63
|
+
## 🔗 Related Issues
|
|
64
|
+
Closes #<issue-number>
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## 4. Automated PR Review Protocol
|
|
70
|
+
|
|
71
|
+
When performing automated reviews on a GitHub PR:
|
|
72
|
+
|
|
73
|
+
1. **Fetch & Inspect Diff**:
|
|
74
|
+
```bash
|
|
75
|
+
gh pr diff <pr-number>
|
|
76
|
+
```
|
|
77
|
+
2. **Review Checklist**:
|
|
78
|
+
- **Correctness**: Does the code satisfy the acceptance criteria without subtle edge-case failures?
|
|
79
|
+
- **Security**: Are there unsanitized inputs, hardcoded secrets, or privilege escalations?
|
|
80
|
+
- **Performance**: Are there N+1 database queries, unmemoized expensive loops, or memory leaks?
|
|
81
|
+
- **Style & Standards**: Does it adhere to the repository's established conventions?
|
|
82
|
+
3. **Submitting Feedback**:
|
|
83
|
+
- Use `gh pr review <pr-number> --comment` for non-blocking suggestions.
|
|
84
|
+
- Use `gh pr review <pr-number> --request-changes` for critical bugs or regressions.
|
|
85
|
+
- Use `gh pr review <pr-number> --approve` once all checks pass.
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## 5. Release Automation
|
|
90
|
+
|
|
91
|
+
To publish a clean semantic release:
|
|
92
|
+
1. Verify `package.json` / version files are updated.
|
|
93
|
+
2. Ensure working tree is clean (`git status`).
|
|
94
|
+
3. Create and push git tag:
|
|
95
|
+
```bash
|
|
96
|
+
git tag vX.Y.Z
|
|
97
|
+
git push origin vX.Y.Z
|
|
98
|
+
```
|
|
99
|
+
4. Generate release notes with GitHub CLI:
|
|
100
|
+
```bash
|
|
101
|
+
gh release create vX.Y.Z --generate-notes
|
|
102
|
+
```
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: rag-architect
|
|
3
|
+
description: >-
|
|
4
|
+
Designs retrieval-augmented generation (RAG) pipelines, semantic chunking strategies, hybrid keyword-vector search, re-ranking, and pgvector embeddings using Gemini models.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# RAG Architecture & Vector Retrieval with Gemini
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
## Core RAG Pipeline
|
|
13
|
+
|
|
14
|
+
```
|
|
15
|
+
[Documents] ──► [Semantic Chunker] ──► [text-embedding-004] ──► [Vector DB / pgvector]
|
|
16
|
+
│
|
|
17
|
+
[User Query] ──► [Hybrid Retrieval: BM25 + Dense Vector] ───────────────┤
|
|
18
|
+
▼
|
|
19
|
+
[Gemini Reranker & Filter]
|
|
20
|
+
▼
|
|
21
|
+
[Context Window (Cached)]
|
|
22
|
+
▼
|
|
23
|
+
[Grounded Synthesis]
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
## Architectural Guidelines
|
|
27
|
+
|
|
28
|
+
### 1. Embedding Model Selection
|
|
29
|
+
- Use **`text-embedding-004`** (768 dimensions) for semantic vector representations.
|
|
30
|
+
- Apply task types appropriately when generating embeddings:
|
|
31
|
+
- `RETRIEVAL_DOCUMENT`: For indexing documents into the knowledge store.
|
|
32
|
+
- `RETRIEVAL_QUERY`: For embedding the user's incoming query.
|
|
33
|
+
- `SEMANTIC_SIMILARITY`: For clustering and duplicate detection.
|
|
34
|
+
|
|
35
|
+
### 2. Semantic Chunking Strategies
|
|
36
|
+
- **Code Repositories**: Chunk by syntax boundaries (AST classes, functions, modules) rather than fixed token lengths.
|
|
37
|
+
- **Documentation**: Chunk by markdown headers (`##`, `###`) preserving title hierarchy as chunk metadata.
|
|
38
|
+
- **Overlap**: Maintain a 10-15% token overlap across sliding windows to prevent boundary truncation of critical concepts.
|
|
39
|
+
|
|
40
|
+
### 3. Hybrid Retrieval (Sparse + Dense)
|
|
41
|
+
Never rely exclusively on vector distance. Combine:
|
|
42
|
+
- **Dense Vector Search**: Cosine or inner product similarity via `pgvector` or Qdrant for semantic meaning.
|
|
43
|
+
- **Sparse Keyword Search**: Full-text search (BM25 or PostgreSQL `tsvector`) for exact identifier matches, error codes, and function names.
|
|
44
|
+
- Combine scores using Reciprocal Rank Fusion (RRF):
|
|
45
|
+
$$RRF(d) = \sum \frac{1}{60 + r_i(d)}$$
|
|
46
|
+
|
|
47
|
+
### 4. Gemini Two-Stage Reranking
|
|
48
|
+
1. Retrieve top 50 candidates from hybrid search.
|
|
49
|
+
2. Pass the top 50 candidate snippets to `gemini-1.5-flash` or `gemini-3.8` for high-speed relevance scoring and deduplication.
|
|
50
|
+
3. Inject the top 5-10 highest-scoring excerpts into the reasoning context window.
|
|
51
|
+
|
|
52
|
+
### 5. Context Injection & Static Prefix Caching
|
|
53
|
+
- Structure prompt templates with static instruction prefixes placed before retrieved dynamic context to maximize Gemini's automatic **Prefix Context Caching**.
|
|
54
|
+
- Tag all retrieved chunks with clickable source links: `[source.py:L10-L45](file:///path/to/source.py#L10-L45)`.
|
|
55
|
+
|
|
56
|
+
## Verification Checklist
|
|
57
|
+
- [ ] Appropriate embedding task types specified (`RETRIEVAL_DOCUMENT` vs `RETRIEVAL_QUERY`)
|
|
58
|
+
- [ ] Chunks respect syntax and AST boundaries
|
|
59
|
+
- [ ] Hybrid search active for exact symbol matching
|
|
60
|
+
- [ ] Clickable `file://` citations attached to synthesized outputs
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Antigravity Enterprise Standards (Full-Power Profile)
|
|
2
|
+
|
|
3
|
+
## 1. Prime Directives
|
|
4
|
+
1. **Zero Hallucination & Evidence-First**: Never speculate on APIs, schemas, or dependencies. Always view code before proposing edits.
|
|
5
|
+
2. **Subagent Delegation Discipline**: Defer heavy multi-file exploration to `planner`, adversarial audits to `security-auditor`, and UI verification to `browser-qa`.
|
|
6
|
+
3. **Progressive Disclosure**: Keep prompt context lean (<3,500 tokens). Pull skills and schemas into context strictly on-demand.
|
|
7
|
+
4. **Deterministic Verification Loop**: Code changes require passing automated tests (`npm test` / pytest) before concluding.
|
|
8
|
+
5. **Continuous Learning**: When errors or user corrections occur, record the insight using `/learn` into permanent Knowledge Items.
|
|
9
|
+
|
|
10
|
+
## 2. Security & Operational Policy
|
|
11
|
+
- Strict zero-trust command execution: All raw shell commands must pass GeminiShield gating.
|
|
12
|
+
- Webhooks, tokens, and credentials must be read from environment variables with no hardcoding.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Antigravity Enterprise Standards (Full-Power Profile)
|
|
2
|
+
|
|
3
|
+
## 1. Prime Directives
|
|
4
|
+
1. **Zero Hallucination & Evidence-First**: Never speculate on APIs, schemas, or dependencies. Always view code before proposing edits.
|
|
5
|
+
2. **Subagent Delegation Discipline**: Defer heavy multi-file exploration to `planner`, adversarial audits to `security-auditor`, and UI verification to `browser-qa`.
|
|
6
|
+
3. **Progressive Disclosure**: Keep prompt context lean (<3,500 tokens). Pull skills and schemas into context strictly on-demand.
|
|
7
|
+
4. **Deterministic Verification Loop**: Code changes require passing automated tests (`npm test` / pytest) before concluding.
|
|
8
|
+
5. **Continuous Learning**: When errors or user corrections occur, record the insight using `/learn` into permanent Knowledge Items.
|
|
9
|
+
|
|
10
|
+
## 2. Security & Operational Policy
|
|
11
|
+
- Strict zero-trust command execution: All raw shell commands must pass GeminiShield gating.
|
|
12
|
+
- Webhooks, tokens, and credentials must be read from environment variables with no hardcoding.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
{
|
|
2
|
+
"gemini-shield": {
|
|
3
|
+
"PreToolUse": [
|
|
4
|
+
{
|
|
5
|
+
"matcher": "run_command",
|
|
6
|
+
"hooks": [
|
|
7
|
+
{
|
|
8
|
+
"type": "command",
|
|
9
|
+
"command": "bash ./hooks/gemini-shield/scripts/shield-gate.sh",
|
|
10
|
+
"timeout": 15
|
|
11
|
+
}
|
|
12
|
+
]
|
|
13
|
+
}
|
|
14
|
+
]
|
|
15
|
+
},
|
|
16
|
+
"auto-lint": {
|
|
17
|
+
"PostToolUse": [
|
|
18
|
+
{
|
|
19
|
+
"matcher": "replace_file_content|write_to_file",
|
|
20
|
+
"hooks": [
|
|
21
|
+
{
|
|
22
|
+
"type": "command",
|
|
23
|
+
"command": "bash ./hooks/auto-lint-formatter/scripts/auto-format.sh",
|
|
24
|
+
"timeout": 10
|
|
25
|
+
}
|
|
26
|
+
]
|
|
27
|
+
}
|
|
28
|
+
]
|
|
29
|
+
},
|
|
30
|
+
"goal-verifier": {
|
|
31
|
+
"Stop": [
|
|
32
|
+
{
|
|
33
|
+
"hooks": [
|
|
34
|
+
{
|
|
35
|
+
"type": "command",
|
|
36
|
+
"command": "bash ./hooks/goal-verifier/scripts/verify-goal.sh",
|
|
37
|
+
"timeout": 15
|
|
38
|
+
}
|
|
39
|
+
]
|
|
40
|
+
}
|
|
41
|
+
]
|
|
42
|
+
},
|
|
43
|
+
"learned-instincts": {
|
|
44
|
+
"PostInvocation": [
|
|
45
|
+
{
|
|
46
|
+
"hooks": [
|
|
47
|
+
{
|
|
48
|
+
"type": "command",
|
|
49
|
+
"command": "bash ./hooks/learned-instincts/scripts/save-instinct.sh",
|
|
50
|
+
"timeout": 10
|
|
51
|
+
}
|
|
52
|
+
]
|
|
53
|
+
}
|
|
54
|
+
]
|
|
55
|
+
}
|
|
56
|
+
}
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
{
|
|
2
|
+
"mcpServers": {
|
|
3
|
+
"github": {
|
|
4
|
+
"command": "npx",
|
|
5
|
+
"args": ["-y", "@modelcontextprotocol/server-github"],
|
|
6
|
+
"env": {
|
|
7
|
+
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
|
|
8
|
+
}
|
|
9
|
+
},
|
|
10
|
+
"postgres": {
|
|
11
|
+
"command": "npx",
|
|
12
|
+
"args": ["-y", "@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
|
|
13
|
+
}
|
|
14
|
+
}
|
|
15
|
+
}
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Antigravity Developer Standards (Recommended)
|
|
2
|
+
|
|
3
|
+
## 1. Prime Directives
|
|
4
|
+
1. **Zero Hallucination**: Always inspect file contents, exports, and signatures with `view_file` or `grep_search` before proposing or applying modifications.
|
|
5
|
+
2. **Minimal Surgical Diffs**: Preserve all existing comments, docstrings, and formatting unrelated to your task.
|
|
6
|
+
3. **Automated Verification Loop**: Every modification must be followed by automated verification (running unit tests, linters, or typecheckers).
|
|
7
|
+
4. **Clickable Markdown Navigation**: Always format file paths and symbols as clickable links using the `file://` scheme: `[filename](file:///absolute/path/to/file)`.
|
|
8
|
+
|
|
9
|
+
## 2. Terminal & Tool Safety
|
|
10
|
+
- Never run unchecked destructive operations (`rm -rf *`, `git reset --hard`, `DROP TABLE`).
|
|
11
|
+
- Run persistent processes and background servers with `IsDaemon: true`.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Antigravity Developer Standards (Recommended)
|
|
2
|
+
|
|
3
|
+
## 1. Prime Directives
|
|
4
|
+
1. **Zero Hallucination**: Always inspect file contents, exports, and signatures with `view_file` or `grep_search` before proposing or applying modifications.
|
|
5
|
+
2. **Minimal Surgical Diffs**: Preserve all existing comments, docstrings, and formatting unrelated to your task.
|
|
6
|
+
3. **Automated Verification Loop**: Every modification must be followed by automated verification (running unit tests, linters, or typecheckers).
|
|
7
|
+
4. **Clickable Markdown Navigation**: Always format file paths and symbols as clickable links using the `file://` scheme: `[filename](file:///absolute/path/to/file)`.
|
|
8
|
+
|
|
9
|
+
## 2. Terminal & Tool Safety
|
|
10
|
+
- Never run unchecked destructive operations (`rm -rf *`, `git reset --hard`, `DROP TABLE`).
|
|
11
|
+
- Run persistent processes and background servers with `IsDaemon: true`.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
{
|
|
2
|
+
"safety-shield": {
|
|
3
|
+
"PreToolUse": [
|
|
4
|
+
{
|
|
5
|
+
"matcher": "run_command",
|
|
6
|
+
"hooks": [
|
|
7
|
+
{
|
|
8
|
+
"type": "command",
|
|
9
|
+
"command": "bash ./hooks/safety-shield/scripts/safety-gate.sh",
|
|
10
|
+
"timeout": 15
|
|
11
|
+
}
|
|
12
|
+
]
|
|
13
|
+
}
|
|
14
|
+
]
|
|
15
|
+
},
|
|
16
|
+
"auto-lint": {
|
|
17
|
+
"PostToolUse": [
|
|
18
|
+
{
|
|
19
|
+
"matcher": "replace_file_content|write_to_file",
|
|
20
|
+
"hooks": [
|
|
21
|
+
{
|
|
22
|
+
"type": "command",
|
|
23
|
+
"command": "bash ./hooks/auto-lint-formatter/scripts/auto-format.sh",
|
|
24
|
+
"timeout": 10
|
|
25
|
+
}
|
|
26
|
+
]
|
|
27
|
+
}
|
|
28
|
+
]
|
|
29
|
+
},
|
|
30
|
+
"goal-verifier": {
|
|
31
|
+
"Stop": [
|
|
32
|
+
{
|
|
33
|
+
"hooks": [
|
|
34
|
+
{
|
|
35
|
+
"type": "command",
|
|
36
|
+
"command": "bash ./hooks/goal-verifier/scripts/verify-goal.sh",
|
|
37
|
+
"timeout": 15
|
|
38
|
+
}
|
|
39
|
+
]
|
|
40
|
+
}
|
|
41
|
+
]
|
|
42
|
+
}
|
|
43
|
+
}
|