@harness-engineering/cli 1.23.1 → 1.24.0

package/dist/agents/skills/codex/graphql-subscriptions/SKILL.md

@@ -0,0 +1,198 @@
+# GraphQL Subscriptions
+
+> Implement real-time data streaming with GraphQL subscriptions over WebSocket connections
+
+## When to Use
+
+- Pushing live updates to clients (chat messages, notifications, live scores)
+- Replacing polling for frequently changing data
+- Building collaborative features (shared cursors, live editing)
+- Streaming long-running operation progress to the client
+
+## Instructions
+
+1. **Define subscription types in the schema.** Subscriptions are root-level operations alongside Query and Mutation.
+
+```graphql
+type Subscription {
+  messageAdded(channelId: ID!): Message!
+  orderStatusChanged(orderId: ID!): Order!
+}
+
+type Message {
+  id: ID!
+  content: String!
+  author: User!
+  createdAt: DateTime!
+}
+```
+
+2. **Use `graphql-ws` for the WebSocket transport.** The older `subscriptions-transport-ws` is unmaintained. `graphql-ws` implements the GraphQL over WebSocket protocol correctly with proper connection lifecycle handling.
+
+```bash
+npm install graphql-ws ws
+```
+
+3. **Set up the WebSocket server alongside your HTTP server.**
+
+```typescript
+import { createServer } from 'http';
+import { WebSocketServer } from 'ws';
+import { useServer } from 'graphql-ws/lib/use/ws';
+import { ApolloServer } from '@apollo/server';
+import { expressMiddleware } from '@apollo/server/express4';
+import { makeExecutableSchema } from '@graphql-tools/schema';
+
+const schema = makeExecutableSchema({ typeDefs, resolvers });
+const httpServer = createServer(app);
+
+const wsServer = new WebSocketServer({
+  server: httpServer,
+  path: '/graphql',
+});
+
+const serverCleanup = useServer(
+  {
+    schema,
+    context: async (ctx) => {
+      const token = ctx.connectionParams?.authToken;
+      return { currentUser: await authenticate(token as string) };
+    },
+  },
+  wsServer
+);
+
+const server = new ApolloServer({
+  schema,
+  plugins: [
+    {
+      async serverWillStart() {
+        return {
+          async drainServer() {
+            await serverCleanup.dispose();
+          },
+        };
+      },
+    },
+  ],
+});
+```
+
+4. **Implement a PubSub system for publishing events.** Use an in-memory PubSub for development and a distributed backend (Redis, Kafka) for production.
+
+```typescript
+import { PubSub } from 'graphql-subscriptions';
+
+// Development only — in-memory, single-process
+const pubsub = new PubSub();
+
+// Production — use Redis-backed PubSub
+import { RedisPubSub } from 'graphql-redis-subscriptions';
+const pubsub = new RedisPubSub({
+  connection: { host: 'redis', port: 6379 },
+});
+```
+
+5. **Write subscription resolvers with `subscribe` and optional `resolve`.** The `subscribe` function returns an AsyncIterator. The `resolve` function transforms the published payload before sending to the client.
+
+```typescript
+const resolvers = {
+  Subscription: {
+    messageAdded: {
+      subscribe: (_parent, { channelId }, { pubsub }) => {
+        return pubsub.asyncIterator(`MESSAGE_ADDED.${channelId}`);
+      },
+      resolve: (payload) => payload.messageAdded,
+    },
+  },
+  Mutation: {
+    sendMessage: async (_parent, { input }, { pubsub, dataSources }) => {
+      const message = await dataSources.messages.create(input);
+      await pubsub.publish(`MESSAGE_ADDED.${input.channelId}`, {
+        messageAdded: message,
+      });
+      return message;
+    },
+  },
+};
+```
+
+6. **Filter subscriptions with `withFilter`.** Only push events that match the subscriber's criteria — do not send all events and let the client discard irrelevant ones.
+
+```typescript
+import { withFilter } from 'graphql-subscriptions';
+
+const resolvers = {
+  Subscription: {
+    orderStatusChanged: {
+      subscribe: withFilter(
+        () => pubsub.asyncIterator('ORDER_STATUS_CHANGED'),
+        (payload, variables) => payload.orderStatusChanged.id === variables.orderId
+      ),
+    },
+  },
+};
+```
+
+7. **Authenticate on the WebSocket connection, not per message.** Extract the auth token from `connectionParams` during the initial WebSocket handshake. Reject unauthenticated connections in the `onConnect` handler.
+
+8. **Handle client-side subscriptions with `useSubscription` or `subscribeToMore`.**
+
+```typescript
+// Standalone subscription
+const { data } = useSubscription(MESSAGE_ADDED, {
+  variables: { channelId },
+});
+
+// Augment an existing query with live updates
+const { subscribeToMore, data } = useQuery(GET_MESSAGES, { variables: { channelId } });
+
+useEffect(() => {
+  return subscribeToMore({
+    document: MESSAGE_ADDED,
+    variables: { channelId },
+    updateQuery: (prev, { subscriptionData }) => ({
+      messages: [...prev.messages, subscriptionData.data.messageAdded],
+    }),
+  });
+}, [channelId, subscribeToMore]);
+```
+
+## Details
+
+**In-memory PubSub limitations:** The default `PubSub` from `graphql-subscriptions` works only within a single Node.js process. In a multi-instance deployment, subscribers on one instance will not receive events published by another. Use Redis, Kafka, or Google PubSub for production.
+
+**Connection lifecycle:** `graphql-ws` supports `onConnect` (authentication, rate limiting), `onDisconnect` (cleanup), and `onSubscribe` (per-subscription validation). Use these hooks for access control.
+
+**Scaling considerations:**
+
+- Each active subscription holds an open WebSocket connection — plan for connection limits
+- Use Redis PubSub for horizontal scaling across server instances
+- Consider connection pooling and heartbeat intervals to detect stale connections
+- Load balancers must support WebSocket upgrade (sticky sessions or Layer 4 balancing)
+
+**Alternatives to subscriptions:**
+
+- Server-Sent Events (SSE) for one-way streaming without WebSocket infrastructure
+- `@defer` and `@stream` directives for incremental delivery of query results (experimental)
+- Polling with `cache-and-network` for simple cases with moderate freshness needs
+
+## Source
+
+https://the-guild.dev/graphql/ws
+
+## 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/codex/graphql-subscriptions/skill.yaml

