@harness-engineering/cli 1.13.0 → 1.13.1

package/dist/agents/skills/claude-code/harness-database/SKILL.md

@@ -0,0 +1,258 @@
+# Harness Database
+
+> Advisory guide for schema design, migrations, ORM patterns, and migration safety. Detects your ORM, analyzes schema health, produces safe migrations, and validates backward compatibility.
+
+## When to Use
+
+- When designing a new database schema for a feature
+- When writing or reviewing migration files (Prisma, Drizzle, Knex, TypeORM, Sequelize, raw SQL)
+- When evaluating schema normalization, indexing, or relationship design
+- When checking migration safety before deploying to production
+- When adding a new model or entity to an existing ORM setup
+- When troubleshooting slow queries caused by missing indexes or poor schema design
+- NOT for API endpoint design that exposes database models (use harness-api-design for that)
+- NOT for caching layers in front of the database (use harness-caching for Redis/Memcached strategy)
+- NOT for data validation at the application layer (use harness-data-validation for Zod/Joi schemas)
+- NOT for event sourcing storage patterns (use harness-event-driven for event store design)
+
+## Process
+
+### Phase 1: DETECT -- Identify Database Engine and ORM
+
+1. **Identify the ORM or query builder.** Scan for stack signals: `prisma/schema.prisma` for Prisma, `drizzle.config.*` for Drizzle, `knexfile.*` for Knex, `typeorm.config.*` or `ormconfig.*` for TypeORM, `sequelize.config.*` or `.sequelizerc` for Sequelize. If the `--orm` argument is provided, use that instead of auto-detection.
+
+2. **Identify the database engine.** Parse the ORM configuration for the connection string or provider field. Detect PostgreSQL, MySQL, SQLite, MongoDB, or SQL Server. Record the engine version if specified in the config or docker-compose file.
+
+3. **Map existing schema.** For Prisma, parse `schema.prisma` for models, relations, and indexes. For Drizzle, parse table definitions in `src/**/schema.*`. For Knex/raw SQL, scan the `migrations/` directory and reconstruct the current schema state. For TypeORM/Sequelize, scan entity or model files.
+
+4. **Assess migration state.** List pending migrations (not yet applied). Check for migration gaps (missing sequence numbers) or conflicts (multiple migrations with the same timestamp). WHERE a migration history table is accessible, THEN compare applied vs. on-disk migrations.
+
+5. **Catalog existing patterns.** Record naming conventions (snake_case vs camelCase for columns), soft-delete patterns (`deletedAt` column), audit patterns (`createdAt`, `updatedAt`), and relationship styles (join tables vs embedded references). These become the baseline for new schema work.
+
+### Phase 2: ANALYZE -- Evaluate Schema Design
+
+1. **Check normalization.** Identify denormalized data that may cause update anomalies. Flag tables with repeated groups of columns (e.g., `address1`, `address2`, `address3`) that should be a separate table. Distinguish intentional denormalization (for read performance) from accidental duplication.
+
+2. **Evaluate indexing.** For every foreign key column, verify an index exists. For columns used in WHERE clauses or ORDER BY (inferred from query patterns in the codebase), check for supporting indexes. Flag tables with more than 8 indexes (write performance concern) or zero indexes beyond the primary key.
+
+3. **Analyze relationships.** Verify that every foreign key has a corresponding ON DELETE action (CASCADE, SET NULL, or RESTRICT). Flag orphan risk where ON DELETE is not specified. Check for circular references that may complicate migrations or deletes.
+
+4. **Review data types.** Flag columns using overly broad types (e.g., `TEXT` where `VARCHAR(255)` suffices, `FLOAT` for monetary values instead of `DECIMAL`). Check for missing NOT NULL constraints on fields that should never be null. Verify ENUM types are used appropriately.
+
+5. **Check for N+1 query patterns.** Scan ORM usage in the codebase for eager vs lazy loading configuration. WHERE a model is loaded in a loop without includes/joins, THEN flag the N+1 risk with a specific file and line reference.
+
+### Phase 3: ADVISE -- Produce Schema Changes and Migrations
+
+1. **Generate schema changes.** Based on the feature requirements and phase 2 analysis, produce the schema modifications. For Prisma, write the `schema.prisma` model additions. For Drizzle, write the table definition. For Knex, write the migration `up` and `down` functions. Match the project's existing conventions.
+
+2. **Write migration files.** Generate the migration in the ORM's native format. For Prisma: `npx prisma migrate dev --name <name>`. For Drizzle: `npx drizzle-kit generate`. For Knex: `npx knex migrate:make <name>`. Include both `up` (apply) and `down` (rollback) logic.
+
+3. **Add indexes for the new schema.** For every foreign key in the new schema, include an index. For columns that will be used in filters or sorting (based on the feature requirements), include a covering index. Justify each index with the expected query pattern.
+
+4. **Handle seed data.** WHERE the new schema requires initial data (enum lookup tables, default configuration rows), THEN include a seed script or migration data insertion. Separate structural migrations from data migrations.
+
+5. **Produce ORM pattern recommendations.** For the new models, recommend the query patterns: which relations to eager-load by default, where to use transactions, and how to handle optimistic locking if the feature requires concurrent writes.
+
+### Phase 4: VALIDATE -- Verify Migration Safety
+
+1. **Check backward compatibility.** WHERE the migration drops a column, renames a table, or changes a column type, THEN flag it as a destructive migration. Destructive migrations require a multi-step deployment: add new column, backfill data, deploy code using new column, drop old column.
+
+2. **Verify rollback safety.** Run the `down` migration mentally (or actually if a test database is available). Confirm that rolling back does not lose data. WHERE the `up` migration drops a column, THEN the `down` migration cannot restore it -- flag this as an irreversible migration.
+
+3. **Check for long-running locks.** WHERE the migration adds a NOT NULL column to a large table without a default value, THEN flag it: the database will lock the table for a full rewrite. Recommend adding the column as nullable first, backfilling, then adding the constraint. WHERE the migration creates an index on a large table, THEN recommend `CREATE INDEX CONCURRENTLY` (PostgreSQL) or equivalent.
+
+4. **Validate constraint additions.** WHERE a new UNIQUE constraint is added, THEN verify existing data will not violate it. WHERE a new FOREIGN KEY is added, THEN verify the referenced table and column exist and have an index. WHERE a CHECK constraint is added, THEN verify the expression syntax is valid for the target engine.
+
+5. **Run migration dry-run.** WHERE a test database connection is available, THEN run the migration in a transaction and roll it back. Report success or failure. WHERE no database is available, THEN validate the migration SQL syntax against the target engine's dialect.
+
+## Harness Integration
+
+- **`harness validate`** -- Run after generating migrations to confirm project health
+- **`harness scan`** -- Refresh the knowledge graph after adding new model files
+- **`query_graph`** -- Trace which services depend on a table before modifying it
+- **`get_impact`** -- Understand blast radius when modifying a shared schema table
+
+## Success Criteria
+
+- ORM and database engine were correctly detected or explicitly specified
+- Existing schema conventions were identified and followed in new designs
+- Every new table has appropriate indexes, constraints, and foreign key actions
+- Migration files include both `up` and `down` logic
+- Destructive migrations are flagged and a safe multi-step deployment plan is provided
+- No long-running table locks are introduced without explicit warning
+- N+1 query risks are identified for new models
+- Migration SQL syntax is valid for the target database engine
+
+## Examples
+
+### Example: Prisma Schema Addition for a Comments Feature
+
+**Input:** "Add a comments model to our Prisma/PostgreSQL app."
+
+**Phase 1 -- DETECT:**
+
+```
+ORM: Prisma 5.x
+Engine: PostgreSQL 15 (from DATABASE_URL in .env.example)
+Existing models: User, Post, Category
+Conventions: camelCase fields, @updatedAt on all models, soft deletes (deletedAt DateTime?)
+Migrations: 12 applied, 0 pending, no gaps
+```
+
+**Phase 2 -- ANALYZE:**
+
+```
+Normalization: PASS -- no denormalized data detected
+Indexing: WARN -- Post.authorId has no index (FK without index)
+Relationships: PASS -- all FKs have onDelete specified
+Data types: PASS
+N+1 risk: WARN -- src/routes/posts.ts:42 loads post.author in a loop without include
+```
+
+**Phase 3 -- ADVISE:**
+
+```prisma
+model Comment {
+  id        String   @id @default(cuid())
+  body      String
+  postId    String
+  post      Post     @relation(fields: [postId], references: [id], onDelete: Cascade)
+  authorId  String
+  author    User     @relation(fields: [authorId], references: [id], onDelete: Cascade)
+  parentId  String?
+  parent    Comment? @relation("CommentReplies", fields: [parentId], references: [id], onDelete: Cascade)
+  replies   Comment[] @relation("CommentReplies")
+  createdAt DateTime @default(now())
+  updatedAt DateTime @updatedAt
+  deletedAt DateTime?
+
+  @@index([postId])
+  @@index([authorId])
+  @@index([parentId])
+}
+```
+
+Migration generated: `npx prisma migrate dev --name add-comments`
+
+**Phase 4 -- VALIDATE:**
+
+```
+Backward compatibility: PASS -- additive change only
+Rollback safety: PASS -- dropping Comment table is safe (no data loss for existing tables)
+Lock risk: PASS -- new table, no ALTER on existing tables
+Constraints: PASS -- all FK targets exist and are indexed
+```
+
+### Example: Knex Migration Safety Check
+
+**Input:** "Review this migration that adds a required email column to the users table."
+
+**Phase 1 -- DETECT:**
+
+```
+ORM: Knex 3.x
+Engine: PostgreSQL 14
+Existing schema: users (id, name, created_at), posts (id, user_id, title, body)
+```
+
+**Phase 4 -- VALIDATE (fast-path for --check-migrations):**
+
+```
+DANGER: Migration adds NOT NULL column 'email' to users table without a default value.
+
+Impact: PostgreSQL will attempt to rewrite the entire users table, acquiring an
+ACCESS EXCLUSIVE lock. If the users table has >10K rows, this will block all
+reads and writes for the duration.
+
+Existing rows will fail the NOT NULL constraint, causing the migration to abort.
+
+Recommended safe approach (3-step migration):
+
+Step 1 (migration: add-email-nullable):
+  exports.up = (knex) => knex.schema.alterTable('users', (t) => {
+    t.string('email', 255);  // nullable first
+    t.index('email');
+  });
+
+Step 2 (data migration: backfill-emails):
+  exports.up = async (knex) => {
+    await knex.raw(`
+      UPDATE users SET email = name || '@placeholder.example'
+      WHERE email IS NULL
+    `);
+  };
+
+Step 3 (migration: enforce-email-not-null):
+  exports.up = (knex) => knex.schema.alterTable('users', (t) => {
+    t.string('email', 255).notNullable().alter();
+  });
+```
+
+### Example: Drizzle Schema for Multi-Tenant SaaS
+
+**Input:** "Design a multi-tenant schema with row-level security for our Drizzle/PostgreSQL app."
+
+**Phase 1 -- DETECT:**
+
+```
+ORM: Drizzle 0.30.x
+Engine: PostgreSQL 16
+Config: drizzle.config.ts (schema: ./src/db/schema.ts)
+Existing tables: none (greenfield)
+```
+
+**Phase 3 -- ADVISE:**
+
+```typescript
+// src/db/schema.ts
+import { pgTable, text, timestamp, uuid, index } from 'drizzle-orm/pg-core';
+
+export const tenants = pgTable('tenants', {
+  id: uuid('id').primaryKey().defaultRandom(),
+  name: text('name').notNull(),
+  slug: text('slug').notNull().unique(),
+  createdAt: timestamp('created_at').defaultNow().notNull(),
+});
+
+export const users = pgTable(
+  'users',
+  {
+    id: uuid('id').primaryKey().defaultRandom(),
+    tenantId: uuid('tenant_id')
+      .notNull()
+      .references(() => tenants.id, { onDelete: 'cascade' }),
+    email: text('email').notNull(),
+    name: text('name').notNull(),
+    role: text('role', { enum: ['owner', 'admin', 'member'] })
+      .notNull()
+      .default('member'),
+    createdAt: timestamp('created_at').defaultNow().notNull(),
+  },
+  (table) => ({
+    tenantIdx: index('users_tenant_id_idx').on(table.tenantId),
+    emailTenantUnique: index('users_email_tenant_unique').on(table.email, table.tenantId).unique(),
+  })
+);
+```
+
+Row-level security policy:
+
+```sql
+ALTER TABLE users ENABLE ROW LEVEL SECURITY;
+CREATE POLICY tenant_isolation ON users
+  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);
+```
+
+## Gates
+
+- **Destructive migrations must not proceed without flagging.** WHERE a migration drops a column, drops a table, renames a column, or changes a column type, THEN the skill must halt and present a safe multi-step alternative. Silently executing destructive DDL against production is not recoverable.
+- **Every foreign key must have an ON DELETE action.** No foreign key may be created without an explicit `onDelete` (CASCADE, SET NULL, or RESTRICT). The database default (NO ACTION) creates orphan rows and constraint violation errors during deletes.
+- **Migration files must include rollback logic.** Every `up` function must have a corresponding `down` function. WHERE a migration is irreversible (data loss on rollback), THEN it must be explicitly marked as such with a comment explaining why.
+- **No migrations that lock large tables without warning.** WHERE a migration performs an ALTER TABLE that acquires an ACCESS EXCLUSIVE lock on a table estimated to have more than 10,000 rows, THEN the skill must flag the lock risk and suggest a non-locking alternative.
+
+## Escalation
+
+- **Production data at risk:** When a migration would delete or overwrite existing data (DROP COLUMN, column type change that truncates), report: "This migration will permanently delete data in column `X`. Provide a data backup confirmation or approve a non-destructive alternative (add new column, backfill, drop old) before proceeding."
+- **ORM auto-detection fails:** When no ORM configuration file is found and no `--orm` flag is provided, report: "No ORM detected. Found raw `.sql` files in `migrations/`. Specify the ORM with `--orm` or confirm this is a raw SQL migration project."
+- **Schema conflicts between team members:** When two pending migrations modify the same table, report: "Migrations `20240315_add_email` and `20240316_add_phone` both ALTER the `users` table. These must be reviewed together to avoid lock contention and ordering issues. Recommend merging into a single migration."
+- **Database engine feature not available:** When the recommended approach uses a feature not available in the detected engine version (e.g., `CREATE INDEX CONCURRENTLY` is PostgreSQL-only), report: "The recommended non-locking index creation is not available in MySQL 5.7. Alternative: schedule the migration during a maintenance window or upgrade to MySQL 8.0+ which supports `ALGORITHM=INPLACE`."

