@harness-engineering/cli 1.14.0 → 1.16.0

package/dist/agents/skills/cursor/harness-feature-flags/SKILL.md

@@ -0,0 +1,287 @@
+# Harness Feature Flags
+
+> Flag lifecycle management, A/B testing infrastructure, and gradual rollout design. Ship features safely with controlled exposure and clean retirement.
+
+## When to Use
+
+- When designing feature flag architecture for a new project or feature
+- When auditing existing flags for staleness, test coverage, or hygiene
+- When planning gradual rollout or A/B testing strategies
+- NOT for deployment pipeline configuration (use harness-deployment)
+- NOT for environment variable management (use harness-secrets)
+- NOT for application performance testing under flag variants (use harness-perf)
+
+## Process
+
+### Phase 1: DETECT -- Discover Flag Definitions and Usage
+
+1. **Identify flag provider.** Scan the project for feature flag infrastructure:
+   - **Third-party SDKs:** LaunchDarkly (`launchdarkly-node-server-sdk`), Unleash (`unleash-client`), Flagsmith (`flagsmith-nodejs`), Split (`@splitsoftware/splitio`)
+   - **Custom implementations:** Files matching `*feature-flag*`, `*toggle*`, `*flags*`
+   - **Configuration-based:** `flags.json`, `features.json`, `feature-flags.yaml`
+   - **Environment-based:** Feature flags controlled via environment variables (`FEATURE_*`, `FF_*`)
+
+2. **Catalog all flag definitions.** For each flag found, record:
+   - Flag name/key
+   - Flag type (boolean, multivariate, percentage rollout)
+   - Default value (what happens when the flag service is unreachable)
+   - Where it is defined (provider dashboard, config file, code)
+   - Creation date or first appearance in git history
+
+3. **Map flag usage in code.** For each flag, find all evaluation points:
+   - Source files that check the flag value
+   - Conditional branches gated by the flag
+   - Components that render differently based on flag state
+   - API endpoints with flag-dependent behavior
+   - Test files that exercise flag variants
+
+4. **Detect flag categories.** Classify each flag:
+   - **Release flag:** Gates a new feature for gradual rollout (temporary)
+   - **Experiment flag:** Controls A/B test variants (temporary)
+   - **Ops flag:** Circuit breaker or kill switch (permanent)
+   - **Permission flag:** Controls access to premium features (permanent)
+
+5. **Present detection summary:**
+
+   ```
+   Feature Flag Detection:
+     Provider: LaunchDarkly (SDK v7.x)
+     Flags defined: 23
+     Flags evaluated in code: 19 (4 defined but unused)
+     Categories: 12 release, 5 experiment, 4 ops, 2 permission
+     Stale candidates: 6 (release flags older than 90 days)
+   ```
+
+---
+
+### Phase 2: DESIGN -- Recommend Flag Architecture and Rollout Strategy
+
+1. **Evaluate flag naming convention.** Check for consistency:
+   - Recommended format: `{team}.{feature}.{variant}` (e.g., `payments.stripe-v2.enabled`)
+   - Flags should have descriptive names (not `flag_123` or `test_flag`)
+   - Naming should indicate category (prefix with `ops.` for operational flags)
+   - Temporary flags should include a target removal date in metadata
+
+2. **Design flag evaluation architecture.** Recommend patterns for:
+   - **Server-side evaluation:** Flags evaluated on the backend, consistent behavior
+   - **Client-side evaluation:** Flags evaluated in the browser/app, real-time updates
+   - **Edge evaluation:** Flags evaluated at CDN layer for zero-latency decisions
+   - **Default values:** Every flag must have a safe default (feature off) for provider outages
+
+3. **Design rollout strategy.** For release flags:
+   - **Percentage rollout:** Start at 1%, monitor metrics, increase to 5%, 25%, 50%, 100%
+   - **User segment targeting:** Internal users first, then beta users, then general availability
+   - **Geographic rollout:** Single region first, expand after validation
+   - **Time-based gates:** Enable during low-traffic periods for initial validation
+   - Define success criteria for each rollout stage (error rate, latency, conversion)
+
+4. **Design A/B testing infrastructure.** For experiment flags:
+   - Consistent user assignment (same user always sees same variant)
+   - Statistical significance calculation before declaring a winner
+   - Event tracking integration for measuring experiment outcomes
+   - Guardrail metrics that auto-disable experiments if health degrades
+   - Experiment duration limits (no indefinite experiments)
+
+5. **Design fallback behavior.** Ensure resilience:
+   - Provider SDK timeout configuration (fail fast, not block)
+   - Local cache for flag values (stale-while-revalidate)
+   - Default values that are safe (feature disabled, not enabled)
+   - Circuit breaker on flag evaluation errors
+   - Monitoring on flag evaluation latency and error rate
+
+---
+
+### Phase 3: VALIDATE -- Verify Flag Hygiene and Test Coverage
+
+1. **Check test coverage per flag.** For each flag, verify:
+   - Tests exist for both the flag-on and flag-off code paths
+   - Integration tests cover the default value behavior (provider down scenario)
+   - No tests depend on a specific flag value being set in production
+   - Test utilities exist for overriding flag values in test context
+
+2. **Validate flag consistency.** Check for common issues:
+   - Flags checked in code but not defined in the provider (will use defaults)
+   - Flags defined in the provider but never checked in code (dead flags)
+   - Same flag checked with different keys in different files (typos)
+   - Nested flag checks that create combinatorial complexity
+
+3. **Check for flag coupling.** Identify problematic patterns:
+   - Flags that depend on other flags (if A and B, then C)
+   - Flags that must be enabled in a specific order
+   - Flags that share state or side effects
+   - Recommend decoupling or consolidating dependent flags
+
+4. **Validate rollout configuration.** For active rollouts:
+   - Percentage values are within expected ranges
+   - Targeting rules are correctly configured
+   - Kill switch is functional (can disable the feature instantly)
+   - Rollback plan is documented
+
+5. **Generate validation report:**
+
+   ```
+   Flag Validation: [PASS/WARN/FAIL]
+
+   Test coverage: WARN (3 flags missing flag-off tests)
+   Consistency: PASS (all code references match definitions)
+   Coupling: WARN (2 flags have interdependencies)
+   Rollout config: PASS (active rollouts correctly configured)
+
+   Issues:
+     1. payments.stripe-v2 -- no test for flag-off fallback path
+     2. search.new-algorithm + search.reranking -- coupled flags
+     3. checkout.express -- missing kill switch test
+   ```
+
+---
+
+### Phase 4: LIFECYCLE -- Audit Stale Flags and Plan Cleanup
+
+1. **Identify stale flags.** Flag candidates for removal:
+   - Release flags that have been at 100% for more than 30 days
+   - Experiment flags past their declared end date
+   - Flags with no evaluation in the last 90 days (from provider analytics)
+   - Flags whose feature has been fully adopted (no rollback expected)
+
+2. **Generate cleanup plan.** For each stale flag:
+   - List all code locations that reference the flag
+   - Identify which branch to keep (the flag-on path for graduated features)
+   - Estimate lines of code to remove (dead branch cleanup)
+   - Determine if any tests need updating after flag removal
+   - Assign a cleanup owner and deadline
+
+3. **Assess technical debt.** Calculate flag burden:
+   - Total active flags per service (recommend under 20)
+   - Ratio of temporary to permanent flags
+   - Average flag age for temporary flags
+   - Code complexity added by flag branching (conditional paths)
+   - Estimate of test matrix growth due to flags
+
+4. **Recommend lifecycle policies.** Design governance:
+   - Maximum lifetime for release flags (e.g., 90 days)
+   - Maximum lifetime for experiment flags (e.g., 30 days)
+   - Required metadata: owner, creation date, expiry date, cleanup ticket
+   - Automated alerting when flags exceed their lifetime
+   - Monthly flag review cadence with the team
+
+5. **Generate lifecycle report:**
+
+   ```
+   Flag Lifecycle Report:
+
+   Active flags: 23
+   Stale flags: 6 (candidates for removal)
+   Technical debt: ~340 lines of dead code across 6 stale flags
+
+   Cleanup plan:
+     1. payments.old-checkout -- at 100% for 45 days, 4 files, ~80 LOC to remove
+     2. search.v1-algorithm -- experiment ended 60 days ago, 2 files, ~40 LOC
+     3. onboarding.legacy-flow -- at 100% for 90 days, 6 files, ~120 LOC
+     4. notifications.email-v1 -- unused for 120 days, 3 files, ~50 LOC
+     5. dashboard.old-charts -- at 100% for 35 days, 2 files, ~30 LOC
+     6. auth.password-reset-v1 -- at 100% for 60 days, 1 file, ~20 LOC
+
+   Recommendations:
+     - Adopt 90-day maximum lifetime policy for release flags
+     - Add flag expiry dates to LaunchDarkly metadata
+     - Schedule monthly flag cleanup sprint
+     - Target: reduce active flag count from 23 to 17
+   ```
+
+---
+
+## Harness Integration
+
+- **`harness skill run harness-feature-flags`** -- Primary invocation for flag analysis and lifecycle management.
+- **`harness validate`** -- Run after flag cleanup to verify project health.
+- **`harness check-deps`** -- Verify flag provider SDK dependencies are installed.
+- **`emit_interaction`** -- Present lifecycle report and gather decisions on cleanup priorities.
+
+## Success Criteria
+
+- All feature flags in the project are discovered and cataloged
+- Flags are categorized by type (release, experiment, ops, permission)
+- Stale flags are identified with specific cleanup plans
+- Test coverage for both flag-on and flag-off paths is verified
+- Rollout configuration is validated for active flags
+- Lifecycle policies are recommended with enforcement mechanisms
+
+## Examples
+
+### Example: React SPA with LaunchDarkly
+
+```
+Phase 1: DETECT
+  Provider: LaunchDarkly (React SDK v3.x)
+  Flags defined: 15 (in LaunchDarkly dashboard)
+  Flags in code: 13 (2 unused in dashboard)
+  Categories: 8 release, 3 experiment, 2 ops
+
+Phase 2: DESIGN
+  Naming: WARN -- inconsistent (mix of camelCase and kebab-case)
+  Recommended convention: team.feature.variant (kebab-case)
+  Evaluation: Client-side (React SDK), 200ms init timeout
+  Default values: WARN -- 2 flags default to true (should default to false)
+  Rollout: checkout.express-pay at 25% (targeting premium users)
+
+Phase 3: VALIDATE
+  Test coverage: WARN -- 4 flags missing useFlags mock in component tests
+  Consistency: PASS
+  Coupling: PASS (no interdependent flags)
+  Kill switch: PASS (all release flags can be instantly disabled)
+
+Phase 4: LIFECYCLE
+  Stale: 3 flags at 100% for 30+ days
+  Cleanup estimate: 180 LOC across 8 files
+  Recommendation: Remove search.v2-results (at 100% for 65 days, 3 components)
+  Result: WARN -- 3 stale flags, 4 missing tests, 2 unsafe defaults
+```
+
+### Example: Spring Boot API with Custom Flag System
+
+```
+Phase 1: DETECT
+  Provider: Custom implementation (FeatureFlagService.java)
+  Flag store: PostgreSQL table (feature_flags)
+  Flags defined: 28
+  Flags in code: 24 (4 in database but unreferenced)
+  Categories: 15 release, 6 experiment, 5 ops, 2 permission
+
+Phase 2: DESIGN
+  Architecture: Server-side evaluation with 60s cache refresh
+  Concern: No SDK resilience -- database outage disables all flags
+  Recommend: Add in-memory cache with stale-while-revalidate pattern
+  Recommend: Add health check endpoint for flag service status
+  Rollout: Using percentage field in database -- no segment targeting
+  Recommend: Add user segment support for targeted rollouts
+
+Phase 3: VALIDATE
+  Test coverage: WARN -- @FeatureFlag annotation used but no test helper
+    to toggle flags in test context (tests rely on database state)
+  Consistency: WARN -- 4 database entries have no code references
+  Coupling: FAIL -- 3 flags form a dependency chain
+    (billing.new-pricing requires billing.tax-calc-v2 requires billing.currency-v3)
+  Recommend: Consolidate into single billing.pricing-v3 flag
+
+Phase 4: LIFECYCLE
+  Stale: 8 flags enabled for all users for 60+ days
+  Technical debt: ~520 LOC of dead code
+  Flag count: 28 (above recommended 20 per service)
+  Recommendation: Immediate cleanup sprint targeting 8 stale flags
+  Recommendation: Enforce 60-day lifetime policy going forward
+  Result: FAIL -- flag coupling detected, high stale flag count
+```
+
+## Gates
+
+- **No flags without default values.** Every flag evaluation must specify a default value for provider outage scenarios. Missing defaults are blocking findings.
+- **No stale release flags beyond policy limit.** Release flags that exceed their maximum lifetime (default 90 days at 100%) are blocking warnings. They must be cleaned up or have an explicit extension with documented justification.
+- **No coupled flag dependencies.** Flags that require other flags to be in a specific state create combinatorial complexity and are fragile. Flag coupling is a blocking finding that requires consolidation.
+- **No flags without test coverage for both paths.** Feature flags that lack tests for the off-path leave the fallback behavior unverified. Both paths must be tested.
+
+## Escalation
+
+- **When flag count exceeds 30 per service:** The flag system is becoming a maintenance burden. Recommend a flag audit sprint with a target of reducing to under 20. Prioritize removing the oldest release flags first.
+- **When a flag provider outage affects production:** If the application does not handle provider unavailability gracefully, this is an architectural issue. Recommend implementing local caching, safe defaults, and a circuit breaker pattern before adding more flags.
+- **When experiment results are inconclusive:** Do not extend the experiment indefinitely. Recommend increasing sample size (broader targeting), simplifying the variants, or declaring the experiment inconclusive and removing it.
+- **When flag cleanup requires database migration:** Removing flags that are stored in a database may require migration scripts. Coordinate cleanup with a release cycle and ensure rollback is possible if the migration fails.

