npm - @harness-engineering/cli - Versions diffs - 1.25.7 → 1.26.1 - Mend

@harness-engineering/cli 1.25.7 → 1.26.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (189) hide show

package/dist/agents/commands/cursor/harness/initialize-harness-project.mdc DELETED Viewed

@@ -1,240 +0,0 @@
----
-description: Scaffold a new harness-compliant project
-alwaysApply: false
----
-<!-- Generated by harness generate-slash-commands. Do not edit. -->
-# Initialize Harness Project
-> Scaffold a new harness-compliant project or migrate an existing project to the next adoption level. Assess current state, configure personas, generate AGENTS.md, and validate the result.
-## When to Use
-- Starting a brand new project that should be harness-managed from day one
-- Migrating an existing project to harness for the first time
-- Upgrading an existing harness project from one adoption level to the next (basic to intermediate, intermediate to advanced)
-- When `on_project_init` triggers fire
-- NOT when the project is already at the desired adoption level (use harness-onboarding to orient instead)
-- NOT when adding a single component to an existing harness project (use add-harness-component)
-- NOT when the project has no clear owner or maintainer — harness setup requires someone to own the constraints
-## Process
-### Phase 1: ASSESS — Determine Current State
-1. **Check for existing harness configuration.** Look for `.harness/` directory, `AGENTS.md`, `harness.config.json`, and any skill definitions. Their presence determines whether this is a new project or a migration.
-2. **For new projects:** Gather project context — language, framework, test runner, build tool. Ask the human if any of these are undecided. Do not assume defaults.
-2b. **For existing projects with detectable frameworks:** Run `harness init` without flags first. The command auto-detects frameworks (FastAPI, Django, Gin, Axum, Spring Boot, Next.js, React+Vite, Vue, Express, NestJS) by scanning project files. Present the detection result to the human and ask for confirmation before proceeding. If detection fails, ask the human to specify `--framework` manually.
-3. **For existing projects:** Run `harness validate` to see what is already configured and what is missing. Read `AGENTS.md` if it exists. Identify the current adoption level:
-   - **Basic:** Has `AGENTS.md` and `harness.config.json` with project metadata. No layers, no skills, no dependency constraints.
-   - **Intermediate:** Has layers defined, dependency constraints between layers, at least one custom skill. `harness check-deps` runs and passes.
-   - **Advanced:** Has full persona configuration, custom skills for the team's workflows, state management, learnings capture, and CI integration for `harness validate`.
-4. **Recommend the target adoption level.** For new projects, start with basic unless the team has harness experience. For existing projects, recommend one level up from current. Present the recommendation and wait for confirmation.
-### Phase 2: SCAFFOLD — Generate Project Structure
-1. **Run `harness init` with the appropriate flags:**
-   - New basic JS/TS project: `harness init --level basic`
-   - With framework: `harness init --level basic --framework <framework>`
-   - Non-JS language: `harness init --language <python|go|rust|java>`
-   - Non-JS with framework: `harness init --framework <fastapi|django|gin|axum|spring-boot>`
-   - Existing project (auto-detect): `harness init` (no flags -- auto-detection runs)
-   - Migration to intermediate: `harness init --level intermediate --migrate`
-   - Migration to advanced: `harness init --level advanced --migrate`
-   **Supported frameworks:** nextjs, react-vite, vue, express, nestjs, fastapi, django, gin, axum, spring-boot
-   **Supported languages:** typescript, python, go, rust, java
-2. **Review generated files.** `harness init` creates:
-   - `harness.config.json` — Project configuration (name, stack, adoption level)
-   - `.harness/` directory — State and learnings storage
-   - `AGENTS.md` — Agent instructions (template, needs customization)
-   - Layer definitions (intermediate and above)
-   - Dependency constraints (intermediate and above)
-3. **Do not blindly accept generated content.** Read the generated `AGENTS.md` and `harness.config.json`. Flag anything that looks wrong or incomplete. The scaffolded output is a starting point, not a finished product.
-### Phase 3: CONFIGURE — Customize for the Project
-1. **Configure personas.** Run `harness persona generate` to create persona definitions based on the project's stack and team structure. Personas define how agents should behave in this project — coding style, communication preferences, constraint strictness.
-2. **Customize AGENTS.md.** The generated template needs project-specific content:
-   - Project description and purpose
-   - Architecture overview (components, layers, data flow)
-   - Key conventions the team follows
-   - Known constraints and forbidden patterns
-   - Links to relevant documentation
-3. **For intermediate and above:** Define layer boundaries. Which modules belong to which layers? What are the allowed import directions? Document these in `harness.config.json` and ensure they match the actual codebase structure.
-4. **For advanced:** Configure state management (`.harness/state.json` schema), learnings capture (`.harness/learnings.md` conventions), and CI integration hooks.
-5. **Configure i18n (all levels).** Ask: "Will this project support multiple languages?" Based on the answer:
-   - **Yes:** Invoke `harness-i18n-workflow` configure phase to set up i18n config in `harness.config.json` (source locale, target locales, framework, strictness). Then invoke `harness-i18n-workflow` scaffold phase to create translation file structure and extraction config. Set `i18n.enabled: true`.
-   - **No:** Set `i18n.enabled: false` in `harness.config.json`. The `harness-i18n-process` skill will still fire gentle prompts for unconfigured projects when features touch user-facing strings.
-   - **Not sure yet:** Skip i18n configuration entirely. Do not set `i18n.enabled`. The project can enable i18n later by running `harness-i18n-workflow` directly.
-### Phase 4: VALIDATE — Confirm Everything Works
-1. **Run `harness validate`** to verify the full configuration. This checks:
-   - `harness.config.json` schema validity
-   - `AGENTS.md` presence and required sections
-   - Layer definitions (if intermediate+)
-   - Dependency constraints (if intermediate+)
-   - Persona configuration (if configured)
-2. **Fix any validation errors before finishing.** Do not leave the project in a half-configured state.
-3. **Run `harness check-deps`** (intermediate and above) to verify dependency constraints match the actual codebase. If there are violations, decide with the human: update the constraints or fix the code.
-### Build the Initial Knowledge Graph
-If the project will use graph-based queries, build the initial knowledge graph now:
-```
-harness scan [path]
-```
-This creates the `.harness/graph/` directory and populates it with the project's dependency and relationship data. Subsequent graph queries (impact analysis, dependency health, test advisor) depend on this initial scan.
-4. **Mention roadmap.** After validation passes, inform the user: "When you are ready to set up a project roadmap, run `/harness:roadmap --create`. This creates a unified `docs/roadmap.md` that tracks features, milestones, and status across your specs and plans." This is informational only — do not create the roadmap automatically.
-5. **Commit the initialization.** All generated and configured files in a single commit.
-## Harness Integration
-- **`harness init --level <level> [--framework <framework>] [--language <language>]`** — Scaffold a new project. `--framework` infers language automatically. `--language` without `--framework` gives a bare language scaffold. Running without flags on an existing project directory triggers auto-detection.
-- **`harness init --level <level> --migrate`** — Migrate an existing project to the next adoption level, preserving existing configuration.
-- **`harness persona generate`** — Generate persona definitions based on project stack and team structure.
-- **`harness validate`** — Verify the full project configuration is valid and complete.
-- **`harness check-deps`** — Verify dependency constraints match the actual codebase (intermediate and above).
-- **`harness-i18n-workflow configure` + `harness-i18n-workflow scaffold`** — Invoked during Phase 3 if the project will support multiple languages. Sets up i18n configuration and translation file structure.
-- **Roadmap nudge** — After successful initialization, inform the user about `/harness:roadmap --create` for setting up project-level feature tracking. Informational only; does not create the roadmap.
-## Success Criteria
-- `harness.config.json` exists and passes schema validation
-- `AGENTS.md` exists with project-specific content (not just the template)
-- `.harness/` directory exists with appropriate state files
-- `harness validate` passes with zero errors
-- `harness check-deps` passes (intermediate and above)
-- Personas are configured if the project uses them
-- The adoption level matches what was agreed upon with the human
-- All generated files are committed in a single atomic commit
-- i18n configuration is set if the human chose to enable it during init
-## Examples
-### Example: New TypeScript Project (Basic Level)
-**ASSESS:**
-```
-Human: "I'm starting a new TypeScript API project using Express and Vitest."
-Check for .harness/ — not found. This is a new project.
-Recommend: basic level (new project, start simple).
-Human confirms: "Basic is fine for now."
-```
-**SCAFFOLD:**
-```bash
-harness init --level basic --framework express
-# Creates: harness.config.json, .harness/, AGENTS.md (template)
-```
-**CONFIGURE:**
-```
-Edit AGENTS.md:
-  - Add project description: "REST API for widget management"
-  - Add stack: TypeScript, Express, Vitest, PostgreSQL
-  - Add conventions: "Use zod for validation, repository pattern for data access"
-  - Add constraints: "No direct SQL queries outside repository layer"
-  - Ask: "Will this project support multiple languages?"
-  - Human: "Yes, Spanish and French."
-  - Run harness-i18n-workflow configure (source: en, targets: es, fr)
-  - Run harness-i18n-workflow scaffold (creates locales/ directory structure)
-```
-**VALIDATE:**
-```bash
-harness validate  # Pass — basic level checks satisfied
-git add harness.config.json .harness/ AGENTS.md
-git commit -m "feat: initialize harness project at basic level"
-```
-### Example: Migrating Existing Project from Basic to Intermediate
-**ASSESS:**
-```
-Read harness.config.json — level: basic
-Read AGENTS.md — exists, has project-specific content
-Run: harness validate — passes at basic level
-Recommend: intermediate (add layers and dependency constraints)
-Human confirms: "Yes, we're ready for layers."
-```
-**SCAFFOLD:**
-```bash
-harness init --level intermediate --migrate
-# Preserves existing harness.config.json and AGENTS.md
-# Adds: layer definitions template, dependency constraints template
-```
-**CONFIGURE:**
-```
-Define layers in harness.config.json:
-  - presentation: src/routes/, src/middleware/
-  - business: src/services/, src/models/
-  - data: src/repositories/, src/db/
-Define constraints:
-  - presentation → business (allowed)
-  - business → data (allowed)
-  - data → presentation (forbidden)
-  - presentation → data (forbidden — must go through business)
-Update AGENTS.md with layer documentation.
-```
-**VALIDATE:**
-```bash
-harness validate      # Pass — intermediate level checks satisfied
-harness check-deps    # Pass — no constraint violations in existing code
-git add -A
-git commit -m "feat: migrate harness project to intermediate level with layers"
-```
-### Example: Adoption Level Progression
-**Basic (start here):**
-- `AGENTS.md` with project context
-- `harness.config.json` with metadata
-- `harness validate` runs in development
-**Intermediate (add structure):**
-- Layer definitions and boundaries
-- Dependency constraints enforced by `harness check-deps`
-- At least one custom skill for team workflows
-**Advanced (full integration):**
-- Persona configuration for consistent agent behavior
-- State management across sessions
-- `.harness/learnings.md` capturing institutional knowledge
-- `harness validate` runs in CI pipeline
-- Custom skills for all common team workflows

