@harness-engineering/cli 1.1.0 → 1.2.0

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

@@ -1,260 +0,0 @@
-# Harness Onboarding
-
-> Navigate an existing harness-managed project and generate a structured orientation for new team members. Map the codebase, understand constraints, identify the adoption level, and produce a summary that gets someone productive fast.
-
-## When to Use
-
-- A new developer (human or agent) is joining a harness-managed project for the first time
-- Resuming work on a project after extended time away and needing to re-orient
-- When `on_project_init` triggers fire in an existing project (agent starting a new session)
-- When someone asks "how does this project work?" or "where do I start?"
-- NOT when initializing a new project (use initialize-harness-project)
-- NOT when the project has no harness configuration (onboard to harness first with initialize-harness-project)
-- NOT when deep-diving into a specific module (use standard code exploration — onboarding gives the big picture)
-
-## Process
-
-### Phase 1: READ — Load Project Configuration
-
-1. **Read `AGENTS.md`.** This is the primary source of truth for agent behavior in the project. Note:
-   - Project description and purpose
-   - Architecture overview
-   - Conventions and coding standards
-   - Constraints and forbidden patterns
-   - Any special instructions or warnings
-
-2. **Read `harness.yaml`.** Extract:
-   - Project name and stack
-   - Adoption level (basic, intermediate, advanced)
-   - Layer definitions and their directory mappings
-   - Dependency constraints between layers
-   - Registered skills and their triggers
-   - Persona configuration (if present)
-
-3. **Read `.harness/learnings.md`** if it exists. This contains hard-won insights from previous sessions — decisions made, gotchas discovered, patterns that worked or failed. Summarize the most recent and most important entries.
-
-4. **Read `.harness/state.json`** if it exists. This reveals what was happening in the last session — current phase, active task, any blockers that were recorded.
-
-### Phase 2: MAP — Understand the Codebase Structure
-
-1. **Map the technology stack.** Identify from package files, configuration, and code:
-   - Language(s) and version(s)
-   - Framework(s) and major libraries
-   - Test framework and test runner command
-   - Build tool and build command
-   - Package manager
-   - Database or data stores (if applicable)
-
-2. **Map the architecture.** Walk the directory structure and identify:
-   - Top-level organization pattern (monorepo, single package, workspace)
-   - Source code location and entry points
-   - Layer boundaries (from `harness.yaml` and actual directory structure)
-   - Shared utilities or common modules
-   - Configuration files and their purposes
-
-3. **Map the conventions.** Look for patterns in existing code:
-   - File naming conventions (kebab-case, camelCase, PascalCase)
-   - Test file location and naming (co-located, separate directory, `.test.ts` vs `.spec.ts`)
-   - Import style (relative, aliases, barrel files)
-   - Error handling patterns
-   - Logging patterns
-   - Code formatting (detect from config files: `.prettierrc`, `.eslintrc`, `biome.json`)
-
-4. **Map the constraints.** Identify what is restricted:
-   - Forbidden imports (from `harness.yaml` dependency constraints)
-   - Layer boundary rules (which layers can import from which)
-   - Linting rules that encode architectural decisions
-   - Any constraints documented in `AGENTS.md` that are not yet automated
-
-5. **Map the concerns.** Identify areas that need attention:
-   - Are there TODOs or FIXMEs in the code?
-   - Does `harness validate` pass cleanly, or are there warnings?
-   - Are there known blockers in `.harness/state.json`?
-   - Is documentation up to date with the code?
-   - Are there tests? What is the approximate coverage?
-
-### Phase 3: ORIENT — Identify Adoption Level and Maturity
-
-1. **Confirm the adoption level** matches what `harness.yaml` declares:
-   - Basic: `AGENTS.md` and `harness.yaml` exist but no layers or constraints
-   - Intermediate: Layers defined, dependency constraints enforced, at least one custom skill
-   - Advanced: Personas, state management, learnings, CI integration
-
-2. **Assess harness health.** Run `harness validate` and note any issues. A project that declares intermediate but fails validation is not truly intermediate.
-
-3. **Identify available skills.** List the skills configured for the project. Note which are custom (project-specific) vs. standard (harness-provided). Each skill represents a workflow the team has formalized.
-
-### Phase 4: SUMMARIZE — Generate Orientation Output
-
-1. **Produce a structured orientation summary.** This is the deliverable. Format:
-
-```markdown
-# Project Orientation: <project-name>
-
-## Overview
-
-<1-2 sentence project description from AGENTS.md>
-
-## Stack
-
-- Language: <language> <version>
-- Framework: <framework>
-- Tests: <test framework> (`<test command>`)
-- Build: <build tool> (`<build command>`)
-- Package manager: <pm>
-
-## Architecture
-
-<Brief description of top-level organization>
-
-### Layers
-
-| Layer   | Directories | Can Import From   |
-| ------- | ----------- | ----------------- |
-| <layer> | <dirs>      | <allowed imports> |
-
-### Key Components
-
-- <component>: <purpose> (<location>)
-
-## Constraints
-
-- <constraint 1>
-- <constraint 2>
-
-## Conventions
-
-- <convention 1>
-- <convention 2>
-
-## Harness Status
-
-- Adoption level: <level>
-- Validation: <pass/fail with summary>
-- Available skills: <list>
-- State: <current phase/task if applicable>
-
-## Recent Learnings
-
-- <most relevant learnings from .harness/learnings.md>
-
-## Getting Started
-
-1. <first thing to do>
-2. <second thing to do>
-3. <third thing to do>
-```
-
-2. **Tailor "Getting Started" to the audience.** For a new developer: how to set up the dev environment and run tests. For an agent resuming work: what the current task is and what to do next. For a reviewer: where to look and what constraints to check.
-
-3. **Present the summary to the human.** Do not write it to a file unless asked. The orientation is a conversation artifact, not a project artifact.
-
-## Harness Integration
-
-- **`harness validate`** — Run during onboarding to assess project health and identify any configuration issues.
-- **`harness skill list`** — List available skills to understand what workflows the team has formalized.
-- **`harness check-deps`** — Run to verify dependency constraints are passing, which confirms layer boundaries are respected.
-- **`harness state show`** — View current state to understand where the last session left off.
-- **`AGENTS.md`** — Primary source of project context and agent instructions.
-- **`harness.yaml`** — Source of structural configuration (layers, constraints, skills).
-- **`.harness/learnings.md`** — Historical context and institutional knowledge.
-
-## Success Criteria
-
-- All four configuration sources were read (`AGENTS.md`, `harness.yaml`, `.harness/learnings.md`, `.harness/state.json`)
-- Technology stack is accurately identified (language, framework, test runner, build tool)
-- Architecture is mapped with correct layer boundaries and dependency directions
-- Conventions are identified from actual code patterns, not assumed
-- Constraints are enumerated from both `harness.yaml` and `AGENTS.md`
-- Adoption level is confirmed (not just declared — validated)
-- A structured orientation summary is produced with all sections filled
-- The "Getting Started" section is actionable and tailored to the audience
-- `harness validate` was run and results are reported
-
-## Examples
-
-### Example: Onboarding to an Intermediate TypeScript Project
-
-**READ:**
-
-```
-Read AGENTS.md:
-  - Project: Widget API — REST service for widget lifecycle management
-  - Stack: TypeScript, Express, Vitest, PostgreSQL
-  - Conventions: zod validation, repository pattern, kebab-case files
-
-Read harness.yaml:
-  - Level: intermediate
-  - Layers: presentation (src/routes/), business (src/services/), data (src/repositories/)
-  - Constraints: presentation → business OK, business → data OK, data → presentation FORBIDDEN
-
-Read .harness/learnings.md:
-  - "Date comparison needs UTC normalization — use Date.now()"
-  - "The notifications table has a unique constraint on (userId, type) — upsert, don't insert"
-
-Read .harness/state.json:
-  - Position: Phase execute, Task 4 of 6
-  - Blocker: none
-```
-
-**MAP:**
-
-```
-Stack: TypeScript 5.3, Express 4, Vitest 1.2, pg (node-postgres)
-Architecture: Single package, 3 layers, entry point src/index.ts
-Conventions: kebab-case files, co-located tests (.test.ts), barrel exports
-Constraints: 3 layers with strict downward-only imports
-Concerns: harness validate passes, 47 tests all passing
-```
-
-**ORIENT:**
-
-```
-Adoption level: intermediate (confirmed — layers defined, constraints enforced)
-Skills: harness-tdd, harness-execution, harness-code-review
-State: Mid-execution on a 6-task notification feature plan
-```
-
-**SUMMARIZE:**
-
-```
-Produce orientation with all sections. Getting Started for this context:
-1. Read the plan at docs/plans/2026-03-14-notifications-plan.md
-2. Resume execution at Task 4 (state shows Tasks 1-3 complete)
-3. Note the UTC normalization gotcha from learnings before working with dates
-```
-
-### Example: Onboarding to a Basic Project
-
-**READ:**
-
-```
-Read AGENTS.md — exists, minimal content
-Read harness.yaml — level: basic, no layers defined
-No .harness/learnings.md
-No .harness/state.json
-```
-
-**MAP and SUMMARIZE:**
-
-```
-Adoption level: basic (confirmed — no layers or constraints)
-Getting Started:
-1. Run npm install && npm test to verify the project builds and tests pass
-2. Read AGENTS.md for project context and conventions
-3. Consider migrating to intermediate level to add layer boundaries
-   (use initialize-harness-project to upgrade)
-```
-
-## Adoption Maturity
-
-A mental model for where a team sits on the harness adoption curve. Not prescriptive — just orientation.
-
-| Level | Name               | Description                                                                                                                                                          |
-| ----- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 1     | **Manual**         | Write `CLAUDE.md` by hand, run commands manually. Harness is a reference, not a tool.                                                                                |
-| 2     | **Repeatable**     | Skills installed, agent follows conventions consistently. Workflows are codified but enforcement is human-driven.                                                    |
-| 3     | **Automated**      | Mechanical gates in CI. `harness validate` runs on PRs. Failures auto-log to `.harness/failures.md`. The system catches mistakes before humans do.                   |
-| 4     | **Self-improving** | Learnings accumulate in `.harness/learnings.md`. Agents reference past failures before planning. Institutional knowledge compounds across sessions and team members. |
-
-Most teams start at Level 1 and move up as they see the value. There is no pressure to reach Level 4 — each level delivers real benefits on its own.

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

