gkt-node 3.3.0

package/assets/.agent/skills/incident-runbook-templates/SKILL.md

@@ -0,0 +1,395 @@
+---
+name: incident-runbook-templates
+description: Create structured incident response runbooks with step-by-step procedures, escalation paths, and recovery actions. Use when building runbooks, responding to incidents, or establishing incident response procedures.
+---
+
+# Incident Runbook Templates
+
+Production-ready templates for incident response runbooks covering detection, triage, mitigation, resolution, and communication.
+
+## Do not use this skill when
+
+- The task is unrelated to incident runbook templates
+- You need a different domain or tool outside this scope
+
+## Instructions
+
+- Clarify goals, constraints, and required inputs.
+- Apply relevant best practices and validate outcomes.
+- Provide actionable steps and verification.
+- If detailed examples are required, open `resources/implementation-playbook.md`.
+
+## Use this skill when
+
+- Creating incident response procedures
+- Building service-specific runbooks
+- Establishing escalation paths
+- Documenting recovery procedures
+- Responding to active incidents
+- Onboarding on-call engineers
+
+## Core Concepts
+
+### 1. Incident Severity Levels
+
+| Severity | Impact | Response Time | Example |
+|----------|--------|---------------|---------|
+| **SEV1** | Complete outage, data loss | 15 min | Production down |
+| **SEV2** | Major degradation | 30 min | Critical feature broken |
+| **SEV3** | Minor impact | 2 hours | Non-critical bug |
+| **SEV4** | Minimal impact | Next business day | Cosmetic issue |
+
+### 2. Runbook Structure
+
+```
+1. Overview & Impact
+2. Detection & Alerts
+3. Initial Triage
+4. Mitigation Steps
+5. Root Cause Investigation
+6. Resolution Procedures
+7. Verification & Rollback
+8. Communication Templates
+9. Escalation Matrix
+```
+
+## Runbook Templates
+
+### Template 1: Service Outage Runbook
+
+```markdown
+# [Service Name] Outage Runbook
+
+## Overview
+**Service**: Payment Processing Service
+**Owner**: Platform Team
+**Slack**: #payments-incidents
+**PagerDuty**: payments-oncall
+
+## Impact Assessment
+- [ ] Which customers are affected?
+- [ ] What percentage of traffic is impacted?
+- [ ] Are there financial implications?
+- [ ] What's the blast radius?
+
+## Detection
+### Alerts
+- `payment_error_rate > 5%` (PagerDuty)
+- `payment_latency_p99 > 2s` (Slack)
+- `payment_success_rate < 95%` (PagerDuty)
+
+### Dashboards
+- [Payment Service Dashboard](https://grafana/d/payments)
+- [Error Tracking](https://sentry.io/payments)
+- [Dependency Status](https://status.stripe.com)
+
+## Initial Triage (First 5 Minutes)
+
+### 1. Assess Scope
+```bash
+# Check service health
+kubectl get pods -n payments -l app=payment-service
+
+# Check recent deployments
+kubectl rollout history deployment/payment-service -n payments
+
+# Check error rates
+curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))"
+```
+
+### 2. Quick Health Checks
+- [ ] Can you reach the service? `curl -I https://api.company.com/payments/health`
+- [ ] Database connectivity? Check connection pool metrics
+- [ ] External dependencies? Check Stripe, bank API status
+- [ ] Recent changes? Check deploy history
+
+### 3. Initial Classification
+| Symptom | Likely Cause | Go To Section |
+|---------|--------------|---------------|
+| All requests failing | Service down | Section 4.1 |
+| High latency | Database/dependency | Section 4.2 |
+| Partial failures | Code bug | Section 4.3 |
+| Spike in errors | Traffic surge | Section 4.4 |
+
+## Mitigation Procedures
+
+### 4.1 Service Completely Down
+```bash
+# Step 1: Check pod status
+kubectl get pods -n payments
+
+# Step 2: If pods are crash-looping, check logs
+kubectl logs -n payments -l app=payment-service --tail=100
+
+# Step 3: Check recent deployments
+kubectl rollout history deployment/payment-service -n payments
+
+# Step 4: ROLLBACK if recent deploy is suspect
+kubectl rollout undo deployment/payment-service -n payments
+
+# Step 5: Scale up if resource constrained
+kubectl scale deployment/payment-service -n payments --replicas=10
+
+# Step 6: Verify recovery
+kubectl rollout status deployment/payment-service -n payments
+```
+
+### 4.2 High Latency
+```bash
+# Step 1: Check database connections
+kubectl exec -n payments deploy/payment-service -- \
+  curl localhost:8080/metrics | grep db_pool
+
+# Step 2: Check slow queries (if DB issue)
+psql -h $DB_HOST -U $DB_USER -c "
+  SELECT pid, now() - query_start AS duration, query
+  FROM pg_stat_activity
+  WHERE state = 'active' AND duration > interval '5 seconds'
+  ORDER BY duration DESC;"
+
+# Step 3: Kill long-running queries if needed
+psql -h $DB_HOST -U $DB_USER -c "SELECT pg_terminate_backend(pid);"
+
+# Step 4: Check external dependency latency
+curl -w "@curl-format.txt" -o /dev/null -s https://api.stripe.com/v1/health
+
+# Step 5: Enable circuit breaker if dependency is slow
+kubectl set env deployment/payment-service \
+  STRIPE_CIRCUIT_BREAKER_ENABLED=true -n payments
+```
+
+### 4.3 Partial Failures (Specific Errors)
+```bash
+# Step 1: Identify error pattern
+kubectl logs -n payments -l app=payment-service --tail=500 | \
+  grep -i error | sort | uniq -c | sort -rn | head -20
+
+# Step 2: Check error tracking
+# Go to Sentry: https://sentry.io/payments
+
+# Step 3: If specific endpoint, enable feature flag to disable
+curl -X POST https://api.company.com/internal/feature-flags \
+  -d '{"flag": "DISABLE_PROBLEMATIC_FEATURE", "enabled": true}'
+
+# Step 4: If data issue, check recent data changes
+psql -h $DB_HOST -c "
+  SELECT * FROM audit_log
+  WHERE table_name = 'payment_methods'
+  AND created_at > now() - interval '1 hour';"
+```
+
+### 4.4 Traffic Surge
+```bash
+# Step 1: Check current request rate
+kubectl top pods -n payments
+
+# Step 2: Scale horizontally
+kubectl scale deployment/payment-service -n payments --replicas=20
+
+# Step 3: Enable rate limiting
+kubectl set env deployment/payment-service \
+  RATE_LIMIT_ENABLED=true \
+  RATE_LIMIT_RPS=1000 -n payments
+
+# Step 4: If attack, block suspicious IPs
+kubectl apply -f - <<EOF
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: block-suspicious
+  namespace: payments
+spec:
+  podSelector:
+    matchLabels:
+      app: payment-service
+  ingress:
+  - from:
+    - ipBlock:
+        cidr: 0.0.0.0/0
+        except:
+        - 192.168.1.0/24  # Suspicious range
+EOF
+```
+
+## Verification Steps
+```bash
+# Verify service is healthy
+curl -s https://api.company.com/payments/health | jq
+
+# Verify error rate is back to normal
+curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))" | jq '.data.result[0].value[1]'
+
+# Verify latency is acceptable
+curl -s "http://prometheus:9090/api/v1/query?query=histogram_quantile(0.99,sum(rate(http_request_duration_seconds_bucket[5m]))by(le))" | jq
+
+# Smoke test critical flows
+./scripts/smoke-test-payments.sh
+```
+
+## Rollback Procedures
+```bash
+# Rollback Kubernetes deployment
+kubectl rollout undo deployment/payment-service -n payments
+
+# Rollback database migration (if applicable)
+./scripts/db-rollback.sh $MIGRATION_VERSION
+
+# Rollback feature flag
+curl -X POST https://api.company.com/internal/feature-flags \
+  -d '{"flag": "NEW_PAYMENT_FLOW", "enabled": false}'
+```
+
+## Escalation Matrix
+
+| Condition | Escalate To | Contact |
+|-----------|-------------|---------|
+| > 15 min unresolved SEV1 | Engineering Manager | @manager (Slack) |
+| Data breach suspected | Security Team | #security-incidents |
+| Financial impact > $10k | Finance + Legal | @finance-oncall |
+| Customer communication needed | Support Lead | @support-lead |
+
+## Communication Templates
+
+### Initial Notification (Internal)
+```
+🚨 INCIDENT: Payment Service Degradation
+
+Severity: SEV2
+Status: Investigating
+Impact: ~20% of payment requests failing
+Start Time: [TIME]
+Incident Commander: [NAME]
+
+Current Actions:
+- Investigating root cause
+- Scaling up service
+- Monitoring dashboards
+
+Updates in #payments-incidents
+```
+
+### Status Update
+```
+📊 UPDATE: Payment Service Incident
+
+Status: Mitigating
+Impact: Reduced to ~5% failure rate
+Duration: 25 minutes
+
+Actions Taken:
+- Rolled back deployment v2.3.4 → v2.3.3
+- Scaled service from 5 → 10 replicas
+
+Next Steps:
+- Continuing to monitor
+- Root cause analysis in progress
+
+ETA to Resolution: ~15 minutes
+```
+
+### Resolution Notification
+```
+✅ RESOLVED: Payment Service Incident
+
+Duration: 45 minutes
+Impact: ~5,000 affected transactions
+Root Cause: Memory leak in v2.3.4
+
+Resolution:
+- Rolled back to v2.3.3
+- Transactions auto-retried successfully
+
+Follow-up:
+- Postmortem scheduled for [DATE]
+- Bug fix in progress
+```
+```
+
+### Template 2: Database Incident Runbook
+
+```markdown
+# Database Incident Runbook
+
+## Quick Reference
+| Issue | Command |
+|-------|---------|
+| Check connections | `SELECT count(*) FROM pg_stat_activity;` |
+| Kill query | `SELECT pg_terminate_backend(pid);` |
+| Check replication lag | `SELECT extract(epoch from (now() - pg_last_xact_replay_timestamp()));` |
+| Check locks | `SELECT * FROM pg_locks WHERE NOT granted;` |
+
+## Connection Pool Exhaustion
+```sql
+-- Check current connections
+SELECT datname, usename, state, count(*)
+FROM pg_stat_activity
+GROUP BY datname, usename, state
+ORDER BY count(*) DESC;
+
+-- Identify long-running connections
+SELECT pid, usename, datname, state, query_start, query
+FROM pg_stat_activity
+WHERE state != 'idle'
+ORDER BY query_start;
+
+-- Terminate idle connections
+SELECT pg_terminate_backend(pid)
+FROM pg_stat_activity
+WHERE state = 'idle'
+AND query_start < now() - interval '10 minutes';
+```
+
+## Replication Lag
+```sql
+-- Check lag on replica
+SELECT
+  CASE
+    WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn() THEN 0
+    ELSE extract(epoch from now() - pg_last_xact_replay_timestamp())
+  END AS lag_seconds;
+
+-- If lag > 60s, consider:
+-- 1. Check network between primary/replica
+-- 2. Check replica disk I/O
+-- 3. Consider failover if unrecoverable
+```
+
+## Disk Space Critical
+```bash
+# Check disk usage
+df -h /var/lib/postgresql/data
+
+# Find large tables
+psql -c "SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
+FROM pg_catalog.pg_statio_user_tables
+ORDER BY pg_total_relation_size(relid) DESC
+LIMIT 10;"
+
+# VACUUM to reclaim space
+psql -c "VACUUM FULL large_table;"
+
+# If emergency, delete old data or expand disk
+```
+```
+
+## Best Practices
+
+### Do's
+- **Keep runbooks updated** - Review after every incident
+- **Test runbooks regularly** - Game days, chaos engineering
+- **Include rollback steps** - Always have an escape hatch
+- **Document assumptions** - What must be true for steps to work
+- **Link to dashboards** - Quick access during stress
+
+### Don'ts
+- **Don't assume knowledge** - Write for 3 AM brain
+- **Don't skip verification** - Confirm each step worked
+- **Don't forget communication** - Keep stakeholders informed
+- **Don't work alone** - Escalate early
+- **Don't skip postmortems** - Learn from every incident
+
+## Resources
+
+- [Google SRE Book - Incident Management](https://sre.google/sre-book/managing-incidents/)
+- [PagerDuty Incident Response](https://response.pagerduty.com/)
+- [Atlassian Incident Management](https://www.atlassian.com/incident-management)

package/assets/.agent/skills/infinite-gratitude/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: Infinite Gratitude
+description: Multi-agent research skill for parallel research execution (10 agents, battle-tested with real case studies).
+risk: safe
+source: https://github.com/sstklen/infinite-gratitude
+---
+
+# Infinite Gratitude
+
+> **Source**: [sstklen/infinite-gratitude](https://github.com/sstklen/infinite-gratitude)
+
+## Description
+
+A multi-agent research skill designed for parallel research execution. It orchestrates 10 agents to conduct deep research, battle-tested with real case studies.
+
+## When to Use
+
+Use this skill when you need to perform extensive, parallelized research on a topic, leveraging multiple agents to gather and synthesize information more efficiently than a single linear process.
+
+## How to Use
+
+This is an external skill. Please refer to the [official repository](https://github.com/sstklen/infinite-gratitude) for installation and usage instructions.
+
+```bash
+git clone https://github.com/sstklen/infinite-gratitude
+```

package/assets/.agent/skills/inngest/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: inngest
+description: "Inngest expert for serverless-first background jobs, event-driven workflows, and durable execution without managing queues or workers. Use when: inngest, serverless background job, event-driven workflow, step function, durable execution."
+source: vibeship-spawner-skills (Apache 2.0)
+---
+
+# Inngest Integration
+
+You are an Inngest expert who builds reliable background processing without
+managing infrastructure. You understand that serverless doesn't mean you can't
+have durable, long-running workflows - it means you don't manage the workers.
+
+You've built AI pipelines that take minutes, onboarding flows that span days,
+and event-driven systems that process millions of events. You know that the
+magic of Inngest is in its steps - each one a checkpoint that survives failures.
+
+Your core philosophy:
+1. Event
+
+## Capabilities
+
+- inngest-functions
+- event-driven-workflows
+- step-functions
+- serverless-background-jobs
+- durable-sleep
+- fan-out-patterns
+- concurrency-control
+- scheduled-functions
+
+## Patterns
+
+### Basic Function Setup
+
+Inngest function with typed events in Next.js
+
+### Multi-Step Workflow
+
+Complex workflow with parallel steps and error handling
+
+### Scheduled/Cron Functions
+
+Functions that run on a schedule
+
+## Anti-Patterns
+
+### ❌ Not Using Steps
+
+### ❌ Huge Event Payloads
+
+### ❌ Ignoring Concurrency
+
+## Related Skills
+
+Works well with: `nextjs-app-router`, `vercel-deployment`, `supabase-backend`, `email-systems`, `ai-agents-architect`, `stripe-integration`

package/assets/.agent/skills/instagram-automation/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: instagram-automation
+description: "Automate Instagram tasks via Rube MCP (Composio): create posts, carousels, manage media, get insights, and publishing limits. Always search tools first for current schemas."
+requires:
+  mcp: [rube]
+---
+
+# Instagram Automation via Rube MCP
+
+Automate Instagram operations through Composio's Instagram toolkit via Rube MCP.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active Instagram connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `instagram`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+- Instagram Business or Creator account required (personal accounts not supported)
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `instagram`
+3. If connection is not ACTIVE, follow the returned auth link to complete Instagram/Facebook OAuth
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Create a Single Image/Video Post
+
+**When to use**: User wants to publish a single photo or video to Instagram
+
+**Tool sequence**:
+1. `INSTAGRAM_GET_USER_INFO` - Get Instagram user ID [Prerequisite]
+2. `INSTAGRAM_CREATE_MEDIA_CONTAINER` - Create a media container with the image/video URL [Required]
+3. `INSTAGRAM_GET_POST_STATUS` - Check if the media container is ready [Optional]
+4. `INSTAGRAM_CREATE_POST` or `INSTAGRAM_POST_IG_USER_MEDIA_PUBLISH` - Publish the container [Required]
+
+**Key parameters**:
+- `image_url`: Public URL of the image to post
+- `video_url`: Public URL of the video to post
+- `caption`: Post caption text
+- `ig_user_id`: Instagram Business account user ID
+
+**Pitfalls**:
+- Media URLs must be publicly accessible; private/authenticated URLs will fail
+- Video containers may take time to process; poll GET_POST_STATUS before publishing
+- Caption supports hashtags and mentions but has a 2200 character limit
+- Publishing a container that is not yet finished processing returns an error
+
+### 2. Create a Carousel Post
+
+**When to use**: User wants to publish multiple images/videos in a single carousel post
+
+**Tool sequence**:
+1. `INSTAGRAM_CREATE_MEDIA_CONTAINER` - Create individual containers for each media item [Required, repeat per item]
+2. `INSTAGRAM_CREATE_CAROUSEL_CONTAINER` - Create the carousel container referencing all media containers [Required]
+3. `INSTAGRAM_GET_POST_STATUS` - Check carousel container readiness [Optional]
+4. `INSTAGRAM_POST_IG_USER_MEDIA_PUBLISH` - Publish the carousel [Required]
+
+**Key parameters**:
+- `children`: Array of media container IDs for the carousel
+- `caption`: Carousel post caption
+- `ig_user_id`: Instagram Business account user ID
+
+**Pitfalls**:
+- Carousels require 2-10 media items; fewer or more will fail
+- Each child container must be created individually before the carousel container
+- All child containers must be fully processed before creating the carousel
+- Mixed media (images + videos) is supported in carousels
+
+### 3. Get Media and Insights
+
+**When to use**: User wants to view their posts or analyze post performance
+
+**Tool sequence**:
+1. `INSTAGRAM_GET_IG_USER_MEDIA` or `INSTAGRAM_GET_USER_MEDIA` - List user's media [Required]
+2. `INSTAGRAM_GET_IG_MEDIA` - Get details for a specific post [Optional]
+3. `INSTAGRAM_GET_POST_INSIGHTS` or `INSTAGRAM_GET_IG_MEDIA_INSIGHTS` - Get metrics for a post [Optional]
+4. `INSTAGRAM_GET_USER_INSIGHTS` - Get account-level insights [Optional]
+
+**Key parameters**:
+- `ig_user_id`: Instagram Business account user ID
+- `media_id`: ID of the specific media post
+- `metric`: Metrics to retrieve (e.g., impressions, reach, engagement)
+- `period`: Time period for insights (e.g., day, week, lifetime)
+
+**Pitfalls**:
+- Insights are only available for Business/Creator accounts
+- Some metrics require minimum follower counts
+- Insight data may have a delay of up to 48 hours
+- The `period` parameter must match the metric type
+
+### 4. Check Publishing Limits
+
+**When to use**: User wants to verify they can publish before attempting a post
+
+**Tool sequence**:
+1. `INSTAGRAM_GET_IG_USER_CONTENT_PUBLISHING_LIMIT` - Check remaining publishing quota [Required]
+
+**Key parameters**:
+- `ig_user_id`: Instagram Business account user ID
+
+**Pitfalls**:
+- Instagram enforces a 25 posts per 24-hour rolling window limit
+- Publishing limit resets on a rolling basis, not at midnight
+- Check limits before bulk posting operations to avoid failures
+
+### 5. Get Media Comments and Children
+
+**When to use**: User wants to view comments on a post or children of a carousel
+
+**Tool sequence**:
+1. `INSTAGRAM_GET_IG_MEDIA_COMMENTS` - List comments on a media post [Required]
+2. `INSTAGRAM_GET_IG_MEDIA_CHILDREN` - List children of a carousel post [Optional]
+
+**Key parameters**:
+- `media_id`: ID of the media post
+- `ig_media_id`: Alternative media ID parameter
+
+**Pitfalls**:
+- Comments may be paginated; follow pagination cursors for complete results
+- Carousel children are returned as individual media objects
+- Comment moderation settings on the account affect what is returned
+
+## Common Patterns
+
+### ID Resolution
+
+**Instagram User ID**:
+```
+1. Call INSTAGRAM_GET_USER_INFO
+2. Extract ig_user_id from response
+3. Use in all subsequent API calls
+```
+
+**Media Container Status Check**:
+```
+1. Call INSTAGRAM_CREATE_MEDIA_CONTAINER
+2. Extract container_id from response
+3. Poll INSTAGRAM_GET_POST_STATUS with container_id
+4. Wait until status is 'FINISHED' before publishing
+```
+
+### Two-Phase Publishing
+
+- Phase 1: Create media container(s) with content URLs
+- Phase 2: Publish the container after it finishes processing
+- Always check container status between phases for video content
+- For carousels, all children must complete Phase 1 before creating the carousel container
+
+## Known Pitfalls
+
+**Media URLs**:
+- All image/video URLs must be publicly accessible HTTPS URLs
+- URLs behind authentication, CDN restrictions, or that require cookies will fail
+- Temporary URLs (pre-signed S3, etc.) may expire before processing completes
+
+**Rate Limits**:
+- 25 posts per 24-hour rolling window
+- API rate limits apply separately from publishing limits
+- Implement exponential backoff for 429 responses
+
+**Account Requirements**:
+- Only Business or Creator Instagram accounts are supported
+- Personal accounts cannot use the Instagram Graph API
+- The account must be connected to a Facebook Page
+
+**Response Parsing**:
+- Media IDs are numeric strings
+- Insights data may be nested under different response keys
+- Pagination uses cursor-based tokens
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| Get user info | INSTAGRAM_GET_USER_INFO | (none) |
+| Create media container | INSTAGRAM_CREATE_MEDIA_CONTAINER | image_url/video_url, caption |
+| Create carousel | INSTAGRAM_CREATE_CAROUSEL_CONTAINER | children, caption |
+| Publish post | INSTAGRAM_CREATE_POST | ig_user_id, creation_id |
+| Publish media | INSTAGRAM_POST_IG_USER_MEDIA_PUBLISH | ig_user_id, creation_id |
+| Check post status | INSTAGRAM_GET_POST_STATUS | ig_container_id |
+| List user media | INSTAGRAM_GET_IG_USER_MEDIA | ig_user_id |
+| Get media details | INSTAGRAM_GET_IG_MEDIA | ig_media_id |
+| Get post insights | INSTAGRAM_GET_POST_INSIGHTS | media_id, metric |
+| Get user insights | INSTAGRAM_GET_USER_INSIGHTS | ig_user_id, metric, period |
+| Get publishing limit | INSTAGRAM_GET_IG_USER_CONTENT_PUBLISHING_LIMIT | ig_user_id |
+| Get media comments | INSTAGRAM_GET_IG_MEDIA_COMMENTS | ig_media_id |
+| Get carousel children | INSTAGRAM_GET_IG_MEDIA_CHILDREN | ig_media_id |