package/dist/agents/commands/gemini-cli/harness/harness.toml DELETED Viewed

@@ -1,277 +0,0 @@
-# Generated by harness generate-slash-commands. Do not edit.
-description = "Natural language router to harness skills — classifies intent, confirms, dispatches"
-prompt = '''
-<context>
-Cognitive mode: analytical-classifier
-Type: rigid
-</context>
-<objective>
-Natural language router to harness skills — classifies intent, confirms, dispatches
-Phases:
-- classify: Parse intent and search skills index for matches
-- confirm: Present routing decision with scope and reasoning
-- dispatch: Invoke selected skill via run_skill with original intent
-</objective>
-<execution_context>
---- SKILL.md (agents/skills/claude-code/harness-router/SKILL.md) ---
-# Harness Router
-> Natural language entry point to all harness skills. Classifies user intent by scope and domain, confirms the routing decision with explicit reasoning, and dispatches to the appropriate skill.
-## When to Use
-- When the user invokes `/harness` with a natural language description of what they want
-- When the user is unsure which harness skill to use
-- When the user wants to describe their intent rather than remember a command name
-- NOT when the user already knows the specific skill (e.g., `/harness:tdd`, `/harness:planning`)
-- NOT for non-harness tasks (general coding, file operations, etc.)
-## Process
-### Iron Law
-**The router confirms before dispatching.** Never silently route to a skill. Always present the chosen skill, scope classification, and reasoning — then wait for the user to confirm.
----
-### Phase 1: CLASSIFY — Parse Intent and Search
-1. **Check for empty input.** If no intent is provided, show usage help:
-   ```
-   Usage: /harness <describe what you want to do>
-   Examples:
-     /harness fix the button spacing on the settings page
-     /harness we need a notification system
-     /harness this page is slow
-     /harness redesign how the sidebar filters work
-     /harness clean up my code
-   I'll figure out the right skill and process level for you.
-   ```
-   Stop here — do not proceed to classification.
-2. **Search the skill catalog.** Call `search_skills` with the user's natural language intent as the query:
-   ```
-   search_skills({ query: "<user's intent>" })
-   ```
-   This returns ranked skill matches from the skills index.
-3. **Classify scope.** Based on the intent language and search results, classify into one of four tiers:
-   | Scope | Signal Words | Description |
-   |-------|-------------|-------------|
-   | **quick-fix** | "fix", "tweak", "adjust", "change X to Y", "update", "correct" | Small, targeted change with no design decisions |
-   | **guided-change** | "redesign", "refactor", "improve how X works", "rework" | Moderate scope, some decisions but architecture is clear |
-   | **full-exploration** | "build", "create", "add a new system for", "we need", "design" | Ambiguous scope, multiple approaches, design decisions needed |
-   | **diagnostic** | "broken", "slow", "failing", "debug", "review", "check", "analyze" | Something is broken or needs analysis |
-   Additional scope signals:
-   - Single file or component mentioned → lower ceremony (quick-fix or guided-change)
-   - Multiple systems or no clear target → higher ceremony (full-exploration)
-   - Error messages or symptoms → diagnostic
-4. **Map scope to entry skill.** Use the classification and search results to select the entry skill:
-   | Scope | Primary Skill | Alternates (when search results indicate better match) |
-   |-------|--------------|-------------------------------------------------------|
-   | quick-fix | `harness-tdd` | `harness-refactoring` if the intent is structural |
-   | guided-change | `harness-planning` | `harness-architecture-advisor` if tradeoffs are involved |
-   | full-exploration | `harness-brainstorming` | — |
-   | diagnostic | `harness-debugging` | `harness-code-review` for review requests, `harness-perf` for performance |
-   If the `search_skills` results strongly favor a specific skill that differs from the scope-based default, prefer the search result. The scope classification provides the fallback when search results are ambiguous.
-5. **Assess confidence.** Determine whether the match is confident or ambiguous:
-   - **High confidence:** Top search result clearly dominates, scope classification aligns with it
-   - **Low confidence:** Top 2-3 results are close in score, or scope classification points to a different skill than search results
----
-### Phase 2: CONFIRM — Present Decision with Reasoning
-**High confidence (single clear match):**
-Present the routing decision with scope classification and reasoning:
-```
-This looks like a [scope-level] — [one-line reasoning about why this scope].
-I'll route to `harness:[skill]` because [why this skill fits the intent].
-Proceed? (y / n / suggest another)
-```
-Wait for the user to confirm before proceeding.
-**Low confidence (ambiguous, multiple candidates):**
-Present the top 2-3 candidates with descriptions:
-```
-This could be a few things:
-1. `harness:[skill-1]` — [one-line description of what this skill does]
-2. `harness:[skill-2]` — [one-line description of what this skill does]
-3. `harness:[skill-3]` — [one-line description of what this skill does]
-Which fits best? (1 / 2 / 3)
-```
-Wait for the user to choose.
-**User rejects the suggestion:**
-If the user says no or suggests a different skill:
-- If they name a specific skill, confirm and dispatch to that skill
-- If they re-phrase their intent, re-run CLASSIFY with the new phrasing
-- Do not loop more than twice — if the second attempt also misses, list all available harness skills and let the user pick
----
-### Phase 3: DISPATCH — Invoke Selected Skill
-1. **Pass the original intent as context.** When invoking the selected skill, include the user's original natural language intent so they do not need to repeat themselves.
-2. **Invoke via `run_skill`.** Call `run_skill` with the selected skill name and the user's intent as the argument:
-   ```
-   run_skill({ skill: "<selected-skill>", path: "<project-root>" })
-   ```
-   Pass the original intent through as the skill's argument context.
-3. **Hand off cleanly.** Once the skill is invoked, the router's job is done. The dispatched skill owns all subsequent interaction, including any downstream chaining to other skills.
----
-## Scope Examples
-### Quick Fix
-**Intent:** "fix the button spacing on the settings page"
-**Classification:** quick-fix — single component, clear target, no design decisions
-**Route:** `harness-tdd`
-### Guided Change
-**Intent:** "redesign how the sidebar filters work"
-**Classification:** guided-change — moderate scope, clear architecture, some decisions
-**Route:** `harness-planning` or `harness-architecture-advisor`
-### Full Exploration
-**Intent:** "we need a notification system"
-**Classification:** full-exploration — ambiguous scope, multiple approaches, design decisions needed
-**Route:** `harness-brainstorming`
-### Diagnostic
-**Intent:** "this page is slow"
-**Classification:** diagnostic — performance symptom, needs investigation
-**Route:** `harness-perf`
-### Ambiguous
-**Intent:** "clean up my code"
-**Classification:** ambiguous — could be refactoring, dead code removal, or architecture cleanup
-**Route:** Present candidates: `harness-refactoring`, `harness-codebase-cleanup`, `harness-cleanup-dead-code`
-## Harness Integration
-- **`search_skills`** — Used in Phase 1 to match the user's natural language intent against the skill catalog. Returns ranked results based on keyword, description, and stack-signal matching.
-- **`run_skill`** — Used in Phase 3 to dispatch to the selected skill. Passes the project path and original intent as context.
-- **`harness validate`** — Not directly used by the router. Validation is the responsibility of the dispatched skill.
-## Success Criteria
-- `/harness fix the button spacing on the settings page` routes to `harness-tdd` with scope "quick-fix" and confirms before dispatching
-- `/harness we need a notification system` routes to `harness-brainstorming` with scope "full-exploration" and confirms before dispatching
-- `/harness clean up my code` (ambiguous) presents top 2-3 candidates and lets user choose
-- `/harness this page is slow` routes to a diagnostic skill with reasoning
-- `/harness redesign how the sidebar filters work` routes to `harness-planning` or `harness-architecture-advisor` with scope "guided-change"
-- Confirmation always includes: scope classification, chosen skill, and one-line reasoning
-- User can reject the suggestion and re-phrase or pick a different skill
-- Dispatched skill receives the original natural language intent as context
-- `search_skills` MCP tool is used for matching — no custom scoring code
-- `/harness` with no arguments shows usage help with examples
-## Rationalizations to Reject
-| Rationalization | Reality |
-|----------------|---------|
-| "The intent is obvious, I can skip the confirmation step" | The Iron Law requires confirmation before every dispatch. Even obvious intents benefit from the user seeing the scope classification — it catches misunderstandings early. |
-| "I should also suggest downstream skills the dispatched skill will chain into" | Each skill owns its own transitions. Surfacing the full chain adds noise and duplicates logic that already exists in the dispatched skill. |
-| "The search results don't match well, so I'll just guess based on keywords" | If `search_skills` returns poor results, present the top candidates and let the user choose. Guessing silently is worse than admitting ambiguity. |
-| "The user rejected my suggestion twice, I should keep trying" | After two misses, list available skills and let the user pick directly. Do not loop indefinitely. |
-## Gates
-- **No silent dispatch.** Every routing decision must be confirmed by the user before the skill is invoked. No exceptions.
-- **No bypassing search_skills.** The skill catalog search must be used for matching. Do not hardcode intent-to-skill mappings or rely solely on keyword heuristics.
-- **No downstream chaining.** The router dispatches to exactly one skill. It does not pre-load or suggest the skills that will follow.
-- **No more than two re-classification attempts.** If the user rejects twice, show the full list and let them pick.
-## Escalation
-- **When `search_skills` returns no results:** The skills index may be stale or missing. Suggest the user run `harness update-skills-index` to regenerate it, then retry.
-- **When the user's intent spans multiple skills:** Ask: "This sounds like it involves both [skill A] and [skill B]. Which should we start with?" Do not attempt to dispatch to multiple skills simultaneously.
-- **When the user asks for something outside the harness skill catalog:** Say so plainly: "This doesn't match any harness skill. You may want to handle this directly, or describe the task differently if you think a harness skill should apply."
---- skill.yaml (agents/skills/claude-code/harness-router/skill.yaml) ---
-name: harness-router
-version: "1.0.0"
-description: Natural language router to harness skills — classifies intent, confirms, dispatches
-cognitive_mode: analytical-classifier
-command_name: harness
-triggers:
-  - manual
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Read
-  - Glob
-  - Grep
-cli:
-  command: harness skill run harness-router
-  args:
-    - name: intent
-      description: Natural language description of what the user wants
-      required: true
-mcp:
-  tool: run_skill
-  input:
-    skill: harness-router
-    path: string
-type: rigid
-tier: 1
-phases:
-  - name: classify
-    description: Parse intent and search skills index for matches
-    required: true
-  - name: confirm
-    description: Present routing decision with scope and reasoning
-    required: true
-  - name: dispatch
-    description: Invoke selected skill via run_skill with original intent
-    required: true
-state:
-  persistent: false
-  files: []
-depends_on: []
-addresses:
-  - signal: high-complexity
-    weight: 0.3
-</execution_context>
-<process>
-1. Try: invoke mcp__harness__run_skill with skill: "harness-router"
-2. If MCP unavailable: follow the SKILL.md workflow provided above directly
-3. Pass through any arguments provided by the user
-</process>
-'''

package/dist/{chunk-RRHUCDRD.js → chunk-ZP5E7YET.js} RENAMED Viewed

@@ -1,9 +1,9 @@
-import {
-  logger
-} from "./chunk-EBJQ6N4M.js";
 import {
   ALLOWED_COGNITIVE_MODES
 } from "./chunk-HIK6OEUF.js";
+import {
+  logger
+} from "./chunk-EBJQ6N4M.js";
 import {
   CLIError,
   ExitCode