@@ -1,30 +0,0 @@
-name: harness-onboarding
-version: "1.0.0"
-description: Onboard a new developer to a harness-managed project
-cognitive_mode: advisory-guide
-triggers:
-  - manual
-  - on_project_init
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Glob
-cli:
-  command: harness skill run harness-onboarding
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: harness-onboarding
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on: []

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

@@ -1,33 +0,0 @@
-name: harness-parallel-agents
-version: "1.0.0"
-description: Coordinate multiple agents working in parallel on a harness project
-cognitive_mode: constructive-architect
-triggers:
-  - manual
-  - on_new_feature
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Write
-  - Edit
-  - Glob
-  - Grep
-cli:
-  command: harness skill run harness-parallel-agents
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: harness-parallel-agents
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on: []

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

@@ -1,47 +0,0 @@
-name: harness-planning
-version: "1.0.0"
-description: Structured project planning with harness constraints and validation
-cognitive_mode: constructive-architect
-triggers:
-  - manual
-  - on_new_feature
-  - on_project_init
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Write
-  - Edit
-  - Glob
-cli:
-  command: harness skill run harness-planning
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: harness-planning
-    path: string
-type: rigid
-phases:
-  - name: scope
-    description: Define goals and constraints
-    required: true
-  - name: decompose
-    description: Break work into tasks
-    required: true
-  - name: sequence
-    description: Order tasks and identify dependencies
-    required: true
-  - name: validate
-    description: Run harness checks on the plan
-    required: true
-state:
-  persistent: false
-  files: []
-depends_on:
-  - harness-verification

