@harness-engineering/cli 1.23.2 → 1.24.1

package/dist/agents/skills/claude-code/angular-standalone-components/skill.yaml

@@ -0,0 +1,45 @@
+name: angular-standalone-components
+version: '1.0.0'
+description: Build module-free Angular apps with standalone components, bootstrapApplication, and lazy routes
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - angular.json
+  - '**/*.component.ts'
+  - '**/*.component.html'
+  - '**/*.service.ts'
+  - '**/*.module.ts'
+related_skills:
+  - angular-component-pattern
+  - angular-routing-guards
+  - angular-lazy-loading
+  - angular-service-di
+stack_signals:
+  - angular
+  - typescript
+  - rxjs
+keywords:
+  - standalone
+  - bootstrapApplication
+  - imports-array
+  - lazy-routes
+  - NgModule-free
+  - provideRouter
+  - provideHttpClient
+metadata:
+  author: angular.dev
+  upstream: 'angular.dev/guide/components/importing'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/angular-state-management/SKILL.md

@@ -0,0 +1,150 @@
+# Angular State Management
+
+> Manage application state with NgRx Store (Redux pattern) or NgRx SignalStore for signal-based state — choose the right tool for the complexity level
+
+## When to Use
+
+- Sharing state across many components that are not in a direct parent-child relationship
+- Tracking complex state transitions that need to be logged, replayed, or time-traveled (NgRx DevTools)
+- Managing server-state with optimistic updates, loading/error states, and caching (NgRx Entity)
+- Building a feature with local, self-contained state that doesn't need global visibility (SignalStore)
+- Replacing ad-hoc `BehaviorSubject` chains that have grown hard to maintain
+
+## Instructions
+
+### NgRx Store (global state)
+
+1. Define actions with `createAction` and `props<{}>()` — one action per user intent or server event. Namespace with `[Feature] EventName` convention.
+2. Write pure reducers with `createReducer` and `on()`. Reducers must be pure functions — no side effects, no mutation.
+3. Use `createSelector` for memoized state projections. Selectors compose and cache; never derive state in component templates.
+4. Write effects with `createEffect` to handle side effects (HTTP, routing, localStorage). Effects listen to actions and dispatch new actions on success/failure.
+5. Use `createEntityAdapter` from `@ngrx/entity` for normalized collections (list of records by ID). It generates standard CRUD reducers and selectors.
+6. Connect components with `store.dispatch(action)` and `store.select(selector)`. Pipe the selector observable through the `async` pipe or convert with `toSignal()`.
+
+```typescript
+// counter.actions.ts
+import { createAction, props } from '@ngrx/store';
+export const increment = createAction('[Counter] Increment');
+export const decrement = createAction('[Counter] Decrement');
+export const reset = createAction('[Counter] Reset', props<{ value: number }>());
+```
+
+```typescript
+// counter.reducer.ts
+import { createReducer, on } from '@ngrx/store';
+import { increment, decrement, reset } from './counter.actions';
+
+export interface CounterState {
+  count: number;
+}
+const initialState: CounterState = { count: 0 };
+
+export const counterReducer = createReducer(
+  initialState,
+  on(increment, (state) => ({ ...state, count: state.count + 1 })),
+  on(decrement, (state) => ({ ...state, count: state.count - 1 })),
+  on(reset, (state, { value }) => ({ ...state, count: value }))
+);
+```
+
+```typescript
+// counter.selectors.ts
+import { createFeatureSelector, createSelector } from '@ngrx/store';
+import { CounterState } from './counter.reducer';
+
+const selectCounterState = createFeatureSelector<CounterState>('counter');
+export const selectCount = createSelector(selectCounterState, (s) => s.count);
+export const selectIsZero = createSelector(selectCount, (count) => count === 0);
+```
+
+```typescript
+// products.effects.ts
+import { inject } from '@angular/core';
+import { Actions, createEffect, ofType } from '@ngrx/effects';
+import { switchMap, map, catchError, of } from 'rxjs';
+import * as ProductActions from './product.actions';
+import { ProductService } from './product.service';
+
+export const loadProducts = createEffect(
+  (actions$ = inject(Actions), productService = inject(ProductService)) =>
+    actions$.pipe(
+      ofType(ProductActions.loadProducts),
+      switchMap(() =>
+        productService.getAll().pipe(
+          map((products) => ProductActions.loadProductsSuccess({ products })),
+          catchError((error) => of(ProductActions.loadProductsFailure({ error: error.message })))
+        )
+      )
+    ),
+  { functional: true }
+);
+```
+
+### NgRx SignalStore (local/feature state)
+
+```typescript
+import { signalStore, withState, withComputed, withMethods } from '@ngrx/signals';
+import { computed } from '@angular/core';
+import { inject } from '@angular/core';
+
+type CartState = { items: CartItem[]; loading: boolean };
+
+export const CartStore = signalStore(
+  { providedIn: 'root' }, // or provide in component for local scope
+  withState<CartState>({ items: [], loading: false }),
+  withComputed(({ items }) => ({
+    totalItems: computed(() => items().length),
+    totalPrice: computed(() => items().reduce((s, i) => s + i.price, 0)),
+  })),
+  withMethods((store, productService = inject(ProductService)) => ({
+    addItem(item: CartItem) {
+      patchState(store, { items: [...store.items(), item] });
+    },
+    async loadCart() {
+      patchState(store, { loading: true });
+      const items = await productService.getCart().toPromise();
+      patchState(store, { items: items ?? [], loading: false });
+    },
+  }))
+);
+```
+
+## Details
+
+**When to use NgRx Store vs SignalStore vs Service:**
+
+| Scenario                                 | Recommended             |
+| ---------------------------------------- | ----------------------- |
+| Global shared state across many features | NgRx Store              |
+| Dev Tools, time travel, action logging   | NgRx Store              |
+| Feature-scoped state, self-contained     | SignalStore             |
+| Simple component-local state             | `signal()` in component |
+| Shared state, 2-3 components             | Service with signals    |
+
+**Entity adapter pattern:** `@ngrx/entity` normalizes a list of records into `{ ids: [], entities: {} }` for O(1) lookup by ID. It generates `addOne`, `addMany`, `updateOne`, `removeOne` adapter methods and `getAll`, `getEntities`, `selectById` selectors.
+
+**Selector memoization:** `createSelector` caches the last output. If the inputs haven't changed, the projector function is not called. This makes selectors safe to use in templates with `OnPush` change detection — the observable only emits when the derived value actually changes.
+
+**NgRx DevTools:** Install `@ngrx/store-devtools` and open Redux DevTools in Chrome to inspect action history, diff state, and replay actions. Invaluable for debugging complex state transitions.
+
+**Action hygiene:** One action per intent, not one action per state field. Actions should describe what happened (`[Cart] Item Added`) not what should change (`[Cart] Set Items`). This makes the action log human-readable.
+
+## Source
+
+https://ngrx.io/guide/store
+
+## 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.

