@harness-engineering/cli 1.2.0 → 1.3.0

package/dist/agents/commands/gemini-cli/harness/git-workflow.toml

@@ -1,325 +0,0 @@
-# Generated by harness generate-slash-commands. Do not edit.
-description = "Git workflow best practices integrated with harness validation"
-prompt = """
-<context>
-Cognitive mode: meticulous-verifier
-Type: flexible
-</context>
-
-<objective>
-Git workflow best practices integrated with harness validation
-</objective>
-
-<execution_context>
---- SKILL.md (agents/skills/claude-code/harness-git-workflow/SKILL.md) ---
-# Harness Git Workflow
-
-> Worktree setup, dependency installation, baseline verification, and branch finishing. Clean isolation for every workstream.
-
-## When to Use
-
-- When starting work that should be isolated from the main branch (new feature, experiment, multi-task plan)
-- When finishing a branch and deciding how to land it (merge, PR, keep, discard)
-- When `on_pr` or `on_commit` triggers fire and worktree management is needed
-- When the human asks to "set up a branch" or "start a new workstream"
-- NOT for simple single-file changes that do not need branch isolation
-- NOT when work is already in progress on the correct branch
-
-## Process
-
-### Part A: Worktree Creation
-
-#### Step 1: Choose Worktree Location
-
-1. **Check for `.worktrees/` directory** in the project root. If it exists, use it — this is the preferred location.
-
-2. **Check CLAUDE.md or AGENTS.md** for worktree preferences. Some projects specify a custom worktree directory or naming convention. Follow those instructions.
-
-3. **If neither exists, ask the user:** "Where should I create the worktree? Options: (A) `.worktrees/<branch-name>` in the project root, (B) a sibling directory alongside the project, (C) a custom path."
-
-4. **If placing worktrees in the project directory,** verify that the worktree directory is gitignored. Check `.gitignore` for `.worktrees/` or the chosen directory name. If not gitignored, add it before creating the worktree.
-
-#### Step 2: Check for Existing Worktrees
-
-1. **Run `git worktree list`** to see active worktrees.
-
-2. **If a worktree already exists for the target branch,** do not create a duplicate. Ask: "A worktree for branch `<name>` already exists at `<path>`. Should I use it, or create a new branch?"
-
-3. **If the target directory already exists** (but is not a worktree), do not overwrite. Ask the user how to proceed.
-
-#### Step 3: Create Branch and Worktree
-
-1. **Create the branch** from the current HEAD (or from the specified base):
-
-   ```
-   git branch <branch-name> <base>
-   ```
-
-2. **Create the worktree:**
-
-   ```
-   git worktree add <path> <branch-name>
-   ```
-
-3. **Verify the worktree was created.** Check that the directory exists and contains a `.git` file (not a `.git` directory — worktrees use a file pointing to the main repo).
-
-#### Step 4: Auto-Detect and Run Setup
-
-Inspect the worktree for project files and run the appropriate setup:
-
-| File Found                         | Action                                                                   |
-| ---------------------------------- | ------------------------------------------------------------------------ |
-| `package.json`                     | `npm install` (or `yarn install` / `pnpm install` if lockfile indicates) |
-| `Cargo.toml`                       | `cargo build`                                                            |
-| `go.mod`                           | `go mod download`                                                        |
-| `requirements.txt`                 | `pip install -r requirements.txt`                                        |
-| `pyproject.toml`                   | `pip install -e .` or `poetry install`                                   |
-| `Gemfile`                          | `bundle install`                                                         |
-| `Makefile` (with `install` target) | `make install`                                                           |
-
-If multiple project files exist (monorepo), install at the root level. Do not guess which subpackages to install — follow the project's documented setup or ask.
-
-#### Step 5: Verify Clean Baseline
-
-Before any work begins, verify the worktree is in a clean, working state:
-
-1. **Run the test suite.** All tests must pass on the fresh branch before any changes.
-
-2. **Run `harness validate`.** Project health must be green before starting work.
-
-3. **If tests fail or validation fails on the fresh branch,** stop. The base branch has issues. Report: "Baseline verification failed on fresh branch: [failure details]. The base branch needs to be fixed first."
-
-4. **Record the baseline.** Note the test count and validation result. This is the comparison point for the branch finishing phase.
-
----
-
-### Part B: Branch Finishing
-
-When work on the branch is complete, follow this protocol to land the changes.
-
-#### Step 1: Pre-Finish Verification
-
-1. **Run the full test suite.** All tests must pass.
-
-2. **Run `harness validate`.** Project health must be green.
-
-3. **Check for uncommitted changes.** Run `git status`. All changes must be committed. If there are uncommitted changes, commit or stash them before finishing.
-
-4. **Check the branch is up to date.** If the base branch has advanced since the worktree was created:
-   ```
-   git fetch origin
-   git log HEAD..origin/main --oneline
-   ```
-   If there are new commits on the base, rebase or merge before finishing:
-   ```
-   git rebase origin/main
-   ```
-   Re-run tests after rebasing.
-
-#### Step 2: Choose Finishing Strategy
-
-Present 4 options to the user:
-
-1. **Merge locally.** Merge the branch into the base branch on the local machine.
-   - Best for: small changes, solo work, when CI is not required
-   - Command: `git checkout main && git merge <branch>`
-
-2. **Push and create PR.** Push the branch to the remote and open a pull request.
-   - Best for: team work, changes that need review, when CI must pass
-   - Command: `git push -u origin <branch>` then create PR via `gh pr create`
-
-3. **Keep as-is.** Leave the branch and worktree in place for continued work later.
-   - Best for: work-in-progress, experiments, paused projects
-
-4. **Discard.** Delete the branch and worktree. All changes are lost.
-   - Best for: failed experiments, abandoned approaches
-   - Safety: Confirm with the user before discarding. List the commits that will be lost.
-
-#### Step 3: Execute Chosen Strategy
-
-**If merge locally:**
-
-```bash
-cd <main-repo-path>
-git merge <branch-name>
-# Run tests on main after merge
-# Run harness validate after merge
-git worktree remove <worktree-path>
-git branch -d <branch-name>
-```
-
-**If push and create PR:**
-
-```bash
-cd <worktree-path>
-git push -u origin <branch-name>
-gh pr create --title "<title>" --body "<description>"
-# Report the PR URL to the user
-# Leave worktree in place until PR is merged
-```
-
-**If keep as-is:**
-
-```
-No action needed. Report the worktree path and branch name for future reference.
-```
-
-**If discard:**
-
-```bash
-# Confirm with user first — list commits that will be lost
-git worktree remove <worktree-path>
-git branch -D <branch-name>
-```
-
-#### Step 4: Clean Up
-
-1. **Remove the worktree** (unless keeping as-is or waiting for PR merge):
-
-   ```
-   git worktree remove <worktree-path>
-   ```
-
-2. **Prune stale worktree references:**
-
-   ```
-   git worktree prune
-   ```
-
-3. **Verify cleanup.** Run `git worktree list` and confirm the removed worktree is no longer listed.
-
-## Harness Integration
-
-- **`harness validate`** — Run during baseline verification (Step 5 of Part A) and pre-finish verification (Step 1 of Part B). Ensures project health is green at both boundaries.
-- **Test runner** — Run fresh in the worktree, not in the main repo. Tests must pass both at baseline (before work) and at finish (after work).
-- **`.gitignore`** — Verify worktree directory is gitignored if it lives inside the project tree.
-
-## Success Criteria
-
-- Worktree was created in the correct location (`.worktrees/` preferred, or per project convention)
-- Dependencies were auto-detected and installed
-- Baseline verification passed (tests green, harness validates) before any work began
-- Branch finishing strategy was chosen by the user (not assumed)
-- Chosen strategy was executed correctly (merge, PR, keep, or discard)
-- Worktree was cleaned up after finishing (unless keeping for continued work)
-- No stale worktree references remain after cleanup
-
-## Examples
-
-### Example: Setting Up a Worktree for a New Feature
-
-```bash
-# Check for preferred location
-ls .worktrees/    # exists — use it
-
-# Check gitignore
-grep '.worktrees' .gitignore    # found — good, already gitignored
-
-# Check existing worktrees
-git worktree list
-# /Users/dev/project  abc1234 [main]
-# No existing worktree for this feature
-
-# Create branch and worktree
-git branch feat/notifications main
-git worktree add .worktrees/notifications feat/notifications
-
-# Auto-detect setup (found package.json)
-cd .worktrees/notifications && npm install
-
-# Verify baseline
-npm test                # 142 tests, all pass
-harness validate        # passes
-
-# Ready to work. Report:
-# "Worktree created at .worktrees/notifications on branch feat/notifications.
-#  142 tests passing. harness validate green. Ready to start."
-```
-
-### Example: Finishing a Branch with PR
-
-```bash
-# Pre-finish verification
-cd .worktrees/notifications
-npm test                # 158 tests, all pass (16 new)
-harness validate        # passes
-git status              # clean — all committed
-
-# Check if base has advanced
-git fetch origin
-git log HEAD..origin/main --oneline
-# 3 new commits on main — rebase
-
-git rebase origin/main
-npm test                # still passes after rebase
-
-# User chooses: Push and create PR
-git push -u origin feat/notifications
-gh pr create --title "feat(notifications): email and in-app notifications" \
-  --body "Implements notification service with create, list, and expiry.
-  16 new tests. All passing."
-
-# Report: "PR created: https://github.com/org/repo/pull/42
-#  Worktree at .worktrees/notifications kept until PR merges."
-```
-
-### Example: Discarding a Failed Experiment
-
-```bash
-# User says: "That approach didn't work, let's scrap it."
-
-# Show what will be lost
-git log main..HEAD --oneline
-# a1b2c3d try websocket approach
-# d4e5f6g add socket.io dependency
-# "These 2 commits will be lost. Discard? (yes/no)"
-# Human: "yes"
-
-git worktree remove .worktrees/ws-experiment
-git branch -D feat/ws-experiment
-git worktree prune
-git worktree list    # ws-experiment no longer listed
-```
-
-
---- skill.yaml (agents/skills/claude-code/harness-git-workflow/skill.yaml) ---
-name: harness-git-workflow
-version: "1.0.0"
-description: Git workflow best practices integrated with harness validation
-cognitive_mode: meticulous-verifier
-triggers:
-  - manual
-  - on_pr
-  - on_commit
-platforms:
-  - claude-code
-  - gemini-cli
-tools:
-  - Bash
-  - Read
-  - Glob
-cli:
-  command: harness skill run harness-git-workflow
-  args:
-    - name: path
-      description: Project root path
-      required: false
-mcp:
-  tool: run_skill
-  input:
-    skill: harness-git-workflow
-    path: string
-type: flexible
-state:
-  persistent: false
-  files: []
-depends_on: []
-
-</execution_context>
-
-<process>
-1. Try: invoke mcp__harness__run_skill with skill: "harness-git-workflow"
-2. If MCP unavailable: follow the SKILL.md workflow provided above directly
-3. Pass through any arguments provided by the user
-</process>
-"""