package/dist/agents/agents/skills/gemini-cli/harness-pre-commit-review/SKILL.md

@@ -1,231 +0,0 @@
-# Harness Pre-Commit Review
-
-> Lightweight pre-commit quality gate — mechanical checks first, AI review second. Fast feedback before code leaves your machine.
-
-## When to Use
-
-- Before committing code (manual invocation or git pre-commit hook)
-- As a quick sanity check before pushing to a branch
-- When you want fast feedback without a full code review cycle
-- NOT as a replacement for full peer review (use `harness-code-review` for that)
-- NOT for commits that only update documentation or configuration (fast path skips AI review)
-
-## Principle: Deterministic First
-
-This skill follows the Deterministic-vs-LLM Responsibility Split principle. Mechanical checks run first and must pass before any AI review occurs. If a linter or type checker can catch the problem, the LLM should not be the one finding it.
-
-## Process
-
-### Phase 1: Mechanical Checks
-
-Run all deterministic checks against staged changes. These are binary pass/fail — no judgment required.
-
-#### 1. Detect Available Check Commands
-
-```bash
-# Check for project-specific commands
-cat package.json 2>/dev/null | grep -E '"(lint|typecheck|test)"'
-cat Makefile 2>/dev/null | grep -E '^(lint|typecheck|test):'
-```
-
-#### 2. Run Checks in Order
-
-Run whichever of these are available in the project:
-
-```bash
-# Lint (fastest — run first)
-pnpm lint 2>&1 || npm run lint 2>&1 || make lint 2>&1
-
-# Type check
-pnpm typecheck 2>&1 || npx tsc --noEmit 2>&1 || make typecheck 2>&1
-
-# Tests (slowest — run last)
-pnpm test 2>&1 || npm test 2>&1 || make test 2>&1
-```
-
-#### 3. Gate Decision
-
-- **Any check fails:** STOP. Report the failure. Do not proceed to AI review. The author must fix mechanical issues first.
-- **All checks pass:** Proceed to Phase 2.
-
-**Output format for failures:**
-
-```
-Pre-Commit Check: FAIL
-
-Mechanical Checks:
-- Lint: FAIL — 3 errors (see output above)
-- Types: PASS
-- Tests: NOT RUN (blocked by lint failure)
-
-Action: Fix lint errors before committing.
-```
-
-### Phase 2: Classify Changes
-
-Determine whether AI review is needed based on what changed.
-
-```bash
-# Get list of staged files
-git diff --cached --name-only
-
-# Check if only docs/config files changed
-git diff --cached --name-only | grep -v -E '\.(md|yml|yaml|json|toml|ini|cfg|conf|env|env\..*)$' | wc -l
-```
-
-#### Fast Path: Skip AI Review
-
-If ALL staged files match these patterns, skip AI review and approve:
-
-- `*.md` (documentation)
-- `*.yml`, `*.yaml` (configuration)
-- `*.json` (configuration — unless in `src/`)
-- `*.toml`, `*.ini`, `*.cfg` (configuration)
-- `.env*` (environment — but warn about secrets)
-- `LICENSE`, `CODEOWNERS`, `.gitignore`
-
-**Output for fast path:**
-
-```
-Pre-Commit Check: PASS (fast path)
-
-Mechanical Checks:
-- Lint: PASS
-- Types: PASS
-- Tests: PASS (12/12)
-
-AI Review: SKIPPED (docs/config only)
-```
-
-#### Standard Path: Proceed to AI Review
-
-If any staged file contains code changes, proceed to Phase 3.
-
-### Phase 3: AI Review (Lightweight)
-
-Perform a focused, lightweight review of staged changes. This is NOT a full code review — it catches obvious issues only.
-
-#### 1. Get the Staged Diff
-
-```bash
-git diff --cached
-```
-
-#### 2. Quick Review Checklist
-
-Review the staged diff for these high-signal issues only:
-
-- **Obvious bugs:** null dereference, infinite loops, off-by-one errors, resource leaks
-- **Security issues:** hardcoded secrets, SQL injection, path traversal, unvalidated input
-- **Broken imports:** references to files/modules that do not exist
-- **Debug artifacts:** console.log, debugger statements, TODO/FIXME without issue reference
-- **Type mismatches:** function called with wrong argument types (if visible in diff)
-
-Do NOT review for:
-
-- Style (that is the linter's job)
-- Architecture (that is the full review's job)
-- Test completeness (that is the full review's job)
-- Naming preferences (subjective and noisy at this stage)
-
-#### 3. Report
-
-**If no issues found:**
-
-```
-Pre-Commit Check: PASS
-
-Mechanical Checks:
-- Lint: PASS
-- Types: PASS
-- Tests: PASS (12/12)
-
-AI Review: PASS (no issues found)
-```
-
-**If issues found:**
-
-```
-Pre-Commit Check: WARN
-
-Mechanical Checks:
-- Lint: PASS
-- Types: PASS
-- Tests: PASS (12/12)
-
-AI Review: 2 observations
-1. [file:line] Possible null dereference — `user.email` accessed without null check after `findUser()` which can return null.
-2. [file:line] Debug artifact — `console.log('debug:', payload)` appears to be left from debugging.
-
-Action: Review observations above. Commit anyway if intentional, or fix first.
-```
-
-## Git Hook Installation
-
-To use as an automatic pre-commit hook, add to `.git/hooks/pre-commit` or configure via your git hooks manager (husky, lefthook, etc.):
-
-```bash
-#!/bin/bash
-# .git/hooks/pre-commit
-harness skill run harness-pre-commit-review
-exit_code=$?
-if [ $exit_code -ne 0 ]; then
-  echo "Pre-commit review failed. Fix issues before committing."
-  exit 1
-fi
-```
-
-**Note:** AI review observations (WARN) do not block the commit — only mechanical check failures (FAIL) block. The author decides whether to address AI observations.
-
-## Gates
-
-- **Mechanical checks must pass before AI review.** Do not run AI review if lint/typecheck/tests fail.
-- **Fast path is mandatory.** If only docs/config changed, skip AI review — do not waste tokens.
-- **AI review is advisory only.** Observations do not block the commit. Only mechanical failures block.
-
-## Harness Integration
-
-- Follows Principle 7 (Deterministic-vs-LLM Split) — mechanical checks first, AI review second
-- Reads `.harness/review-learnings.md` for calibration (if present)
-- Complements harness-code-review (full review) — use pre-commit for quick checks, code-review for thorough analysis
-
-## Success Criteria
-
-- [ ] Mechanical checks ran and produced clear pass/fail results
-- [ ] Fast path correctly identified docs/config-only changes
-- [ ] AI review focused on high-signal issues only (no style nits)
-- [ ] Report follows the structured format exactly
-
-## Examples
-
-### Example: Clean Commit
-
-```
-Pre-Commit Check: PASS
-
-Mechanical Checks:
-- Lint: PASS
-- Types: PASS
-- Tests: PASS (12/12)
-
-AI Review: PASS (no issues found)
-```
-
-### Example: Docs-Only Fast Path
-
-```
-Pre-Commit Check: PASS (fast path)
-
-Mechanical Checks:
-- Lint: PASS
-- Types: PASS
-- Tests: PASS (12/12)
-
-AI Review: SKIPPED (docs/config only)
-```
-
-## Escalation
-
-- **Mechanical checks fail:** Fix the issues. Do not bypass the hook.
-- **AI review finds a potential issue you disagree with:** Commit anyway — AI review observations are advisory, not blocking. If the observation is consistently wrong, add it to `.harness/review-learnings.md` under Noise / False Positives.
-- **Hook is too slow:** If the full test suite is slow, configure the project to run only affected tests in pre-commit. The full suite runs in CI.

package/dist/agents/agents/skills/gemini-cli/harness-pre-commit-review/skill.yaml

@@ -1,33 +0,0 @@
-name: harness-pre-commit-review
-version: "1.0.0"
-description: Lightweight pre-commit quality gate combining mechanical checks and AI review
-triggers: [manual, on_commit]
-platforms: [claude-code, gemini-cli]
-tools: [Bash, Read, Glob, Grep]
-cli:
-  command: harness skill run harness-pre-commit-review
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: harness-pre-commit-review
-    path: string
-type: rigid
-phases:
-  - name: mechanical-checks
-    description: Run deterministic checks (lint, typecheck, tests)
-    required: true
-  - name: classify-changes
-    description: Determine if AI review is needed based on change type
-    required: true
-  - name: ai-review
-    description: Lightweight AI review of staged changes (skipped for docs/config-only)
-    required: false
-state:
-  persistent: false
-  files: []
-depends_on:
-  - harness-code-review