@harness-engineering/cli 1.24.0 → 1.24.1

package/dist/agents/skills/codex/owasp-injection-prevention/skill.yaml

@@ -1,6 +1,7 @@
 name: owasp-injection-prevention
 version: "1.0.0"
 description: Prevent SQL, NoSQL, and command injection via parameterized queries and input validation
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3
@@ -23,6 +24,9 @@ related_skills:
   - nestjs-guards-pattern
   - node-crypto-patterns
   - ts-type-guards
+  - security-injection-families
+  - security-deserialization-attacks
+  - security-memory-safety
 stack_signals:
   - nodejs
   - typescript

package/dist/agents/skills/codex/owasp-logging-monitoring/skill.yaml

@@ -1,6 +1,7 @@
 name: owasp-logging-monitoring
 version: '1.0.0'
 description: Implement security logging and monitoring to detect and respond to threats
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3
@@ -20,6 +21,10 @@ paths:
 related_skills:
   - owasp-auth-patterns
   - owasp-rate-limiting
+  - security-audit-log-design
+  - security-log-correlation
+  - security-compliance-logging
+  - security-incident-containment
 stack_signals:
   - nodejs
   - typescript

package/dist/agents/skills/codex/owasp-rate-limiting/SKILL.md

@@ -208,6 +208,7 @@ https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.htm
 
 - **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:** owasp-auth-patterns, owasp-logging-monitoring, security-zero-trust-principles, security-threat-modeling-stride, api-rate-limiting, api-rate-limit-headers
 
 ## Success Criteria
 

package/dist/agents/skills/codex/owasp-rate-limiting/skill.yaml

@@ -1,6 +1,7 @@
 name: owasp-rate-limiting
 version: '1.0.0'
 description: Protect APIs with rate limiting, throttling, and abuse prevention strategies
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3
@@ -19,6 +20,10 @@ paths:
 related_skills:
   - owasp-auth-patterns
   - owasp-logging-monitoring
+  - security-zero-trust-principles
+  - security-threat-modeling-stride
+  - api-rate-limiting
+  - api-rate-limit-headers
 stack_signals:
   - nodejs
   - typescript

package/dist/agents/skills/codex/owasp-secrets-management/SKILL.md

