@harness-engineering/cli 1.1.1 → 1.2.2

package/dist/agents/skills/gemini-cli/align-documentation/SKILL.md

@@ -1,181 +0,0 @@
-# Align Documentation
-
-> Sync documentation with code after implementation changes. Keep AGENTS.md, API docs, and architecture docs accurate by mapping code changes to their documentation impact.
-
-## When to Use
-
-- After completing a feature implementation (post-merge or post-commit)
-- After fixing a bug that changes observable behavior
-- After a refactoring that renames, moves, or restructures code
-- When detect-doc-drift reports findings that need fixing
-- When `on_post_feature` or `on_post_merge` triggers fire
-- NOT during active development — wait until the code is stable
-- NOT for creating documentation for a brand-new project (use validate-context-engineering for initial setup)
-- NOT for fixing code — this skill only changes documentation
-
-## Process
-
-### Phase 1: Detect — Identify What Changed
-
-1. **Run `git diff` against the appropriate baseline.** Choose the baseline based on context:
-   - After a feature: diff against the branch point (`git diff main...HEAD`)
-   - After a bug fix: diff against the commit before the fix
-   - After a refactoring: diff against the commit before refactoring started
-   - Periodic sync: diff against the last documentation sync commit
-
-2. **Extract the list of changed files.** For each changed file, note:
-   - File path (current and previous if renamed/moved)
-   - Nature of change (added, modified, deleted, renamed)
-   - Changed exports (new, removed, renamed, signature changed)
-   - Changed behavior (different return values, new error types, new side effects)
-
-3. **Run `harness check-docs`** to identify any documentation that already has broken references due to the changes.
-
-### Phase 2: Map — Connect Code Changes to Documentation
-
-For each changed file, identify all documentation that references it:
-
-**AGENTS.md sections:**
-
-- Knowledge map entries that reference the file path
-- Architecture descriptions that mention the module
-- Constraint documentation that references the file's layer or patterns
-- Onboarding guides that walk through the file
-
-**API documentation:**
-
-- JSDoc/TSDoc comments in the changed files themselves
-- Generated API doc pages that pull from the changed files
-- README examples that demonstrate the changed functions
-- Tutorial or guide pages that use the changed code
-
-**Architecture documentation:**
-
-- Diagrams that include the changed module
-- Data flow descriptions that reference the changed functions
-- Layer descriptions that list the changed file
-- Dependency documentation that references the changed imports
-
-**Inline code comments:**
-
-- Comments in OTHER files that reference the changed file or function
-- TODO comments that reference the changed behavior
-- Workaround comments that may no longer apply after the change
-
-### Phase 3: Generate — Draft Documentation Updates
-
-For each affected documentation location:
-
-1. **Draft the specific text change.** Show the old text and the new text. Keep the existing style and tone — documentation updates should be invisible in terms of voice.
-
-2. **Preserve context.** When updating a section, do not just change the specific reference — read the surrounding paragraph and ensure it still makes sense. A renamed function may require updating the explanatory text around it, not just the function name.
-
-3. **Handle deletions carefully.** When code is deleted, do not just delete the documentation reference. Consider whether the section should be removed entirely, replaced with information about the replacement, or noted as deprecated.
-
-4. **Add new sections when needed.** If a new module was added, draft a complete documentation section following the existing AGENTS.md structure and style.
-
-### Phase 4: Validate — Verify Documentation Accuracy
-
-1. **Run `harness check-docs`** to verify all links and references resolve correctly after the updates.
-
-2. **Cross-check each update against the actual code.** Read the updated documentation and verify every claim by looking at the code. Documentation that is wrong is worse than documentation that is missing.
-
-3. **Verify no orphaned references remain.** Search documentation files for any remaining references to old names, old paths, or deleted features.
-
-4. **Run `harness fix-drift`** to catch any remaining simple drift issues that manual review missed.
-
-5. **Commit the documentation update.** Use a commit message that references the original change: "docs: update AGENTS.md for notification service refactoring" or "docs: sync API docs after auth module rename."
-
-## What to Update
-
-### AGENTS.md Knowledge Map
-
-- File paths and module names (renamed or moved files)
-- Module purpose descriptions (changed responsibilities)
-- Constraint descriptions (new or changed rules)
-- Relationship descriptions (new or changed dependencies)
-- Gotcha sections (resolved gotchas, new gotchas)
-
-### Inline Code Comments
-
-- Function/class doc comments in the changed files (JSDoc, TSDoc)
-- Comments in other files that reference the changed code
-- TODO comments that reference completed or changed work
-- Workaround comments for issues that may now be resolved
-
-### Documentation Pages (docs/)
-
-- API reference pages that describe changed functions
-- Architecture pages that diagram changed modules
-- Tutorial and guide pages that demonstrate changed code
-- Getting-started guides if entry points changed
-- Changelog entries for user-facing changes
-
-## Harness Integration
-
-- **`harness check-docs`** — Run before and after updates. Identifies broken references and validates that all documentation links resolve.
-- **`harness fix-drift`** — Auto-fix simple drift issues (broken file paths, renamed references) after manual review confirms correctness.
-- **`harness fix-drift --json`** — Machine-readable output for tracking what was auto-fixed.
-- **`harness validate`** — Run after documentation changes to verify overall project health is maintained.
-
-## Success Criteria
-
-- `harness check-docs` passes with zero errors after documentation updates
-- Every code change from the diff has been mapped to its documentation impact
-- All file paths in documentation match current file locations
-- All function/class names in documentation match current code
-- All behavioral descriptions in documentation match current implementation
-- Documentation updates are committed with clear references to the triggering code change
-- No orphaned references to old names, paths, or deleted features remain
-
-## Examples
-
-### Example: Syncing docs after a module rename
-
-**Code change:** `src/services/mailer.ts` renamed to `src/services/email-service.ts`. Functions `sendMail()` and `formatMailBody()` renamed to `sendEmail()` and `formatEmailBody()`.
-
-**Documentation impact map:**
-
-```
-AGENTS.md:34      — "mailer.ts handles email delivery" → update path and description
-AGENTS.md:78      — "Use sendMail() for all outbound email" → update function name
-docs/api.md:156   — sendMail() API reference → update name and import path
-docs/arch.md:45   — architecture diagram lists "mailer" → update to "email-service"
-src/controllers/user-controller.ts:12 — comment "// delegates to mailer" → update
-```
-
-**Updates applied:**
-
-- AGENTS.md: updated two sections with new file path and function names
-- docs/api.md: updated function reference and import example
-- docs/arch.md: updated module name in architecture description
-- src/controllers/user-controller.ts: updated inline comment
-
-**Validation:** `harness check-docs` passes. All references resolve. Commit: "docs: sync documentation after mailer rename to email-service"
-
-### Example: Syncing docs after adding error handling
-
-**Code change:** `createUser()` in `src/services/user-service.ts` now throws `ValidationError` instead of returning `null` on invalid input.
-
-**Documentation impact map:**
-
-```
-docs/api.md:89    — "Returns null if validation fails" → update to describe thrown error
-AGENTS.md:52      — No mention of error handling → add note about ValidationError
-src/services/user-service.ts:15 — JSDoc @returns tag → update, add @throws tag
-```
-
-**Updates applied:**
-
-- docs/api.md: replaced "returns null" with "throws ValidationError" and added example
-- AGENTS.md: added note about error handling pattern in user-service section
-- JSDoc: updated @returns, added @throws ValidationError
-
-**Validation:** `harness check-docs` passes. Commit: "docs: update documentation for createUser error handling change"
-
-## Escalation
-
-- **When you cannot determine what documentation is affected:** Run `harness check-docs` for automated detection. For manual analysis, search all `.md` files and code comments for the old name/path. If the change is large, use detect-doc-drift first to get a complete inventory.
-- **When documentation is in an external system (wiki, Confluence):** Document the needed change and flag it for manual update. Include the specific text that needs changing and the correct replacement.
-- **When the code change is so large that documentation needs a rewrite:** Break the documentation update into sections. Update one section at a time, validating after each. Do not attempt a full rewrite in one pass.
-- **When you disagree with the existing documentation style:** Follow the existing style. Documentation alignment is about accuracy, not style improvement. Style changes should be a separate, deliberate effort.

