everything-gemini 0.0.0-stage → 1.0.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/.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/.github/workflows/release.yml +42 -0
- package/AGENTS.md +15 -0
- package/CHANGELOG.md +45 -0
- package/CONTRIBUTING.md +114 -0
- package/GEMINI.md +15 -0
- package/LICENSE +176 -0
- package/README.md +316 -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/cloudflare-workers/SKILL.md +72 -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-grounding/SKILL.md +37 -0
- package/skills/gemini-multimodal/SKILL.md +43 -0
- package/skills/git-craftsman/SKILL.md +43 -0
- package/skills/kubernetes-operator/SKILL.md +82 -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/stripe-integration/SKILL.md +65 -0
- package/skills/subagent-handoff/SKILL.md +28 -0
- package/skills/subagent-handoff/references/handoff-patterns.md +30 -0
- package/skills/supabase-architect/SKILL.md +53 -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,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,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.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# Fast git bisect helper script
|
|
3
|
+
|
|
4
|
+
TEST_CMD="${1:-npm test}"
|
|
5
|
+
|
|
6
|
+
echo "Running bisect test: $TEST_CMD"
|
|
7
|
+
if eval "$TEST_CMD" >/dev/null 2>&1; then
|
|
8
|
+
echo "Commit is GOOD (tests passed)"
|
|
9
|
+
exit 0
|
|
10
|
+
else
|
|
11
|
+
echo "Commit is BAD (tests failed)"
|
|
12
|
+
exit 1
|
|
13
|
+
fi
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: security-audit
|
|
3
|
+
description: >-
|
|
4
|
+
Performs security audits, OWASP top 10 vulnerability checks, dependency vulnerability scans, and secret leakage detection. Use when reviewing code for security vulnerabilities.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Security Audit
|
|
8
|
+
|
|
9
|
+
This skill guides the agent through proactive security evaluations, secret detection, and dependency hygiene.
|
|
10
|
+
|
|
11
|
+
## Audit Checklist
|
|
12
|
+
|
|
13
|
+
### 1. Secret Scanning
|
|
14
|
+
Ensure no sensitive keys, tokens, private keys, or credentials are hardcoded:
|
|
15
|
+
- Check for `.env`, `*.pem`, `id_rsa`, AWS keys (`AKIA...`), GitHub tokens (`ghp_...`).
|
|
16
|
+
- Execute `scripts/scan-secrets.sh` to search for known credential regex patterns.
|
|
17
|
+
|
|
18
|
+
### 2. Dependency Vulnerability Assessment
|
|
19
|
+
Run ecosystem-specific vulnerability scanners:
|
|
20
|
+
- **Node**: `npm audit` or `pnpm audit`
|
|
21
|
+
- **Python**: `pip-audit`
|
|
22
|
+
- **Go**: `govulncheck ./...`
|
|
23
|
+
- **Rust**: `cargo audit`
|
|
24
|
+
|
|
25
|
+
### 3. Code-Level Vulnerability Inspection
|
|
26
|
+
- **Injection Flaws**: Check all database queries for parameterized values. Ensure no raw string interpolation in SQL or NoSQL queries.
|
|
27
|
+
- **Cross-Site Scripting (XSS)**: Ensure user input rendered in HTML is sanitized or escaped. In React, inspect any usage of `dangerouslySetInnerHTML`.
|
|
28
|
+
- **Insecure Deserialization**: Avoid `eval()`, `pickle.loads()`, or unrestricted YAML parsing (`yaml.unsafe_load`).
|
|
29
|
+
- **Path Traversal**: Ensure file system operations resolve paths against a safe root directory.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# Fast secret scanner for committed files
|
|
3
|
+
|
|
4
|
+
echo "Scanning tracked files for potential exposed secrets..."
|
|
5
|
+
|
|
6
|
+
PATTERNS=(
|
|
7
|
+
"AKIA[0-9A-Z]{16}"
|
|
8
|
+
"ghp_[a-zA-Z0-9]{36}"
|
|
9
|
+
"github_pat_[a-zA-Z0-9_]{82}"
|
|
10
|
+
"-----BEGIN (RSA|EC|OPENSSH) PRIVATE KEY-----"
|
|
11
|
+
"AIza[0-9A-Za-z\\-_]{35}"
|
|
12
|
+
)
|
|
13
|
+
|
|
14
|
+
FOUND=0
|
|
15
|
+
for pattern in "${PATTERNS[@]}"; do
|
|
16
|
+
MATCHES=$(git grep -EI "$pattern" 2>/dev/null || true)
|
|
17
|
+
if [ -n "$MATCHES" ]; then
|
|
18
|
+
echo "⚠️ Potential secret match for pattern: $pattern"
|
|
19
|
+
echo "$MATCHES"
|
|
20
|
+
FOUND=$((FOUND + 1))
|
|
21
|
+
fi
|
|
22
|
+
done
|
|
23
|
+
|
|
24
|
+
if [ "$FOUND" -eq 0 ]; then
|
|
25
|
+
echo "✔ No high-entropy secrets detected."
|
|
26
|
+
fi
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: stripe-integration
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when implementing Stripe checkout sessions, managing subscription billing lifecycles, verifying webhook signatures, or configuring customer billing portals.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Stripe Payments & Subscription Architecture
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
This skill guides the implementation of PCI-compliant payment flows, webhook signature verification, idempotent charge processing, and customer portal session generation using the official Stripe SDK.
|
|
11
|
+
|
|
12
|
+
## Procedural Workflow
|
|
13
|
+
|
|
14
|
+
### 1. Robust Webhook Signature Verification
|
|
15
|
+
Never process webhooks without verifying the cryptographic signature against your endpoint secret:
|
|
16
|
+
```typescript
|
|
17
|
+
import Stripe from "stripe";
|
|
18
|
+
|
|
19
|
+
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
|
|
20
|
+
apiVersion: "2024-06-20",
|
|
21
|
+
});
|
|
22
|
+
|
|
23
|
+
export async function handleStripeWebhook(rawBody: string | Buffer, signature: string) {
|
|
24
|
+
let event: Stripe.Event;
|
|
25
|
+
try {
|
|
26
|
+
event = stripe.webhooks.constructEvent(
|
|
27
|
+
rawBody,
|
|
28
|
+
signature,
|
|
29
|
+
process.env.STRIPE_WEBHOOK_SECRET!
|
|
30
|
+
);
|
|
31
|
+
} catch (err: any) {
|
|
32
|
+
throw new Error(`Webhook signature verification failed: ${err.message}`);
|
|
33
|
+
}
|
|
34
|
+
|
|
35
|
+
// Handle idempotent events using database transaction
|
|
36
|
+
switch (event.type) {
|
|
37
|
+
case "checkout.session.completed":
|
|
38
|
+
await handleCheckoutCompleted(event.data.object as Stripe.Checkout.Session);
|
|
39
|
+
break;
|
|
40
|
+
case "customer.subscription.updated":
|
|
41
|
+
case "customer.subscription.deleted":
|
|
42
|
+
await syncSubscriptionStatus(event.data.object as Stripe.Subscription);
|
|
43
|
+
break;
|
|
44
|
+
}
|
|
45
|
+
}
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
### 2. Idempotency & Concurrency Safety
|
|
49
|
+
- Always store `event.id` in an `idempotency_keys` table or set a unique constraint. If Stripe retries a webhook, discard duplicates immediately.
|
|
50
|
+
- Use `client_reference_id` or `metadata` to link Stripe customers with your internal user IDs.
|
|
51
|
+
|
|
52
|
+
### 3. Customer Billing Portal
|
|
53
|
+
Generate pre-authenticated portal sessions so users can update payment methods and invoices self-service without custom frontend form logic:
|
|
54
|
+
```typescript
|
|
55
|
+
const portalSession = await stripe.billingPortal.sessions.create({
|
|
56
|
+
customer: stripeCustomerId,
|
|
57
|
+
return_url: `${process.env.NEXT_PUBLIC_APP_URL}/dashboard/billing`,
|
|
58
|
+
});
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
## Verification Checklist
|
|
62
|
+
- [ ] Raw body buffer preserved for webhook cryptographic verification
|
|
63
|
+
- [ ] Idempotency key checked before applying database mutations
|
|
64
|
+
- [ ] Webhook handler returns HTTP 200 promptly before long-running async tasks
|
|
65
|
+
- [ ] Stripe secret keys read strictly from environment variables
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: subagent-handoff
|
|
3
|
+
description: >-
|
|
4
|
+
Guides the primary agent in delegating complex, multi-step subtasks to scoped subagents (Planner, Reviewer, Build-Repair, QA, Security) with minimal token contamination and deterministic handoffs.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Subagent Handoff Protocol
|
|
8
|
+
|
|
9
|
+
This skill governs how the primary agent orchestrates and delegates work to scoped subagents.
|
|
10
|
+
|
|
11
|
+
## Core Directives
|
|
12
|
+
|
|
13
|
+
1. **When to Delegate vs. Execute Directly**:
|
|
14
|
+
- **Delegate**: Visual browser testing (`browser_subagent`), deep dependency planning (`agents/planner.md`), adversarial code review (`agents/code-reviewer.md`), and build-break triage (`agents/build-repair.md`).
|
|
15
|
+
- **Execute Directly**: Simple file edits, direct user questions, single test runs, and minor refactorings.
|
|
16
|
+
|
|
17
|
+
2. **The Clean Handoff Principle**:
|
|
18
|
+
- Never dump the entire conversation history into the subagent prompt.
|
|
19
|
+
- Provide a self-contained, bounded task prompt containing:
|
|
20
|
+
1. Specific objective.
|
|
21
|
+
2. Exact file paths to inspect.
|
|
22
|
+
3. Clear constraints and tools allowed.
|
|
23
|
+
4. Explicit stop condition and expected return report schema.
|
|
24
|
+
|
|
25
|
+
3. **Synthesis & Integration**:
|
|
26
|
+
- When the subagent completes its task and returns its report, the primary agent evaluates the report, links findings to source files, and seamlessly continues the top-level plan.
|
|
27
|
+
|
|
28
|
+
For delegation prompt templates and examples, see [references/handoff-patterns.md](./references/handoff-patterns.md).
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Subagent Handoff Patterns & Prompt Templates
|
|
2
|
+
|
|
3
|
+
## Pattern 1: Code Review Delegation Template
|
|
4
|
+
```text
|
|
5
|
+
Task Name: Security & Quality Code Review
|
|
6
|
+
Task:
|
|
7
|
+
You are acting as the 'code-reviewer' subagent.
|
|
8
|
+
Inspect the recent changes in git branch 'feature/payment-v2' (or git diff HEAD~1).
|
|
9
|
+
Focus on:
|
|
10
|
+
1. Null/undefined safety and edge cases in checkout logic.
|
|
11
|
+
2. Parameterized queries in src/services/payment.ts.
|
|
12
|
+
3. Verification that tests pass via 'npm test'.
|
|
13
|
+
Stop condition: All diff files reviewed and tests executed.
|
|
14
|
+
Return a markdown report with Verdict, Critical Blockers, and Suggestions.
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## Pattern 2: Build-Repair Delegation Template
|
|
18
|
+
```text
|
|
19
|
+
Task Name: TypeScript Compiler & Test Fix
|
|
20
|
+
Task:
|
|
21
|
+
You are acting as the 'build-repair' subagent.
|
|
22
|
+
Command 'npm run build' is failing with:
|
|
23
|
+
"TS2322: Type 'string' is not assignable to type 'number' in src/api/user.ts:54"
|
|
24
|
+
1. Read src/api/user.ts around line 54.
|
|
25
|
+
2. Trace the type definition in src/types/user.ts.
|
|
26
|
+
3. Apply a surgical fix using replace_file_content.
|
|
27
|
+
4. Verify by running 'npm run build'.
|
|
28
|
+
Stop condition: 'npm run build' exits with code 0.
|
|
29
|
+
Return a report summarizing the root cause and applied fix.
|
|
30
|
+
```
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: supabase-architect
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when designing Supabase database schemas, writing Row Level Security (RLS) policies, setting up pgvector AI embeddings, or configuring Supabase Edge Functions.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Supabase Architecture & Security Playbook
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
Supabase provides a powerful managed backend powered by PostgreSQL. This skill guides the agent in crafting bulletproof Row Level Security (RLS) policies, configuring pgvector for semantic search and AI embeddings, and deploying performant Supabase Edge Functions.
|
|
11
|
+
|
|
12
|
+
## Procedural Workflow
|
|
13
|
+
|
|
14
|
+
### 1. Row Level Security (RLS) Defense-in-Depth
|
|
15
|
+
Never leave a table with RLS disabled in production:
|
|
16
|
+
```sql
|
|
17
|
+
-- 1. Always enable RLS on newly created tables
|
|
18
|
+
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
|
|
19
|
+
|
|
20
|
+
-- 2. Enforce strict tenant isolation or user ownership
|
|
21
|
+
CREATE POLICY "Users can only read their own documents"
|
|
22
|
+
ON documents
|
|
23
|
+
FOR SELECT
|
|
24
|
+
USING (auth.uid() = user_id);
|
|
25
|
+
|
|
26
|
+
CREATE POLICY "Users can only insert their own documents"
|
|
27
|
+
ON documents
|
|
28
|
+
FOR INSERT
|
|
29
|
+
WITH CHECK (auth.uid() = user_id);
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
### 2. Semantic Search & Vector Embeddings (`pgvector`)
|
|
33
|
+
When storing AI embeddings in PostgreSQL:
|
|
34
|
+
1. Enable extension: `CREATE EXTENSION IF NOT EXISTS vector;`
|
|
35
|
+
2. Create vector column matching model dimensions (e.g., 768 or 1536):
|
|
36
|
+
```sql
|
|
37
|
+
ALTER TABLE documents ADD COLUMN embedding vector(768);
|
|
38
|
+
```
|
|
39
|
+
3. Create an HNSW index for fast similarity lookups:
|
|
40
|
+
```sql
|
|
41
|
+
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
|
|
42
|
+
```
|
|
43
|
+
4. Define match RPC functions with inner product or cosine distance queries.
|
|
44
|
+
|
|
45
|
+
### 3. Realtime Channels & Subscriptions
|
|
46
|
+
- Filter broadcasts server-side using Postgres row-level filters (`eq`, `in`) to prevent client-side data leaks.
|
|
47
|
+
- Ensure sensitive columns are omitted or masked in realtime publication sets.
|
|
48
|
+
|
|
49
|
+
## Verification Checklist
|
|
50
|
+
- [ ] RLS explicitly enabled on every table
|
|
51
|
+
- [ ] RLS policies tested against unauthenticated and cross-tenant tokens
|
|
52
|
+
- [ ] Vector index created with appropriate similarity operator (`vector_cosine_ops`)
|
|
53
|
+
- [ ] Edge functions handle CORS headers and verify JWT signatures
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: tdd-workflow
|
|
3
|
+
description: >-
|
|
4
|
+
Enforces strict Test-Driven Development (Red-Green-Refactor). Use this skill when the user asks to implement a new feature, fix a bug, or refactor logic using TDD.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Test-Driven Development (TDD) Workflow
|
|
8
|
+
|
|
9
|
+
This skill guides the agent through an uncompromising Red-Green-Refactor cycle.
|
|
10
|
+
|
|
11
|
+
## Procedure
|
|
12
|
+
|
|
13
|
+
### Step 1: Discover Existing Test Runner
|
|
14
|
+
Detect the test framework in use:
|
|
15
|
+
- **Node/TS**: Check `package.json` for `jest`, `vitest`, `mocha`, or `npm test`.
|
|
16
|
+
- **Python**: Check for `pytest` or `unittest`.
|
|
17
|
+
- **Go**: Look for `*_test.go` and run `go test ./...`.
|
|
18
|
+
|
|
19
|
+
Run the existing suite to ensure the baseline is green before touching anything:
|
|
20
|
+
```bash
|
|
21
|
+
# Example
|
|
22
|
+
npm test
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
### Step 2: Phase RED (Write Failing Test)
|
|
26
|
+
1. Write a minimal test file or test case specifying the expected outcome or reproducing the exact bug reported.
|
|
27
|
+
2. Run the specific test and verify that it **fails**.
|
|
28
|
+
3. Confirm failure reason: It must fail on the assertion, NOT because of an import error or syntax error.
|
|
29
|
+
|
|
30
|
+
### Step 3: Phase GREEN (Write Minimal Implementation)
|
|
31
|
+
1. Write the absolute minimum production code to satisfy the test assertion.
|
|
32
|
+
2. Do not prematurely optimize or handle un-tested edge cases yet.
|
|
33
|
+
3. Re-run the test to confirm it now passes (turns green).
|
|
34
|
+
|
|
35
|
+
### Step 4: Phase REFACTOR (Clean Code with Confidence)
|
|
36
|
+
1. Eliminate duplication, extract functions, refine variable names, and improve readability.
|
|
37
|
+
2. Re-run tests immediately after each edit.
|
|
38
|
+
3. Repeat for next edge case.
|
|
39
|
+
|
|
40
|
+
For detailed test patterns and mocking strategies, see [references/tdd-patterns.md](./references/tdd-patterns.md).
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# TDD Patterns & Mocking Reference
|
|
2
|
+
|
|
3
|
+
## 1. Arrange-Act-Assert (AAA)
|
|
4
|
+
Always structure tests cleanly into three discrete blocks:
|
|
5
|
+
```typescript
|
|
6
|
+
it('should calculate discount correctly', () => {
|
|
7
|
+
// Arrange
|
|
8
|
+
const cart = new Cart();
|
|
9
|
+
cart.addItem({ price: 100 });
|
|
10
|
+
|
|
11
|
+
// Act
|
|
12
|
+
const total = cart.getDiscountedTotal(0.2);
|
|
13
|
+
|
|
14
|
+
// Assert
|
|
15
|
+
expect(total).toBe(80);
|
|
16
|
+
});
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## 2. Mocking Boundaries
|
|
20
|
+
- Only mock at system boundaries (e.g. 3rd-party HTTP APIs, payment gateways, hardware).
|
|
21
|
+
- Avoid mocking internal domain services or utilities; test them through public contracts.
|
|
22
|
+
- In Python, use `unittest.mock.patch` with context managers.
|
|
23
|
+
- In Node/TypeScript, use `vi.spyOn` or `jest.spyOn`.
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
# Minimal Antigravity Guidelines
|
|
2
|
+
|
|
3
|
+
1. **Verify**: Always check code with tests or linters after making changes.
|
|
4
|
+
2. **Minimal Diffs**: Keep modifications targeted and preserve existing styles and comments.
|
|
5
|
+
3. **Zero Secrets**: Never print, log, or commit secret keys or sensitive tokens.
|