@harness-engineering/cli 1.23.1 → 1.24.0

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

@@ -411,6 +411,15 @@ When this skill makes claims about task completion, test results, or code behavi
 - No improvisation: tasks were executed as written, or execution was stopped and the blocker was reported
 - All stopping conditions were respected (no guessing past blockers, no blind retries)
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                | Reality                                                                                                                                                   |
+| -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "The plan says to do X, but doing Y would be cleaner -- I will improvise"                                      | The Iron Law states: execute the plan as written. If the plan is wrong, stop and fix the plan. Improvising mid-execution introduces untested assumptions. |
+| "This task depends on Task 3 which I know is done, so I can skip verifying prerequisites"                      | Prerequisites must be verified mechanically, not from memory. Check that dependency tasks are marked complete in state and that referenced files exist.   |
+| "The checkpoint is just a confirmation step and the output looks correct, so I will auto-continue"             | Checkpoints are non-negotiable pause points. If a task has a checkpoint marker, execution must pause.                                                     |
+| "Harness validate passed on the previous task and nothing changed structurally, so I can skip it for this one" | Validation runs after every task with no exceptions. Each task may introduce subtle architectural drift that only harness validate catches.               |
+
 ## Examples
 
 ### Example: Executing a 5-Task Notification Plan

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

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

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

@@ -206,6 +206,16 @@
 - Rollout configuration is validated for active flags
 - Lifecycle policies are recommended with enforcement mechanisms
 
+## Rationalizations to Reject
+
+| Rationalization                                                            | Why It Is Wrong                                                                                                                        |
+| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| "This release flag has been at 100% for a while, but removing it is risky" | Release flags at 100% for more than 30 days are stale candidates. Every stale flag adds dead code branches and test matrix complexity. |
+| "We only need to test the flag-on path since that is the path we ship"     | No flags without test coverage for both paths. The flag-off path IS the fallback when the flag provider is unreachable.                |
+| "These two flags depend on each other, but they work fine together"        | No coupled flag dependencies is a blocking finding. Flags that require other flags creates combinatorial complexity.                   |
+| "Setting the flag default to true makes the rollout easier"                | Every flag must default to safe (feature disabled). A default of true means a provider outage enables the feature for everyone.        |
+| "We do not need a naming convention -- our flag count is small"            | Inconsistent naming becomes unmanageable as flag count grows. The skill flags inconsistency as a warning even at small scale.          |
+
 ## Examples
 
 ### Example: React SPA with LaunchDarkly

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

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

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

@@ -190,6 +190,16 @@ git branch -D <branch-name>
 - Worktree was cleaned up after finishing (unless keeping for continued work)
 - No stale worktree references remain after cleanup
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                                                       | Reality                                                                                                                                                                                                                                                        |
+| ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "The tests are probably fine on the fresh branch — they were passing on main when I last checked. I'll skip baseline verification and start working." | Baseline verification is the condition that makes branch work trustworthy. A test failure discovered at finish time is ambiguous — it could be pre-existing or introduced by the work. Skipping baseline removes the only clean comparison point.              |
+| "The user said 'just merge it' — I'll merge without checking if the base branch has advanced since the worktree was created."                         | The pre-finish check for base branch divergence is mandatory before any finishing strategy. Merging without rebasing first can produce a merge that silently breaks tests that were passing on the branch but conflict with new commits on main.               |
+| "The worktree directory isn't gitignored, but it's inside a nested folder that's unlikely to be committed accidentally."                              | The `.gitignore` check is not about likelihood — it is about preventing accidental commits of worktree state that would corrupt the repository. If the worktree directory is not gitignored, add it before creating the worktree. No exceptions.               |
+| "The user chose to discard — I'll delete the branch and worktree immediately without showing the commits that will be lost."                          | The discard path requires showing the commit list from `git log main..HEAD --oneline` and receiving explicit confirmation before running `git worktree remove` and `git branch -D`. Work is being permanently deleted; the user must see what they are losing. |
+| "There's already a worktree for this branch at a different path — I'll create a second one since the user asked for a fresh setup."                   | Git does not allow two worktrees checked out to the same branch. Attempting to create a duplicate will fail. Instead, ask the user whether to use the existing worktree or create a new branch. Never assume a second worktree is the right answer.            |
+
 ## Examples
 
 ### Example: Setting Up a Worktree for a New Feature

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

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

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