@@ -0,0 +1,39 @@
+name: graphql-subscriptions
+version: '1.0.0'
+description: Implement real-time data streaming with GraphQL subscriptions over WebSocket
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - '**/*.graphql'
+  - '**/resolvers/**'
+  - '**/subscriptions/**'
+related_skills:
+  - graphql-resolver-pattern
+  - graphql-apollo-server
+  - graphql-client-patterns
+stack_signals:
+  - graphql
+  - typescript
+  - apollo
+keywords:
+  - subscriptions
+  - websocket
+  - pubsub
+  - real-time
+  - streaming
+metadata:
+  author: community
+  upstream: apollographql.com/docs/apollo-server/data/subscriptions
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/codex/harness-accessibility/SKILL.md

@@ -261,6 +261,16 @@ A11Y-030 [info] Hardcoded color value not from design token set
 - `A11Y-031`: Contrast failure -- fix requires choosing a darker color. Escalate to design tokens or get human input on replacement color.
 - `A11Y-001`: The `alt=""` fix assumes decorative. If the icon conveys meaning, human must write descriptive alt text.
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                                         | Reality                                                                                                                                                                                                                                                                        |
+| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| "The contrast ratio is 4.4:1 — that's essentially 4.5:1 and the difference is imperceptible. I'll mark it passing."                     | WCAG AA requires exactly 4.5:1 for normal text. 4.4:1 fails. There is no rounding or visual perception exception in the standard. Flag the failure with the actual ratio and let the user decide how to remediate.                                                             |
+| "This `<div onClick>` already has good visual styling — adding `role='button'` and a keyboard handler is unnecessary clutter."          | A clickable `<div>` without `role="button"` and `onKeyDown` is inaccessible to keyboard-only users and screen reader users. Visual styling has no bearing on ARIA semantics or keyboard reachability. This is A11Y-012, always flagged.                                        |
+| "The automated fix for this `<img>` alt attribute is obvious — I'll apply it without showing the diff since it's just adding `alt=''`." | Every automated fix must be presented as a before/after diff before being written to disk. This is a hard gate. The correct alt value for non-decorative images requires human judgment, and even `alt=""` makes a semantic claim about decorativeness that must be confirmed. |
+| "I18n is enabled, so I'll skip the `lang` and `dir` attribute checks entirely — harness-i18n will catch them."                          | Deferral to harness-i18n is conditional on `i18n.enabled: true` in config. If i18n is not configured, these checks remain part of this skill's scan. Always read the config before skipping any check category.                                                                |
+| "There are 15 findings in this component — I'll fix the easy ones automatically and leave the rest without reporting them explicitly."  | All findings must be reported, regardless of whether they are auto-fixable. The report is the primary deliverable of the REPORT phase. Selectively reporting only fixable violations hides the full accessibility debt from the team.                                          |
+
 ## Gates
 
 These are hard stops. Violating any gate means the process has broken down.

