@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/claude-code/db-vertical-partitioning/SKILL.md

@@ -0,0 +1,249 @@
+# Vertical Partitioning
+
+> Splitting a wide table into multiple narrower tables, separating hot columns from cold columns, and managing large objects with TOAST to reduce I/O and improve cache efficiency.
+
+## When to Use
+
+- Tables with 30+ columns where most queries only access 5-10 columns
+- Tables containing both frequently-accessed metadata and rarely-accessed large payloads
+- JSONB or TEXT columns causing table bloat that slows scans of other columns
+- Hot/cold data patterns where recent data is queried frequently but historical data is rarely touched
+- Performance issues from large row sizes reducing the number of rows per page
+
+## Instructions
+
+### Key Concepts
+
+**1. What Is Vertical Partitioning**
+
+Horizontal partitioning splits rows across tables. Vertical partitioning splits columns across tables. The goal: keep frequently-accessed columns together in a narrow table that fits more rows per page, improving cache hit ratios and reducing I/O.
+
+```
+Before (one wide table):
+  users: id | name | email | avatar_blob | preferences_json | audit_log_json
+
+After (vertically partitioned):
+  users:          id | name | email
+  user_profiles:  user_id | avatar_blob | preferences_json
+  user_audit:     user_id | audit_log_json
+```
+
+**2. Row Size and Pages**
+
+PostgreSQL stores data in 8 KB pages. A row with a 4 KB JSONB column and a 2 KB TEXT column wastes most of the page on those columns, leaving room for only 1 row per page. Separating large columns into a different table lets the core table fit 50+ rows per page.
+
+```sql
+-- Check average row size
+SELECT avg(pg_column_size(t.*)) AS avg_row_bytes,
+       8192 / avg(pg_column_size(t.*)) AS rows_per_page
+FROM users t;
+
+-- If avg_row_bytes > 2000, vertical partitioning may help
+-- Target: narrow table with avg_row_bytes < 200 for hot data
+```
+
+**3. Hot/Cold Column Separation**
+
+Identify which columns queries actually read:
+
+```sql
+-- Find most-queried columns by analyzing pg_stat_user_tables
+-- and checking application query logs
+
+-- Hot columns (queried in 90%+ of queries):
+--   id, name, email, status, created_at
+
+-- Cold columns (queried in <5% of queries):
+--   bio, avatar_url, preferences, notification_settings
+
+-- Split:
+CREATE TABLE users (
+  id BIGSERIAL PRIMARY KEY,
+  name TEXT NOT NULL,
+  email TEXT NOT NULL,
+  status TEXT NOT NULL,
+  created_at TIMESTAMPTZ DEFAULT now()
+);
+
+CREATE TABLE user_profiles (
+  user_id BIGINT PRIMARY KEY REFERENCES users(id),
+  bio TEXT,
+  avatar_url TEXT,
+  preferences JSONB,
+  notification_settings JSONB
+);
+```
+
+**4. TOAST (The Oversized-Attribute Storage Technique)**
+
+PostgreSQL automatically compresses and out-of-line stores values larger than about 2 KB. TOAST is implicit vertical partitioning managed by the storage engine.
+
+```sql
+-- Check TOAST usage for a table
+SELECT relname, pg_size_pretty(pg_relation_size(reltoastrelid)) AS toast_size
+FROM pg_class
+WHERE relname = 'users' AND reltoastrelid != 0;
+
+-- Control TOAST strategy per column:
+ALTER TABLE users ALTER COLUMN bio SET STORAGE EXTERNAL;    -- store out-of-line, no compression
+ALTER TABLE users ALTER COLUMN bio SET STORAGE EXTENDED;    -- compress and store out-of-line (default)
+ALTER TABLE users ALTER COLUMN bio SET STORAGE MAIN;        -- compress, try to keep inline
+ALTER TABLE users ALTER COLUMN bio SET STORAGE PLAIN;       -- no compression, no TOAST (fails if too large)
+```
+
+**5. Join Cost vs I/O Savings**
+
+Vertical partitioning trades join complexity for reduced I/O. The split is worthwhile when:
+
+- The narrow table is queried 10x more than the wide columns
+- The cold columns are large (JSONB, TEXT, BYTEA)
+- Index-only scans become possible on the narrow table
+
+```sql
+-- Without vertical partitioning: every index scan fetches the full wide row
+-- With vertical partitioning: index scan on narrow table fetches only hot columns
+-- Cold columns only fetched when explicitly joined
+
+-- Query hot data (no join, fast):
+SELECT id, name, email FROM users WHERE status = 'active';
+
+-- Query with cold data (join when needed):
+SELECT u.id, u.name, p.preferences
+FROM users u
+JOIN user_profiles p ON u.id = p.user_id
+WHERE u.id = 42;
+```
+
+### Worked Example
+
+Scenario: an e-commerce product catalog with 2M products. The `products` table has 45 columns, but listing pages only use 6 columns. Detail pages use all columns.
+
+```sql
+-- Current table: 45 columns, avg row size 4.2 KB
+-- Listing queries (95% of traffic): SELECT id, name, price, image_url, rating, category_id
+-- Detail queries (5% of traffic): SELECT * ... WHERE id = ?
+
+-- Step 1: Create narrow table for listing queries
+CREATE TABLE products (
+  id BIGSERIAL PRIMARY KEY,
+  name TEXT NOT NULL,
+  price NUMERIC(10,2) NOT NULL,
+  image_url TEXT,
+  rating NUMERIC(3,2),
+  category_id INT REFERENCES categories(id),
+  created_at TIMESTAMPTZ DEFAULT now()
+);
+-- avg row size: ~120 bytes, ~65 rows per page
+
+-- Step 2: Create detail table for cold columns
+CREATE TABLE product_details (
+  product_id BIGINT PRIMARY KEY REFERENCES products(id),
+  description TEXT,
+  specifications JSONB,
+  shipping_info JSONB,
+  manufacturer_data JSONB,
+  seo_metadata JSONB,
+  internal_notes TEXT,
+  updated_at TIMESTAMPTZ DEFAULT now()
+);
+
+-- Step 3: Listing query (hot path, no join)
+SELECT id, name, price, image_url, rating
+FROM products
+WHERE category_id = 5
+ORDER BY rating DESC
+LIMIT 20;
+-- Scans narrow table: fast, cache-friendly
+
+-- Step 4: Detail query (cold path, join)
+SELECT p.*, d.description, d.specifications, d.shipping_info
+FROM products p
+JOIN product_details d ON p.id = d.product_id
+WHERE p.id = 12345;
+-- Single row join by primary key: fast
+```
+
+Result: listing pages load 3x faster because the narrow table fits entirely in shared_buffers. Detail pages have negligible overhead from the join since it is a single-row primary key lookup.
+
+### Anti-Patterns
+
+1. **Splitting tables that are already narrow.** If the table has 8 columns and each row is 200 bytes, vertical partitioning adds join overhead with no I/O benefit. Only split when wide rows are causing measurable performance issues.
+
+2. **Putting frequently-joined columns in different partitions.** If queries always need both `name` and `preferences`, splitting them into different tables forces a join on every query. Analyze actual query patterns before splitting.
+
+3. **Using vertical partitioning instead of fixing TOAST behavior.** If large columns are the problem, adjusting TOAST storage strategies may solve the issue without schema changes. Check TOAST usage first.
+
+4. **Creating too many split tables.** Two or three partitions is typical. Five or more becomes a maintenance burden with complex joins and migration scripts. Each split table needs its own indexes, vacuum schedules, and backup considerations.
+
+5. **Not maintaining referential integrity.** The split table must have a foreign key back to the main table. Without it, orphaned rows accumulate when the main table row is deleted.
+
+### PostgreSQL Specifics
+
+- TOAST automatically handles values > ~2 KB. Explicit vertical partitioning is only needed when TOAST's automatic behavior is insufficient (e.g., TOAST overhead is too high for scan-heavy workloads).
+- `pg_column_size()` returns the on-disk size of a value, including TOAST overhead.
+- `pg_table_size()` includes TOAST table size. `pg_relation_size()` excludes it. Compare both to understand TOAST impact.
+- Covering indexes (`INCLUDE` clause, PostgreSQL 11+) can serve as a form of vertical partitioning: store hot columns in the index to enable index-only scans without touching the heap.
+
+```sql
+-- Covering index as lightweight vertical partitioning
+CREATE INDEX idx_products_listing ON products (category_id, rating DESC)
+  INCLUDE (name, price, image_url);
+
+-- This query can be answered entirely from the index:
+SELECT name, price, image_url FROM products
+  WHERE category_id = 5 ORDER BY rating DESC LIMIT 20;
+```
+
+## Details
+
+### Advanced Topics
+
+**Materialized Views as Virtual Vertical Partitions:** Create a materialized view of hot columns (`CREATE MATERIALIZED VIEW products_listing AS SELECT id, name, price ...`). Listing queries hit the view; detail queries hit the base table. This avoids schema changes but adds refresh overhead and data staleness.
+
+**Column-Oriented Storage:** Extensions like `cstore_fdw` (now `columnar` in Citus) store data column-by-column rather than row-by-row, providing automatic vertical partitioning at the storage level:
+
+```sql
+-- Citus columnar storage
+CREATE TABLE analytics_events (
+  id BIGSERIAL, event_type TEXT, user_id INT,
+  payload JSONB, created_at TIMESTAMPTZ
+) USING columnar;
+
+-- Queries that read only event_type and created_at skip payload column entirely
+```
+
+### Engine Differences
+
+MySQL's InnoDB stores all columns in a single clustered index (primary key B-tree). Large BLOB/TEXT columns are stored off-page, similar to PostgreSQL's TOAST. MySQL does not expose storage strategy controls per-column the way PostgreSQL does with `SET STORAGE`.
+
+MySQL's `ROW_FORMAT=COMPRESSED` compresses entire rows, which can help with wide tables but adds CPU overhead. PostgreSQL's column-level TOAST compression is more granular.
+
+### Real-World Case Studies
+
+A job board stored listings with 40+ columns including a 20 KB average `description` HTML field. Search queries (95% of traffic) only needed title, company, location, and salary. The `listings` table was 800 GB; shared_buffers could only cache 3% of it. After vertically partitioning into `listings` (8 hot columns, avg 180 bytes) and `listing_content` (descriptions, requirements, benefits), the hot table shrank to 45 GB. Shared_buffers could cache 35% of it. Search p95 latency dropped from 1.2s to 180ms. Detail page latency was unchanged because the join was a single-row primary key lookup adding under 1ms.
+
+## Source
+
+- [PostgreSQL TOAST](https://www.postgresql.org/docs/current/storage-toast.html)
+- [PostgreSQL Page Layout](https://www.postgresql.org/docs/current/storage-page-layout.html)
+- Kleppmann, M. "Designing Data-Intensive Applications" (2017), Chapter 3
+
+## Process
+
+1. Measure average row size and identify hot vs cold columns from query patterns.
+2. If large columns dominate row size, check TOAST behavior before splitting tables.
+3. Create a narrow table with hot columns and a detail table with cold columns, linked by foreign key.
+4. Verify performance improvement with `EXPLAIN ANALYZE` comparing before and after query plans.
+
+## Harness Integration
+
+- **Type:** knowledge -- this skill is a reference document, not a procedural workflow.
+- **No tools or state** -- consumed as context by other skills and agents.
+- **related_skills:** db-table-partitioning, db-horizontal-sharding, db-denormalization, db-btree-index
+
+## Success Criteria
+
+- Hot and cold columns are identified from actual query patterns before splitting.
+- The narrow (hot) table fits significantly more rows per page, improving cache hit ratios.
+- TOAST behavior is checked before splitting; explicit partitioning is used only when TOAST is insufficient.
+- Referential integrity is maintained between split tables via foreign keys.

package/dist/agents/skills/claude-code/db-vertical-partitioning/skill.yaml

@@ -0,0 +1,40 @@
+name: db-vertical-partitioning
+version: '1.0.0'
+description: Table splitting, hot/cold data separation, TOAST management, and large object strategies
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - db-table-partitioning
+  - db-horizontal-sharding
+  - db-denormalization
+  - db-btree-index
+stack_signals:
+  - postgresql
+  - mysql
+  - database
+keywords:
+  - vertical-partitioning
+  - table-splitting
+  - hot-cold
+  - TOAST
+  - large-objects
+  - narrow-table
+  - wide-table
+metadata:
+  author: community
+  upstream: postgresql.org/docs/current/storage-toast.html
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/db-zero-downtime-migration/SKILL.md

@@ -0,0 +1,199 @@
+# Zero-Downtime Migration
+
+> Online schema changes that avoid table locks and keep the application serving traffic throughout the migration.
+
+## When to Use
+
+- Adding, removing, or modifying columns on tables with millions of rows
+- Creating indexes on large production tables
+- Changing column types or constraints without downtime
+- Planning DDL operations during high-traffic periods
+- Evaluating whether a migration requires a maintenance window
+
+## Instructions
+
+### Key Concepts
+
+**1. The Lock Problem**
+
+Most DDL statements in PostgreSQL acquire an `ACCESS EXCLUSIVE` lock, which blocks all reads and writes on the table. On a table with active queries, just waiting to acquire this lock can create a queue that cascades into a full outage.
+
+```sql
+-- This blocks ALL reads and writes until it completes:
+ALTER TABLE orders ADD COLUMN shipped_at TIMESTAMPTZ;
+
+-- On a table with 100M rows and active queries, this can take
+-- minutes to acquire the lock, during which new queries queue up
+```
+
+**2. Safe vs Unsafe Operations**
+
+Safe (no rewrite, brief lock):
+
+- `ADD COLUMN` with no default (PostgreSQL 11+ with volatile default is also safe)
+- `DROP COLUMN` (marks column as dropped, no rewrite)
+- `CREATE INDEX CONCURRENTLY` (does not block writes)
+- `ADD CONSTRAINT ... NOT VALID` (skips existing row validation)
+
+Unsafe (full table rewrite or long lock):
+
+- `ALTER COLUMN TYPE` (rewrites every row)
+- `ADD COLUMN ... DEFAULT <value>` (pre-PostgreSQL 11)
+- `CREATE INDEX` without `CONCURRENTLY`
+- `ADD CONSTRAINT` without `NOT VALID`
+
+**3. Lock Timeout Strategy**
+
+Set a short lock timeout so DDL fails fast instead of queueing:
+
+```sql
+SET lock_timeout = '3s';
+ALTER TABLE orders ADD COLUMN shipped_at TIMESTAMPTZ;
+-- If the lock is not acquired within 3 seconds, the statement
+-- fails instead of creating a cascading queue
+-- Retry during a quieter moment
+```
+
+**4. Concurrent Index Creation**
+
+```sql
+-- WRONG: blocks all writes until index is built
+CREATE INDEX idx_orders_customer ON orders (customer_id);
+
+-- RIGHT: builds index without blocking writes
+CREATE INDEX CONCURRENTLY idx_orders_customer ON orders (customer_id);
+-- Takes longer but allows normal operations to continue
+-- IMPORTANT: if this fails, it leaves an INVALID index that must be dropped
+```
+
+**5. pg_repack**
+
+Rebuilds tables online without holding `ACCESS EXCLUSIVE` for the duration. Uses triggers to capture changes during the rebuild.
+
+```bash
+# Rebuild a table to reclaim bloat without downtime
+pg_repack --no-superuser-check -t orders mydb
+
+# Rebuild and reorder by a specific column for better locality
+pg_repack --no-superuser-check -t orders -o created_at mydb
+```
+
+### Worked Example
+
+Scenario: add a `NOT NULL` column with a default to a 50M-row orders table.
+
+```sql
+-- Step 1: Add the column as nullable (instant, no rewrite)
+SET lock_timeout = '3s';
+ALTER TABLE orders ADD COLUMN priority INT;
+
+-- Step 2: Set the default for new rows
+ALTER TABLE orders ALTER COLUMN priority SET DEFAULT 0;
+
+-- Step 3: Backfill existing rows in batches
+DO $$
+DECLARE
+  batch_size INT := 10000;
+  max_id BIGINT;
+  current_id BIGINT := 0;
+BEGIN
+  SELECT MAX(id) INTO max_id FROM orders;
+  WHILE current_id < max_id LOOP
+    UPDATE orders
+    SET priority = 0
+    WHERE id > current_id AND id <= current_id + batch_size
+      AND priority IS NULL;
+    current_id := current_id + batch_size;
+    COMMIT;
+  END LOOP;
+END $$;
+
+-- Step 4: Add NOT NULL constraint without validating existing rows
+ALTER TABLE orders ADD CONSTRAINT orders_priority_not_null
+  CHECK (priority IS NOT NULL) NOT VALID;
+
+-- Step 5: Validate the constraint (does not hold ACCESS EXCLUSIVE)
+ALTER TABLE orders VALIDATE CONSTRAINT orders_priority_not_null;
+```
+
+This approach completes each step in seconds of lock time, regardless of table size.
+
+### Anti-Patterns
+
+1. **Running `ALTER COLUMN TYPE` directly on large tables.** This rewrites every row while holding an `ACCESS EXCLUSIVE` lock. Instead, use the expand-contract pattern: add a new column, backfill, swap in application code, drop old column.
+
+2. **Forgetting `lock_timeout` on DDL statements.** Without a timeout, a DDL statement can wait indefinitely for a lock while queueing all subsequent queries. Always set `lock_timeout` before DDL.
+
+3. **Leaving invalid indexes after failed `CREATE INDEX CONCURRENTLY`.** A failed concurrent index creation leaves an INVALID index. It consumes space and slows writes. Check with `SELECT * FROM pg_indexes WHERE indexdef LIKE '%INVALID%'` and drop invalid indexes.
+
+4. **Backfilling millions of rows in a single transaction.** This holds locks on all modified rows and generates massive WAL. Batch the backfill into chunks of 1,000-10,000 rows with commits between batches.
+
+5. **Using `NOT NULL` constraint directly via `ALTER COLUMN SET NOT NULL`.** On PostgreSQL versions before 12, this scans the entire table. Use a `CHECK` constraint with `NOT VALID` plus `VALIDATE CONSTRAINT` instead.
+
+### PostgreSQL Specifics
+
+- PostgreSQL 11+: `ADD COLUMN ... DEFAULT <value>` no longer rewrites the table for most types. The default is stored in the catalog and applied on read.
+- PostgreSQL 12+: `ALTER COLUMN SET NOT NULL` can use an existing valid `CHECK (col IS NOT NULL)` constraint to skip the table scan.
+- `pg_stat_progress_create_index` shows progress of `CREATE INDEX CONCURRENTLY`.
+- `pg_repack` requires the `pg_repack` extension and briefly acquires `ACCESS EXCLUSIVE` at the start and end of a rebuild.
+
+## Details
+
+### Advanced Topics
+
+**gh-ost for MySQL:** GitHub's online schema change tool avoids MySQL's trigger-based limitations. It creates a shadow table, copies data via binlog streaming, and swaps atomically. Key flags:
+
+```bash
+gh-ost --alter "ADD COLUMN shipped_at DATETIME" \
+  --database mydb --table orders \
+  --host replica.db --allow-on-master \
+  --chunk-size 1000 --max-load Threads_running=25 \
+  --execute
+```
+
+**pt-online-schema-change:** Percona's tool uses triggers to capture changes during the copy. Simpler than gh-ost but adds trigger overhead. Choose gh-ost for high-write tables, pt-osc for simpler setups.
+
+**Statement Timeout as Safety Net:**
+
+```sql
+SET statement_timeout = '30s';
+-- Any migration step that takes longer than 30s is killed
+-- Prevents runaway operations from monopolizing the database
+```
+
+### Engine Differences
+
+PostgreSQL provides transactional DDL -- `ALTER TABLE` inside a transaction can be rolled back. MySQL commits DDL implicitly; there is no rollback. This makes PostgreSQL significantly safer for multi-step schema changes, as a failed step does not leave the schema in an inconsistent state.
+
+MySQL's `ALGORITHM=INPLACE` and `ALGORITHM=INSTANT` hint at the DDL strategy. `INSTANT` operations (available in MySQL 8.0+) are similar to PostgreSQL 11+ catalog-only changes. However, MySQL `INSTANT` is limited to adding columns at the end of the table.
+
+### Real-World Case Studies
+
+A SaaS platform needed to add a `tenant_id` column to a 200M-row events table. Direct `ALTER TABLE` estimated 45 minutes of downtime. The team used the zero-downtime approach: added the nullable column (instant), set a default for new rows, backfilled in 10K-row batches over 4 hours during off-peak, then added a `NOT VALID` check constraint and validated it. Total lock time: under 10 seconds cumulative. The application served traffic throughout the entire migration.
+
+## Source
+
+- [PostgreSQL ALTER TABLE](https://www.postgresql.org/docs/current/sql-altertable.html)
+- [pg_repack](https://reorg.github.io/pg_repack/)
+- [gh-ost](https://github.com/github/gh-ost)
+- Sadalage, P. & Fowler, M. "Refactoring Databases" (2006)
+
+## Process
+
+1. Classify the DDL operation as safe or unsafe using the lock reference above.
+2. Set `lock_timeout` before every DDL statement; fail fast if the lock is not available.
+3. For unsafe operations, decompose into safe steps: add column, backfill in batches, add constraint with `NOT VALID`, validate.
+4. Monitor with `pg_stat_activity` and `pg_locks` during each migration step.
+
+## Harness Integration
+
+- **Type:** knowledge -- this skill is a reference document, not a procedural workflow.
+- **No tools or state** -- consumed as context by other skills and agents.
+- **related_skills:** db-expand-contract, db-migration-rollback, db-acid-properties, db-pessimistic-locking, db-deadlock-prevention
+
+## Success Criteria
+
+- Every DDL statement is preceded by `SET lock_timeout` to fail fast instead of queueing.
+- Unsafe operations (type changes, adding constraints) are decomposed into safe steps using the expand-contract pattern.
+- Indexes are created with `CONCURRENTLY` to avoid blocking writes.
+- Data backfills run in batches with commits between batches, not in a single transaction.

package/dist/agents/skills/claude-code/db-zero-downtime-migration/skill.yaml

@@ -0,0 +1,42 @@
+name: db-zero-downtime-migration
+version: '1.0.0'
+description: Online schema changes without downtime -- avoiding locks, pg_repack, and gh-ost patterns
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - db-expand-contract
+  - db-migration-rollback
+  - db-acid-properties
+  - db-pessimistic-locking
+  - db-deadlock-prevention
+stack_signals:
+  - postgresql
+  - mysql
+  - database
+keywords:
+  - zero-downtime
+  - online-schema-change
+  - pg_repack
+  - gh-ost
+  - DDL
+  - ACCESS-EXCLUSIVE
+  - concurrent-index
+  - migrations
+metadata:
+  author: community
+  upstream: postgresql.org/docs/current/sql-altertable.html
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/design-affordances/skill.yaml

@@ -1,6 +1,7 @@
 name: design-affordances
 version: "1.0.0"
 description: Perceived actionability — signifiers, constraints, mappings (Don Norman), flat design's affordance problem, touch targets, hover states as affordance
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-alignment/skill.yaml

@@ -1,6 +1,7 @@
 name: design-alignment
 version: "1.0.0"
 description: Visual order — edge, center, optical vs. mathematical alignment, alignment as invisible structure
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-apple-hig/skill.yaml

@@ -1,6 +1,7 @@
 name: design-apple-hig
 version: '1.0.0'
 description: Apple Human Interface Guidelines covering clarity/deference/depth, vibrancy and materials, SF Symbols, semantic colors, safe areas, and platform-specific navigation
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-atomic-design/skill.yaml

@@ -1,6 +1,7 @@
 name: design-atomic-design
 version: '1.0.0'
 description: Composition methodology for building design systems using atoms, molecules, organisms, templates, and pages
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-brand-consistency/skill.yaml

@@ -1,6 +1,7 @@
 name: design-brand-consistency
 version: "1.0.0"
 description: Visual coherence — brand attributes to design decisions, voice to visual mapping, consistency vs monotony, brand flex zones, multi-platform coherence
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-color-accessibility/skill.yaml

@@ -1,6 +1,7 @@
 name: design-color-accessibility
 version: "1.0.0"
 description: Color independence — conveying information without color alone, colorblind-safe palettes, perceptual uniformity
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-color-harmony/skill.yaml

@@ -1,6 +1,7 @@
 name: design-color-harmony
 version: "1.0.0"
 description: Color wheel relationships — complementary, analogous, triadic, split-complementary, tetradic schemes
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-color-psychology/skill.yaml

@@ -1,6 +1,7 @@
 name: design-color-psychology
 version: "1.0.0"
 description: Emotional and cultural color associations — warmth/coolness, trust, urgency, industry conventions
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-component-anatomy/skill.yaml

@@ -1,6 +1,7 @@
 name: design-component-anatomy
 version: '1.0.0'
 description: Anatomy of reusable components covering slots, variants, states, sizes, composition patterns, and compound components
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-consistency/skill.yaml

@@ -1,6 +1,7 @@
 name: design-consistency
 version: "1.0.0"
 description: Internal vs. external consistency — consistent patterns within a product, platform convention adherence, and when to break consistency deliberately
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-content-density/skill.yaml

@@ -1,6 +1,7 @@
 name: design-content-density
 version: "1.0.0"
 description: Information density tradeoffs — compact vs. comfortable vs. spacious, data-dense vs. marketing
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-contrast-ratio/skill.yaml

@@ -1,6 +1,7 @@
 name: design-contrast-ratio
 version: "1.0.0"
 description: Luminance contrast for readability and visual weight — WCAG ratios, contrast as hierarchy tool
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-dark-mode-color/skill.yaml

@@ -1,6 +1,7 @@
 name: design-dark-mode-color
 version: "1.0.0"
 description: Color adaptation for dark themes — inverted hierarchy, reduced saturation, elevation through lightness
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-data-viz-design/skill.yaml

@@ -1,6 +1,7 @@
 name: design-data-viz-design
 version: "1.0.0"
 description: Data visualization principles — chart selection, color encoding, annotation, Tufte's data-ink ratio, accessible charts, avoiding chartjunk, small multiples
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-design-audit/skill.yaml

@@ -1,6 +1,7 @@
 name: design-design-audit
 version: "1.0.0"
 description: Evaluating existing design — heuristic evaluation, consistency inventory, accessibility audit, competitive analysis, identifying design debt
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3

package/dist/agents/skills/claude-code/design-design-critique/skill.yaml

@@ -1,6 +1,7 @@
 name: design-design-critique
 version: "1.0.0"
 description: Structured feedback — critique frameworks (like/wish/wonder, what/why/improve), separating subjective preference from objective assessment
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3