package/dist/agents/skills/cursor/harness-feature-flags/skill.yaml

@@ -0,0 +1,74 @@
+name: harness-feature-flags
+version: "1.0.0"
+description: Flag lifecycle management, A/B testing infrastructure, and gradual rollouts
+cognitive_mode: advisory-guide
+tier: 3
+internal: false
+keywords:
+  - feature flags
+  - feature toggles
+  - LaunchDarkly
+  - Unleash
+  - Flagsmith
+  - A/B testing
+  - canary
+  - gradual rollout
+  - kill switch
+  - experiment
+stack_signals:
+  - "src/**/flags/**"
+  - "src/**/features/**"
+  - "src/**/*feature-flag*"
+  - "src/**/*toggle*"
+  - "flags.json"
+  - "features.json"
+triggers:
+  - manual
+  - on_new_feature
+platforms:
+  - claude-code
+  - gemini-cli
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - emit_interaction
+cli:
+  command: harness skill run harness-feature-flags
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: audit
+      description: Run stale flag audit to find flags past their expiry
+      type: boolean
+      required: false
+    - name: provider
+      description: Flag provider context (launchdarkly, unleash, flagsmith, custom)
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-feature-flags
+    path: string
+type: rigid
+phases:
+  - name: detect
+    description: Discover flag definitions, providers, and usage patterns
+    required: true
+  - name: design
+    description: Recommend flag architecture, naming, and rollout strategies
+    required: true
+  - name: validate
+    description: Verify flag hygiene, test coverage, and fallback behavior
+    required: true
+  - name: lifecycle
+    description: Audit stale flags and recommend cleanup or graduation
+    required: true
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/harness-git-workflow/SKILL.md

@@ -0,0 +1,268 @@
+# 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
+```

package/dist/agents/skills/cursor/harness-git-workflow/skill.yaml

@@ -0,0 +1,32 @@
+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
+tier: 3
+state:
+  persistent: false
+  files: []
+depends_on: []