package/dist/agents/skills/codex/harness-accessibility/skill.yaml

@@ -9,6 +9,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

package/dist/agents/skills/codex/harness-api-design/SKILL.md

@@ -332,21 +332,11 @@ These apply to ALL skills. If you catch yourself doing any of these, STOP.
 
 ## Rationalizations to Reject
 
-### Universal
-
-These reasoning patterns sound plausible but lead to bad outcomes. Reject them.
-
-- **"It's probably fine"** — "Probably" is not evidence. Verify before asserting.
-- **"This is best practice"** — Best practice in what context? Cite the source and
-  confirm it applies to this codebase.
-- **"We can fix it later"** — If it is worth flagging, it is worth documenting now
-  with a concrete follow-up plan.
-
-### Domain-Specific
-
-- **"It's an internal API, breaking changes are fine"** — Internal consumers break too. Version the change or coordinate the migration explicitly.
-- **"The field name is obvious enough"** — API field names are a public contract. Follow existing naming conventions and document the semantics.
-- **"Nobody uses that endpoint anyway"** — Verify with access logs or usage data. Assumptions about usage without evidence lead to silent breakages.
+| Rationalization                                   | Reality                                                                                                   |
+| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+| "It's an internal API, breaking changes are fine" | Internal consumers break too. Version the change or coordinate the migration explicitly.                  |
+| "The field name is obvious enough"                | API field names are a public contract. Follow existing naming conventions and document the semantics.     |
+| "Nobody uses that endpoint anyway"                | Verify with access logs or usage data. Assumptions about usage without evidence lead to silent breakages. |
 
 ## Escalation
 

package/dist/agents/skills/codex/harness-api-design/skill.yaml

@@ -8,6 +8,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read
@@ -72,3 +74,8 @@ state:
   persistent: false
   files: []
 depends_on: []
+related_skills:
+  - graphql-schema-design
+  - graphql-resolver-pattern
+  - graphql-pagination-patterns
+  - trpc-router-composition

package/dist/agents/skills/codex/harness-architecture-advisor/SKILL.md

@@ -309,21 +309,11 @@ These apply to ALL skills. If you catch yourself doing any of these, STOP.
 
 ## Rationalizations to Reject
 
