everything-gemini 1.0.0 → 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 +49 -0
- package/CHANGELOG.md +81 -0
- package/CONTRIBUTING.md +2 -2
- package/README.md +55 -25
- package/assets/banner.jpg +0 -0
- package/bin/everything-gemini +198 -7
- package/docs/LAUNCH_KIT.md +156 -0
- package/docs/architecture/progressive-disclosure.md +1 -1
- package/docs/index.html +555 -0
- package/docs/workflows/slash-commands.md +3 -3
- package/examples/python-sdk/README.md +36 -0
- package/examples/python-sdk/orchestrate_subagents.py +59 -0
- package/hooks/auto-lint-formatter/scripts/auto-format.sh +1 -1
- package/hooks/ephemeral-context/scripts/inject-context.sh +2 -2
- package/hooks/goal-verifier/scripts/verify-goal.sh +2 -2
- package/hooks/safety-shield/scripts/safety-gate.sh +3 -3
- package/package.json +2 -1
- package/plugins/core/plugin.json +1 -1
- package/plugins/python-ai/plugin.json +1 -1
- package/plugins/security-shield/plugin.json +1 -1
- package/plugins/web-fullstack/plugin.json +1 -1
- package/rules/common/AGENTS.md +1 -1
- package/rules/common/GEMINI.md +1 -1
- package/skills/ai-first-engineering/SKILL.md +68 -0
- package/skills/cloudflare-workers/SKILL.md +72 -0
- package/skills/gemini-function-calling/SKILL.md +90 -0
- package/skills/gemini-grounding/SKILL.md +37 -0
- package/skills/github-ops/SKILL.md +102 -0
- package/skills/kubernetes-operator/SKILL.md +82 -0
- package/skills/rag-architect/SKILL.md +60 -0
- package/skills/stripe-integration/SKILL.md +65 -0
- package/skills/supabase-architect/SKILL.md +53 -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
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
#!/usr/bin/env bash
|
|
2
|
-
#
|
|
2
|
+
# Everything Gemini Ephemeral Context Injector: PreInvocation Hook
|
|
3
3
|
# Sends a transient reminder to the agent prior to model invocation.
|
|
4
4
|
|
|
5
5
|
set -eo pipefail
|
|
6
6
|
|
|
7
|
-
echo '{"injectSteps": [{"ephemeralMessage": "[
|
|
7
|
+
echo '{"injectSteps": [{"ephemeralMessage": "[Everything Gemini Harness Active]: Verify code with tests, follow progressive disclosure, and ensure all file links use markdown file:// scheme."}]}'
|
|
8
8
|
exit 0
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
#!/usr/bin/env bash
|
|
2
|
-
#
|
|
2
|
+
# Everything Gemini Goal Verifier: Stop Hook
|
|
3
3
|
# Checks if the workspace has uncommitted broken tests before allowing termination.
|
|
4
4
|
|
|
5
5
|
set -eo pipefail
|
|
@@ -14,7 +14,7 @@ if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
|
|
|
14
14
|
# If package.json has a test script, verify tests pass
|
|
15
15
|
if [ -f "package.json" ] && grep -q '"test"' package.json; then
|
|
16
16
|
if ! npm test >/dev/null 2>&1; then
|
|
17
|
-
echo "{\"decision\": \"continue\", \"reason\": \"[
|
|
17
|
+
echo "{\"decision\": \"continue\", \"reason\": \"[Everything Gemini Goal Verifier] Uncommitted changes failed 'npm test'. Please resolve failing tests before stopping.\"}"
|
|
18
18
|
exit 0
|
|
19
19
|
fi
|
|
20
20
|
fi
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
#!/usr/bin/env bash
|
|
2
|
-
#
|
|
2
|
+
# Everything Gemini Safety Shield: PreToolUse Security Gate
|
|
3
3
|
# Reads protojson hook payload from stdin, evaluates safety, outputs JSON on stdout.
|
|
4
4
|
|
|
5
5
|
set -eo pipefail
|
|
@@ -46,7 +46,7 @@ ASK_PATTERNS=(
|
|
|
46
46
|
# Check blocked patterns
|
|
47
47
|
for pattern in "${BLOCKED_PATTERNS[@]}"; do
|
|
48
48
|
if [[ "$CMD" == *"$pattern"* ]]; then
|
|
49
|
-
echo "{\"decision\": \"deny\", \"reason\": \"[
|
|
49
|
+
echo "{\"decision\": \"deny\", \"reason\": \"[Everything Gemini Safety Shield] Catastrophic command pattern detected and blocked: '$pattern'\"}"
|
|
50
50
|
exit 0
|
|
51
51
|
fi
|
|
52
52
|
done
|
|
@@ -54,7 +54,7 @@ done
|
|
|
54
54
|
# Check ask patterns
|
|
55
55
|
for pattern in "${ASK_PATTERNS[@]}"; do
|
|
56
56
|
if [[ "$CMD" == *"$pattern"* ]]; then
|
|
57
|
-
echo "{\"decision\": \"ask\", \"reason\": \"[
|
|
57
|
+
echo "{\"decision\": \"ask\", \"reason\": \"[Everything Gemini Safety Shield] Potentially destructive command requires user confirmation: '$pattern'\"}"
|
|
58
58
|
exit 0
|
|
59
59
|
fi
|
|
60
60
|
done
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "everything-gemini",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.1.1",
|
|
4
4
|
"description": "Everything Gemini (everything-gemini) - The Ultimate Agent Harness, Multi-Agent Orchestrator & Performance Suite for Gemini & Google Antigravity",
|
|
5
5
|
"main": "bin/everything-gemini",
|
|
6
6
|
"bin": {
|
|
@@ -35,6 +35,7 @@
|
|
|
35
35
|
"type": "git",
|
|
36
36
|
"url": "git+https://github.com/salmandev/everything-gemini.git"
|
|
37
37
|
},
|
|
38
|
+
"homepage": "https://salmandev.github.io/everything-gemini/",
|
|
38
39
|
"engines": {
|
|
39
40
|
"node": ">=18.0.0"
|
|
40
41
|
}
|
package/plugins/core/plugin.json
CHANGED
package/rules/common/AGENTS.md
CHANGED
package/rules/common/GEMINI.md
CHANGED
|
@@ -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,72 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: cloudflare-workers
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when developing Cloudflare Workers, configuring Wrangler v3, integrating Cloudflare D1 SQL or KV storage, or deploying global edge APIs.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Cloudflare Workers & Edge Infrastructure
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
Cloudflare Workers execute on V8 isolates across 300+ edge locations worldwide. This skill provides architectural patterns for ultra-low latency serverless APIs, D1 relational databases, KV storage, and Wrangler configuration.
|
|
11
|
+
|
|
12
|
+
## Procedural Workflow
|
|
13
|
+
|
|
14
|
+
### 1. Project Scaffolding & Wrangler Config
|
|
15
|
+
Structure `wrangler.jsonc` or `wrangler.toml` with strict environment bindings:
|
|
16
|
+
```jsonc
|
|
17
|
+
{
|
|
18
|
+
"$schema": "node_modules/wrangler/config-schema.json",
|
|
19
|
+
"name": "edge-api",
|
|
20
|
+
"main": "src/index.ts",
|
|
21
|
+
"compatibility_date": "2024-09-23",
|
|
22
|
+
"compatibility_flags": ["nodejs_compat"],
|
|
23
|
+
"d1_databases": [
|
|
24
|
+
{
|
|
25
|
+
"binding": "DB",
|
|
26
|
+
"database_name": "prod-db",
|
|
27
|
+
"database_id": "xxxx-xxxx"
|
|
28
|
+
}
|
|
29
|
+
],
|
|
30
|
+
"kv_namespaces": [
|
|
31
|
+
{
|
|
32
|
+
"binding": "CACHE",
|
|
33
|
+
"id": "yyyy-yyyy"
|
|
34
|
+
}
|
|
35
|
+
]
|
|
36
|
+
}
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
### 2. Edge Request Handling
|
|
40
|
+
Use typed `Env` interfaces and native `fetch` handlers:
|
|
41
|
+
```typescript
|
|
42
|
+
export interface Env {
|
|
43
|
+
DB: D1Database;
|
|
44
|
+
CACHE: KVNamespace;
|
|
45
|
+
API_SECRET: string;
|
|
46
|
+
}
|
|
47
|
+
|
|
48
|
+
export default {
|
|
49
|
+
async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
|
|
50
|
+
const url = new URL(request.url);
|
|
51
|
+
if (request.method === "OPTIONS") {
|
|
52
|
+
return handleCors(request);
|
|
53
|
+
}
|
|
54
|
+
// Execution context for background tasks that shouldn't block response
|
|
55
|
+
ctx.waitUntil(logAnalytics(request, env));
|
|
56
|
+
return new Response(JSON.stringify({ status: "ok" }), {
|
|
57
|
+
headers: { "Content-Type": "application/json" }
|
|
58
|
+
});
|
|
59
|
+
}
|
|
60
|
+
};
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
### 3. Edge Storage Patterns
|
|
64
|
+
- **Cloudflare KV**: High-read, low-write caching (eventually consistent). Ideal for session tokens, feature flags, and redirect maps.
|
|
65
|
+
- **Cloudflare D1**: Serverless SQLite at the edge. Always use parameterized queries (`env.DB.prepare("SELECT * FROM users WHERE id = ?").bind(id).first()`).
|
|
66
|
+
- **Cloudflare R2**: Zero-egress S3-compatible object storage.
|
|
67
|
+
|
|
68
|
+
## Verification Checklist
|
|
69
|
+
- [ ] `compatibility_date` pinned to a modern version
|
|
70
|
+
- [ ] Secrets managed via `wrangler secret put`, never hardcoded
|
|
71
|
+
- [ ] Background telemetry wrapped in `ctx.waitUntil`
|
|
72
|
+
- [ ] D1 queries use parameterized bindings to prevent SQL injection
|
|
@@ -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,37 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gemini-grounding
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when verifying dynamic facts, researching live documentation, fact-checking technical claims, or integrating Google Search grounding into Gemini agent reasoning workflows.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Gemini Search Grounding & Dynamic Fact Verification
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
Gemini frontier models feature native **Google Search Grounding**, enabling agents to supplement static training weights with real-time web citations, current API documentation, and package release notes. This skill outlines best practices for search grounding, citation verification, and hallucination elimination.
|
|
11
|
+
|
|
12
|
+
## Procedural Workflow
|
|
13
|
+
|
|
14
|
+
### 1. Identify Grounding Triggers
|
|
15
|
+
Activate search grounding when:
|
|
16
|
+
- Querying rapidly evolving SDKs, library APIs, or breaking versions released after model cutoffs.
|
|
17
|
+
- Verifying deployment status, cloud service outages, or public CVE advisories.
|
|
18
|
+
- Researching latest framework releases (e.g., Next.js canary features, Tailwind v4, React 19).
|
|
19
|
+
|
|
20
|
+
### 2. Search Query Formulation
|
|
21
|
+
Formulate targeted search queries:
|
|
22
|
+
- **Exact Syntax Match**: Use quotes for exact error strings or function signatures.
|
|
23
|
+
- **Official Domain Prioritization**: Target authoritative documentation:
|
|
24
|
+
- `site:github.com` for issue threads and release tags.
|
|
25
|
+
- `site:npmjs.com` or `site:pypi.org` for version numbers and dependencies.
|
|
26
|
+
- Official vendor docs (`docs.antigravity.google`, `developer.mozilla.org`).
|
|
27
|
+
|
|
28
|
+
### 3. Verification & Citation Attribution
|
|
29
|
+
When incorporating search findings into code:
|
|
30
|
+
1. **Cross-Check with Active Code**: Never assume an external snippet works as-is; inspect local types and configurations first.
|
|
31
|
+
2. **Clickable Links**: Link external references using markdown links in documentation and artifacts.
|
|
32
|
+
3. **Zero-Trust Validation**: Verify any third-party code against local linters (`npm test` or typecheckers).
|
|
33
|
+
|
|
34
|
+
## Verification Checklist
|
|
35
|
+
- [ ] Claims backed by verifiable, recent documentation
|
|
36
|
+
- [ ] No hallucinated imports or deprecated APIs
|
|
37
|
+
- [ ] External references properly attributed
|
|
@@ -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,82 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: kubernetes-operator
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when authoring Kubernetes manifests, configuring Helm charts, setting up Horizontal Pod Autoscalers (HPA), or troubleshooting container cluster deployments.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Kubernetes Cluster & Workload Operations
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
This skill guides the agent in writing declarative, production-ready Kubernetes manifests, configuring health probes, resource constraints, ingress controllers, and rolling update strategies.
|
|
11
|
+
|
|
12
|
+
## Procedural Workflow
|
|
13
|
+
|
|
14
|
+
### 1. Hardened Deployment Manifest Pattern
|
|
15
|
+
Always configure resource limits, security contexts, and liveness/readiness probes:
|
|
16
|
+
```yaml
|
|
17
|
+
apiVersion: apps/v1
|
|
18
|
+
kind: Deployment
|
|
19
|
+
metadata:
|
|
20
|
+
name: api-service
|
|
21
|
+
labels:
|
|
22
|
+
app.kubernetes.io/name: api-service
|
|
23
|
+
spec:
|
|
24
|
+
replicas: 3
|
|
25
|
+
strategy:
|
|
26
|
+
type: RollingUpdate
|
|
27
|
+
rollingUpdate:
|
|
28
|
+
maxSurge: 1
|
|
29
|
+
maxUnavailable: 0
|
|
30
|
+
selector:
|
|
31
|
+
matchLabels:
|
|
32
|
+
app: api-service
|
|
33
|
+
template:
|
|
34
|
+
metadata:
|
|
35
|
+
labels:
|
|
36
|
+
app: api-service
|
|
37
|
+
spec:
|
|
38
|
+
securityContext:
|
|
39
|
+
runAsNonRoot: true
|
|
40
|
+
runAsUser: 10001
|
|
41
|
+
containers:
|
|
42
|
+
- name: app
|
|
43
|
+
image: myregistry.azurecr.io/api-service:v1.0.0
|
|
44
|
+
securityContext:
|
|
45
|
+
readOnlyRootFilesystem: true
|
|
46
|
+
allowPrivilegeEscalation: false
|
|
47
|
+
resources:
|
|
48
|
+
requests:
|
|
49
|
+
cpu: "100m"
|
|
50
|
+
memory: "128Mi"
|
|
51
|
+
limits:
|
|
52
|
+
cpu: "500m"
|
|
53
|
+
memory: "512Mi"
|
|
54
|
+
ports:
|
|
55
|
+
- containerPort: 8080
|
|
56
|
+
readinessProbe:
|
|
57
|
+
httpGet:
|
|
58
|
+
path: /health/ready
|
|
59
|
+
port: 8080
|
|
60
|
+
initialDelaySeconds: 5
|
|
61
|
+
periodSeconds: 10
|
|
62
|
+
livenessProbe:
|
|
63
|
+
httpGet:
|
|
64
|
+
path: /health/live
|
|
65
|
+
port: 8080
|
|
66
|
+
initialDelaySeconds: 15
|
|
67
|
+
periodSeconds: 20
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### 2. Auto-scaling & Ingress
|
|
71
|
+
- **HorizontalPodAutoscaler (HPA)**: Target CPU (e.g. 70%) and Memory utilization before traffic spikes.
|
|
72
|
+
- **Ingress with TLS**: Annotate with cert-manager (`cert-manager.io/cluster-issuer: letsencrypt-prod`) for automated SSL lifecycle.
|
|
73
|
+
|
|
74
|
+
### 3. Triage & Debugging Commands
|
|
75
|
+
- Inspect crash loops: `kubectl logs -l app=api-service --tail=100 -p` (previous container logs).
|
|
76
|
+
- Inspect pod events: `kubectl describe pod <pod-name>`.
|
|
77
|
+
|
|
78
|
+
## Verification Checklist
|
|
79
|
+
- [ ] Non-root security context configured (`runAsNonRoot: true`)
|
|
80
|
+
- [ ] Both readiness and liveness probes defined
|
|
81
|
+
- [ ] Memory limits defined to prevent cluster OOM killer cascades
|
|
82
|
+
- [ ] Rolling update configured with zero downtime (`maxUnavailable: 0`)
|
|
@@ -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
|