@@ -128,6 +128,16 @@ Use `get_relationships` to check structural edges between co-change pairs.
 - Report follows the structured output format
 - All findings are backed by graph query evidence (with graph) or git log analysis (without graph)
 
+## 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                                                                                                                                         |
+| ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "High churn just means the file is actively developed, not that it is risky"                                             | High churn in shared utilities specifically equals high risk. A file with 45 commits that co-changes with 12 different files indicates hidden coupling. |
+| "The co-change pair is between two files in different modules, but they probably just happen to change at the same time" | Distant co-change pairs are flagged as suspicious precisely because they indicate hidden coupling.                                                      |
+| "No graph exists so the analysis will be too incomplete to be useful"                                                    | Git log provides ~90% of the data needed for hotspot detection. The fallback is the highest-completeness fallback across all graph-enhanced skills.     |
+
 ## Examples
 
 ### Example: Detecting Hotspots in a Growing Codebase

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

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

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

@@ -465,6 +465,16 @@ Remaining violations (require human judgment): 5
 - I18N-401: Missing key in es -- requires Spanish translation
 - I18N-402: Untranslated value in fr -- requires French translation
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                                           | Reality                                                                                                                                                                                                                                               |
+| ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "This string is the app's brand name — it's technically hardcoded but obviously shouldn't be translated. I'll skip flagging it."          | Brand names require explicit suppression via `// i18n-ignore` comment, not silent omission from the scan. Skipping without suppression means future scans have inconsistent results and the team has no record of the deliberate decision.            |
+| "The framework isn't in the knowledge base, but I can tell from context it's using i18next patterns — I'll apply i18next rules directly." | Unrecognized frameworks must fall back to generic detection rules, not assumed framework rules. Applying i18next-specific fix patterns to an unknown framework produces incorrect wrapping that breaks at runtime. Log the gap and use generic rules. |
+| "The project has `i18n.enabled: false` — I'll still flag errors for hardcoded strings since the team should know about them."             | Respecting `i18n.enabled: false` is a gate. The team made a configuration decision. In that state, run in discovery mode (info severity only). Escalating to errors overrides the team's explicit choice.                                             |
+| "I18N-402 untranslated values are just warnings — I'll skip reporting them to keep the report shorter."                                   | Untranslated values (target identical to source) are a distinct violation category with their own code. They indicate copy-paste during file creation without actual translation. Omitting them produces a misleadingly optimistic coverage report.   |
+| "The plural rules for this locale look complex — I'll just check for 'one' and 'other' forms like English and move on."                   | Plural rules are locale-specific and must be loaded from the locale profile. Arabic requires six categories; Polish requires four. Checking only English plural categories produces false-passing results for languages that require more forms.      |
+
 ## Gates
 
 These are hard stops. Violating any gate means the process has broken down.

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

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

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

@@ -369,6 +369,16 @@ Result:         BLOCKED -- i18n review not conducted for user-facing PR
 Action:         Run harness-i18n scan on changed files, address findings, then re-review
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                                                     | Reality                                                                                                                                                                                                                                                                   |
+| --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "I can see hardcoded strings in the component the user is discussing — I'll flag them now as part of the process review."                           | This skill operates on artifacts (specs, plans, review context), never on source code. Scanning source files is harness-i18n's responsibility. Running Grep on component files from within this skill violates the skill boundary, regardless of how convenient it seems. |
+| "The feature clearly has no user-facing strings — it's a background job. I'll skip injection entirely without checking."                            | The skill must assess whether injection is applicable before skipping. Background jobs can produce user-facing output via notifications, emails, and error responses. A deliberate "not applicable" decision requires reading the feature description, not assuming.      |
+| "The team is in prompt mode and has dismissed the suggestion twice — I'll escalate to gate mode enforcement to make sure they take i18n seriously." | Escalating to gate mode is a configuration decision the team must make explicitly. Prompt mode is always dismissible. Unilaterally enforcing gate-mode behavior overrides a team's deliberate choice and violates the skill's core operating contract.                    |
+| "The plan has one task called 'polish and cleanup' — that probably includes i18n work. I'll mark the i18n check as passing."                        | In gate mode, i18n task presence must be verified by keyword match (i18n, translation, locale, localization, l10n), not inferred from vague task names. Ambiguous tasks must be flagged as missing, not assumed to cover the requirement.                                 |
+| "The spec mentions 'multi-language support' in passing — that counts as addressing i18n, so I won't require a dedicated section."                   | A passing mention is not an i18n section. The validation check requires the spec to identify which strings are user-facing, which locales are affected, and any formatting requirements. A vague reference satisfies none of these.                                       |
+
 ## Gates
 
 These are hard stops. Violating any gate means the process has broken down.

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

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

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