-### Universal
-
-These reasoning patterns sound plausible but lead to bad outcomes. Reject them.
-
-- **"It's probably fine"** — "Probably" is not evidence. Verify before asserting.
-- **"This is best practice"** — Best practice in what context? Cite the source and
-  confirm it applies to this codebase.
-- **"We can fix it later"** — If it is worth flagging, it is worth documenting now
-  with a concrete follow-up plan.
-
-### Domain-Specific
-
-- **"This will be easier to maintain"** — Easier for whom, and compared to what? Cite the maintenance burden with evidence from the codebase.
-- **"It's the modern approach"** — Modernity is not a design criterion. Fitness for purpose is. State the specific benefit.
-- **"Other teams do it this way"** — Other teams have different constraints. Evaluate the option on this codebase's specific merits.
+| Rationalization                   | Reality                                                                                             |
+| --------------------------------- | --------------------------------------------------------------------------------------------------- |
+| "This will be easier to maintain" | Easier for whom, and compared to what? Cite the maintenance burden with evidence from the codebase. |
+| "It's the modern approach"        | Modernity is not a design criterion. Fitness for purpose is. State the specific benefit.            |
+| "Other teams do it this way"      | Other teams have different constraints. Evaluate the option on this codebase's specific merits.     |
 
 ## Escalation
 

package/dist/agents/skills/codex/harness-architecture-advisor/skill.yaml

@@ -8,6 +8,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Read
   - Glob

package/dist/agents/skills/codex/harness-auth/SKILL.md

@@ -307,21 +307,11 @@ These apply to ALL skills. If you catch yourself doing any of these, STOP.
 
 ## Rationalizations to Reject
 
-### Universal
-
-These reasoning patterns sound plausible but lead to bad outcomes. Reject them.
-
-- **"It's probably fine"** — "Probably" is not evidence. Verify before asserting.
-- **"This is best practice"** — Best practice in what context? Cite the source and
-  confirm it applies to this codebase.
-- **"We can fix it later"** — If it is worth flagging, it is worth documenting now
-  with a concrete follow-up plan.
-
-### Domain-Specific
-
-- **"No one would guess this token format"** — Security by obscurity. Tokens must be cryptographically secure regardless of format predictability.
-- **"This is an internal service, auth is less critical"** — Internal services are lateral movement targets. Authenticate all service boundaries.
-- **"The frontend validates permissions, so the backend doesn't need to"** — Client-side checks are bypassable. Server-side authorization is the only real enforcement.
+| Rationalization                                                      | Reality                                                                                             |
+| -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| "No one would guess this token format"                               | Security by obscurity. Tokens must be cryptographically secure regardless of format predictability. |
+| "This is an internal service, auth is less critical"                 | Internal services are lateral movement targets. Authenticate all service boundaries.                |
+| "The frontend validates permissions, so the backend doesn't need to" | Client-side checks are bypassable. Server-side authorization is the only real enforcement.          |
 
 ## Escalation
 

package/dist/agents/skills/codex/harness-auth/skill.yaml

@@ -9,6 +9,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read
@@ -79,3 +81,7 @@ state:
   persistent: false
   files: []
 depends_on: []
+related_skills:
+  - owasp-auth-patterns
+  - owasp-csrf-protection
+  - next-auth-patterns

package/dist/agents/skills/codex/harness-autopilot/SKILL.md