package/dist/agents/skills/claude-code/harness-database/skill.yaml

@@ -0,0 +1,80 @@
+name: harness-database
+version: "1.0.0"
+description: Schema design, migrations, ORM patterns, and migration safety checks
+cognitive_mode: advisory-guide
+triggers:
+  - manual
+  - on_new_feature
+platforms:
+  - claude-code
+  - gemini-cli
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+cli:
+  command: harness skill run harness-database
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: orm
+      description: "ORM/query builder: prisma, drizzle, knex, typeorm, sequelize. Auto-detected when omitted."
+      required: false
+    - name: check-migrations
+      description: Run migration safety analysis on pending migrations
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-database
+    path: string
+type: rigid
+tier: 3
+internal: false
+keywords:
+  - database
+  - migration
+  - schema
+  - ORM
+  - prisma
+  - knex
+  - drizzle
+  - typeorm
+  - sequelize
+  - SQL
+  - DDL
+  - postgresql
+  - mysql
+  - sqlite
+  - mongodb
+stack_signals:
+  - "prisma/schema.prisma"
+  - "drizzle.config.*"
+  - "knexfile.*"
+  - "migrations/"
+  - "*.sql"
+  - "typeorm.config.*"
+  - "sequelize.config.*"
+  - "src/**/models/**"
+  - "src/**/entities/**"
+phases:
+  - name: detect
+    description: Identify database engine, ORM, existing schema, and migration state
+    required: true
+  - name: analyze
+    description: Evaluate schema design, indexing, relationships, and normalization
+    required: true
+  - name: advise
+    description: Produce schema changes, migration scripts, and ORM pattern recommendations
+    required: true
+  - name: validate
+    description: Verify migration safety, backward compatibility, and data integrity
+    required: true
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/harness-debugging/skill.yaml