package/dist/agents/skills/claude-code/angular-state-management/skill.yaml

@@ -0,0 +1,46 @@
+name: angular-state-management
+version: '1.0.0'
+description: Manage application state with NgRx Store, createAction/createReducer/createSelector, or signal stores
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - angular.json
+  - '**/*.component.ts'
+  - '**/*.component.html'
+  - '**/*.service.ts'
+  - '**/*.module.ts'
+related_skills:
+  - angular-signals-pattern
+  - angular-rxjs-patterns
+  - angular-service-di
+  - state-management
+stack_signals:
+  - angular
+  - typescript
+  - rxjs
+keywords:
+  - NgRx
+  - Store
+  - createAction
+  - createReducer
+  - createSelector
+  - createEffect
+  - signalStore
+  - state-management
+metadata:
+  author: angular.dev
+  upstream: 'angular.dev/guide/signals'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/angular-testing-patterns/SKILL.md

@@ -0,0 +1,180 @@
+# Angular Testing Patterns
+
+> Test Angular components, services, directives, and pipes with TestBed, ComponentFixture, fakeAsync, and service mocks
+
+## When to Use
+
+- Writing unit tests for Angular components with shallow or deep rendering
+- Mocking service dependencies in component and service tests
+- Testing asynchronous code (HTTP, timers, observables) with `fakeAsync` + `tick`
+- Using `spectator` to reduce `TestBed` boilerplate for component tests
+- Testing standalone components without NgModule ceremony
+
+## Instructions
+
+1. Use `TestBed.configureTestingModule({ imports: [MyStandaloneComponent] })` for standalone components — import, not declare.
+2. Mock services with `{ provide: MyService, useValue: mockService }` in the `providers` array. Define mocks as `jasmine.createSpyObj` (Jasmine) or `jest.fn()` (Jest) objects.
+3. Always call `fixture.detectChanges()` after setup and after state mutations to trigger change detection before asserting on the DOM.
+4. Use `fakeAsync` + `tick()` for timer-based code. Use `fakeAsync` + `flush()` for promise-based code. Use `fakeAsync` + `flushMicrotasks()` for microtasks.
+5. Query DOM elements with `fixture.debugElement.query(By.css('selector'))` or `fixture.nativeElement.querySelector()`. Prefer `By.css` — it returns a `DebugElement` with Angular context.
+6. Test outputs by subscribing to the `EventEmitter` or signal output directly: `component.myOutput.subscribe(spy)`.
+7. For HTTP services, use `HttpClientTestingModule` and `HttpTestingController` to verify requests and flush mock responses.
+8. Use the `spectator` library (`@ngneat/spectator`) to reduce boilerplate — it wraps `TestBed` and adds ergonomic query helpers.
+
+```typescript
+// product-card.component.spec.ts
+import { ComponentFixture, TestBed } from '@angular/core/testing';
+import { By } from '@angular/platform-browser';
+import { signal } from '@angular/core';
+import { ProductCardComponent } from './product-card.component';
+import { CartService } from '../cart.service';
+
+describe('ProductCardComponent', () => {
+  let component: ProductCardComponent;
+  let fixture: ComponentFixture<ProductCardComponent>;
+  let mockCartService: jasmine.SpyObj<CartService>;
+
+  beforeEach(async () => {
+    mockCartService = jasmine.createSpyObj('CartService', ['addItem']);
+
+    await TestBed.configureTestingModule({
+      imports: [ProductCardComponent], // standalone component
+      providers: [{ provide: CartService, useValue: mockCartService }],
+    }).compileComponents();
+
+    fixture = TestBed.createComponent(ProductCardComponent);
+    component = fixture.componentInstance;
+
+    // Set required signal input
+    fixture.componentRef.setInput('product', {
+      id: '1',
+      name: 'Widget',
+      price: 9.99,
+    });
+
+    fixture.detectChanges();
+  });
+
+  it('should display the product name', () => {
+    const heading = fixture.debugElement.query(By.css('h2'));
+    expect(heading.nativeElement.textContent).toBe('Widget');
+  });
+
+  it('should emit addToCart when button clicked', () => {
+    const addSpy = jasmine.createSpy();
+    component.addToCart.subscribe(addSpy);
+
+    fixture.debugElement.query(By.css('button')).nativeElement.click();
+    expect(addSpy).toHaveBeenCalledWith({ id: '1', name: 'Widget', price: 9.99 });
+  });
+});
+```
+
+```typescript
+// product.service.spec.ts — HTTP service test
+import { TestBed } from '@angular/core/testing';
+import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
+import { ProductService } from './product.service';
+
+describe('ProductService', () => {
+  let service: ProductService;
+  let httpMock: HttpTestingController;
+
+  beforeEach(() => {
+    TestBed.configureTestingModule({
+      imports: [HttpClientTestingModule],
+      providers: [ProductService],
+    });
+    service = TestBed.inject(ProductService);
+    httpMock = TestBed.inject(HttpTestingController);
+  });
+
+  afterEach(() => httpMock.verify()); // assert no pending requests
+
+  it('should fetch products', () => {
+    const mockProducts = [{ id: '1', name: 'Widget', price: 9.99 }];
+    let result: Product[] | undefined;
+
+    service.getProducts().subscribe((p) => (result = p));
+
+    const req = httpMock.expectOne('/api/products');
+    expect(req.request.method).toBe('GET');
+    req.flush(mockProducts);
+
+    expect(result).toEqual(mockProducts);
+  });
+});
+```
+
+```typescript
+// async test with fakeAsync
+import { fakeAsync, tick } from '@angular/core/testing';
+
+it('should debounce search input', fakeAsync(() => {
+  component.searchControl.setValue('widget');
+  tick(300); // advance timer by 300ms (debounce time)
+  fixture.detectChanges();
+
+  expect(mockSearchService.search).toHaveBeenCalledWith('widget');
+}));
+```
+
+```typescript
+// spectator usage — reduces boilerplate significantly
+import { createComponentFactory, Spectator } from '@ngneat/spectator';
+
+describe('ProductCardComponent', () => {
+  let spectator: Spectator<ProductCardComponent>;
+  const createComponent = createComponentFactory({
+    component: ProductCardComponent,
+    mocks: [CartService],
+  });
+
+  beforeEach(() => {
+    spectator = createComponent({ props: { product: mockProduct } });
+  });
+
+  it('shows product name', () => {
+    expect(spectator.query('h2')).toHaveText('Widget');
+  });
+
+  it('calls addItem on click', () => {
+    spectator.click('button');
+    expect(spectator.inject(CartService).addItem).toHaveBeenCalled();
+  });
+});
+```
+
+## Details
+
+**Setting signal inputs in tests:** Signal inputs (`input()`) cannot be set directly via `component.myInput = value` because they are read-only signals. Use `fixture.componentRef.setInput('inputName', value)` instead — this is the supported API for setting signal inputs in tests.
+
+**`compileComponents()` requirement:** In tests that use `templateUrl` or `styleUrls`, call `await TestBed.configureTestingModule({...}).compileComponents()` to compile the external resources asynchronously. For inline templates, it is not strictly required but harmless.
+
+**Testing `OnPush` components:** `OnPush` components only update when inputs change, an async pipe resolves, or signals emit. In tests, `fixture.detectChanges()` triggers a change detection cycle. If you mutate state without changing a signal or input reference, the template won't update. Set signal values with `.set()` and call `fixture.detectChanges()` afterward.
+
+**Test isolation:** Each `TestBed.configureTestingModule` call in `beforeEach` creates a fresh Angular testing environment. Avoid sharing mutable state across tests — reset spies in `afterEach` if reused.
+
+**Avoiding real HTTP calls:** Always provide `HttpClientTestingModule` or mock the service. `HttpTestingController.verify()` in `afterEach` ensures no unexpected HTTP requests were made.
+
+**Signal stores in tests:** Provide a test version of the store or override state with `patchState` if the store is provided in the component.
+
+## Source
+
+https://angular.dev/guide/testing
+
+## 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.