@@ -493,6 +493,16 @@ emails.welcome.greeting           -> "Hello {name}, welcome aboard!"
 Approve to continue scaffolding, or provide corrections.
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                                                  | Reality                                                                                                                                                                                                                                                                |
+| ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "The user already told me they want Spanish and French — I can skip the configuration phase and go straight to scaffolding."                     | The configuration phase writes the `i18n` block to `harness.config.json`. Without it, subsequent runs of harness-i18n have no enabled flag, no strictness level, and no locale list to work against. Verbal confirmation does not substitute for written config.       |
+| "In retrofit mode, the key naming is straightforward — I'll apply the generated key catalog directly without showing it to the user for review." | The retrofit key catalog checkpoint is a hard gate. Key names become permanent identifiers that translation teams, TMS tools, and source code will reference for years. The user must review and approve them before any files are written.                            |
+| "The pseudo-locale transformation for this string with `{name}` is obvious — I'll just wrap the entire string including the placeholder."        | ICU MessageFormat placeholders must be preserved exactly. Transforming `{name}` to `{ñàmë}` breaks the interpolation at runtime. The pseudo-locale algorithm must detect and skip all placeholder syntax before applying accent and expansion transforms.              |
+| "These target locale files already exist from a previous run — I'll overwrite them with the new extraction output to keep things clean."         | Existing target locale translations must never be overwritten. A key with a translated (non-empty, non-source-identical) value in a target locale represents real translation work. Overwriting it destroys that work silently. Always preserve existing translations. |
+| "We found 120 strings in retrofit mode — I'll just run the full extraction without the audit phase since we clearly need everything extracted."  | The retrofit audit results are what tell the user how much effort the extraction requires and let them prioritize high-traffic flows. Skipping the audit and going straight to extraction removes the user's ability to scope the work before it happens.              |
+
 ## Gates
 
 These are hard stops. Violating any gate means the process has broken down.

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

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

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

@@ -151,6 +151,16 @@ When no graph is available, use static analysis to approximate impact:
 - Report follows the structured output format
 - All findings are backed by graph query evidence (with graph) or systematic static analysis (without graph)
 
+## 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                                                                                                                          |
+| -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| "The change is small so the blast radius must be low -- I can skip the transitive dependent check" | Small changes to shared utilities can have outsized blast radius. A one-line change to auth.ts can affect 23 transitive dependents.      |
+| "The graph is a few commits behind but it is close enough for this analysis"                       | If the graph is more than 2 commits behind, the skill requires a refresh before proceeding. Recent commits may have added new consumers. |
+| "No graph exists so I cannot produce a useful impact analysis"                                     | The fallback strategy using import parsing and naming conventions achieves ~70% completeness. Missing the graph does not mean stopping.  |
+
 ## Examples
 
 ### Example: Analyzing a Change to auth.ts

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

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

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

