he-spec Entry
Use when the user needs a Harness Engineering specification artifact before planning or implementation.
Context disposition: Apply the context-disposition policy: move important still-valid context to references and index it when meaningful; intentionally discard stale, duplicated, unsafe, superseded, or low-signal text.
Philosophy
- Clarify the behavior contract before planning or coding.
- Keep acceptance criteria concrete enough for downstream verification.
When to use
Use he-spec when the user needs the WHAT-before-HOW contract for a feature, UI behavior, bug, QA report, or ambiguous implementation request.
Required inputs
- A brainstorm, Linear issue, existing spec, QA report, UI source, feature description, or behavior gap.
- Known caller-facing interfaces, domain terms, source acceptance IDs, and relevant repo paths.
- Parent/child issue context and branch/PR metadata when the work is already tracked.
Deliverables
- A spec-mode decision and implementation-grade behavior contract.
- Stable
SA or VAC acceptance IDs, explicit non-goals, risks, observability notes, and planning-ready first slice.
- For tracked work, Linear issue frontmatter plus a Linear Acceptance Traceability table.
Core Contract
- Specify the WHAT before
he-plan; do not implement code here.
- Resolve the active Linear issue for non-trivial tracked work; stop and request or create one if it is missing.
- Ground the spec in the source artifact, QA report, Linear issue, UI source, feature description, and any
CONTEXT.md terms that shape behavior.
- Detect caller-facing interfaces early: module, API, CLI, plugin, tool, service, data-access, or shared-helper boundaries.
- Name the selected contract, acceptance criteria, failure/recovery behavior, observability expectations, and planning-ready first slice.
- Route unresolved contract gaps to
he-deepen-spec; route complete specs to he-plan.
Procedure
- Resolve source artifact, Linear issue, and domain terms.
- Define expected behavior, non-goals, interface shape, and acceptance IDs.
- Add Linear acceptance traceability and the first planning slice.
Traceability
Tracked specs need Linear Work Item Contract frontmatter and a Linear Acceptance Traceability table mapping the issue to SA or VAC acceptance IDs, parent/child context when relevant, and the planning handoff.
Validation
- Confirm required frontmatter and mode-specific sections exist.
- Confirm
SA or VAC IDs are concrete enough for planning.
- Confirm tracked specs include Linear issue frontmatter and acceptance traceability.
- For written tracked specs, run
python3 Infrastructure/scripts/validation-and-linting/he_linear_traceability_lint.py <spec-path> as a required gate.
- Stop at the first failed gate.
Constraints
- Redact secrets, credentials, tokens, and sensitive data by default.
- Do not plan sequencing or implement code from this skill.
- Use Linear issues or comments for durable decisions.
Anti-patterns
- Inventing undocumented behavior.
- Sending an unspecified interface to planning.
- Sending tracked work onward without Linear acceptance traceability.
Examples
- "Turn this Linear issue into a spec before planning."
- "Specify this QA behavior gap with acceptance criteria."
Failure mode
If required behavior, interface boundaries, or tracker context cannot be resolved, stop and ask for the missing source instead of inventing acceptance criteria.
Gotchas
- Do not plan sequencing or implement code from this skill.
- Do not treat GitHub PRs as the tracker of record; use them as delivery evidence linked back to Linear.
- Route incomplete caller-facing contracts to
he-deepen-spec before he-plan.
References
- Full guide:
Plugins/harness-engineering/fixtures/preserved-context/skills/he-spec/SKILL.full.md
- Spec artifact contract:
Plugins/harness-engineering/fixtures/preserved-context/skills/he-spec/references/spec-artifacts.md
- Spec mode rules:
Plugins/harness-engineering/fixtures/preserved-context/skills/he-spec/references/spec-modes.md
- Subagent routing:
Plugins/harness-engineering/references/subagent-routing.md
- Domain and QA routing:
Plugins/harness-engineering/references/domain-model-routing.md, Plugins/harness-engineering/references/qa-intake-routing.md
1---2name: he-spec-23description: Write Harness Engineering specs before planning. Use when a feature, QA report, Linear issue, or UI source needs a clear WHAT contract.4---56# he-spec Entry78Use when the user needs a Harness Engineering specification artifact before planning or implementation.910Context disposition: Apply the context-disposition policy: move important still-valid context to references and index it when meaningful; intentionally discard stale, duplicated, unsafe, superseded, or low-signal text.1112## Philosophy1314- Clarify the behavior contract before planning or coding.15- Keep acceptance criteria concrete enough for downstream verification.1617## When to use1819Use `he-spec` when the user needs the WHAT-before-HOW contract for a feature, UI behavior, bug, QA report, or ambiguous implementation request.2021## Required inputs2223- A brainstorm, Linear issue, existing spec, QA report, UI source, feature description, or behavior gap.24- Known caller-facing interfaces, domain terms, source acceptance IDs, and relevant repo paths.25- Parent/child issue context and branch/PR metadata when the work is already tracked.2627## Deliverables2829- A spec-mode decision and implementation-grade behavior contract.30- Stable `SA` or `VAC` acceptance IDs, explicit non-goals, risks, observability notes, and planning-ready first slice.31- For tracked work, Linear issue frontmatter plus a Linear Acceptance Traceability table.3233## Core Contract3435- Specify the WHAT before `he-plan`; do not implement code here.36- Resolve the active Linear issue for non-trivial tracked work; stop and request or create one if it is missing.37- Ground the spec in the source artifact, QA report, Linear issue, UI source, feature description, and any `CONTEXT.md` terms that shape behavior.38- Detect caller-facing interfaces early: module, API, CLI, plugin, tool, service, data-access, or shared-helper boundaries.39- Name the selected contract, acceptance criteria, failure/recovery behavior, observability expectations, and planning-ready first slice.40- Route unresolved contract gaps to `he-deepen-spec`; route complete specs to `he-plan`.4142## Procedure43441. Resolve source artifact, Linear issue, and domain terms.452. Define expected behavior, non-goals, interface shape, and acceptance IDs.463. Add Linear acceptance traceability and the first planning slice.4748## Traceability4950Tracked specs need Linear Work Item Contract frontmatter and a Linear Acceptance Traceability table mapping the issue to `SA` or `VAC` acceptance IDs, parent/child context when relevant, and the planning handoff.5152## Validation5354- Confirm required frontmatter and mode-specific sections exist.55- Confirm `SA` or `VAC` IDs are concrete enough for planning.56- Confirm tracked specs include Linear issue frontmatter and acceptance traceability.57- For written tracked specs, run `python3 Infrastructure/scripts/validation-and-linting/he_linear_traceability_lint.py <spec-path>` as a required gate.58- Stop at the first failed gate.5960## Constraints6162- Redact secrets, credentials, tokens, and sensitive data by default.63- Do not plan sequencing or implement code from this skill.64- Use Linear issues or comments for durable decisions.6566## Anti-patterns6768- Inventing undocumented behavior.69- Sending an unspecified interface to planning.70- Sending tracked work onward without Linear acceptance traceability.7172## Examples7374- "Turn this Linear issue into a spec before planning."75- "Specify this QA behavior gap with acceptance criteria."7677## Failure mode7879If required behavior, interface boundaries, or tracker context cannot be resolved, stop and ask for the missing source instead of inventing acceptance criteria.8081## Gotchas8283- Do not plan sequencing or implement code from this skill.84- Do not treat GitHub PRs as the tracker of record; use them as delivery evidence linked back to Linear.85- Route incomplete caller-facing contracts to `he-deepen-spec` before `he-plan`.8687## References8889- Full guide: `Plugins/harness-engineering/fixtures/preserved-context/skills/he-spec/SKILL.full.md`90- Spec artifact contract: `Plugins/harness-engineering/fixtures/preserved-context/skills/he-spec/references/spec-artifacts.md`91- Spec mode rules: `Plugins/harness-engineering/fixtures/preserved-context/skills/he-spec/references/spec-modes.md`92- Subagent routing: `Plugins/harness-engineering/references/subagent-routing.md`93- Domain and QA routing: `Plugins/harness-engineering/references/domain-model-routing.md`, `Plugins/harness-engineering/references/qa-intake-routing.md`