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, apply, mirror (Scenarios 4, 7, 27)
  • Plugin curation: plugin create, plugin edit, plugin doctor, add (Scenarios 5, 23, 35)
  • Plugin pins: resource sync, plugin show, apply --strict-plugin-versions (Scenarios 8, 16)
  • Repo profiles: config show, ht use (Scenario 40)
  • Sharing: migrate export / import, plugin pull / plugin 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 plugins
OccasionalSetup, customization, sharing, maintenance, automation, CI integration
RareEdge cases, team-only constraints, debugging, or recovery after a mistake
ScenarioTitleFrequencyStatus
7Preview and apply a pluginCommonShipped
11Start from a catalog baselineCommonShipped
4Scan and import an existing repoCommonShipped
35Add a remote skill packageCommonShipped
38Create a plugin from a skill packageCommonShipped
31Import dual-mode plugin repoCommonShipped
3Override harness preferences for one repositoryCommonShipped
15Apply to a subset of target platformsCommonShipped
25Stack multiple pluginsCommonShipped
26Turn a project's current state into a pluginCommonShipped
27True cross-harness mirrorCommonShipped
36Switch global profile presetsCommonShipped
40Switch repo profiles from apm.ymlCommonShipped
1Bootstrap HarnessTap on a machineOccasionalShipped
2Choose a default main harness and aliasesOccasionalShipped
5Build a reusable plugin from imported resourcesOccasionalShipped
8Audit plugin resources and plugin pinsOccasionalShipped
10Export or import a plugin bundleOccasionalShipped
12Drive HarnessTap from scripts or agentsOccasionalShipped
13Choose a materialization strategy (symlink vs copy)OccasionalShipped
16Enforce plugin and plugin state in CIOccasionalShipped
19Sync plugin resources from install treesOccasionalShipped
20Inspect supported platforms before targetingOccasionalShipped
21Detect drift between project and last applied pluginOccasionalShipped
22Diff two pluginsOccasionalShipped
23Doctor-check a plugin without writingOccasionalShipped
24Apply a plugin directly from a URLOccasionalShipped
37Publish a profile plugin 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 pluginRareShipped
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 plugin, or when one repo needs different harness defaults than your machine-wide setup.

ScenarioSummary
7Preview and apply a plugin 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 plugin from a skill package
31Import a repo with both harness files and plugin-source layout
3Override harness preferences for one repository
15Apply a plugin to a subset of target platforms
25Stack multiple plugins in one apply
26Turn a project's current state into a plugin
27True cross-harness mirror
36Switch global profile presets on the machine
40Switch repo profiles from apm.yml

Occasional

Reach for these during initial setup, when curating plugins, 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 plugin from imported resources
8Audit plugin resources and plugin pins
10Export or import a plugin as a portable bundle
12Drive HarnessTap from scripts or other agents
13Choose a materialization strategy (symlink vs copy)
16Enforce plugin 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 plugin
22Diff two plugins (or a plugin vs an imported bundle)
23Doctor-check a plugin without writing to disk
24Apply a plugin directly from a URL
28Share a full workspace offline with migrate export/import
37Publish and install profile-tagged catalog plugins
32Apply plugins 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 plugin
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