@@ -208,6 +208,16 @@ Phase 4: IMPROVE
     4. [P2] Create secret rotation runbook for all services (owner: @sre)
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                         | Reality                                                                                                                                                                                                                                                                           |
+| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "The root cause was human error — someone pushed a bad config"                          | Human error is a symptom, not a root cause. The root cause is the system that allowed a bad config to reach production undetected. A postmortem that stops at "human error" prevents no future incidents because it identifies no systemic fix.                                   |
+| "We know what happened — we don't need to write a full postmortem for a minor incident" | The decision about what is "minor" is made under the stress of recovery, not under calm analysis. Contributing factors and near-misses that look minor in the moment are frequently the root cause of the next major incident. Document while the context is fresh.               |
+| "The action items are in Slack — we don't need to track them formally"                  | Action items not tracked in a formal system with owners and due dates are not completed. Slack messages are buried within hours. The improvement phase of an incident exists only if its outputs are tracked to completion.                                                       |
+| "We don't have SLOs yet so we can't calculate error budget impact"                      | The absence of SLOs is itself a finding. Without SLOs, there is no objective basis for deciding whether reliability is acceptable. The incident is the forcing function to establish baseline SLOs. Document this gap as a P0 action item.                                        |
+| "The incident was caused by a third-party outage — nothing we could have done"          | Third-party outages expose missing circuit breakers, absent fallbacks, and insufficient multi-region routing. The postmortem should document why the third-party outage caused a customer-visible incident and what resilience improvements would have isolated the blast radius. |
+
 ## Gates
 
 - **No postmortem without a root cause statement.** A postmortem that says "cause unknown" is incomplete. If the root cause cannot be determined, the postmortem must document what was investigated, what was ruled out, and what additional data is needed. Do not close the investigation.

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

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

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

@@ -264,6 +264,16 @@ Phase 4: VALIDATE
   Result: WARN -- 2 security improvements needed
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                | Reality                                                                                                                                                                                                                                                                                                  |
+| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "We store state locally because it's just a dev environment"                                   | Local state is not shared between team members. Two developers running `terraform apply` against the same environment with diverged local state will produce conflicting resource definitions, duplicate resources, or state corruption that requires manual recovery.                                   |
+| "We haven't pinned the provider version because we want to automatically get security patches" | Unpinned providers can silently change resource behavior on `terraform init`. A `~> 5.0` constraint without an upper bound can pull a provider with breaking changes. Pin the minor version and upgrade explicitly via reviewed PRs so changes are intentional.                                          |
+| "That S3 bucket has public access because it hosts our static site"                            | Static site hosting does not require a public bucket ACL. CloudFront with an Origin Access Control (OAC) policy serves files from a private bucket. Public bucket ACLs are a common misconfiguration vector because they apply to all objects, including accidentally uploaded sensitive files.          |
+| "We'll tag resources properly before we go to production"                                      | Untagged resources accumulate. Cost allocation reports become impossible, security audits cannot identify owners, and decommissioning requires manual investigation of every resource. Tagging must be enforced at resource creation — retroactive tagging at scale is a weeks-long engineering project. |
+| "Manual changes are fine for urgent hotfixes — we'll import them to Terraform afterward"       | Manual changes without immediate import create drift that may be overwritten by the next `terraform apply`. The "import it later" step is almost never done. Every manual change that goes unimported erodes the reliability guarantee that IaC provides.                                                |
+
 ## Gates
 
 - **No local state for shared infrastructure.** Terraform configurations managing shared resources must use a remote backend with locking. Local state is blocking for any non-experimental configuration.

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

@@ -28,6 +28,13 @@ stack_signals:
   - "Pulumi.yaml"
   - "cdk.json"
   - "infrastructure/"
+paths:
+  - '*.tf'
+  - '*.tfvars'
+  - 'Pulumi.yaml'
+  - 'cdk.json'
+  - '*.template.yaml'
+  - '*.template.json'
 triggers:
   - manual
   - on_new_feature
@@ -35,6 +42,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

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

@@ -256,6 +256,15 @@ describe('ProjectService contract', () => {
 });
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                           | Why It Is Wrong                                                                                                                                             |
+| ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "Testing the happy path is sufficient -- error scenarios are edge cases"                  | The success criteria require error scenarios (400, 401, 403, 404, 500, timeout) for all public endpoints. Error paths are where real-world failures happen. |
+| "We can test against the staging environment instead of setting up local mocks"           | No integration tests that require external staging environments for CI. Tests must run with local test doubles.                                             |
+| "The consumer contract changed, so I will update the consumer test to match the provider" | Contract changes must be coordinated. The provider may have introduced a bug, not an intentional change.                                                    |
+| "Tests pass when I run them in order, so they are fine"                                   | Phase 4 requires running tests in random order. Any test that fails only in a specific order has a shared-state bug.                                        |
+
 ## Gates
 
 - **No integration tests that require external staging environments for CI.** Every integration test must run with local test doubles (mocks, containers, in-memory databases). Tests that fail without a staging VPN are not integration tests -- they are environment tests.

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

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

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

