@harness-engineering/cli 1.1.1 → 1.2.0

package/dist/agents/agents/skills/gemini-cli/add-harness-component/SKILL.md

@@ -1,182 +0,0 @@
-# Add Harness Component
-
-> Add layers, documentation, components, or skills to an existing harness project with proper integration. Validate against existing constraints, wire into architecture, and verify the result.
-
-## When to Use
-
-- Adding a new layer to the project's architecture
-- Adding a new documentation file that harness should track
-- Adding a new component (module, service, package) that must be wired into existing layer boundaries
-- Adding a new skill to the project's skill library
-- When a plan calls for introducing a new architectural boundary or module
-- NOT when initializing a project from scratch (use initialize-harness-project)
-- NOT when modifying an existing component (use standard editing workflows)
-- NOT when removing components (manual process — removing requires careful dependency analysis)
-
-## Process
-
-### Phase 1: DETERMINE — Identify What to Add
-
-1. **Clarify the component type.** Ask if not obvious from context:
-   - **Layer:** A new architectural boundary (e.g., adding an "infrastructure" layer to a project that only has "business" and "data")
-   - **Document:** A documentation file that harness should track for drift detection (e.g., API docs, architecture decision records)
-   - **Component:** A code module, service, or package that lives within an existing layer
-   - **Skill:** A new harness skill definition for the project's workflow
-
-2. **Gather requirements.** For each type:
-   - **Layer:** Name, which directories belong to it, which layers it can import from, which layers can import from it
-   - **Document:** Path, what it documents, which code files it relates to
-   - **Component:** Name, which layer it belongs to, what it depends on, what will depend on it
-   - **Skill:** Name, purpose, type (rigid or flexible), triggers
-
-3. **Check prerequisites.** The project must already be initialized with harness. If `harness.yaml` does not exist, stop and run initialize-harness-project first.
-
-### Phase 2: VALIDATE — Check Against Existing Constraints
-
-1. **Read the current configuration.** Load `harness.yaml` and `AGENTS.md` to understand existing layers, constraints, and architecture.
-
-2. **Verify the new component does not conflict:**
-   - Does the layer name already exist?
-   - Does the component directory already exist?
-   - Would the new dependency relationships create circular imports?
-   - Does the component violate any existing forbidden-import rules?
-
-3. **If conflicts are found,** report them clearly: "Adding layer X would conflict with existing layer Y because [reason]. Options: [A] rename, [B] merge into existing layer, [C] restructure. Which do you prefer?"
-
-4. **Run `harness check-deps`** on the current state to establish a clean baseline. If it already fails, fix existing violations before adding new components.
-
-### Phase 3: ADD — Create the Component
-
-1. **Run `harness add` with appropriate arguments:**
-   - Layer: `harness add layer <name> --dirs <dir1,dir2> --imports <allowed-layers>`
-   - Document: `harness add doc <path> --tracks <related-code-paths>`
-   - Component: `harness add component <name> --layer <layer-name>`
-   - Skill: `harness add skill <name> --type <rigid|flexible>`
-
-2. **Review generated files and configuration changes.** `harness add` modifies `harness.yaml` and may generate template files. Check that the changes look correct.
-
-3. **Create the actual code or content.** `harness add` creates the configuration entry but not necessarily the implementation. Create the directories, files, and initial code as needed.
-
-### Phase 4: WIRE — Integrate into Architecture
-
-1. **Update imports and exports.** If the new component needs to be imported by existing code, add the imports. If existing code needs to be aware of the new layer, update barrel files or index modules.
-
-2. **Update `AGENTS.md`.** Add the new component to the architecture section. Document its purpose, boundaries, and relationships to other components. This keeps agent instructions accurate.
-
-3. **Update layer configuration** if the new component changes dependency relationships. Ensure `harness.yaml` reflects the actual import graph.
-
-4. **For new skills:** Write the `skill.yaml` and `SKILL.md` files following the harness skill format. Use harness-skill-authoring for guidance on writing good skill content.
-
-### Phase 5: VERIFY — Confirm Integration
-
-1. **Run `harness validate`** to verify the full project configuration is still valid after the addition.
-
-2. **Run `harness check-deps`** to verify no dependency violations were introduced. The new component's imports must respect layer boundaries.
-
-3. **If validation fails,** fix the issues before committing. Common causes:
-   - New layer not properly registered in `harness.yaml`
-   - Component placed in wrong directory for its declared layer
-   - Imports from forbidden layers
-   - `AGENTS.md` references outdated architecture
-
-4. **Commit the addition.** All new and modified files in a single atomic commit.
-
-## Harness Integration
-
-- **`harness add layer <name>`** — Register a new architectural layer with directory mappings and import rules.
-- **`harness add doc <path>`** — Register a documentation file for drift tracking.
-- **`harness add component <name> --layer <layer>`** — Register a new code component within an existing layer.
-- **`harness add skill <name> --type <type>`** — Scaffold a new skill definition.
-- **`harness validate`** — Verify project configuration after the addition.
-- **`harness check-deps`** — Verify dependency constraints are respected after the addition.
-
-## Success Criteria
-
-- The new component is properly registered in `harness.yaml`
-- The component's files exist in the correct directories for its declared layer
-- `AGENTS.md` is updated to reflect the new component
-- `harness validate` passes after the addition
-- `harness check-deps` passes after the addition (no new violations)
-- No circular dependencies were introduced
-- The addition is committed as a single atomic commit
-
-## Examples
-
-### Example: Adding a New Layer
-
-```
-Human: "We need an infrastructure layer for external API clients."
-
-DETERMINE: Adding a layer. Name: infrastructure. Dirs: src/infrastructure/.
-  Imports from: (none — infrastructure is a leaf layer, no internal dependencies).
-  Imported by: business layer (services call external APIs through infrastructure).
-
-VALIDATE:
-  Read harness.yaml — existing layers: presentation, business, data.
-  No conflict with "infrastructure" name.
-  Run: harness check-deps — passes (clean baseline).
-
-ADD:
-  harness add layer infrastructure --dirs src/infrastructure --imports none
-  mkdir -p src/infrastructure
-
-WIRE:
-  Update harness.yaml: allow business → infrastructure imports.
-  Update AGENTS.md: document infrastructure layer purpose and boundaries.
-
-VERIFY:
-  harness validate    # Pass
-  harness check-deps  # Pass
-  git add harness.yaml AGENTS.md src/infrastructure/
-  git commit -m "feat: add infrastructure layer for external API clients"
-```
-
-### Example: Adding a Document for Drift Tracking
-
-```
-Human: "Track our API specification for documentation drift."
-
-DETERMINE: Adding a document. Path: docs/api-spec.md.
-  Tracks: src/routes/, src/models/response.ts.
-
-ADD:
-  harness add doc docs/api-spec.md --tracks src/routes,src/models/response.ts
-
-WIRE:
-  Update AGENTS.md: note that docs/api-spec.md is tracked for drift.
-
-VERIFY:
-  harness validate  # Pass
-  git add harness.yaml AGENTS.md
-  git commit -m "feat: track API spec for documentation drift detection"
-```
-
-### Example: Adding a Component to an Existing Layer
-
-```
-Human: "Add a notification service to the business layer."
-
-DETERMINE: Adding a component. Name: notification-service. Layer: business.
-  Depends on: data layer (notification repository). Depended on by: presentation layer (routes).
-
-VALIDATE:
-  Read harness.yaml — business layer exists, maps to src/services/.
-  No existing notification-service directory.
-  business → data is an allowed import. Presentation → business is allowed.
-  Run: harness check-deps — passes.
-
-ADD:
-  harness add component notification-service --layer business
-  Create src/services/notification-service.ts
-  Create src/services/notification-service.test.ts
-
-WIRE:
-  Add export to src/services/index.ts (if barrel file exists).
-  Update AGENTS.md: add notification service to business layer component list.
-
-VERIFY:
-  harness validate    # Pass
-  harness check-deps  # Pass
-  git add harness.yaml AGENTS.md src/services/notification-service.*
-  git commit -m "feat: add notification service to business layer"
-```

