@kodrunhq/opencode-autopilot 1.12.2 → 1.14.1

package/assets/skills/database-patterns/SKILL.md

@@ -0,0 +1,270 @@
+---
+# opencode-autopilot
+name: database-patterns
+description: Database design, query optimization, migration strategies, indexing, connection pooling, transactions, and data modeling patterns
+stacks: []
+requires: []
+---
+
+# Database Patterns
+
+Practical patterns for database design, query optimization, and operational management. Covers schema design, indexing, query optimization, migrations, connection pooling, transactions, data modeling, and backup/recovery. Apply these when designing schemas, reviewing queries, planning migrations, or troubleshooting performance.
+
+## 1. Schema Design Principles
+
+**DO:** Design schemas that balance normalization with practical query performance.
+
+- Normalize to 3NF by default -- eliminate data duplication and update anomalies
+- Denormalize deliberately when read performance justifies it (document the trade-off)
+- Use consistent naming conventions:
+  ```
+  -- Tables: plural snake_case
+  users, order_items, payment_methods
+
+  -- Columns: singular snake_case
+  user_id, created_at, is_active, total_amount
+
+  -- Foreign keys: referenced_table_singular_id
+  user_id, order_id, category_id
+
+  -- Indexes: idx_table_column(s)
+  idx_users_email, idx_orders_user_id_created_at
+  ```
+- Include standard metadata columns: `id`, `created_at`, `updated_at`
+- Use UUIDs for public-facing identifiers; auto-increment for internal references
+- Add `NOT NULL` constraints by default -- make nullable columns the exception with justification
+
+**DON'T:**
+
+- Over-normalize to 5NF+ (diminishing returns, excessive joins)
+- Use reserved words as column names (`order`, `user`, `group`, `select`)
+- Create tables without primary keys
+- Use floating-point types for monetary values (use `DECIMAL`/`NUMERIC`)
+- Store comma-separated values in a single column (normalize into a junction table)
+
+```
+-- DO: Junction table for many-to-many
+CREATE TABLE user_roles (
+  user_id INTEGER NOT NULL REFERENCES users(id),
+  role_id INTEGER NOT NULL REFERENCES roles(id),
+  PRIMARY KEY (user_id, role_id)
+);
+
+-- DON'T: CSV in a column
+ALTER TABLE users ADD COLUMN roles TEXT; -- "admin,editor,viewer"
+```
+
+## 2. Indexing Strategy
+
+**DO:** Create indexes based on actual query patterns, not guesswork.
+
+- **B-tree indexes** (default): equality and range queries (`WHERE`, `ORDER BY`, `JOIN`)
+- **Hash indexes**: exact equality lookups only (faster than B-tree for `=`, no range support)
+- **Composite indexes**: order columns by selectivity (most selective first) and match query patterns
+  ```sql
+  -- Query: WHERE status = 'active' AND created_at > '2024-01-01' ORDER BY created_at
+  -- Index: (status, created_at) -- status for equality, created_at for range + sort
+  CREATE INDEX idx_orders_status_created ON orders(status, created_at);
+  ```
+- **Covering indexes**: include all columns needed by the query to avoid table lookups
+  ```sql
+  -- Query only needs id, email, name -- index covers it entirely
+  CREATE INDEX idx_users_email_covering ON users(email) INCLUDE (id, name);
+  ```
+- Use `EXPLAIN ANALYZE` to verify index usage before and after adding indexes
+- Index foreign key columns (required for efficient joins and cascade deletes)
+
+**DON'T:**
+
+- Index every column (indexes slow writes and consume storage)
+- Create indexes on low-cardinality columns alone (`is_active` with 2 values -- combine with other columns)
+- Ignore index maintenance (rebuild/reindex fragmented indexes periodically)
+- Forget that composite index column order matters: `(a, b)` serves `WHERE a = ?` but NOT `WHERE b = ?`
+- Add indexes without checking if an existing index already covers the query
+
+## 3. Query Optimization
+
+**DO:** Write efficient queries and use EXPLAIN to verify execution plans.
+
+- **Read EXPLAIN output** to understand:
+  - Scan type: Sequential Scan (bad for large tables) vs Index Scan (good)
+  - Join strategy: Nested Loop (small datasets), Hash Join (equality), Merge Join (sorted)
+  - Estimated vs actual row counts (large discrepancies indicate stale statistics)
+
+- **Avoid N+1 queries** -- the most common ORM performance problem:
+  ```
+  // DON'T: N+1 -- 1 query for users + N queries for orders
+  users = await User.findAll()
+  for (user of users) {
+    user.orders = await Order.findAll({ where: { userId: user.id } })
+  }
+
+  // DO: Eager loading -- 1 or 2 queries total
+  users = await User.findAll({ include: [Order] })
+
+  // DO: Batch loading
+  users = await User.findAll()
+  userIds = users.map(u => u.id)
+  orders = await Order.findAll({ where: { userId: { in: userIds } } })
+  ```
+
+- Use `LIMIT` on all queries that don't need full result sets
+- Use `EXISTS` instead of `COUNT(*)` when checking for existence
+- Avoid `SELECT *` -- request only needed columns
+- Use batch operations for bulk inserts/updates (not individual queries in a loop)
+
+**DON'T:**
+
+- Use `OFFSET` for deep pagination (use cursor-based pagination instead)
+- Wrap queries in unnecessary subqueries
+- Use functions on indexed columns in WHERE clauses (`WHERE LOWER(email) = ?` -- use a functional index or store normalized)
+- Ignore slow query logs -- review them regularly
+
+## 4. Migration Strategies
+
+**DO:** Use versioned, incremental migrations with rollback plans.
+
+- Number migrations sequentially or by timestamp: `001_create_users.sql`, `20240115_add_email_index.sql`
+- Each migration must be idempotent or have a corresponding down migration
+- Test migrations against a copy of production data volume (not just empty schemas)
+- Plan zero-downtime migrations for production:
+  ```
+  -- Step 1: Add nullable column (no downtime)
+  ALTER TABLE users ADD COLUMN phone TEXT;
+
+  -- Step 2: Backfill data (background job)
+  UPDATE users SET phone = 'unknown' WHERE phone IS NULL;
+
+  -- Step 3: Add NOT NULL constraint (after backfill completes)
+  ALTER TABLE users ALTER COLUMN phone SET NOT NULL;
+  ```
+
+- For column renames or type changes, use the expand-contract pattern:
+  1. Add new column
+  2. Deploy code that writes to both old and new columns
+  3. Backfill new column from old
+  4. Deploy code that reads from new column
+  5. Drop old column
+
+**DON'T:**
+
+- Run destructive migrations without a rollback plan (`DROP TABLE`, `DROP COLUMN`)
+- Apply schema changes and code changes in the same deployment (deploy schema first)
+- Lock large tables with `ALTER TABLE` during peak traffic
+- Skip testing migrations on production-like data (row counts, constraints, FK relationships)
+- Use ORM auto-migration in production (unpredictable, no rollback)
+
+## 5. Connection Pooling
+
+**DO:** Use connection pools to manage database connections efficiently.
+
+- Size the pool based on: `pool_size = (core_count * 2) + disk_spindles` (start with this, tune under load)
+- Set connection timeouts (acquisition: 5s, idle: 60s, max lifetime: 30min)
+- Use a connection pool per service instance, not a global shared pool
+- Monitor pool metrics: active connections, waiting requests, timeout rate
+- Close connections gracefully on application shutdown
+
+**DON'T:**
+
+- Create a new connection per query (connection setup is expensive: TCP + TLS + auth)
+- Set pool size equal to `max_connections` on the database (leave room for admin, monitoring, other services)
+- Use unbounded pools (set a maximum to prevent connection exhaustion)
+- Ignore idle connection cleanup (stale connections waste database resources)
+- Share connection pools across unrelated services
+
+## 6. Transactions and Locking
+
+**DO:** Use transactions to maintain data integrity for multi-step operations.
+
+- Choose the appropriate isolation level:
+
+| Level | Dirty Read | Non-repeatable Read | Phantom Read | Use Case |
+|-------|-----------|-------------------|-------------|---------|
+| READ COMMITTED | No | Yes | Yes | Default for most apps |
+| REPEATABLE READ | No | No | Yes | Financial reports |
+| SERIALIZABLE | No | No | No | Critical financial ops |
+
+- Use optimistic locking for low-contention updates:
+  ```sql
+  -- Add version column
+  UPDATE orders SET status = 'shipped', version = version + 1
+  WHERE id = 123 AND version = 5;
+  -- If 0 rows affected: someone else updated first (retry or error)
+  ```
+
+- Use pessimistic locking (`SELECT ... FOR UPDATE`) only when contention is high and retries are expensive
+- Keep transactions as short as possible -- do computation outside the transaction
+- Always handle deadlocks: retry with exponential backoff (2-3 attempts max)
+
+**DON'T:**
+
+- Hold transactions open during user input or external API calls
+- Use `SERIALIZABLE` as the default isolation level (performance impact)
+- Nest transactions without understanding savepoint semantics
+- Ignore deadlock errors -- they are expected in concurrent systems; handle them
+- Lock entire tables when row-level locks suffice
+
+## 7. Data Modeling Patterns
+
+**DO:** Use established patterns for common data modeling challenges.
+
+- **Soft deletes:** Add `deleted_at TIMESTAMP NULL` instead of removing rows. Filter with `WHERE deleted_at IS NULL` by default. Use a partial index for performance:
+  ```sql
+  CREATE INDEX idx_users_active ON users(email) WHERE deleted_at IS NULL;
+  ```
+
+- **Temporal data (audit history):** Use a separate history table or event sourcing:
+  ```sql
+  CREATE TABLE order_events (
+    id SERIAL PRIMARY KEY,
+    order_id INTEGER NOT NULL REFERENCES orders(id),
+    event_type TEXT NOT NULL,  -- 'created', 'updated', 'shipped'
+    payload JSONB NOT NULL,
+    created_at TIMESTAMP NOT NULL DEFAULT NOW()
+  );
+  ```
+
+- **Polymorphic associations:** Use a discriminator column or separate tables per type:
+  ```sql
+  -- DO: Separate tables (type-safe, indexable)
+  CREATE TABLE comment_on_post (comment_id INT, post_id INT);
+  CREATE TABLE comment_on_photo (comment_id INT, photo_id INT);
+
+  -- Acceptable: Discriminator column (simpler, less type-safe)
+  CREATE TABLE comments (
+    id SERIAL, body TEXT,
+    commentable_type TEXT NOT NULL,  -- 'post', 'photo'
+    commentable_id INTEGER NOT NULL
+  );
+  ```
+
+- **JSON columns:** Use for semi-structured data that doesn't need relational queries. Index with GIN for JSONB queries:
+  ```sql
+  ALTER TABLE products ADD COLUMN metadata JSONB;
+  CREATE INDEX idx_products_metadata ON products USING GIN(metadata);
+  ```
+
+**DON'T:**
+
+- Use soft deletes without filtering them by default (data leaks)
+- Store structured, queryable data in JSON columns (normalize instead)
+- Create polymorphic foreign keys without application-level integrity checks
+- Use EAV (Entity-Attribute-Value) pattern when a proper schema is feasible
+
+## 8. Backup and Recovery
+
+**DO:** Plan for data loss scenarios before they happen.
+
+- Implement automated daily backups with point-in-time recovery (PITR) capability
+- Store backups in a different region/account than the database
+- Test backup restoration quarterly -- an untested backup is not a backup
+- Document the recovery procedure: who, what, where, how long (RTO/RPO targets)
+- Use logical backups (pg_dump, mysqldump) for portability and physical backups (WAL archiving, snapshots) for speed
+
+**DON'T:**
+
+- Keep backups on the same server/disk as the database
+- Skip backup verification (restore to a test environment periodically)
+- Rely solely on database replication as a backup strategy (replication propagates corruption)
+- Store backup credentials in the same place as database credentials
+- Assume cloud provider handles backup without verifying configuration and retention policy