package/dist/agents/skills/gemini-cli/align-documentation/skill.yaml

@@ -1,31 +0,0 @@
-name: align-documentation
-version: "1.0.0"
-description: Auto-fix documentation drift issues
-cognitive_mode: meticulous-verifier
-triggers:
-  - manual
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Write
-  - Edit
-cli:
-  command: harness skill run align-documentation
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: align-documentation
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on:
-  - detect-doc-drift

package/dist/agents/skills/gemini-cli/check-mechanical-constraints/SKILL.md

@@ -1,191 +0,0 @@
-# Check Mechanical Constraints
-
-> Run all mechanical constraint checks: linter rules, boundary schemas, and forbidden imports. These are automated, enforceable rules — if it can be checked by a machine, it must be.
-
-## When to Use
-
-- Before every commit (ideally via pre-commit hook)
-- Before submitting a pull request for review
-- After any code generation or automated refactoring
-- When `on_pre_commit` or `on_validate` triggers fire
-- After resolving merge conflicts (constraints may have been silently violated)
-- NOT as a substitute for code review — mechanical constraints catch structural issues, not logic errors
-- NOT when only editing non-code files (docs, config) unless those files have their own schema constraints
-
-## Process
-
-### Phase 1: Run All Checks
-
-1. **Run `harness validate`** to check project-wide constraints: file structure, naming conventions, required files, and configuration validity.
-
-2. **Run `harness linter validate`** to check all linter rules: code style, import restrictions, forbidden patterns, and boundary schemas.
-
-3. **Run `harness check-deps`** to check architectural layer boundaries. This is included here because dependency violations are mechanical — they can be detected purely from import statements and the constraint config.
-
-4. **Capture all output.** Combine results from all three commands into a single violation list for triage.
-
-### Phase 2: Categorize Violations by Severity
-
-Organize violations into three tiers:
-
-**Tier 1 — Errors (must fix before commit):**
-
-- Forbidden imports (importing banned modules)
-- Layer boundary violations (importing across architectural boundaries)
-- Schema violations (config files that do not match required schema)
-- Missing required files (every package must have index.ts, etc.)
-
-**Tier 2 — Warnings (must fix before merge):**
-
-- Naming convention violations (wrong casing, wrong prefix)
-- Import ordering issues
-- Unused exports detected by linter
-- Documentation file references that do not resolve
-
-**Tier 3 — Info (fix when convenient):**
-
-- Style suggestions (formatting that does not affect behavior)
-- Complexity warnings (functions exceeding thresholds)
-- Minor inconsistencies with project conventions
-
-### Phase 3: Auto-Fix Where Safe
-
-Some violations can be fixed automatically without risk:
-
-- **Import ordering** — reorder imports to match the configured convention. This never changes behavior.
-- **Formatting** — apply the project's formatter (prettier, etc.). Pure whitespace and style changes.
-- **Simple forbidden imports** — when a forbidden import has a known replacement (e.g., `import lodash` to `import lodash-es`), apply the substitution.
-- **Missing trailing commas, semicolons** — mechanical formatting fixes.
-
-**Rules for auto-fix:**
-
-- ONLY auto-fix violations that cannot change runtime behavior
-- Run the test suite after auto-fixing to confirm nothing broke
-- Present the auto-fix diff to the user for awareness (do not silently change code)
-- If unsure whether a fix is safe, do NOT auto-fix — report it for manual resolution
-
-### Phase 4: Report Remaining Violations
-
-For each violation that was not auto-fixed, report:
-
-1. **File and line number** — exact location of the violation
-2. **Rule name** — which constraint was violated
-3. **What it protects against** — why this rule exists (see reference below)
-4. **How to fix** — specific guidance for resolving this type of violation
-5. **Severity tier** — whether it blocks commit, merge, or is informational
-
-## What Each Constraint Type Protects Against
-
-### Forbidden Imports
-
-**Protects against:** Implementation detail leakage and unwanted coupling. When a library is forbidden in a layer, it is because using it there would create a dependency that makes the layer harder to test, replace, or maintain. Example: forbidding `fs` in the UI layer ensures UI code never directly accesses the filesystem.
-
-### Layer Boundaries
-
-**Protects against:** Architectural erosion. Without enforced boundaries, codebases gradually become a tangle where everything depends on everything. Layer boundaries ensure changes in one area do not ripple unpredictably through the whole system.
-
-### Boundary Schemas
-
-**Protects against:** Configuration drift and invalid state. When config files must match a schema, you catch invalid configurations at lint time rather than at runtime. This prevents deployment failures and hard-to-debug runtime errors.
-
-### Naming Conventions
-
-**Protects against:** Cognitive overhead and inconsistency. Consistent naming means developers (human and AI) can predict file locations, function names, and module structure without searching. It also ensures automated tools that rely on naming patterns continue to work.
-
-### Required File Rules
-
-**Protects against:** Incomplete modules. When every package must have an `index.ts` or every component must have a test file, you ensure that the project structure remains complete and navigable.
-
-### Import Ordering
-
-**Protects against:** Merge conflicts and readability issues. Consistent import ordering reduces git conflicts when multiple developers add imports to the same file. It also makes imports scannable at a glance.
-
-## Harness Integration
-
-- **`harness validate`** — Project-wide structural validation. Checks file structure, naming conventions, required files, and configuration schemas.
-- **`harness validate --json`** — Machine-readable output for parsing and categorization.
-- **`harness linter validate`** — Runs all configured linter rules. Checks code patterns, import restrictions, and style conventions.
-- **`harness check-deps`** — Architectural boundary enforcement. Checks all imports against the layer model.
-- **`harness check-deps --json`** — Machine-readable dependency check output.
-
-## Success Criteria
-
-- All three commands (`harness validate`, `harness linter validate`, `harness check-deps`) pass with zero errors
-- All Tier 1 violations are resolved before any commit
-- All Tier 2 violations are resolved before any merge to main
-- Auto-fixed changes are verified by running the test suite
-- No violations are suppressed without explicit team approval and a documented reason
-
-## Examples
-
-### Example: Forbidden import detected
-
-**Violation:**
-
-```
-ERROR [forbidden-import] src/components/Dashboard.tsx:3
-  Import 'pg' is forbidden in layer 'ui'
-  Rule: ui layer must not import database drivers
-```
-
-**What it protects against:** The UI layer importing a PostgreSQL driver means UI code could execute raw SQL queries, bypassing the service and repository layers entirely. This breaks testability (tests need a real database) and security (SQL injection risk from UI layer).
-
-**Fix:** Remove the direct database call. Add the needed query to the appropriate repository, expose it through the service layer, and call the service from the UI component.
-
-### Example: Auto-fixable import ordering
-
-**Violation:**
-
-```
-WARNING [import-order] src/services/auth-service.ts:1-8
-  Imports are not in the configured order
-  Expected: builtin -> external -> internal -> relative
-  Found: relative -> external -> builtin
-```
-
-**Auto-fix applied:**
-
-```typescript
-// BEFORE
-import { hashPassword } from './utils';
-import bcrypt from 'bcrypt';
-import { createHash } from 'crypto';
-
-// AFTER (auto-fixed)
-import { createHash } from 'crypto';
-import bcrypt from 'bcrypt';
-import { hashPassword } from './utils';
-```
-
-Tests re-run: all passing. No behavioral change.
-
-### Example: Schema violation in config
-
-**Violation:**
-
-```
-ERROR [schema-violation] harness.config.json:24
-  Property 'layers[2].allowedImports' must be an array of strings
-  Found: number (42)
-  Schema: harness-config-schema.json#/properties/layers/items/properties/allowedImports
-```
-
-**What it protects against:** An invalid config means `harness check-deps` will either crash or silently skip validation. The layer constraints would not be enforced, allowing violations to slip through undetected.
-
-**Fix:** Correct the config value to be a valid string array: `"allowedImports": ["@shared/types", "@shared/utils"]`.
-
-## Gates
-
-These are hard stops. Mechanical constraints are non-negotiable.
-
-- **No commits with Tier 1 violations.** Errors must be resolved before the code is committed. No exceptions.
-- **No merges with Tier 2 violations.** Warnings must be resolved before merging to the main branch.
-- **No suppressing rules without documentation.** If a rule must be disabled for a specific line or file, the suppression comment must explain WHY (not just disable the rule).
-- **No auto-fix without test verification.** Every auto-fix must be followed by a test run to confirm no behavioral change.
-
-## Escalation
-
-- **When a rule seems wrong for the project:** Rules are configured in `harness.config.json` and linter configs. If a rule does not fit, propose a config change with justification. Do not disable the rule inline.
-- **When a violation cannot be fixed without a larger refactor:** Document the violation, create a task for the refactor, and get team approval for a temporary inline suppression with a TODO linking to the task.
-- **When auto-fix produces unexpected changes:** Undo the auto-fix, report the issue, and fix manually. Auto-fix tools are not infallible.
-- **When multiple constraints conflict:** The stricter constraint wins. If `harness validate` says a file is required but `harness linter validate` says its contents violate a rule, fix the contents to satisfy both. Escalate if truly irreconcilable.