@@ -122,6 +122,16 @@ Rules:
 - [ ] Unified report follows the exact format
 - [ ] Overall verdict correctly reflects both mechanical and review results
 
+## 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                                                                                                                                    |
+| -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "All three mechanical checks failed, but I should still run the AI review to get useful feedback"              | When ALL three checks fail, stop immediately. Do not proceed to Phase 2. AI review on code that does not compile is wasted effort.                 |
+| "The security scanner found a warning but it is not high severity, so it should not affect the overall result" | Error-severity security findings are blocking. The distinction is severity, not the agent's opinion of importance.                                 |
+| "The AI review flagged an architectural concern as blocking, so the integrity check should fail"               | Only runtime errors, data loss, and security vulnerabilities count as blocking review findings. Architectural concerns are noted but do not block. |
+
 ## Examples
 
 ### Example: All Clear

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

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

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

@@ -162,6 +162,15 @@ This ensures subsequent graph queries (impact analysis, drift detection) include
 - Report follows the structured output format
 - All findings are backed by graph query evidence (with graph) or directory/file analysis (without graph)
 
+## Rationalizations to Reject
+
+| Rationalization                                                                         | Why It Is Wrong                                                                                                                                                   |
+| --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "The graph is a few commits behind, but it is close enough for knowledge mapping"       | If the graph is more than 10 commits behind, run harness scan before proceeding. A stale graph produces a knowledge map with missing modules.                     |
+| "No graph exists, so this skill cannot produce useful output"                           | The fallback strategy is explicit: use directory structure and file analysis. Fallback completeness is ~50%, significantly better than nothing.                   |
+| "The existing AGENTS.md is outdated, so I will overwrite it with the generated version" | Never overwrite without confirmation. Existing AGENTS.md may contain carefully authored context the graph cannot infer.                                           |
+| "The module descriptions I inferred from function names are accurate enough"            | Inferred descriptions are starting points. Phase 3 (AUDIT) exists to identify coverage gaps. Name-based inference misses purpose, constraints, and relationships. |
+
 ## Examples
 
 ### Example: Generating AGENTS.md from Graph

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

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

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

@@ -259,6 +259,16 @@ Phase 4: ANALYZE
   Recommendation: Add DataLoader for orders resolver, re-test after fix
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                             | Reality                                                                                                                                                                                                                                                                  |
+| ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| "The smoke test passed, so the full load test will probably be fine too."                                   | A smoke test at 1-2 VUs tells you the script runs — it says nothing about behavior at 100 or 1000 VUs. Connection pool exhaustion, lock contention, and GC pressure only appear under load. Smoke passing is the floor, not the ceiling.                                 |
+| "Staging is smaller than production, so results won't be accurate anyway — no point running the full test." | Staging results are always useful as a proxy: they reveal algorithmic bottlenecks, N+1 queries, and missing indexes that scale identically regardless of instance count. Document the scale factor and use it. Do not skip testing because the environment is imperfect. |
+| "We haven't changed the API, so the old load test baselines still apply."                                   | Baselines go stale when dependencies update, traffic patterns shift, or adjacent services change. A deployment that adds one middleware layer or changes a database index can move p99 by 200ms. Baselines must be re-validated, not assumed.                            |
+| "The p95 threshold is arbitrary — let's just relax it until the test passes."                               | A threshold without a documented basis is a guess. A threshold lowered to make a failing test pass is a suppressed regression. Thresholds must be derived from SLOs or measured baselines. If the SLO is wrong, change the SLO explicitly with stakeholder sign-off.     |
+| "We'll run the soak test later — we just need to ship the load test first."                                 | Soak tests catch failures that only emerge over hours: memory leaks, connection pool exhaustion, log file growth. If the feature involves a long-lived process, background worker, or WebSocket, skipping the soak test means the failure surfaces in production.        |
+
 ## Gates
 
 - **No load tests against production without explicit human approval.** Load tests can cause real outages. The target environment must be verified as non-production before execution. If production testing is required, a `[checkpoint:human-verify]` must be passed with documented approval.

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

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

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