package/assets/skills/docker-deployment/SKILL.md

@@ -0,0 +1,326 @@
+---
+# opencode-autopilot
+name: docker-deployment
+description: Dockerfile best practices, container orchestration, CI/CD deployment patterns, container security, and health checks
+stacks: []
+requires: []
+---
+
+# Docker and Deployment Patterns
+
+Practical patterns for containerizing applications, orchestrating services, and deploying through CI/CD pipelines. Covers Dockerfile best practices, docker-compose patterns, CI/CD pipeline design, container security, health checks, logging, deployment strategies, and environment configuration. Apply these when building containers, reviewing Dockerfiles, designing pipelines, or troubleshooting deployments.
+
+## 1. Dockerfile Best Practices
+
+**DO:** Write Dockerfiles that produce small, secure, reproducible images.
+
+- Use multi-stage builds to separate build dependencies from runtime:
+  ```dockerfile
+  # Stage 1: Build
+  FROM node:20-alpine AS builder
+  WORKDIR /app
+  COPY package.json package-lock.json ./
+  RUN npm ci --production=false
+  COPY src/ src/
+  RUN npm run build
+
+  # Stage 2: Runtime (no build tools, no dev dependencies)
+  FROM node:20-alpine AS runtime
+  WORKDIR /app
+  RUN addgroup -S appgroup && adduser -S appuser -G appgroup
+  COPY --from=builder /app/dist ./dist
+  COPY --from=builder /app/node_modules ./node_modules
+  USER appuser
+  EXPOSE 3000
+  CMD ["node", "dist/server.js"]
+  ```
+
+- Order layers from least to most frequently changing (dependencies before source code)
+- Use `.dockerignore` to exclude unnecessary files:
+  ```
+  node_modules
+  .git
+  .env
+  *.md
+  tests/
+  .github/
+  ```
+- Pin base image versions with SHA digests for reproducibility (get the digest from `docker pull <image>`):
+  ```dockerfile
+  FROM node:20-alpine@sha256:<64-char-hex-digest>
+  ```
+- Use `COPY` instead of `ADD` (unless extracting archives)
+- Combine `RUN` commands to reduce layers:
+  ```dockerfile
+  RUN apk add --no-cache curl && \
+      curl -fsSL https://example.com/install.sh | sh && \
+      apk del curl
+  ```
+
+**DON'T:**
+
+- Use `latest` tag for base images (non-reproducible builds)
+- Run containers as root (use `USER` directive)
+- Copy the entire build context when only specific files are needed
+- Store secrets in image layers (`ENV`, `ARG`, or `COPY` of `.env` files)
+- Install unnecessary packages in the runtime image
+- Use `apt-get upgrade` in Dockerfiles (non-reproducible; pin package versions instead)
+
+## 2. Docker Compose Patterns
+
+**DO:** Structure docker-compose files for development and testing environments.
+
+```yaml
+services:
+  app:
+    build:
+      context: .
+      target: runtime
+    ports:
+      - "3000:3000"
+    environment:
+      - DATABASE_URL=postgres://user:pass@db:5432/myapp
+      - REDIS_URL=redis://cache:6379
+    depends_on:
+      db:
+        condition: service_healthy
+      cache:
+        condition: service_started
+    healthcheck:
+      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
+      interval: 10s
+      timeout: 5s
+      retries: 3
+      start_period: 15s
+
+  db:
+    image: postgres:16-alpine
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    env_file: .env  # Never hardcode credentials — use env_file or Docker secrets
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U $POSTGRES_USER -d $POSTGRES_DB"]
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  cache:
+    image: redis:7-alpine
+    volumes:
+      - redisdata:/data
+
+volumes:
+  pgdata:
+  redisdata:
+```
+
+- Use `depends_on` with `condition: service_healthy` for startup ordering
+- Define named volumes for persistent data
+- Use `profiles` to group optional services (monitoring, debug tools)
+- Use environment files for secrets in development: `env_file: .env.local`
+
+**DON'T:**
+
+- Use `links` (deprecated -- use networks and service names for DNS)
+- Mount code volumes in production (use built images)
+- Hardcode production credentials in docker-compose files
+- Use `restart: always` without health checks (endlessly restarting a broken container)
+
+## 3. CI/CD Pipeline Design
+
+**DO:** Design pipelines with clear stages, fast feedback, and reliable deployments.
+
+```
+Pipeline stages:
+  1. Lint & Type Check (fast, catch obvious errors)
+  2. Unit Tests (parallel, cached)
+  3. Build (Docker image, artifacts)
+  4. Integration Tests (against real services via docker-compose)
+  5. Security Scan (image scanning, dependency audit)
+  6. Deploy to Staging (automatic on main branch)
+  7. Smoke Tests (against staging)
+  8. Deploy to Production (manual approval or automatic)
+```
+
+- Cache aggressively: dependencies, Docker layers, test results
+- Run lint and unit tests in parallel for fast feedback (<5 min target)
+- Use immutable artifacts: build once, deploy the same image to all environments
+- Tag images with commit SHA (not `latest`) for traceability
+- Implement environment promotion: dev -> staging -> production (same image)
+
+**DON'T:**
+
+- Build different images for different environments (build once, configure per environment)
+- Skip integration tests to save time (they catch real issues)
+- Deploy without a rollback plan
+- Use CI secrets in build logs (mask all sensitive values)
+- Run production deployments without a preceding staging test
+
+## 4. Container Security
+
+**DO:** Follow defense-in-depth principles for container security.
+
+- Run containers as non-root users:
+  ```dockerfile
+  RUN addgroup -S appgroup && adduser -S appuser -G appgroup
+  USER appuser
+  ```
+- Use read-only root filesystems where possible:
+  ```yaml
+  services:
+    app:
+      read_only: true
+      tmpfs:
+        - /tmp
+        - /var/run
+  ```
+- Set resource limits to prevent DoS:
+  ```yaml
+  services:
+    app:
+      deploy:
+        resources:
+          limits:
+            cpus: "1.0"
+            memory: 512M
+          reservations:
+            cpus: "0.25"
+            memory: 128M
+  ```
+- Scan images for vulnerabilities in CI (Trivy, Snyk, Grype)
+- Use minimal base images (Alpine, distroless, scratch)
+- Inject secrets via environment variables or mounted volumes at runtime -- never bake into images
+
+**DON'T:**
+
+- Run containers with `--privileged` (breaks all container isolation)
+- Mount the Docker socket inside containers (enables container escape)
+- Use images from untrusted registries without scanning
+- Skip security scanning in CI ("it works" does not mean "it is safe")
+- Store secrets in environment variables in docker-compose for production (use Docker secrets or external vault)
+
+## 5. Health Checks and Readiness Probes
+
+**DO:** Implement health checks at every level.
+
+- **Liveness probe:** Is the process alive and not deadlocked?
+  ```
+  GET /healthz -> 200 OK
+  Checks: process is running, not in deadlock
+  ```
+
+- **Readiness probe:** Can the service handle requests?
+  ```
+  GET /readyz -> 200 OK
+  Checks: database connected, cache reachable, required services available
+  ```
+
+- **Startup probe:** Has the service finished initializing?
+  ```
+  GET /startupz -> 200 OK
+  Use for services with long startup times (loading ML models, warming caches)
+  ```
+
+- Return structured health check responses:
+  ```json
+  {
+    "status": "healthy",
+    "checks": {
+      "database": { "status": "up", "latency_ms": 12 },
+      "cache": { "status": "up", "latency_ms": 2 },
+      "disk": { "status": "up", "free_gb": 45.2 }
+    }
+  }
+  ```
+
+**DON'T:**
+
+- Use the same endpoint for liveness and readiness (different failure modes)
+- Make liveness checks depend on external services (liveness = process health only)
+- Set health check intervals too short (adds load) or too long (slow failure detection)
+- Return 200 from health endpoints when the service is actually degraded
+
+## 6. Logging and Monitoring
+
+**DO:** Design containers for observability from the start.
+
+- Write logs to stdout/stderr (let the platform handle collection):
+  ```
+  // DO: stdout logging
+  console.log(JSON.stringify({ level: "info", msg: "Order created", orderId: 123 }))
+
+  // DON'T: File logging inside container
+  fs.appendFileSync("/var/log/app.log", message)
+  ```
+- Use structured JSON logging for machine parsing
+- Include correlation IDs in all log entries for request tracing
+- Export metrics in a standard format (Prometheus, OpenTelemetry)
+- Set up alerts for: error rate spikes, latency p99 increases, resource saturation
+
+**DON'T:**
+
+- Log to files inside containers (ephemeral filesystems, lost on restart)
+- Log sensitive data (credentials, PII, tokens)
+- Use log levels inconsistently (ERROR for expected conditions, INFO for everything)
+- Skip correlation IDs (impossible to trace requests across services without them)
+
+## 7. Deployment Strategies
+
+**DO:** Choose deployment strategies based on risk tolerance and infrastructure capabilities.
+
+- **Rolling update** (default): Replace instances gradually. Zero downtime. Requires backward-compatible changes.
+  ```yaml
+  deploy:
+    update_config:
+      parallelism: 1
+      delay: 10s
+      order: start-first
+  ```
+
+- **Blue-green:** Run two identical environments. Switch traffic atomically. Instant rollback by switching back.
+  - Best for: critical services, database schema changes, major version upgrades
+  - Cost: 2x infrastructure during deployment
+
+- **Canary:** Route a small percentage of traffic to the new version. Monitor metrics. Gradually increase.
+  - Best for: high-traffic services, risky changes, A/B testing infrastructure
+  - Requires: traffic routing (load balancer rules, service mesh)
+
+**DON'T:**
+
+- Deploy without a rollback plan (every deployment should be reversible within minutes)
+- Use recreate strategy in production (causes downtime)
+- Skip smoke tests after deployment (verify the new version actually works)
+- Deploy breaking changes without a migration strategy (expand-contract pattern)
+
+## 8. Environment Configuration (12-Factor App)
+
+**DO:** Configure applications through the environment, not through code.
+
+- Store config in environment variables (database URLs, API keys, feature flags)
+- Use a `.env.example` file (committed) to document required variables:
+  ```
+  # .env.example (committed to repo)
+  DATABASE_URL=postgres://user:password@localhost:5432/myapp
+  REDIS_URL=redis://localhost:6379
+  API_KEY=your-api-key-here
+  LOG_LEVEL=info
+  ```
+- Validate all environment variables at startup -- fail fast if missing:
+  ```
+  const required = ["DATABASE_URL", "API_KEY", "SESSION_SECRET"]
+  for (const key of required) {
+    if (!process.env[key]) {
+      throw new Error("Missing required environment variable: " + key)
+    }
+  }
+  ```
+- Use different values per environment (dev, staging, production) -- same code, different config
+- Use platform-native secret injection (Kubernetes secrets, AWS Parameter Store, Docker secrets)
+
+**DON'T:**
+
+- Hardcode environment-specific values in source code
+- Commit `.env` files with real credentials to version control
+- Use different code paths per environment (`if (env === 'production')` for config)
+- Mix application config with infrastructure config in the same file
+- Store secrets in ConfigMaps or plain environment variables in production (use encrypted secret stores)

