@harness-engineering/cli 1.1.1 → 1.2.2

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

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

package/dist/agents/agents/skills/claude-code/validate-context-engineering/SKILL.md

@@ -1,129 +0,0 @@
-# Validate Context Engineering
-
-> Validate AGENTS.md quality and evolve it as the codebase changes. Good context engineering means AI agents always have accurate, current knowledge about the project.
-
-## When to Use
-
-- After adding new files, modules, or packages to the project
-- After renaming, moving, or deleting significant files
-- After changing public APIs, architectural patterns, or conventions
-- When onboarding a new contributor (human or AI) and want to verify context is current
-- When `on_context_check` or `on_pre_commit` triggers fire
-- Periodically (weekly or per-sprint) as a hygiene check
-- NOT when making trivial changes (typo fixes, comment updates, formatting)
-- NOT during active feature development — run this between features or at cycle boundaries
-
-## Process
-
-### Phase 1: Audit — Run Automated Checks
-
-1. **Run `harness validate`** to check overall project health. Review any context-related warnings or errors in the output.
-
-2. **Run `harness check-docs`** to detect documentation gaps, broken links, and stale references. Capture the full output for analysis.
-
-3. **Review AGENTS.md manually.** Automated tools catch structural issues but miss semantic drift. Read each section and ask: "Is this still true?"
-
-### Phase 2: Detect Gaps
-
-Categorize findings into four types:
-
-1. **Undocumented files.** New source files, modules, or packages that are not mentioned in AGENTS.md or any knowledge map section. These are the highest priority — an AI agent encountering these files has no context.
-
-2. **Broken links.** References to files, functions, or URLs that no longer exist. These actively mislead agents.
-
-3. **Stale sections.** Content that was accurate when written but no longer reflects reality. Examples: renamed functions still referenced by old name, removed features still described, changed conventions not updated.
-
-4. **Missing context.** Sections that exist but lack critical information. A module is listed but its purpose, constraints, or relationships are not explained. An AI agent can find the file but does not understand why it exists or how to use it correctly.
-
-### Phase 3: Suggest Updates
-
-For each gap, generate a specific suggestion:
-
-- **Undocumented files:** Draft a new section or entry with the file path, purpose, key exports, and relationship to existing modules. Use the existing AGENTS.md style and structure.
-- **Broken links:** Identify the correct target (renamed file, moved function) or recommend removal if the target was deleted.
-- **Stale sections:** Draft replacement text that reflects current reality. Show the diff between old and new.
-- **Missing context:** Draft additional content that fills the gap. Focus on what an AI agent needs to know: purpose, constraints, relationships, and gotchas.
-
-### Phase 4: Apply with Approval
-
-1. **Present all suggestions as a grouped list.** Organize by section of AGENTS.md for easy review.
-
-2. **Apply approved changes.** Update AGENTS.md with the approved suggestions. Preserve existing formatting and style.
-
-3. **Re-run `harness check-docs`** to verify all fixes are clean. No new issues should be introduced.
-
-4. **Commit the update.** Use a descriptive commit message that summarizes what was updated and why.
-
-## What Makes Good AGENTS.md Content
-
-Good context engineering treats AGENTS.md as a **dynamic knowledge base**, not a static document.
-
-- **Accuracy over completeness.** A small, accurate AGENTS.md is better than a comprehensive but stale one. Every statement must be verifiable against the current codebase.
-- **Purpose-first descriptions.** Do not just list files. Explain WHY each module exists, what problem it solves, and what constraints apply to it.
-- **Relationship mapping.** Show how modules connect. Which modules depend on which? What are the boundaries? An agent reading one section should understand how it fits into the whole.
-- **Gotchas and constraints.** Document the non-obvious. What will break if someone does X? What patterns must be followed? What is forbidden and why?
-- **Change-friendly structure.** Organize so that adding a new module means adding one section, not updating ten places. Use consistent formatting so automated tools can parse it.
-- **Actionable guidance.** Every section should help an agent make correct decisions. "This module handles authentication" is less useful than "This module handles authentication. All auth changes must go through the AuthService class. Direct database access for auth data is forbidden — use the repository layer."
-
-## Harness Integration
-
-- **`harness validate`** — Full project health check. Reports context gaps as part of overall validation.
-- **`harness check-docs`** — Focused documentation audit. Detects broken links, missing references, stale sections, and undocumented files.
-- **`harness fix-drift`** — Auto-fix simple drift issues (broken links, renamed references). Use after manual review confirms the fixes are correct.
-
-## Success Criteria
-
-- `harness check-docs` passes with zero errors and zero warnings
-- Every source file that contains public API or architectural significance is referenced in AGENTS.md
-- All file paths and function names in AGENTS.md match the current codebase
-- All links (internal and external) resolve correctly
-- AGENTS.md sections accurately describe current module purposes, constraints, and relationships
-- A new AI agent reading AGENTS.md can navigate the codebase and make correct decisions without additional guidance
-
-## Examples
-
-### Example: New module added but not documented
-
-**Audit output from `harness check-docs`:**
-
-```
-WARNING: Undocumented file detected: src/services/notification-service.ts
-  - File contains 3 public exports: NotificationService, NotificationType, sendNotification
-  - File is imported by 4 other modules
-  - No AGENTS.md section references this file
-```
-
-**Suggested update:**
-
-```markdown
-### Notification Service (`src/services/notification-service.ts`)
-
-Handles all outbound notifications (email, Slack, webhook). All notification delivery
-must go through `NotificationService` — direct use of transport libraries (nodemailer,
-Slack SDK) outside this module is forbidden.
-
-- `NotificationType` — enum of supported notification channels
-- `sendNotification()` — primary entry point; routes to the correct transport
-- Requires `NOTIFICATION_CONFIG` environment variables to be set
-- Respects rate limits defined in `harness.config.json` under `notifications`
-```
-
-**Apply:** Add the section under the Services heading in AGENTS.md. Re-run `harness check-docs` to confirm the warning is resolved.
-
-### Example: Renamed function still referenced by old name
-
-**Audit output:**
-
-```
-ERROR: Broken reference in AGENTS.md line 47: `calculateShipping()`
-  - Function was renamed to `computeShippingCost()` in commit abc123
-  - Located in src/services/shipping.ts
-```
-
-**Fix:** Replace `calculateShipping()` with `computeShippingCost()` in AGENTS.md. Verify no other references to the old name exist.
-
-## Escalation
-
-- **When AGENTS.md is severely outdated (>20 issues):** Do not attempt to fix everything at once. Prioritize: broken links first, then undocumented public APIs, then stale descriptions. Batch the work across multiple commits.
-- **When you are unsure whether a section is stale:** Check git blame for the section and compare against recent changes to the referenced files. If the section has not been updated since the referenced files changed, it is likely stale.
-- **When the project has no AGENTS.md:** Escalate to the human. Creating an AGENTS.md from scratch is a significant decision about project structure and should be done intentionally, not automatically.

package/dist/agents/agents/skills/claude-code/validate-context-engineering/skill.yaml

@@ -1,31 +0,0 @@
-name: validate-context-engineering
-version: "1.0.0"
-description: Validate repository context engineering practices (AGENTS.md, doc coverage, knowledge map)
-cognitive_mode: meticulous-verifier
-triggers:
-  - manual
-  - on_pr
-  - on_commit
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Glob
-cli:
-  command: harness skill run validate-context-engineering
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: validate-context-engineering
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on: []

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.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/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