package/dist/agents/commands/gemini-cli/harness/initialize-project.toml

@@ -1,257 +0,0 @@
-# Generated by harness generate-slash-commands. Do not edit.
-description = "Scaffold a new harness-compliant project"
-prompt = """
-<context>
-Cognitive mode: constructive-architect
-Type: flexible
-</context>
-
-<objective>
-Scaffold a new harness-compliant project
-</objective>
-
-<execution_context>
---- SKILL.md (agents/skills/claude-code/initialize-harness-project/SKILL.md) ---
-# 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.yaml`, 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.
-
-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.yaml` 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 project: `harness init --level basic --framework <framework>`
-   - New intermediate project: `harness init --level intermediate --framework <framework>`
-   - Migration to intermediate: `harness init --level intermediate --migrate`
-   - Migration to advanced: `harness init --level advanced --migrate`
-
-2. **Review generated files.** `harness init` creates:
-   - `harness.yaml` — 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.yaml`. 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.yaml` 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.
-
-### Phase 4: VALIDATE — Confirm Everything Works
-
-1. **Run `harness validate`** to verify the full configuration. This checks:
-   - `harness.yaml` 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.
-
-4. **Commit the initialization.** All generated and configured files in a single commit.
-
-## Harness Integration
-
-- **`harness init --level <level> --framework <framework>`** — Scaffold a new project at the specified adoption level.
-- **`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).
-
-## Success Criteria
-
-- `harness.yaml` 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
-
-## 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.yaml, .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"
-```
-
-**VALIDATE:**
-
-```bash
-harness validate  # Pass — basic level checks satisfied
-git add harness.yaml .harness/ AGENTS.md
-git commit -m "feat: initialize harness project at basic level"
-```
-
-### Example: Migrating Existing Project from Basic to Intermediate
-
-**ASSESS:**
-
-```
-Read harness.yaml — 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.yaml and AGENTS.md
-# Adds: layer definitions template, dependency constraints template
-```
-
-**CONFIGURE:**
-
-```
-Define layers in harness.yaml:
-  - 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.yaml` 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
-
-
---- skill.yaml (agents/skills/claude-code/initialize-harness-project/skill.yaml) ---
-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: []
-
-</execution_context>
-
-<process>
-1. Try: invoke mcp__harness__run_skill with skill: "initialize-harness-project"
-2. If MCP unavailable: follow the SKILL.md workflow provided above directly
-3. Pass through any arguments provided by the user
-</process>
-"""