package/assets/skills/e2e-testing/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: e2e-testing
 description: End-to-end testing patterns for critical user flows -- test the system as a user would use it
 stacks: []

package/assets/skills/frontend-design/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: frontend-design
 description: State-of-the-art frontend UX/UI design patterns covering component architecture, responsive design, accessibility, and design system integration
 stacks:

package/assets/skills/git-worktrees/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: git-worktrees
 description: Git worktrees for isolated parallel development — work on multiple branches simultaneously without stashing
 stacks: []

package/assets/skills/go-patterns/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: go-patterns
 description: Idiomatic Go patterns covering error handling, concurrency, interfaces, and testing conventions
 stacks:

package/assets/skills/java-patterns/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: java-patterns
 description: Idiomatic Java patterns including records, Spring Boot conventions, JPA/Hibernate, and common pitfalls
 stacks:

package/assets/skills/plan-executing/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: plan-executing
 description: Batch execution methodology for implementing plans with verification checkpoints after each task
 stacks: []

package/assets/skills/plan-writing/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: plan-writing
 description: Methodology for decomposing features into bite-sized implementation tasks with file paths, dependencies, and verification criteria
 stacks: []

package/assets/skills/python-patterns/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: python-patterns
 description: Pythonic patterns covering type hints, error handling, async, testing with pytest, and project organization
 stacks:

package/assets/skills/rust-patterns/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: rust-patterns
 description: Rust patterns covering ownership, error handling with Result/Option, unsafe guidelines, and testing conventions
 stacks: