| name | harness-config-specs |
| description | Use when working in the harness-config repository on the Harness config v1 standard, conformance rules, specification wording, manifest/resource/dir/profile/ignore semantics, or docs ownership. |
Harness config Specs
Purpose
Use this skill when the task is about the v1 contract: what Harness config
means, which behavior is normative, and which docs should carry the wording.
Source Of Truth
docs/STANDARD.md is the normative contract.docs/CONFORMANCE.md is the testable support checklist.docs/TOOLING.md and package READMEs describe CLI behavior.docs/TESTING.md maps scenarios to tests.
Load only the reference needed:
references/docs-ownership.md for doc ownership decisions.references/v1-invariants.md for stable v1 projection rules.
Workflow
- Decide whether the change is normative, tooling-specific, or test-only.
- Update the owning doc before or alongside behavior changes.
- Keep the standard implementation-neutral.
- Add or update conformance text when a claim should be externally testable.
- Use focused tests for new or sharpened behavior.
Useful checks:
rg -n "harnessProfileRoot|harnessProfileIsolation|harnessIgnore|target.*parent|wildcard|harnessComposable|\\.harnessRef" docs packages
pnpm --filter @harnessconfig/core test
pnpm --filter @harnessconfig/cli test
Guardrails
- Do not make runtime folders implicit.
- Do not turn target folders into source repositories.
- Do not encode agent product choices or registries into the v1 core contract.
- Keep CLI flags and package names out of
docs/STANDARD.md.