@@ -720,6 +720,16 @@ INIT → ASSESS → PLAN → APPROVE_PLAN → EXECUTE → VERIFY → REVIEW →
 - Checkpoint commits fire after every passing checkpoint; recovery commits fire on retry budget exhaustion
 - Rigor level persists across session resume — set once during INIT, never changed mid-session
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                     | Reality                                                                                                                                                                                                                 |
+| --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "This phase is low complexity, so I can skip the APPROVE_PLAN gate entirely"                        | Low complexity only means auto-approval when no concern signals fire. If the planner flagged concerns, produced a complexity override, or the task count exceeds 15, the gate pauses regardless of the spec annotation. |
+| "I can write the planning logic inline instead of dispatching to the harness-planner persona agent" | The Iron Law is explicit: autopilot delegates, never reimplements. Using a general-purpose agent or inlining planning logic bypasses the harness methodology.                                                           |
+| "The retry budget is exhausted but I can try one more approach before stopping"                     | The 3-attempt retry budget exists because each failed attempt degrades context and compounds risk. Exceeding the budget without human input turns a recoverable failure into an unrecoverable one.                      |
+| "I will skip the scratchpad since keeping research in conversation is faster"                       | Scratchpad is gated by rigor level. At standard or thorough, bulky research (>500 words) must go to scratchpad to keep agent conversation focused on decisions.                                                         |
+| "The plan auto-approved, so I can skip recording the decision in the decisions array"               | Every plan approval -- auto or manual -- must be recorded with its signal evaluation. The decisions array is the audit trail that explains why a plan was approved.                                                     |
+
 ## Examples
 
 ### Example: 3-Phase Security Scanner

package/dist/agents/skills/codex/harness-autopilot/skill.yaml

@@ -7,6 +7,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

package/dist/agents/skills/codex/harness-brainstorming/SKILL.md

@@ -326,6 +326,15 @@ These patterns make requirements testable and unambiguous. Apply them when the o
 - `harness validate` passes after the spec is written
 - If scope was too large, it was decomposed into sub-projects with the human's approval
 
+## Rationalizations to Reject
+
+| Rationalization                                                                    | Reality                                                                                                                                                                                     |
+| ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "I already understand the problem well enough to skip the question phase"          | The Gates section is explicit: you must ask at least one clarifying question before proposing approaches. Skipping questions means making untested assumptions.                             |
+| "There is only one viable approach, so presenting alternatives would be contrived" | The gate requires at least 2 approaches with tradeoffs. A single approach is a recommendation disguised as a decision -- the human has no real choice.                                      |
+| "I will draft the full spec and present it for review all at once to save time"    | Section-dump specs are explicitly forbidden. Presenting section by section with feedback between each catches misunderstandings early.                                                      |
+| "This future capability is low-cost to include now, so we should build it in"      | YAGNI is a gate, not a suggestion. Every capability must trace to a stated requirement. "We might need this later" is the exact rationalization that turns focused specs into bloated ones. |
+
 ## Examples
 
 ### Example: Designing a Notification System

package/dist/agents/skills/codex/harness-brainstorming/skill.yaml

@@ -8,6 +8,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

package/dist/agents/skills/codex/harness-caching/SKILL.md

@@ -295,6 +295,16 @@ async function getProducts(): Promise<Product[]> {
 }
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                         | Reality                                                                                                                                                                                                                                                                                                                               |
+| --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "Cache invalidation is complex — a short TTL means we're always fresh enough"           | Short TTLs without event-based invalidation guarantee staleness windows proportional to the TTL. A 60-second TTL on pricing data means a price change takes up to 60 seconds to propagate. For correctness-sensitive data, TTL alone is not a strategy — it is a staleness budget.                                                    |
+| "Redis is fast — we don't need to worry about the cache stampede, it'll resolve itself" | Cache stampedes do not resolve themselves; they resolve after they have already caused a database overload. With 200 requests per second and a 450ms rebuild time, a stampede generates ~90 concurrent database queries at once. The database can fail before a single cache entry is rebuilt.                                        |
+| "We cache the whole user object so we have everything in one key"                       | Caching composite objects creates broad invalidation requirements. A user profile update invalidates a cache entry that includes unrelated fields like payment methods or notification preferences. Cache keys scoped to specific sub-resources reduce invalidation blast radius.                                                     |
+| "The cache failure is caught and logged — users will just get a slower response"        | Catching the error is not the same as handling it. If cache failure causes a 30-second database query on every request, "slower response" becomes "timeout" becomes "circuit breaker opens" becomes "service unavailable." Failure handling must degrade to database reads within the acceptable latency budget, not unconditionally. |
+| "We namespace by feature name — there's no collision risk"                              | Feature names are not unique across services. Two services that share a Redis instance and both cache `user:123` without a service prefix will corrupt each other's data silently. Namespace prefixes must include the service and the data schema version, not just the feature name.                                                |
+
 ## Gates
 
 - **No unbounded caches.** Every cache (in-memory, Redis, Memcached) must have either a `maxSize`/`maxmemory` limit or a TTL on every key. An unbounded cache will grow until it causes memory exhaustion. WHERE a cache has no eviction policy configured, THEN the skill must halt and require one before proceeding.