package/dist/agents/agents/skills/gemini-cli/add-harness-component/skill.yaml

@@ -1,32 +0,0 @@
-name: add-harness-component
-version: "1.0.0"
-description: Add a component to an existing harness project
-cognitive_mode: constructive-architect
-triggers:
-  - manual
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Write
-  - Edit
-  - Glob
-cli:
-  command: harness skill run add-harness-component
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: add-harness-component
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on:
-  - initialize-harness-project

package/dist/agents/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/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/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/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: []

package/dist/agents/agents/skills/gemini-cli/detect-doc-drift/skill.yaml

@@ -1,30 +0,0 @@
-name: detect-doc-drift
-version: "1.0.0"
-description: Detect documentation that has drifted from code
-cognitive_mode: diagnostic-investigator
-triggers:
-  - manual
-  - on_pr
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Glob
-cli:
-  command: harness skill run detect-doc-drift
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: detect-doc-drift
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on: []

package/dist/agents/agents/skills/gemini-cli/enforce-architecture/skill.yaml

@@ -1,31 +0,0 @@
-name: enforce-architecture
-version: "1.0.0"
-description: Validate architectural layer boundaries and detect circular dependencies
-cognitive_mode: meticulous-verifier
-triggers:
-  - manual
-  - on_pr
-  - on_commit
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Glob
-cli:
-  command: harness skill run enforce-architecture
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: enforce-architecture
-    path: string
-type: rigid
-state:
-  persistent: false
-  files: []
-depends_on: []