@@ -326,6 +326,16 @@ Phase 4: VALIDATE
   After fixes: projected NEEDS_ATTENTION (missing precision/recall metrics)
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                         | Reality                                                                                                                                                                                                                                                                                                                                 |
+| ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "We re-trained with more data but the architecture is the same — the previous evaluation still applies."                | Evaluation results are bound to a specific model artifact, not to the architecture. A re-trained model with different weights can have dramatically different failure modes even if accuracy appears similar. Every model version that goes to production must be evaluated against the golden set, not inherited from its predecessor. |
+| "The model file is only 8MB — committing it to git is more convenient than setting up an artifact store."               | Model files in git corrupt repository history, explode clone times for all contributors, and cannot be versioned alongside experiment metadata. Convenience now creates permanent technical debt. The artifact store setup is a one-time cost; git pollution is permanent.                                                              |
+| "Loading the model inside the request handler is simpler — the model is small enough that latency won't be noticeable." | Per-request model loading adds I/O and deserialization on every inference call, holds no persistent state across requests, and collapses under any meaningful concurrency. "Small enough" is a guess without measurement. Models must be loaded at startup and held in memory.                                                          |
+| "We can add experiment tracking after we get the model working — right now we just need to iterate quickly."            | Experiment tracking is hardest to add retroactively because you cannot reconstruct the conditions of runs you did not log. The runs being executed without tracking right now are the ones producing the model that may go to production. Log them now or accept that the model is not reproducible.                                    |
+| "The prompt template is short enough to read in context — version controlling it adds unnecessary process."             | Prompts embedded in application code change silently when developers edit them, have no history of what changed and why, and cannot be evaluated independently. A prompt is a model artifact. It requires the same versioning, evaluation, and promotion discipline as model weights.                                                   |
+
 ## Gates
 
 - **No deploying models without evaluation.** A model that has not been evaluated against a golden set or baseline cannot be promoted to production. This is always an error.

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

@@ -2,12 +2,17 @@ name: harness-ml-ops
 version: "1.0.0"
 description: Model serving patterns, experiment tracking, prompt evaluation, and ML pipeline management
 cognitive_mode: advisory-guide
+paths:
+  - '*.ipynb'
+  - 'mlflow.yaml'
 triggers:
   - manual
   - on_new_feature
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read

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

@@ -311,6 +311,16 @@ Phase 4: VALIDATE
   Store submission ready: PASS
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                                                  | Reality                                                                                                                                                                                                                                                                                                  |
+| -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "We request all permissions at launch to get them out of the way — users can deny them if they want."                            | App stores treat permissions-at-launch as a review red flag and users deny at much higher rates when there is no contextual explanation. Permissions requested at the moment they are needed, with a sentence explaining why, consistently achieve higher grant rates and reduce store rejection risk.   |
+| "Universal Links are optional — the URL scheme fallback works fine for deep linking."                                            | URL scheme fallbacks (`myapp://`) can be claimed by any installed app on the device. A malicious or coincidentally named app can intercept links intended for yours. Universal Links with verified `apple-app-site-association` files are cryptographically bound to your domain and cannot be hijacked. |
+| "The push notification handler works in foreground and background — we can handle the terminated state separately after launch." | Users often first interact with an app by tapping a push notification when the app is terminated. The cold-start tap handler is commonly the first impression. Shipping without it means a class of users experiences a broken entry point from day one.                                                 |
+| "The staging configuration is slightly different but we'll remember to change it before the App Store build."                    | "Remember to change it" is not a process. Staging URLs, debug API keys, and sandbox APNs environments in production builds have shipped before and will again. Separate build configurations and environment-specific entitlement files are the only reliable mitigation.                                |
+| "The privacy manifest requirement is new — we'll add it in the next release after the store flags it."                           | Apple has enforced PrivacyInfo.xcprivacy requirements for new submissions and updates since May 2024. Submitting without it results in rejection, which blocks the entire release. Adding it retroactively under rejection pressure is strictly more costly than adding it now.                          |
+
 ## Gates
 
 - **No missing permission usage descriptions.** Every permission requested in code must have a corresponding usage description in the platform manifest. Missing descriptions cause automatic App Store rejection on iOS and are a best practice requirement on Android.

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