package/dist/agents/skills/codex/harness-caching/skill.yaml

@@ -8,6 +8,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read
@@ -71,3 +73,6 @@ state:
   persistent: false
   files: []
 depends_on: []
+related_skills:
+  - resilience-rate-limiting
+  - resilience-fallback-pattern

package/dist/agents/skills/codex/harness-chaos/SKILL.md

@@ -280,6 +280,16 @@ Result: PASSED - System maintained availability throughout.
         Zero 5xx errors observed. No data loss.
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                           | Reality                                                                                                                                                                                                                                                                        |
+| ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| "Our circuit breakers are already tested in unit tests — we don't need chaos experiments" | Unit tests verify that circuit breaker code executes. Chaos experiments verify that the circuit breaker actually opens under real load, that the fallback produces an acceptable user-facing response, and that monitoring detects the transition. These are different things. |
+| "We can't run chaos experiments in production — it's too risky"                           | Avoiding chaos experiments does not reduce risk — it defers the discovery of failure modes to real incidents. Chaos experiments in staging with defined abort criteria and short durations are lower risk than discovering failure modes at 2am during a real outage.          |
+| "The experiment passed in staging so we know it'll work in production"                    | Staging differences in traffic volume, data distribution, and infrastructure scale can mask failure modes. Staging experiments validate the mechanism; production experiments (with tightly scoped blast radius) validate the system under real conditions.                    |
+| "We injected the fault and the system recovered — the experiment is done"                 | Recovery alone does not validate resilience. The experiment must also confirm: detection time (did monitoring catch it?), recovery time (did it meet the SLA?), and no data loss or corruption. A system that recovers after 10 minutes of data inconsistency has not passed.  |
+| "We have runbooks for these failure modes, so game days aren't necessary"                 | A runbook that has never been executed under pressure is a hypothesis, not a procedure. Game days reveal whether runbooks are complete, whether on-call engineers can execute them accurately under stress, and whether the estimated recovery times are realistic.            |
+
 ## Gates
 
 - **No chaos experiments without abort criteria.** Every experiment must define conditions under which it is immediately terminated. Running an experiment that you cannot stop is reckless, not engineering.

package/dist/agents/skills/codex/harness-chaos/skill.yaml

@@ -8,6 +8,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

package/dist/agents/skills/codex/harness-code-review/SKILL.md

@@ -831,21 +831,11 @@ These apply to ALL skills. If you catch yourself doing any of these, STOP.
 
 ## Rationalizations to Reject
 
-### Universal
-
-These reasoning patterns sound plausible but lead to bad outcomes. Reject them.
-
-- **"It's probably fine"** — "Probably" is not evidence. Verify before asserting.
-- **"This is best practice"** — Best practice in what context? Cite the source and
-  confirm it applies to this codebase.
-- **"We can fix it later"** — If it is worth flagging, it is worth documenting now
-  with a concrete follow-up plan.
-
-### Domain-Specific
-
-- **"The tests pass, so the logic must be correct"** — Tests can be incomplete. Review the logic independently of test results.
-- **"This is how it was done elsewhere in the codebase"** — Existing patterns can be wrong. Evaluate the pattern on its merits, not just its precedent.
-- **"It's just a refactor, low risk"** — Refactors change behavior surfaces. Review them with the same rigor as feature changes.
+| Rationalization                                     | Reality                                                                                     |
+| --------------------------------------------------- | ------------------------------------------------------------------------------------------- |
+| "The tests pass, so the logic must be correct"      | Tests can be incomplete. Review the logic independently of test results.                    |
+| "This is how it was done elsewhere in the codebase" | Existing patterns can be wrong. Evaluate the pattern on its merits, not just its precedent. |
+| "It's just a refactor, low risk"                    | Refactors change behavior surfaces. Review them with the same rigor as feature changes.     |
 
 ## Escalation
 