@@ -17,7 +17,7 @@
 ```typescript
 // BAD — will end up in version control
 const db = new Client({ password: 'super_secret_password' });
-const stripe = new Stripe('sk_live_abc123xyz');
+const stripe = new Stripe('sk_example_abc123xyz');
 
 // GOOD — always from environment
 const db = new Client({ password: process.env.DB_PASSWORD });
@@ -164,6 +164,7 @@ https://owasp.org/www-project-top-ten/
 
 - **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:** owasp-logging-monitoring, owasp-cryptography, nestjs-guards-pattern, security-secrets-lifecycle, security-vault-patterns, security-environment-variable-risks, api-api-keys
 
 ## Success Criteria
 

package/dist/agents/skills/codex/owasp-secrets-management/skill.yaml

@@ -1,6 +1,7 @@
 name: owasp-secrets-management
 version: "1.0.0"
 description: Manage secrets safely via env vars and secrets managers, never logging or hardcoding credentials
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3
@@ -22,6 +23,10 @@ related_skills:
   - owasp-logging-monitoring
   - owasp-cryptography
   - nestjs-guards-pattern
+  - security-secrets-lifecycle
+  - security-vault-patterns
+  - security-environment-variable-risks
+  - api-api-keys
 stack_signals:
   - nodejs
   - typescript

package/dist/agents/skills/codex/owasp-security-headers/skill.yaml

@@ -1,6 +1,7 @@
 name: owasp-security-headers
 version: '1.0.0'
 description: Configure HTTP security headers to protect against XSS, clickjacking, MIME sniffing, and data leaks
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3
@@ -19,6 +20,9 @@ paths:
 related_skills:
   - owasp-xss-prevention
   - owasp-csrf-protection
+  - security-hsts-preloading
+  - security-tls-fundamentals
+  - security-zero-trust-principles
 stack_signals:
   - nodejs
   - typescript

package/dist/agents/skills/codex/owasp-xss-prevention/skill.yaml

@@ -1,6 +1,7 @@
 name: owasp-xss-prevention
 version: "1.0.0"
 description: Prevent reflected, stored, and DOM-based XSS via CSP headers, output encoding, and input sanitization
+stability: static
 cognitive_mode: advisory-guide
 type: knowledge
 tier: 3
@@ -21,6 +22,8 @@ related_skills:
   - owasp-security-headers
   - owasp-csrf-protection
   - nestjs-guards-pattern
+  - security-injection-families
+  - security-threat-modeling-stride
 stack_signals:
   - nodejs
   - typescript

package/dist/agents/skills/codex/perf-browser-cache/SKILL.md

@@ -0,0 +1,151 @@
+# Browser Caching
+
+> Master HTTP browser caching — Cache-Control directives, ETag and Last-Modified validation, immutable assets with content-hashed filenames, stale-while-revalidate patterns, and cache partitioning in modern browsers for optimal repeat-visit performance.
+
+## When to Use
+
+- Repeat visitors experience slow page loads despite no content changes
+- Lighthouse flags "Serve static assets with an efficient cache policy"
+- DevTools Network panel shows 200 responses instead of 304 or (disk cache) for static assets
+- You need to decide between no-cache, no-store, and max-age for different content types
+- A deploy invalidates all cached assets unnecessarily (cache busting is too aggressive)
+- Content-hashed filenames are not implemented and versioned assets are served with short TTLs
+- Stale content is being served after deploys because cache invalidation is not working
+- You need to understand cache partitioning impact on shared CDN-hosted resources
+- API responses could benefit from conditional caching with ETags
+- Cache hit rates on repeat visits are below 90%
+
+## Instructions
+
+1. **Audit current caching behavior.** In Chrome DevTools Network panel, check the "Size" column. Values like "(disk cache)" or "(memory cache)" indicate cached resources. Look at response headers for Cache-Control directives. Resources without caching headers or with `no-store` are fetched fresh every time.
+
+2. **Design a caching strategy by content type.** Different content types need different caching policies:
+
+   ```
+   Static assets (JS, CSS, images) with content hash:
+     Cache-Control: public, max-age=31536000, immutable
+
+   HTML documents:
+     Cache-Control: no-cache
+     (or: Cache-Control: public, max-age=0, must-revalidate)
+
+   API responses (cacheable):
+     Cache-Control: private, max-age=60, stale-while-revalidate=300
+
+   User-specific data:
+     Cache-Control: private, no-cache
+
+   Sensitive data (banking, health):
+     Cache-Control: no-store
+   ```
+
+3. **Implement content-hashed filenames.** Content hashing ensures cached files are automatically invalidated when content changes:
+
+   ```
+   # Build output with content hash
+   app.a1b2c3d4.js     ← hash changes when code changes
+   style.e5f6g7h8.css  ← hash changes when styles change
+   vendor.i9j0k1l2.js  ← hash rarely changes (stable dependencies)
+
+   # Cache-Control for hashed files
+   Cache-Control: public, max-age=31536000, immutable
+   # 1 year TTL + immutable = browser never revalidates
+   ```
+
+   The HTML document (not content-hashed) references specific hashed filenames. When you deploy, the HTML changes to reference new hashes, and the browser fetches the new files.
+
+4. **Configure ETag validation for dynamic content.** ETags allow the browser to check if content has changed without re-downloading:
+
+   ```
+   # First request
+   GET /api/products
+   → 200 OK
+   → ETag: "abc123"
+   → Cache-Control: no-cache
+
+   # Subsequent request (browser sends conditional request)
+   GET /api/products
+   If-None-Match: "abc123"
+   → 304 Not Modified  (no body, saves bandwidth)
+   ```
+
+5. **Use stale-while-revalidate for balanced freshness.** This directive serves the cached version immediately while fetching a fresh copy in the background:
+
+   ```
+   Cache-Control: public, max-age=3600, stale-while-revalidate=86400
+
+   Timeline:
+   0-1h:    Serve from cache (fresh)
+   1h-25h:  Serve from cache (stale) + revalidate in background
+   >25h:    Must revalidate before serving (cache expired)
+   ```
+
+6. **Understand browser cache layers.** Browsers maintain multiple cache tiers:
+   - **Memory cache** — fastest, cleared on tab close, used for preloaded resources and recently accessed items
+   - **Disk cache** — persists across sessions, used for most HTTP-cached resources
+   - **Service Worker cache** — application-controlled via Cache API
+   - **Push cache** — HTTP/2 push cache, cleared after connection closes
+
+7. **Account for cache partitioning.** Modern browsers (Chrome 86+, Firefox 85+) partition the HTTP cache by top-level site. A resource cached when visiting `site-a.com` is NOT reused when visiting `site-b.com`, even if the URL is identical. This impacts shared CDN-hosted resources (Google Fonts, cdnjs, unpkg) — self-hosting eliminates the cross-site cache miss.
+
+## Details
+
+### Cache-Control Directive Reference
+
+| Directive                  | Meaning                                                    |
+| -------------------------- | ---------------------------------------------------------- |
+| `public`                   | Any cache (browser, CDN, proxy) may store this response    |
+| `private`                  | Only the end-user browser may cache (not CDN or proxy)     |
+| `max-age=N`                | Cache is fresh for N seconds from response time            |
+| `s-maxage=N`               | CDN/proxy TTL (overrides max-age for shared caches)        |
+| `no-cache`                 | Cache the response but revalidate before every use         |
+| `no-store`                 | Do not cache at all — not in memory, not on disk           |
+| `must-revalidate`          | After max-age expires, MUST revalidate (no stale serving)  |
+| `immutable`                | Content will never change — skip revalidation entirely     |
+| `stale-while-revalidate=N` | Serve stale for N seconds while revalidating in background |
+| `stale-if-error=N`         | Serve stale for N seconds if origin returns an error       |
+
+### Worked Example: Twitter Static Asset Caching
+
+Twitter serves static assets with `Cache-Control: public, max-age=31536000, immutable` using content-hashed filenames (e.g., `main.a1b2c3d4.js`). This eliminates all revalidation requests on repeat visits — the browser serves directly from disk cache without any network activity. On deploy, the HTML document (cached with `no-cache`) references new hashed filenames, triggering fresh downloads only for changed assets. Unchanged assets (vendor libraries, shared components) remain cached. This approach achieves >99% cache hit rate for static assets on repeat visits.
+
+### Worked Example: Financial Times Stale-While-Revalidate
+
+The Financial Times implemented `stale-while-revalidate` with a 1-hour fresh window and 24-hour stale window for their article pages. Result: 95% of page views are served instantly from cache (either fresh or stale), with background revalidation keeping content within 1 hour of the latest version. For breaking news, they supplement with explicit cache purging via the CDN API. This approach reduced perceived page load time by 70% on repeat visits compared to their previous `no-cache` policy.
+
+### Anti-Patterns
+
+**Using no-cache when you mean no-store.** `no-cache` DOES cache the response — it just requires revalidation before each use (a conditional request). `no-store` prevents caching entirely. For truly sensitive data (banking details, health records), use `no-store`. For HTML that should always be fresh, use `no-cache` (allows 304 responses).
+
+**Setting short max-age on versioned assets.** If filenames contain content hashes, the content at that URL will never change. Setting `max-age=3600` on `app.a1b2c3.js` forces unnecessary revalidation every hour. Use `max-age=31536000, immutable` instead.
+
+**Forgetting Vary header with content negotiation.** If your server returns different content based on `Accept-Encoding` or `Accept-Language`, the `Vary` header must list those headers. Without it, a cache may serve a gzip-compressed response to a client that sent `Accept-Encoding: br`.
+
+**Query string cache busting instead of filename hashing.** URLs like `/app.js?v=123` rely on all caches respecting query parameters. Some CDNs strip or ignore query strings by default. Content-hashed filenames (`/app.abc123.js`) are universally reliable.
+
+## Source
+
+- MDN Web Docs: HTTP Caching — https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
+- RFC 9111: HTTP Caching — https://www.rfc-editor.org/rfc/rfc9111
+- web.dev: HTTP Cache — https://web.dev/articles/http-cache
+- Chrome Cache Partitioning — https://developer.chrome.com/blog/http-cache-partitioning/
+- Jake Archibald: "Caching best practices" — https://jakearchibald.com/2016/caching-best-practices/
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## 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.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.
+- Static assets with content hashes use `max-age=31536000, immutable` caching.
+- HTML documents use `no-cache` or equivalent to ensure fresh content on navigation.
+- Repeat visit network activity shows (disk cache) for static assets instead of 200 responses.

package/dist/agents/skills/codex/perf-browser-cache/skill.yaml

@@ -0,0 +1,39 @@
+name: perf-browser-cache
+version: '1.0.0'
+description: Browser caching — Cache-Control directives, ETag validation, immutable assets, stale-while-revalidate, and cache partitioning
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - perf-cdn-cache-control
+  - perf-cache-invalidation
+  - perf-service-worker-caching
+  - perf-cdn-strategies
+  - perf-compression
+stack_signals: []
+keywords:
+  - cache-control
+  - etag
+  - immutable
+  - stale-while-revalidate
+  - max-age
+  - browser cache
+  - cache partitioning
+  - conditional request
+  - 304 not modified
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/perf-bundle-analysis/SKILL.md

@@ -0,0 +1,217 @@
+# Bundle Analysis
+
+> Master bundle analysis techniques — visualization tools for chunk composition, size budget enforcement in CI, dependency cost evaluation, source map exploration, and continuous size tracking to prevent bundle bloat.
+
+## When to Use
+
+- Bundle size has grown and you need to identify the largest contributors
+- A new dependency was added and you need to assess its impact on bundle size
+- CI should fail when bundle size exceeds a defined budget
+- You need to compare bundle size between branches or releases
+- Lighthouse flags "Reduce unused JavaScript" but you do not know which modules to target
+- A production build takes unexpectedly long and you suspect large dependencies
+- Tree shaking is configured but you need to verify it is eliminating dead code
+- Evaluating whether to add a library or implement the functionality from scratch
+- Multiple chunks share duplicated code that should be in a common chunk
+- The team needs visibility into bundle size trends over time
+
+## Instructions
+
+1. **Generate a bundle visualization.** Use webpack-bundle-analyzer or vite-bundle-visualizer to see the treemap of every chunk and module:
+
+   ```bash
+   # Webpack
+   npx webpack-bundle-analyzer dist/stats.json
+
+   # Generate stats.json first if not present:
+   npx webpack --profile --json > dist/stats.json
+
+   # Vite
+   npx vite-bundle-visualizer
+
+   # Next.js
+   ANALYZE=true npx next build
+   # Requires: npm install @next/bundle-analyzer
+   ```
+
+   ```javascript
+   // next.config.js — integrate bundle analyzer
+   const withBundleAnalyzer = require('@next/bundle-analyzer')({
+     enabled: process.env.ANALYZE === 'true',
+   });
+   module.exports = withBundleAnalyzer({
+     /* next config */
+   });
+   ```
+
+2. **Explore bundle composition with source map explorer.** Source-map-explorer uses source maps to show exact byte-for-byte attribution:
+
+   ```bash
+   npx source-map-explorer dist/main.*.js
+   npx source-map-explorer dist/main.*.js --html result.html
+   npx source-map-explorer dist/*.js --tsv sizes.tsv  # machine-readable
+   ```
+
+3. **Evaluate dependency cost before installing.** Check the size impact of any npm package before adding it:
+
+   ```bash
+   # bundlephobia.com — check gzipped and minified size
+   # https://bundlephobia.com/package/date-fns@3.0.0
+
+   # package-size CLI — measure actual bundled size
+   npx package-size lodash-es/debounce
+   npx package-size date-fns/format date-fns/parseISO
+
+   # import-cost VS Code extension — inline size display next to imports
+   ```
+
+4. **Configure size budgets with size-limit.** Enforce maximum bundle sizes in CI:
+
+   ```json
+   // package.json
+   {
+     "size-limit": [
+       {
+         "name": "Entry point",
+         "path": "dist/index.js",
+         "limit": "50 KB",
+         "gzip": true
+       },
+       {
+         "name": "Full bundle",
+         "path": "dist/**/*.js",
+         "limit": "200 KB",
+         "gzip": true
+       },
+       {
+         "name": "CSS",
+         "path": "dist/**/*.css",
+         "limit": "30 KB",
+         "gzip": true
+       }
+     ],
+     "scripts": {
+       "size": "size-limit",
+       "size:check": "size-limit --why"
+     }
+   }
+   ```
+
+   ```yaml
+   # GitHub Actions CI integration
+   - name: Check bundle size
+     uses: andresz1/size-limit-action@v1
+     with:
+       github_token: ${{ secrets.GITHUB_TOKEN }}
+       skip_step: build
+       directory: dist
+   ```
+
+5. **Use webpack performance hints for build-time enforcement.**
+
+   ```javascript
+   // webpack.config.js
+   module.exports = {
+     performance: {
+       maxEntrypointSize: 250000, // 250KB
+       maxAssetSize: 200000, // 200KB per file
+       hints: process.env.NODE_ENV === 'production' ? 'error' : 'warning',
+       assetFilter: (filename) => {
+         return filename.endsWith('.js') || filename.endsWith('.css');
+       },
+     },
+   };
+   ```
+
+6. **Identify and eliminate duplicate dependencies.** Check for multiple versions of the same package bundled together:
+
+   ```bash
+   # webpack — duplicate package checker
+   npx duplicate-package-checker-webpack-plugin
+
+   # npm — list duplicates
+   npm ls --all | grep -E "deduped|invalid"
+
+   # pnpm — dedupe
+   pnpm dedupe
+
+   # yarn — dedupe
+   yarn dedupe
+   ```
+
+7. **Track bundle size over time.** Integrate size tracking into the PR workflow so every change shows its size impact:
+
+   ```bash
+   # bundlewatch — CI size tracking with GitHub status checks
+   npx bundlewatch --config .bundlewatch.config.js
+   ```
+
+   ```javascript
+   // .bundlewatch.config.js
+   module.exports = {
+     files: [
+       { path: 'dist/main.*.js', maxSize: '150KB' },
+       { path: 'dist/vendor.*.js', maxSize: '100KB' },
+       { path: 'dist/*.css', maxSize: '30KB' },
+     ],
+     ci: {
+       trackBranches: ['main'],
+       repoBranchBase: 'main',
+     },
+   };
+   ```
+
+## Details
+
+### Understanding Treemap Visualizations
+
+Bundle analyzer treemaps show nested rectangles where area is proportional to file size. The outer rectangles represent chunks (main, vendor, route-specific). Inner rectangles represent modules. Colors typically distinguish between application code and node_modules. When analyzing, look for: (1) unexpectedly large modules that suggest missing tree shaking, (2) duplicate modules appearing in multiple chunks, (3) node_modules that dominate the treemap relative to application code.
+
+### Gzipped vs Parsed vs Raw Size
+
+Bundle tools report three size metrics. **Raw size** is the uncompressed file on disk. **Parsed size** is the JavaScript the browser must parse and compile (after decompression, before execution). **Gzipped size** (or Brotli size) is the transfer size over the network. Parsed size most directly correlates with CPU cost (parsing/compilation). Gzipped size correlates with network transfer time. Budget both: a 500KB parsed file might compress to 100KB gzipped (fast download) but still take 200ms to parse on mobile.
+
+### Worked Example: Walmart Bundle Audit
+
+Walmart's web team used webpack-bundle-analyzer to discover that their checkout page bundled the full moment.js library (67KB gzipped) for a single date formatting call. Replacing it with a 2-line Intl.DateTimeFormat call eliminated the dependency entirely. They also found three different versions of lodash in the bundle (lodash, lodash-es, and lodash.merge). Deduplicating to lodash-es with direct function imports reduced the combined lodash footprint from 72KB to 8KB gzipped. Total savings: 129KB gzipped, reducing checkout TTI by 1.1 seconds on 3G.
+
+### Worked Example: Notion Size Budget Enforcement
+
+Notion enforces strict per-route bundle budgets in CI. Every PR shows a size comparison table in the GitHub check. If any route exceeds its budget, the PR is blocked. When a developer adds a new dependency, the CI check surfaces the exact byte increase and which route is affected. This prevents the gradual size creep that makes individual additions seem harmless while the cumulative effect degrades performance. Their main route budget is 180KB gzipped, and they have maintained it within 5% for two years.
+
+### Anti-Patterns
+
+**Analyzing only total bundle size.** A total size that stays constant can mask problems: one chunk grows while another shrinks. Always analyze per-chunk and per-route sizes.
+
+**Ignoring parsed/compile size.** A highly compressible library might be small over the wire but enormous to parse. Source maps and JSON blobs compress well but still impose parse cost. Budget parsed size independently.
+
+**Running analysis only in development mode.** Development builds include hot module replacement, React DevTools integration, and verbose error messages. Always analyze production builds.
+
+**Setting budgets too loose.** A 1MB budget never triggers. Start with the current size plus 10% headroom, then ratchet down. Effective budgets are ones that occasionally fail, prompting investigation.
+
+## Source
+
+- webpack-bundle-analyzer — https://github.com/webpack-contrib/webpack-bundle-analyzer
+- source-map-explorer — https://github.com/danvk/source-map-explorer
+- size-limit — https://github.com/ai/size-limit
+- Bundlephobia — https://bundlephobia.com/
+- bundlewatch — https://bundlewatch.io/
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## 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.
+
+## Success Criteria
+
+- Bundle visualization is generated and reviewed for unexpected large modules.
+- Size budgets are configured in CI and enforce per-chunk and per-route limits.
+- No duplicate dependencies exist in the production bundle.
+- New dependency additions include a size impact assessment.
+- Bundle size trends are tracked over time with visibility in PRs.

package/dist/agents/skills/codex/perf-bundle-analysis/skill.yaml

@@ -0,0 +1,37 @@
+name: perf-bundle-analysis
+version: '1.0.0'
+description: Bundle analysis — Bundle visualization, size budgets, dependency cost analysis, and CI-integrated size tracking
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - perf-code-splitting
+  - perf-tree-shaking
+  - perf-lazy-loading
+  - perf-compression
+stack_signals: []
+keywords:
+  - bundle analysis
+  - bundle size
+  - webpack-bundle-analyzer
+  - size budget
+  - dependency cost
+  - bundlephobia
+  - source map explorer
+  - size limit
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []