CLIScenarios

User scenarios

Workflow guides for the current HarnessTap CLI, grouped by usage frequency.

This document reflects the current shipped CLI. Each scenario links to a detail page with typical commands.

Orientation

  • Machine-wide setup: init, profile use, harness set (Scenarios 1, 2, 36)
  • Repo adoption: scan, layer apply, mirror (Scenarios 4, 7, 27)
  • Layer curation: layer create, layer edit, layer doctor, add (Scenarios 5, 23, 35)
  • Plugin pins: resource sync, layer show, layer apply --strict-plugin-versions (Scenarios 8, 16)
  • Repo profiles: config show, ht use (Scenario 40)
  • Sharing: migrate export / import, layer pull / layer publish (Scenarios 10, 28)

See the VHS demo pack for rendered walkthroughs of the covered workflows.

Usage frequency

Frequency describes how often a typical active user reaches for a scenario after HarnessTap is set up — not how important it is the first time.

FrequencyMeaning
CommonRegular per-repo work: onboarding, adoption, repo-specific prefs, applying layers
OccasionalSetup, customization, sharing, maintenance, automation, CI integration
RareEdge cases, team-only constraints, debugging, or recovery after a mistake
ScenarioTitleFrequencyStatus
7Preview and apply a layerCommonShipped
11Start from a catalog baselineCommonShipped
4Scan and import an existing repoCommonShipped
35Add a remote skill packageCommonShipped
38Create a layer from a skill packageCommonShipped
31Import dual-mode plugin repoCommonShipped
3Override harness preferences for one repositoryCommonShipped
15Apply to a subset of target platformsCommonShipped
25Stack multiple layersCommonShipped
26Turn a project's current state into a layerCommonShipped
27True cross-harness mirrorCommonShipped
36Switch global profile presetsCommonShipped
40Switch repo profiles from .harnesstap/config.tomlCommonShipped
1Bootstrap HarnessTap on a machineOccasionalShipped
2Choose a default main harness and aliasesOccasionalShipped
5Build a reusable layer from imported resourcesOccasionalShipped
8Audit plugin resources and layer pinsOccasionalShipped
10Export or import a layer bundleOccasionalShipped
12Drive HarnessTap from scripts or agentsOccasionalShipped
13Choose a materialization strategy (symlink vs copy)OccasionalShipped
16Enforce layer and plugin state in CIOccasionalShipped
19Sync plugin resources from install treesOccasionalShipped
20Inspect supported platforms before targetingOccasionalShipped
21Detect drift between project and last applied layerOccasionalShipped
22Diff two layersOccasionalShipped
23Doctor-check a layer without writingOccasionalShipped
24Apply a layer directly from a URLOccasionalShipped
37Publish a profile layer to the catalogOccasionalShipped
32Apply to instruction-tier harnessesOccasionalShipped
33Mirror with plugin-source fallbackOccasionalShipped
34Understand portability limitsOccasionalShipped
39Switch MCP tokens via environments; OAuth limitsOccasionalDocumented
6Add plugin constraints to a layerRareShipped
9Review history and recover from a bad applyRareShipped
14Curate and clean up the local resource DBRareShipped
17Migrate HarnessTap state to a new machineRareShipped (manual)
18Debug committed vs effective Claude plugin settingsRareShipped
28Share workspace offline with migrate export/importOccasionalShipped

Status legend

  • Shipped — the commands shown in the scenario exist in the current CLI.
  • Documented — workflow is documented with known product limits (see the scenario detail page).
  • Shipped (manual) — achievable today with current commands but as a multi-step workflow (see Scenario 17 vs 28).

Common

Use these when starting or adopting a repository, applying a layer, or when one repo needs different harness defaults than your machine-wide setup.

ScenarioSummary
7Preview and apply a layer to one or more target harnesses
11Start from a catalog baseline instead of building from scratch
4Scan an existing repository and import its current harness setup
35Add a remote skill package
38Create a layer from a skill package
31Import a repo with both harness files and plugin-source layout
3Override harness preferences for one repository
15Apply a layer to a subset of target platforms
25Stack multiple layers in one apply
26Turn a project's current state into a layer
27True cross-harness mirror
36Switch global profile presets on the machine
40Switch repo profiles from .harnesstap/config.toml

Occasional

Reach for these during initial setup, when curating layers, when sharing baselines, or when integrating HarnessTap into tooling.

ScenarioSummary
1Bootstrap HarnessTap on a machine and discover existing defaults
2Choose a default main harness and alias harnesses
5Build a reusable layer from imported resources
8Audit plugin resources and layer pins
10Export or import a layer as a portable bundle
12Drive HarnessTap from scripts or other agents
13Choose a materialization strategy (symlink vs copy)
16Enforce layer and plugin state in CI
19Sync plugin resources from install trees
20Inspect supported platforms before targeting
21Detect drift between project files and the last applied layer
22Diff two layers (or a layer vs an imported bundle)
23Doctor-check a layer without writing to disk
24Apply a layer directly from a URL
28Share a full workspace offline with migrate export/import
37Publish and install profile-tagged catalog layers
32Apply layers to instruction-tier harnesses (windsurf, cline, copilot, …)
33Mirror alias harnesses when main harness tree is empty
34Review what transfers across harnesses and what does not
39Switch MCP tokens via environments; OAuth host limits (Documented)

Rare

These matter when requirements are strict, when something went wrong, or when maintaining the local DB after a lot of activity.

ScenarioSummary
6Add plugin constraints to a layer
9Review project state, history, and recover from a bad apply
14Curate and clean up the local resource DB
17Migrate HarnessTap state to a new machine (manual workflow)
18Debug committed vs effective Claude plugin settings