@harness-engineering/cli 1.1.1 → 1.2.0

package/dist/agents/agents/skills/claude-code/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/claude-code/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/claude-code/detect-doc-drift/SKILL.md

@@ -1,159 +0,0 @@
-# Detect Doc Drift
-
-> Detect documentation that has drifted from code. Find stale docs before they mislead developers and AI agents.
-
-## When to Use
-
-- After completing a feature, bug fix, or refactoring
-- During code review — check if the changed files have associated docs that need updating
-- As a periodic hygiene check (weekly or per-sprint)
-- When `on_post_feature` or `on_doc_check` triggers fire
-- When onboarding reveals confusion caused by outdated documentation
-- NOT during active development — wait until the code is stable before checking docs
-- NOT for writing new documentation from scratch (use align-documentation instead)
-
-## Process
-
-### Phase 1: Scan — Run Drift Detection
-
-1. **Run `harness check-docs`** to identify all documentation issues. Capture the full output.
-
-2. **Run `harness cleanup --type drift`** for a deeper analysis that cross-references code changes against documentation references.
-
-3. **Optionally, run `git diff` against a baseline** (last release, last sprint, etc.) to identify which code files changed. This helps prioritize — docs for recently changed files are most likely to be drifted.
-
-### Phase 2: Identify — Classify Drift Types
-
-Categorize each finding into one of these drift types:
-
-**Renamed but not updated:**
-A function, class, variable, or file was renamed in code, but documentation still references the old name. This is the most common type of drift.
-
-- Example: `calculateShipping()` was renamed to `computeShippingCost()`, but AGENTS.md and three inline comments still say `calculateShipping`.
-
-**New code with no docs:**
-A new module, function, or API was added but no documentation entry exists. This is not "drift" in the strict sense but a gap that grows into drift over time.
-
-- Example: `src/services/notification-service.ts` was added two sprints ago. It has 5 public exports. No AGENTS.md section, no doc page, no inline doc comments beyond basic JSDoc.
-
-**Deleted code still referenced:**
-A file, function, or feature was removed, but documentation still describes it as if it exists. This actively misleads readers.
-
-- Example: `src/utils/legacy-parser.ts` was deleted. The architecture doc still includes it in the data flow diagram. AGENTS.md still warns about its quirks.
-
-**Changed behavior not reflected:**
-A function's signature, return type, error handling, or side effects changed, but the documentation describes the old behavior.
-
-- Example: `createUser()` now throws `ValidationError` instead of returning `null` on invalid input. The API docs still say "returns null if validation fails."
-
-**Moved code with stale paths:**
-A file or module was moved to a different directory, but documentation references the old path.
-
-- Example: `src/helpers/format.ts` was moved to `src/utils/format.ts`. Three doc files and AGENTS.md reference the old path.
-
-### Phase 3: Prioritize — Rank by Impact
-
-Not all drift is equally harmful. Prioritize fixes:
-
-**Critical (fix immediately):**
-
-- Public API documentation that describes wrong behavior — external consumers will write broken code
-- AGENTS.md sections that reference deleted files — AI agents will hallucinate about non-existent code
-- README getting-started guides with wrong commands — new developers cannot onboard
-
-**High (fix before next release):**
-
-- Internal API docs with wrong signatures — developers waste time debugging
-- Architecture docs with stale diagrams — wrong mental models lead to wrong decisions
-- Frequently accessed docs with broken links — high-traffic pages with dead ends
-
-**Medium (fix in next sprint):**
-
-- Internal docs for stable code — low change rate means low confusion rate
-- Comments in rarely modified files — few people read them
-- Edge case documentation — affects few users
-
-**Low (fix when convenient):**
-
-- Stylistic inconsistencies in docs (capitalization, formatting)
-- Redundant documentation that says the same thing in multiple places
-- Historical notes that are outdated but clearly marked as historical
-
-### Phase 4: Report — Generate Actionable Output
-
-For each drift finding, provide:
-
-1. **File and line number** of the drifted documentation
-2. **The specific stale content** (quote the exact text that is wrong)
-3. **What changed in code** (the commit, file, and nature of the change)
-4. **Suggested fix** (the replacement text or action needed)
-5. **Priority tier** (Critical / High / Medium / Low)
-
-Group findings by documentation file so that fixes can be applied file-by-file.
-
-## Harness Integration
-
-- **`harness check-docs`** — Primary tool. Scans all documentation files for broken references, stale paths, and missing entries.
-- **`harness cleanup --type drift`** — Deeper analysis that cross-references git history with documentation references to detect semantic drift.
-- **`harness cleanup --type drift --json`** — Machine-readable output for automated pipelines.
-- **`harness fix-drift`** — Auto-fix simple drift issues after review (use align-documentation skill for applying fixes).
-
-## Success Criteria
-
-- `harness check-docs` reports zero errors
-- All file paths referenced in documentation resolve to existing files
-- All function/class names referenced in documentation match current code
-- All API documentation matches current function signatures and behavior
-- No documentation references deleted files, functions, or features
-- Drift findings are prioritized and assigned to the appropriate fix cycle
-
-## Examples
-
-### Example: Renamed function detected
-
-**Drift finding:**
-
-```
-DRIFT: Renamed reference detected
-  Doc: AGENTS.md:47
-  Stale text: "Use `calculateShipping()` to compute shipping costs"
-  Code change: calculateShipping renamed to computeShippingCost (commit a1b2c3d)
-  File: src/services/shipping.ts:24
-  Priority: High
-  Suggested fix: Replace `calculateShipping()` with `computeShippingCost()`
-```
-
-### Example: Deleted file still documented
-
-**Drift finding:**
-
-```
-DRIFT: Reference to deleted file
-  Doc: docs/architecture.md:112
-  Stale text: "The legacy parser (src/utils/legacy-parser.ts) handles XML input"
-  Code change: File deleted in commit d4e5f6g, functionality merged into unified-parser.ts
-  Priority: Critical
-  Suggested fix: Update section to reference unified-parser.ts, remove legacy parser description
-```
-
-### Example: New module with no documentation
-
-**Drift finding:**
-
-```
-GAP: Undocumented module
-  File: src/services/notification-service.ts
-  Created: commit h7i8j9k (3 weeks ago)
-  Public exports: NotificationService, NotificationType, sendNotification
-  Imported by: 4 modules
-  Documentation references: 0
-  Priority: High
-  Suggested fix: Add AGENTS.md section describing purpose, constraints, and public API
-```
-
-## Escalation
-
-- **When drift is extensive (>30 findings):** Do not try to fix everything. Focus on Critical and High priority items. Create a tracking issue for the remaining items and schedule them across sprints.
-- **When you cannot determine the correct replacement text:** The code change may have been complex. Check the commit message and PR description for context. If still unclear, flag the finding for the original author to resolve.
-- **When documentation is in a format you cannot parse:** Some docs may be in wiki pages, Confluence, or other external systems. Report the finding with a link and flag it for manual review.
-- **When drift reveals a deeper problem (code changed but nobody knew):** This suggests a process gap. Recommend adding `harness check-docs` to the CI pipeline or pre-merge hooks to catch drift at the source.