package/dist/agents/skills/claude-code/angular-testing-patterns/skill.yaml

@@ -0,0 +1,46 @@
+name: angular-testing-patterns
+version: '1.0.0'
+description: Test Angular components, services, and pipes with TestBed, ComponentFixture, and service mocks
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - angular.json
+  - '**/*.component.ts'
+  - '**/*.component.html'
+  - '**/*.service.ts'
+  - '**/*.module.ts'
+related_skills:
+  - angular-component-pattern
+  - angular-service-di
+  - angular-signals-pattern
+  - test-unit-patterns
+stack_signals:
+  - angular
+  - typescript
+  - rxjs
+keywords:
+  - TestBed
+  - ComponentFixture
+  - jasmine
+  - jest
+  - service-mock
+  - spectator
+  - fakeAsync
+  - tick
+metadata:
+  author: angular.dev
+  upstream: 'angular.dev/guide/testing'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/api-api-keys/SKILL.md

@@ -0,0 +1,135 @@
+# API Keys
+
+> API KEY DESIGN IS A SECURITY CONTRACT — ENTROPY REQUIREMENTS PREVENT BRUTE FORCE, SCOPING LIMITS BLAST RADIUS, HASHED STORAGE PREVENTS DATABASE DUMPS FROM BECOMING CREDENTIAL LISTS, AND ROTATION STRATEGY DETERMINES HOW QUICKLY A COMPROMISED KEY CAN BE CONTAINED.
+
+## When to Use
+
+- Designing the API key subsystem for a new developer platform or API product
+- Auditing an existing key management implementation for security gaps
+- Deciding between query parameter and header transmission for a legacy API migration
+- Implementing key rotation for a service that currently uses long-lived static credentials
+- Setting policy on key scoping and permission granularity for a multi-tenant API
+- Responding to a security incident where an API key was exposed in a public repository
+- Writing the API key section of an API style guide or security design document
+
+## Instructions
+
+### Key Concepts
+
+1. **Entropy requirements** — A secure API key must contain at least 128 bits of cryptographic randomness, generating a key of at least 32 characters when base-62 encoded. Use a cryptographically secure random number generator (CSPRNG): `crypto.randomBytes(32)` in Node.js, `secrets.token_urlsafe(32)` in Python, or `SecureRandom` in Java. Dictionary words, sequential IDs, and UUIDs v4 have known entropy floors and predictable structure that makes offline attacks feasible. Prefix the key with a service identifier (`sk_test_`, `ghp_`, `stripe_`) to enable secret scanning tools (GitHub Advanced Security, truffleHog) to detect accidental exposure.
+
+2. **Key scoping and permissions** — Every key must be issued with an explicit permission scope, not as a global admin credential. Scopes should be granular enough to express the minimum privilege needed: `orders:read`, `inventory:write`, `webhooks:manage`. At issuance, the consumer selects the scopes required for their integration; the server enforces them on every request. A key scoped to `orders:read` must not be accepted on a `POST /orders` endpoint. Scoped keys contain breach impact to only the operations the key was authorized for.
+
+3. **Transmission — Authorization header only** — API keys must be transmitted in the `Authorization` header: `Authorization: Bearer sk_test_...` or `Authorization: ApiKey sk_test_...`. Query parameter transmission (`?api_key=...`) exposes the key in access logs, CDN logs, browser history, referrer headers, and URL-sharing patterns. TLS protects header values from eavesdropping; it does not protect query parameters from being logged. Any API accepting credentials via query parameters must be treated as compromised until migrated.
+
+4. **Storage — hash, never store plaintext** — The server must store a one-way hash of the API key, never the key itself. Use HMAC-SHA256 or bcrypt against the key value; store the hash in the database. When validating, hash the incoming key and compare against the stored hash. The full key is shown to the user exactly once at creation time — after that it is irrecoverable. This means a database dump does not give an attacker working credentials. Stripe, GitHub, and Twilio all follow this pattern: their support teams cannot retrieve a key, only revoke it.
+
+5. **Rotation strategy** — Keys must be rotatable without service downtime. The rotation flow: generate new key → consumer updates their configuration → old key is deprecated (still valid) → old key is revoked after a grace period. Overlapping validity windows (new and old key both valid for 24–72 hours) prevent hard cutover outages. For automated rotation, platforms should offer a key rotation API that generates the new key and schedules the old key's revocation in a single call. GitHub, AWS IAM, and HashiCorp Vault all support overlapping key validity during rotation.
+
+6. **Key identification and audit** — Each key should have a stable, non-secret identifier (a key ID or prefix) that appears in audit logs without exposing the key value. `GET /api-keys/key_abc123` returns the key's metadata (scopes, created date, last used, owner) but never the key value. Audit logs should record every request with the key ID and the operation performed — enabling incident response to determine which key was used and what it accessed.
+
+### Worked Example
+
+**Stripe API key design** is the industry reference for API key best practices at scale.
+
+**Key creation — only one exposure:**
+
+```http
+POST /v1/restricted_keys
+Authorization: Bearer sk_example_master_...
+Content-Type: application/x-www-form-urlencoded
+
+name=CI+Pipeline&permissions[orders][read]=true
+```
+
+```json
+{
+  "id": "rk_example_abc123",
+  "name": "CI Pipeline",
+  "secret": "rk_example_abc123xxxxxxxxxxxxxxxxxxx",
+  "permissions": { "orders": ["read"] },
+  "created": 1704067200
+}
+```
+
+The `secret` field is returned only in this response. Stripe's database stores `HMAC-SHA256(secret)`. A subsequent `GET /v1/restricted_keys/rk_example_abc123` returns metadata but never the `secret` field.
+
+**Key transmission — Authorization header:**
+
+```http
+GET /v1/charges?limit=10
+Authorization: Bearer rk_example_abc123xxxxxxxxxxxxxxxxxxx
+```
+
+**Key rotation — overlapping validity:**
+
+```http
+POST /v1/restricted_keys/rk_example_abc123/rotate
+Authorization: Bearer sk_example_master_...
+Content-Type: application/x-www-form-urlencoded
+
+grace_period_hours=48
+```
+
+```json
+{
+  "new_key": { "id": "rk_example_def456", "secret": "rk_example_def456..." },
+  "old_key": { "id": "rk_example_abc123", "expires_at": 1704240000 }
+}
+```
+
+Both keys are valid for 48 hours, giving the consumer time to update their configuration before the old key expires.
+
+### Anti-Patterns
+
+1. **Storing keys in plaintext.** A plaintext key database is a single query away from a complete credential compromise. An attacker with read access to the `api_keys` table can impersonate every customer. Always store hashed values; accept the operational cost of irrecoverable keys as a necessary security trade-off.
+
+2. **Issuing global admin keys for integrations.** Every CI pipeline, partner integration, and internal service that receives a master admin key expands the blast radius of any single key exposure to full account takeover. Scope keys to the minimum required permissions; create separate keys per integration.
+
+3. **Accepting keys in query parameters.** Beyond the log exposure risk, query parameter keys end up in browser bookmarks, shared links, Slack messages, and error report URLs. The migration cost of moving to header transmission is always less than the cost of a key exposure incident from log analysis.
+
+4. **No key rotation mechanism.** Keys that cannot be rotated without a service outage will not be rotated. Teams accept the security risk of old keys indefinitely because the rotation cost is too high. Design overlapping validity windows into the rotation flow from day one.
+
+## Details
+
+### Secret Scanning Integration
+
+The `sk_example_` / `ghp_` / `AIza` prefix patterns used by major API providers enable automated secret scanning to detect accidental key exposure in version control, CI logs, and issue trackers. GitHub Advanced Security, truffleHog, and GitLeaks all ship with detection patterns for known prefixes. When designing a key prefix, register the pattern with the GitHub Secret Scanning Partner Program — GitHub will notify your platform when matching patterns are detected in public repositories, enabling proactive revocation before exploitation. Stripe's partner integration with GitHub has prevented thousands of key exposures since its introduction.
+
+### HMAC Request Signing as an Alternative
+
+For high-security integrations where replay attack prevention matters, HMAC request signing replaces bearer token transmission entirely. The client generates a signature over the request method, path, timestamp, and body using a shared secret: `HMAC-SHA256(secret, "POST\n/orders\n1704067200\n{...body...}")`. The server recomputes the signature and compares. AWS Signature Version 4 and Stripe webhook signatures use this pattern. HMAC signing prevents replay attacks (the timestamp window is typically ±5 minutes) and credential transmission — the secret never appears on the wire.
+
+### Real-World Case Study: GitHub PAT Token Format Migration
+
+In 2021, GitHub migrated from opaque 40-character hex PATs to structured tokens with type prefixes (`ghp_`, `gho_`, `ghs_`, `ghr_`). The motivation: the old format was undetectable by secret scanning — any 40-character hex string could be a GitHub token or a SHA-1 hash. The new format enabled GitHub's secret scanning to detect PATs in public repositories and immediately notify and offer revocation. In the first year post-migration, GitHub detected and auto-revoked over 1.7 million exposed tokens before they were exploited. The lesson: key format is a security feature, not just a UX decision.
+
+## Source
+
+- [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)
+- [GitHub PAT Token Format Migration](https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/)
+- [Stripe API Keys Documentation](https://stripe.com/docs/keys)
+- [NIST SP 800-132 — Recommendation for Password-Based Key Derivation](https://csrc.nist.gov/publications/detail/sp/800-132/final)
+- [Google Secret Manager — Best Practices](https://cloud.google.com/secret-manager/docs/best-practices)
+
+## Process
+
+1. Generate keys using a CSPRNG with at least 128 bits of entropy; prefix with a service identifier for secret scanning compatibility.
+2. Store only the HMAC-SHA256 hash of the key in the database; return the full key to the user exactly once at creation time.
+3. Require scope selection at key creation time; enforce scopes on every request at the gateway or middleware layer.
+4. Implement overlapping validity rotation: new key valid immediately, old key valid for a configurable grace period before revocation.
+5. Run `harness validate` to confirm skill files are well-formed and related skills are correctly cross-referenced.
+
+## 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:** api-authentication-patterns, owasp-secrets-management, security-authentication, api-rate-limiting
+
+## Success Criteria
+
+- All API keys are generated with at least 128 bits of CSPRNG entropy and a service-specific prefix.
+- Keys are stored as one-way hashes (HMAC-SHA256 or bcrypt); the plaintext value is never persisted after the creation response.
+- Keys are transmitted exclusively via `Authorization` headers; query parameter transmission is rejected at the gateway.
+- Every key has an explicit scope; requests with insufficient scope return 403 before reaching business logic.
+- A key rotation flow exists that supports overlapping validity windows with no service downtime.

package/dist/agents/skills/claude-code/api-api-keys/skill.yaml

@@ -0,0 +1,41 @@
+name: api-api-keys
+version: '1.0.0'
+description: API key design — generation entropy requirements, rotation strategy, scoping permissions, transmission via Authorization header, storage hashing
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - api-authentication-patterns
+  - owasp-secrets-management
+  - security-authentication
+  - api-rate-limiting
+stack_signals:
+  - rest
+  - api
+  - http
+  - security
+keywords:
+  - api-keys
+  - key-rotation
+  - key-scoping
+  - key-transmission
+  - key-storage
+  - HMAC
+  - secret-entropy
+metadata:
+  author: community
+  upstream: cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
+state:
+  persistent: false
+  files: []
+depends_on: []