package/dist/agents/skills/gemini-cli/check-mechanical-constraints/skill.yaml

@@ -1,32 +0,0 @@
-name: check-mechanical-constraints
-version: "1.0.0"
-description: Run all mechanical constraint checks (context validation + architecture)
-cognitive_mode: meticulous-verifier
-triggers:
-  - manual
-  - on_pr
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Glob
-cli:
-  command: harness skill run check-mechanical-constraints
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: check-mechanical-constraints
-    path: string
-type: rigid
-state:
-  persistent: false
-  files: []
-depends_on:
-  - validate-context-engineering
-  - enforce-architecture

package/dist/agents/skills/gemini-cli/cleanup-dead-code/SKILL.md

@@ -1,202 +0,0 @@
-# Cleanup Dead Code
-
-> Entropy analysis and safe cleanup. Find unused exports, dead files, and pattern violations — then remove them without breaking anything.
-
-## When to Use
-
-- After a major refactoring or feature removal
-- When the codebase feels "heavy" — too many files, unclear what is used
-- As a periodic hygiene task (monthly or per-quarter)
-- When `on_entropy_check` triggers fire
-- After deleting a feature flag and its associated code paths
-- When `harness cleanup` reports growing entropy in the project health dashboard
-- NOT during active feature development — dead code cleanup is a separate, focused task
-- NOT when tests are failing — fix tests first, then clean up
-- NOT under time pressure — dead code removal requires careful verification
-
-## Process
-
-### Phase 1: Analyze — Run Entropy Report
-
-1. **Run `harness cleanup`** to generate a full entropy report. This analyzes:
-   - **Dead exports** — functions, classes, and constants that are exported but never imported anywhere
-   - **Unused files** — files that are not imported by any other file in the project
-   - **Pattern violations** — code that violates established project patterns (e.g., a service file without a corresponding test file)
-   - **Orphaned dependencies** — npm packages listed in package.json but never imported
-
-2. **Run `harness cleanup --type dead-code --json`** for machine-readable output focused specifically on unused code.
-
-3. **Review the report summary.** Note the total count and distribution. A few dead exports are normal; dozens suggest accumulated entropy from incomplete refactorings.
-
-### Phase 2: Categorize — Safe vs. Needs Review
-
-**Safe to auto-fix (remove without further analysis):**
-
-- Exports that are not imported anywhere AND not referenced in any config file
-- Files that are not imported anywhere AND have no side effects (no top-level execution)
-- Commented-out code blocks (dead by definition)
-- Unused local variables and imports within a file (linter can catch these)
-
-**Needs human review before removal:**
-
-- Exports that APPEAR unused but might be consumed dynamically (see "What NOT to Delete" below)
-- Files that appear unused but are entry points (CLI scripts, test fixtures, config files)
-- Code that is only used in specific build configurations or environments
-- Exports from a public package — external consumers may depend on them
-
-### Phase 3: Apply Safe Fixes
-
-For each item categorized as safe:
-
-1. **Remove the dead code.** Delete the export, function, file, or import.
-
-2. **Run `harness fix-drift`** to update any documentation references that pointed to the deleted code.
-
-3. **Run the full test suite.** All tests must pass. If any test fails:
-   - **STOP.** The code was not actually dead — something depends on it.
-   - **Undo the deletion immediately.**
-   - **Reclassify** the item as "needs human review" and investigate the hidden dependency.
-
-4. **Run `harness validate` and `harness check-deps`.** Both must pass.
-
-5. **Commit the cleanup.** Group related removals into logical commits (e.g., "remove unused shipping utilities" not "delete dead code").
-
-### Phase 4: Report Remaining Items
-
-For items that need human review, report:
-
-1. **What it is** — file path, export name, what it does
-2. **Why it appears dead** — no static imports found
-3. **Why it might not be dead** — dynamic import patterns, external consumers, test utilities
-4. **Recommended action** — delete with confidence, delete with caution, or keep
-
-## What NOT to Delete
-
-These patterns make code APPEAR dead when it is actually in use:
-
-### Dynamically imported modules
-
-```typescript
-// This import won't show up in static analysis
-const module = await import(`./plugins/${pluginName}`);
-```
-
-Files in a `plugins/` directory may appear unused but are loaded dynamically at runtime. Check for `import()` calls, `require()` with variables, and glob-based loading patterns.
-
-### Test utilities and fixtures
-
-```typescript
-// test-helpers.ts — only imported by test files
-export function createMockUser() { ... }
-```
-
-Test utility files may appear unused if the analysis excludes test files. Verify that `harness cleanup` includes test files in its import graph.
-
-### Type-only exports
-
-```typescript
-// Only used as a type, never as a value
-export interface UserConfig { ... }
-```
-
-Some analysis tools miss type-only imports (`import type { UserConfig }`). Verify before deleting any exported interface or type alias.
-
-### Package entry points
-
-```typescript
-// index.ts — re-exports for external consumers
-export { createClient } from './client';
-```
-
-The entry point of a package re-exports things for external consumers. These exports may have zero internal imports but are the public API.
-
-### Side-effect files
-
-```typescript
-// polyfills.ts — imported for side effects, not for exports
-import './polyfills';
-```
-
-Some files are imported for their side effects (polyfills, global registrations, CSS). They have no exports but are not dead.
-
-### Environment-specific code
-
-```typescript
-// Only used when FEATURE_FLAG_X is enabled
-if (process.env.FEATURE_FLAG_X) {
-  const handler = require('./experimental-handler');
-}
-```
-
-Code behind feature flags or environment checks may appear dead in the default configuration.
-
-## Harness Integration
-
-- **`harness cleanup`** — Full entropy analysis. Reports dead exports, unused files, pattern violations, and orphaned dependencies.
-- **`harness cleanup --type dead-code`** — Focused analysis on unused code specifically.
-- **`harness cleanup --type dead-code --json`** — Machine-readable output for automation.
-- **`harness fix-drift`** — Update documentation after removing dead code. Ensures deleted items are not still referenced in docs.
-- **`harness validate`** — Run after cleanup to verify project structure remains valid.
-- **`harness check-deps`** — Run after cleanup to verify no dependency violations were introduced.
-
-## Success Criteria
-
-- `harness cleanup` reports zero dead exports and zero unused files (or all remaining items are documented as intentional)
-- All tests pass after every deletion
-- `harness validate` and `harness check-deps` pass after cleanup
-- Documentation references to deleted code are updated or removed
-- No dynamically-imported, type-only, or side-effect code was accidentally deleted
-- Each cleanup commit is atomic and has a descriptive message explaining what was removed and why
-
-## Examples
-
-### Example: Removing unused utility functions
-
-**Entropy report:**
-
-```
-DEAD EXPORT: src/utils/string-helpers.ts
-  - capitalizeFirst() — 0 imports found
-  - truncateWithEllipsis() — 0 imports found
-  - slugify() — 3 imports found (ACTIVE, not dead)
-```
-
-**Action:** Remove `capitalizeFirst` and `truncateWithEllipsis` from the file. Keep `slugify`. Run tests — all pass. Commit: "remove unused capitalizeFirst and truncateWithEllipsis from string-helpers"
-
-### Example: Detecting a false positive
-
-**Entropy report:**
-
-```
-UNUSED FILE: src/plugins/markdown-renderer.ts
-  - 0 static imports found
-  - File contains: export default class MarkdownRenderer
-```
-
-**Investigation:** Check for dynamic imports:
-
-```typescript
-// src/plugins/index.ts
-const renderer = await import(`./${format}-renderer`);
-```
-
-**Result:** False positive. The file is loaded dynamically based on the `format` variable. Mark as intentional and add a comment in the file explaining the dynamic loading pattern.
-
-### Example: Orphaned npm dependency
-
-**Entropy report:**
-
-```
-ORPHANED DEPENDENCY: moment (package.json)
-  - 0 imports of 'moment' found in src/
-  - Last imported in commit abc123 (removed 3 months ago)
-```
-
-**Action:** Remove `moment` from package.json dependencies. Run `npm install` to update lockfile. Run tests — all pass. Commit: "remove unused moment dependency"
-
-## Escalation
-
-- **When removing code causes unexpected test failures:** The code has a hidden dependency. Undo the deletion, investigate the dependency chain, and document the finding. The code is not dead — it is just hard to trace.
-- **When the entropy report is very large (>50 items):** Do not attempt to clean everything at once. Pick the highest-confidence dead code (files with zero imports, no dynamic patterns) and clean those first. Schedule the rest across multiple sessions.
-- **When you are unsure if an export is used externally:** Check if the code is in a published package. If so, removing an export is a breaking change. Deprecate first, then remove in a major version.
-- **When dead code is tangled with live code in the same file:** Extract the live code first (using harness-refactoring), then delete the remaining dead code. Do not try to surgically remove dead code from a complex file in one step.

package/dist/agents/skills/gemini-cli/cleanup-dead-code/skill.yaml

@@ -1,30 +0,0 @@
-name: cleanup-dead-code
-version: "1.0.0"
-description: Detect unused exports and dead code
-cognitive_mode: diagnostic-investigator
-triggers:
-  - manual
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Glob
-  - Grep
-cli:
-  command: harness skill run cleanup-dead-code
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: cleanup-dead-code
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on: []