package/dist/agents/skills/codex/harness-code-review/skill.yaml

@@ -9,6 +9,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

package/dist/agents/skills/codex/harness-codebase-cleanup/SKILL.md

@@ -187,6 +187,17 @@ Remaining findings: 3 (require human action)
      Suggested: Deprecate with @deprecated JSDoc tag, remove in next major version
 ```
 
+## Rationalizations to Reject
+
+These are common rationalizations that sound reasonable but lead to incorrect results. When you catch yourself thinking any of these, stop and follow the documented process instead.
+
+| Rationalization                                                                                               | Why It Is Wrong                                                                                                                                  |
+| ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
+| "This dead export is in a high-churn file but the removal is clearly safe"                                    | High-churn files have more hidden consumers. Safe findings in the top 10% by churn are downgraded to probably-safe, requiring explicit approval. |
+| "The convergence loop is not reducing findings quickly enough, so I will apply unsafe fixes to make progress" | Unsafe findings are never auto-fixed, regardless of convergence pressure. Each requires human judgment.                                          |
+| "The verification gate failed on a probably-safe fix, but I am confident the fix is correct"                  | When verification fails after a fix batch, the entire batch must be reverted and all findings reclassified as unsafe.                            |
+| "I will skip the hotspot context phase since it adds time and the churn data is just supplementary"           | The hotspot map drives safety classification accuracy. Without it, safe fixes in high-churn areas are not downgraded.                            |
+
 ## Examples
 
 ### Example: Post-Refactoring Cleanup

package/dist/agents/skills/codex/harness-codebase-cleanup/skill.yaml

@@ -7,6 +7,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

package/dist/agents/skills/codex/harness-compliance/SKILL.md

@@ -288,6 +288,16 @@ Phase 4: REPORT
       7. Add automated HIPAA compliance regression tests to CI pipeline
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                 | Reality                                                                                                                                                                                                                                       |
+| ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "We're not in the EU so GDPR doesn't apply to us"                               | GDPR applies to any organization that processes data of EU residents, regardless of where the organization is based. If a single EU user can sign up, GDPR scope must be assessed.                                                            |
+| "Our lawyers will handle the compliance questions — just document what we have" | Legal review and technical implementation are distinct. Lawyers cannot attest that Article 17 deletion cascades to S3 and Segment. The technical implementation must be audited separately.                                                   |
+| "We already did a SOC2 audit last year — this codebase is the same"             | SOC2 Type II assesses controls over time. Adding a new data store, third-party processor, or API endpoint can invalidate previous control attestations. Audits are point-in-time snapshots, not permanent certificates.                       |
+| "The audit isn't for three months — we can fix the gaps before then"            | Gaps found now require implementation, testing, and evidence collection time. Auditors expect evidence of sustained control operation, not freshly deployed fixes. A gap fixed the week before an audit is still a finding.                   |
+| "That field is technically a username, not PII"                                 | Data classification cannot be done by naming convention. A username combined with any other identifying field (email, IP, phone) is PII under GDPR. Classification must be based on the realistic re-identification risk, not the field name. |
+
 ## Gates
 
 - **No compliance report without data classification.** A compliance audit that does not inventory and classify data fields is incomplete. The classification matrix must be produced before controls can be meaningfully assessed. Without knowing what data exists and where, control checks are theoretical.

package/dist/agents/skills/codex/harness-compliance/skill.yaml

@@ -9,6 +9,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read