@@ -27,6 +27,7 @@ mcp:
     skill: harness-debugging
     path: string
 type: rigid
+tier: 1
 phases:
   - name: investigate
     description: Entropy analysis and root cause search

package/dist/agents/skills/claude-code/harness-dependency-health/skill.yaml

@@ -25,6 +25,7 @@ mcp:
     skill: harness-dependency-health
     path: string
 type: rigid
+tier: 2
 phases:
   - name: metrics
     description: Compute graph structural metrics

package/dist/agents/skills/claude-code/harness-deployment/SKILL.md

@@ -0,0 +1,255 @@
+# Harness Deployment
+
+> CI/CD pipeline analysis, deployment strategy design, and environment management. From commit to production with confidence.
+
+## When to Use
+
+- When setting up or reviewing CI/CD pipelines for a new or existing project
+- When evaluating deployment strategies (blue-green, canary, rolling) for a service
+- When auditing environment separation and promotion workflows
+- NOT for container image building or registry management (use harness-containerization)
+- NOT for infrastructure provisioning (use harness-infrastructure-as-code)
+- NOT for application performance under load (use harness-perf)
+
+## Process
+
+### Phase 1: DETECT -- Identify Pipeline and Environment Configuration
+
+1. **Scan for CI/CD configuration files.** Search the project root for pipeline definitions:
+   - `.github/workflows/*.yml` -- GitHub Actions
+   - `.gitlab-ci.yml` -- GitLab CI
+   - `Jenkinsfile` -- Jenkins
+   - `.circleci/config.yml` -- CircleCI
+   - `bitbucket-pipelines.yml` -- Bitbucket Pipelines
+   - `azure-pipelines.yml` -- Azure DevOps
+   - `deploy/`, `scripts/deploy*` -- custom deployment scripts
+
+2. **Identify deployment targets.** Parse pipeline files for deployment steps and extract:
+   - Target environments (dev, staging, production)
+   - Deployment mechanisms (kubectl apply, aws ecs update-service, serverless deploy, rsync)
+   - Cloud provider and region information
+   - Container registry references
+
+3. **Detect environment configuration.** Look for environment-specific config:
+   - `.env.production`, `.env.staging` files
+   - Environment variable injection in pipeline definitions
+   - Secret references (GitHub Secrets, GitLab CI variables, Vault paths)
+   - Feature flag provider configuration per environment
+
+4. **Map the deployment topology.** Build a summary of what gets deployed where:
+   - Service name, pipeline file, target environment, deployment mechanism
+   - Dependencies between services (deploy order constraints)
+   - Manual approval gates vs. automatic promotion
+
+5. **Present detection summary.** Output the discovered topology before proceeding:
+
+   ```
+   Deployment Topology:
+     Platform: GitHub Actions
+     Pipelines: 3 workflow files
+     Environments: dev, staging, production
+     Strategy: Rolling (detected from kubectl rolling-update)
+     Approval gates: production (manual)
+   ```
+
+---
+
+### Phase 2: ANALYZE -- Evaluate Pipeline Quality and Gaps
+
+1. **Check pipeline stage completeness.** A mature pipeline includes these stages. Flag any that are missing:
+   - Build and compile
+   - Unit tests
+   - Integration tests
+   - Security scan (SAST/DAST)
+   - Artifact packaging
+   - Deploy to staging
+   - Smoke tests post-deploy
+   - Deploy to production
+   - Post-deploy verification
+
+2. **Evaluate environment isolation.** Verify that environments are properly separated:
+   - Staging and production use different credentials
+   - Environment-specific variables are not shared across environments
+   - Database connections point to the correct environment
+   - No hardcoded production URLs in non-production configs
+
+3. **Check deployment safety mechanisms.** Verify the pipeline includes:
+   - Rollback procedures (automatic or documented manual)
+   - Health checks after deployment
+   - Timeout configuration on deployment steps
+   - Concurrency controls (prevent parallel deploys to the same environment)
+   - Branch protection rules that gate production deploys
+
+4. **Analyze pipeline performance.** Identify bottlenecks:
+   - Steps that could run in parallel but are sequential
+   - Missing caching (dependencies, build artifacts, Docker layers)
+   - Redundant steps across workflows
+   - Total pipeline duration from commit to production
+
+5. **Check secret hygiene in pipelines.** Verify:
+   - No secrets hardcoded in pipeline files
+   - Secrets are scoped to the minimum required environment
+   - Secret rotation is possible without pipeline changes
+   - OIDC or workload identity is used where available instead of long-lived credentials
+
+---
+
+### Phase 3: DESIGN -- Recommend Strategy Improvements
+
+1. **Recommend deployment strategy.** Based on the service characteristics:
+   - **Rolling** -- suitable for stateless services with backward-compatible changes
+   - **Blue-green** -- suitable when zero-downtime cutover is required and rollback must be instant
+   - **Canary** -- suitable for high-traffic services where gradual validation reduces blast radius
+   - **Recreate** -- suitable only for development environments or when downtime is acceptable
+
+2. **Design missing pipeline stages.** For each gap identified in Phase 2, provide:
+   - The stage definition in the project's CI/CD platform syntax
+   - Where it fits in the pipeline order
+   - What tools or services it requires
+   - Example configuration snippet
+
+3. **Recommend environment promotion workflow.** Design the path from commit to production:
+   - Automatic promotion from dev to staging after tests pass
+   - Manual approval gate before production (with notification to the team channel)
+   - Smoke test suite that runs post-deploy in each environment
+   - Rollback trigger conditions (error rate spike, health check failure)
+
+4. **Design rollback procedure.** Every deployment must have a documented rollback:
+   - For container deployments: revert to previous image tag
+   - For serverless: revert to previous function version
+   - For database migrations: backward-compatible migration strategy
+   - Maximum rollback time target (e.g., under 5 minutes)
+
+5. **Recommend monitoring integration.** Connect deployment events to observability:
+   - Deploy markers in APM tools (Datadog, New Relic, Grafana)
+   - Automated alerts on error rate increase after deploy
+   - Deployment frequency and lead time tracking
+
+---
+
+### Phase 4: VALIDATE -- Verify Pipeline Correctness
+
+1. **Lint pipeline configuration.** Run syntax validation:
+   - GitHub Actions: `actionlint` or YAML schema validation
+   - GitLab CI: `gitlab-ci-lint` API endpoint
+   - Jenkinsfile: Groovy syntax check
+   - General: YAML structure validation for all config files
+
+2. **Verify environment variable completeness.** For each environment:
+   - All required variables are defined
+   - No placeholder values remain (TODO, CHANGEME, xxx)
+   - Variables referenced in code exist in the pipeline configuration
+
+3. **Verify branch protection alignment.** Confirm that:
+   - Production deploy pipelines only trigger from protected branches
+   - Required status checks match the pipeline stages
+   - Force-push is disabled on deployment branches
+
+4. **Generate deployment readiness report.** Summarize findings:
+
+   ```
+   Deployment Readiness: [PASS/WARN/FAIL]
+
+   Pipeline stages: 7/9 present (missing: security scan, smoke tests)
+   Environment isolation: PASS
+   Rollback procedure: WARN (documented but not automated)
+   Secret hygiene: PASS
+   Pipeline performance: 12m avg (recommend parallelizing test stages)
+
+   Recommendations:
+     1. Add SAST scan stage between build and deploy
+     2. Add post-deploy smoke test stage
+     3. Automate rollback on health check failure
+   ```
+
+5. **Present results.** Use `emit_interaction` to deliver the report and ask whether to proceed with implementing recommendations.
+
+---
+
+## Harness Integration
+
+- **`harness skill run harness-deployment`** -- Primary invocation for deployment analysis.
+- **`harness validate`** -- Run after any pipeline configuration changes to verify project health.
+- **`harness check-deps`** -- Verify deployment script dependencies are available.
+- **`emit_interaction`** -- Present deployment readiness report and gather decisions on strategy.
+
+## Success Criteria
+
+- All CI/CD configuration files in the project are identified and cataloged
+- Pipeline stage completeness is assessed against the standard checklist
+- Environment isolation is verified with no cross-environment credential leakage
+- A deployment strategy recommendation is provided with rationale
+- Rollback procedures are documented or flagged as missing
+- Pipeline lint passes without errors
+
+## Examples
+
+### Example: Node.js API with GitHub Actions
+
+```
+Phase 1: DETECT
+  Found: .github/workflows/ci.yml, .github/workflows/deploy.yml
+  Environments: staging (auto), production (manual dispatch)
+  Strategy: Rolling (kubectl set image)
+  Registry: ghcr.io/org/api-server
+
+Phase 2: ANALYZE
+  Missing stages: security scan, post-deploy smoke tests
+  Environment isolation: PASS
+  Secret hygiene: WARN -- AWS_ACCESS_KEY_ID used instead of OIDC
+  Pipeline duration: 18m (test and lint run sequentially)
+
+Phase 3: DESIGN
+  Recommendation: Add trivy scan after Docker build
+  Recommendation: Switch to AWS OIDC for keyless authentication
+  Recommendation: Parallelize lint and test jobs (saves ~4m)
+  Recommendation: Add smoke test job after deploy-staging
+
+Phase 4: VALIDATE
+  actionlint: PASS
+  Environment variables: PASS
+  Branch protection: WARN -- main branch allows force-push
+  Result: WARN -- 3 recommendations, 1 security improvement needed
+```
+
+### Example: Python Service with GitLab CI and Canary Deploy
+
+```
+Phase 1: DETECT
+  Found: .gitlab-ci.yml with 5 stages
+  Environments: dev, staging, production
+  Strategy: Canary (Istio VirtualService weight shifting)
+  Registry: registry.gitlab.com/org/service
+
+Phase 2: ANALYZE
+  All 9 standard stages present
+  Environment isolation: PASS
+  Canary configuration: 5% -> 25% -> 75% -> 100% over 30 minutes
+  Rollback: Automatic on 5xx rate > 1%
+
+Phase 3: DESIGN
+  Current strategy is well-configured. Minor recommendations:
+  - Add canary duration metrics to Grafana dashboard
+  - Add deployment event annotation to Prometheus
+  - Consider adding a manual gate between 75% and 100%
+
+Phase 4: VALIDATE
+  GitLab CI lint: PASS
+  Environment variables: PASS
+  Branch protection: PASS
+  Result: PASS -- pipeline is production-ready
+```
+
+## Gates
+
+- **No production deploy without staging validation.** If the pipeline allows direct-to-production deployment without a prior staging step, flag as a blocking issue.
+- **No long-lived credentials in pipelines.** Hardcoded secrets or long-lived access keys in pipeline files are blocking findings. OIDC or short-lived tokens must be used.
+- **No deploy without rollback.** Every deployment target must have a documented or automated rollback mechanism. Missing rollback is a blocking warning.
+- **No skipping pipeline lint.** Pipeline configuration must pass syntax validation before recommendations are made.
+
+## Escalation
+
+- **When the CI/CD platform is unsupported:** Report which platform was detected and that analysis is limited to general best practices. Recommend the user provide platform-specific documentation for deeper analysis.
+- **When secrets are found hardcoded in pipeline files:** Immediately flag as a critical finding. Do not proceed with strategy recommendations until secrets are remediated. Recommend rotating the exposed credentials.
+- **When multiple deployment strategies are mixed across environments:** This is valid (e.g., rolling for staging, canary for production). Analyze each independently and verify the promotion workflow handles the strategy transition.
+- **When pipeline configuration is generated by a tool (Terraform, Pulumi):** Analyze the generated output but note that fixes must be applied to the generator configuration, not the output files.