package/dist/agents/agents/skills/claude-code/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/claude-code/enforce-architecture/SKILL.md

@@ -1,165 +0,0 @@
-# Enforce Architecture
-
-> Validate architectural layer boundaries and detect dependency violations. No code may violate layer constraints — this is a hard gate, not a suggestion.
-
-## When to Use
-
-- Before approving any pull request or merge
-- After writing new imports or module references
-- When adding a new module or package to the project
-- When `on_pre_commit` or `on_architecture_check` triggers fire
-- After refactoring that moves code between layers or modules
-- NOT when editing documentation, configuration, or non-code files
-- NOT when the violation is intentional and requires a constraint update (escalate instead)
-
-## Process
-
-### Phase 1: Load Constraints
-
-1. **Read `harness.config.json`** to understand the project's architectural constraints. The config defines:
-   - **Layers** — ordered list of architectural layers (e.g., `ui -> service -> repository -> domain`)
-   - **Dependency rules** — which layers may import from which (typically: layers may only import from layers below them)
-   - **Forbidden imports** — specific import paths that are never allowed in certain contexts
-   - **Boundary definitions** — which directories/packages belong to which layer
-
-2. **Understand the layer model.** In a typical layered architecture:
-   - Higher layers depend on lower layers (UI depends on Service, Service depends on Repository)
-   - Lower layers NEVER depend on higher layers (Repository must not import from UI)
-   - Same-layer imports may or may not be allowed depending on project config
-   - Cross-cutting concerns (logging, config) have their own rules
-
-### Phase 2: Run Dependency Checks
-
-1. **Run `harness check-deps`** to analyze all import statements against the constraint model. Capture the full JSON output.
-
-2. **Parse the results.** Each violation includes:
-   - The violating file and line number
-   - The forbidden import target
-   - The source layer and target layer
-   - The specific rule being violated
-
-### Phase 3: Analyze Violations
-
-For each violation, determine:
-
-1. **Which layers are involved.** Identify the source file's layer and the imported module's layer. Map them to the constraint model.
-
-2. **What rule is violated.** Common violation types:
-   - **Upward dependency** — a lower layer imports from a higher layer (e.g., repository importing from UI). This is the most serious type. It creates coupling that makes the lower layer untestable in isolation.
-   - **Skip-layer dependency** — a layer reaches past its immediate neighbor (e.g., UI importing directly from Repository, bypassing Service). This breaks encapsulation and makes the middle layer pointless.
-   - **Circular dependency** — two modules or layers depend on each other. This creates fragile coupling where changing either module risks breaking the other.
-   - **Forbidden import** — a specific import that is explicitly banned (e.g., importing a database driver outside the repository layer). This prevents implementation details from leaking.
-
-3. **Explain the impact.** For each violation, state:
-   - WHY the constraint exists (what architectural property it protects)
-   - WHAT would happen if the violation were allowed to persist
-   - HOW it affects testability, maintainability, and changeability
-
-### Phase 4: Guide Resolution
-
-For each violation, provide a specific fix:
-
-- **Upward dependency:** Introduce an interface or abstraction in the lower layer. The higher layer implements it; the lower layer depends only on the abstraction. Alternatively, use dependency injection.
-- **Skip-layer dependency:** Route the call through the intermediate layer. Add a method to the Service layer that delegates to the Repository, then have the UI call the Service.
-- **Circular dependency:** Break the cycle by extracting shared types into a common module that both can depend on, or restructure so the dependency flows in one direction only.
-- **Forbidden import:** Replace the forbidden import with the approved alternative. If no alternative exists, the feature may need to live in a different layer.
-
-## Common Violation Patterns
-
-### Pattern: "I just need one thing from that layer"
-
-A UI component imports a repository function directly because "it is just one query." Fix: add the query to the Service layer. The extra indirection is the architecture working correctly.
-
-### Pattern: "Shared types across layers"
-
-Two layers both need the same type definition. Fix: place shared types in the lowest layer that both depend on, or create a dedicated `types` or `shared` module at the bottom of the layer stack.
-
-### Pattern: "Test utilities importing production code from wrong layer"
-
-Test helpers import across layer boundaries for convenience. Fix: each layer's tests should only import from that layer and below. Test utilities should follow the same constraints as production code.
-
-### Pattern: "Circular dependency through re-exports"
-
-Module A re-exports from Module B, and Module B imports from Module A. The circular dependency is hidden by the re-export. Fix: identify the true dependency direction and remove the reverse path.
-
-## Harness Integration
-
-- **`harness check-deps`** — Primary tool. Analyzes all imports against the layer model defined in `harness.config.json`. Returns structured violation data including file, line, source layer, target layer, and rule violated.
-- **`harness check-deps --json`** — Machine-readable output for automated pipelines. Use this when parsing results programmatically.
-- **`harness validate`** — Includes dependency checking as part of full project validation. Use when you want a complete health check, not just architecture.
-
-## Success Criteria
-
-- `harness check-deps` reports zero violations
-- All imports flow downward through the layer stack (or follow explicitly configured exceptions)
-- No circular dependencies exist between modules or layers
-- No forbidden imports are present anywhere in the codebase
-- Every new module is assigned to the correct layer in the config
-- The layer model in `harness.config.json` accurately reflects the intended architecture
-
-## Examples
-
-### Example: Service layer importing from UI layer
-
-**Violation from `harness check-deps`:**
-
-```
-VIOLATION: Upward dependency
-  File: src/services/user-service.ts:12
-  Import: import { UserForm } from '../components/UserForm'
-  Source layer: service (level 2)
-  Target layer: ui (level 3)
-  Rule: service layer must not depend on ui layer
-```
-
-**Impact:** The UserService now depends on a React component. It cannot be used in a CLI tool, a background job, or tested without a DOM. The service layer should be framework-agnostic.
-
-**Resolution:**
-
-```typescript
-// BEFORE (violating)
-import { UserForm } from '../components/UserForm';
-const data = UserForm.defaultValues; // using UI defaults in service
-
-// AFTER (fixed)
-// Define the defaults where they belong — in the service layer
-const DEFAULT_USER_DATA: UserInput = { name: '', email: '' };
-```
-
-### Example: Circular dependency between modules
-
-**Violation from `harness check-deps`:**
-
-```
-VIOLATION: Circular dependency detected
-  Cycle: src/services/order-service.ts -> src/services/inventory-service.ts -> src/services/order-service.ts
-  order-service imports checkStock from inventory-service
-  inventory-service imports getOrderQuantity from order-service
-```
-
-**Resolution:** Extract the shared concern into a new module:
-
-```typescript
-// src/services/stock-calculator.ts (new, shared module)
-export function calculateRequiredStock(quantity: number, reserved: number): number {
-  return quantity - reserved;
-}
-```
-
-Both services import from `stock-calculator` instead of from each other. The cycle is broken.
-
-## Gates
-
-These are hard stops. Architecture violations are not warnings — they are errors.
-
-- **No code with layer violations may be approved or merged.** If `harness check-deps` reports violations, the code must be fixed before it proceeds.
-- **No new modules without layer assignment.** Every new directory or package must be mapped to a layer in `harness.config.json` before code is written in it.
-- **No "temporary" violations.** There is no TODO for architecture. Either the code respects the constraints or it does not ship.
-- **No suppressing violations without team approval.** If a violation needs to be allowed, the constraint in `harness.config.json` must be explicitly updated with a comment explaining why.
-
-## Escalation
-
-- **When a violation seems impossible to fix within the current architecture:** The architecture may need to evolve. Escalate to the human with a clear explanation of the constraint, the use case, and why they conflict. Propose options: update the constraint, restructure the code, or add a new layer.
-- **When `harness check-deps` reports false positives:** Verify the layer assignments in `harness.config.json` are correct. If a file is assigned to the wrong layer, fix the config. If the tool is genuinely wrong, report the issue.
-- **When fixing one violation creates another:** This usually indicates a deeper structural issue. Step back and look at the dependency graph as a whole rather than fixing violations one at a time.
-- **When the team wants to change the layer model:** This is a significant architectural decision. All existing code must be migrated to the new model. Plan this as a dedicated refactoring effort, not a side task.

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