@@ -2,6 +2,11 @@ name: harness-mobile-patterns
 version: "1.0.0"
 description: Mobile platform lifecycle, permissions, deep linking, push notifications, and app store submission
 cognitive_mode: advisory-guide
+paths:
+  - 'app.json'
+  - 'pubspec.yaml'
+  - 'AndroidManifest.xml'
+  - 'Info.plist'
 triggers:
   - manual
   - on_new_feature
@@ -9,6 +14,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read
@@ -80,3 +87,8 @@ state:
   persistent: false
   files: []
 depends_on: []
+related_skills:
+  - mobile-performance-patterns
+  - mobile-navigation-pattern
+  - mobile-network-patterns
+  - mobile-storage-patterns

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

@@ -236,6 +236,15 @@ mvn org.pitest:pitest-maven:mutationCoverage
 # Report generated at target/pit-reports/index.html
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                                | Why It Is Wrong                                                                                                      |
+| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
+| "We have 80% line coverage, so test quality is already good"                                   | Line coverage measures execution, not verification. Mutation testing reveals missing assertions and weak assertions. |
+| "The survived mutants are in non-critical utility code, so we can ignore them"                 | Every survived mutant must be either addressed with a test or explicitly justified as an equivalent mutant.          |
+| "I will write a test that targets the specific mutation to kill it"                            | No gaming the mutation score. Every new test must test a meaningful behavior, not just kill a specific mutant.       |
+| "The test suite has some failures, but we can still run mutation testing to see what we learn" | No mutation testing against a failing test suite. Mutations against broken tests produce garbage results.            |
+
 ## Gates
 
 - **No mutation testing against a failing test suite.** All tests must pass before mutants are generated. Running mutations against broken tests produces garbage results. Fix the tests first.

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

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

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

@@ -268,6 +268,16 @@ Phase 4: VALIDATE
   Result: WARN -- 3 instrumentation gaps, alerting needs SLO alignment
 ```
 
+## Rationalizations to Reject
+
+| Rationalization                                                                        | Reality                                                                                                                                                                                                                                                                                                     |
+| -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "We can see what's happening in CloudWatch logs — we don't need structured logging"    | Unstructured log lines cannot be queried, aggregated, or correlated across services. When an incident spans three services, searching for a request ID across unstructured logs is manual forensics. Structured logging is not a nicety — it is the foundation for incident response.                       |
+| "We'll add alerting once we've seen a few incidents and know what to alert on"         | The first incident is the worst time to define alerting. SLO-based burn rate alerts can be defined from traffic patterns before any incidents occur. Waiting for incidents to define thresholds means every early failure goes undetected.                                                                  |
+| "User ID is a useful label for the latency metric — it helps us debug per-user issues" | User ID as a metric label creates one time series per user, which at 100,000 users means 100,000 label combinations. High-cardinality labels exhaust metric storage, cause query timeouts, and make the entire metrics system unstable. Use logs for per-user debugging; use metrics for aggregate signals. |
+| "The tracing library is initialized, so we have distributed tracing"                   | Initializing the library creates root spans but does not propagate context across HTTP boundaries, instrument database calls, or connect traces to logs. Trace initialization without verified end-to-end propagation produces disconnected, useless traces.                                                |
+| "We have alerts — they're just not linked to runbooks yet"                             | An alert that fires at 3am without a runbook link requires the on-call engineer to start debugging from scratch. The absence of a runbook is not a documentation gap; it is a mean-time-to-recover multiplier.                                                                                              |
+
 ## Gates
 
 - **No sensitive data in logs.** If PII, credentials, or tokens are detected in log output, it is a blocking finding. The logging configuration must sanitize or redact sensitive fields before any other improvements are made.

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

@@ -33,6 +33,8 @@ triggers:
 platforms:
   - claude-code
   - gemini-cli
+  - cursor
+  - codex
 tools:
   - Bash
   - Read
@@ -76,3 +78,8 @@ state:
   persistent: false
   files: []
 depends_on: []
+related_skills:
+  - otel-sdk-setup
+  - otel-tracing-pattern
+  - otel-metrics-pattern
+  - otel-logging-pattern