package/dist/agents/skills/claude-code/harness-deployment/skill.yaml

@@ -0,0 +1,77 @@
+name: harness-deployment
+version: "1.0.0"
+description: CI/CD pipelines, blue-green, canary, and environment management
+cognitive_mode: advisory-guide
+tier: 3
+internal: false
+keywords:
+  - deployment
+  - CI/CD
+  - pipeline
+  - GitHub Actions
+  - GitLab CI
+  - Jenkins
+  - blue-green
+  - canary
+  - rolling
+  - environment
+  - staging
+  - production
+  - CD
+stack_signals:
+  - ".github/workflows/"
+  - ".gitlab-ci.yml"
+  - "Jenkinsfile"
+  - "deploy/"
+  - "infrastructure/"
+  - ".circleci/"
+  - "bitbucket-pipelines.yml"
+triggers:
+  - manual
+  - on_new_feature
+platforms:
+  - claude-code
+  - gemini-cli
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - emit_interaction
+cli:
+  command: harness skill run harness-deployment
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: strategy
+      description: Deployment strategy to evaluate (blue-green, canary, rolling)
+      required: false
+    - name: platform
+      description: Target CI/CD platform (github-actions, gitlab-ci, jenkins)
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-deployment
+    path: string
+type: rigid
+phases:
+  - name: detect
+    description: Identify existing CI/CD configuration and deployment targets
+    required: true
+  - name: analyze
+    description: Evaluate pipeline structure, stages, and environment separation
+    required: true
+  - name: design
+    description: Recommend deployment strategy improvements and missing stages
+    required: true
+  - name: validate
+    description: Verify pipeline correctness and environment isolation
+    required: true
+state:
+  persistent: false
+  files: []
+depends_on: []