@harness-engineering/cli 1.14.0 → 1.16.0

package/dist/agents/skills/claude-code/harness-security-scan/SKILL.md

@@ -58,6 +58,58 @@
 - **`harness.config.json`** — Security section configures severity threshold and file exclusions.
 - **codebase-health-analyst persona** — Invokes this skill as part of its sweep.
 
+## Evidence Requirements
+
+When this skill makes claims about existing code, architecture, or behavior,
+it MUST cite evidence using one of:
+
+1. **File reference:** `file:line` format (e.g., `src/auth.ts:42`)
+2. **Code pattern reference:** `file` with description (e.g., `src/utils/hash.ts` —
+   "existing bcrypt wrapper")
+3. **Test/command output:** Inline or referenced output from a test run or CLI command
+4. **Session evidence:** Write to the `evidence` session section via `manage_state`
+
+**Uncited claims:** Technical assertions without citations MUST be prefixed with
+`[UNVERIFIED]`. Example: `[UNVERIFIED] The auth middleware supports refresh tokens`.
+
+## Red Flags
+
+### Universal
+
+These apply to ALL skills. If you catch yourself doing any of these, STOP.
+
+- **"I believe the codebase does X"** — Stop. Read the code and cite a file:line
+  reference. Belief is not evidence.
+- **"Let me recommend [pattern] for this"** without checking existing patterns — Stop.
+  Search the codebase first. The project may already have a convention.
+- **"While we're here, we should also [unrelated improvement]"** — Stop. Flag the idea
+  but do not expand scope beyond the stated task.
+
+### Domain-Specific
+
+- **"This finding is in test code, so it's not a real issue"** — Stop. Test code can leak secrets, establish bad patterns, and be copy-pasted to production.
+- **"This dependency is widely used, so it's safe"** — Stop. Popularity is not a security guarantee. Check CVE databases and advisory feeds.
+- **"This is a low-severity finding, skipping"** — Stop. Low-severity findings compound. Document why you are deprioritizing, do not silently skip.
+- **"The scanner didn't flag it, so it's clean"** — Stop. Scanners have false negatives. A clean scan is not proof of security — it is absence of evidence.
+
+## Rationalizations to Reject
+
+### Universal
+
+These reasoning patterns sound plausible but lead to bad outcomes. Reject them.
+
+- **"It's probably fine"** — "Probably" is not evidence. Verify before asserting.
+- **"This is best practice"** — Best practice in what context? Cite the source and
+  confirm it applies to this codebase.
+- **"We can fix it later"** — If it is worth flagging, it is worth documenting now
+  with a concrete follow-up plan.
+
+### Domain-Specific
+
+- **"No attacker would find this"** — Security by obscurity. If the code is wrong, flag it regardless of discoverability.
+- **"We're behind a firewall"** — Network boundaries change. Code should be secure at every layer regardless of deployment topology.
+- **"The framework handles this for us"** — Verify the framework's actual behavior. Misuse of a secure framework is still insecure.
+
 ## Escalation
 
 - **When error-severity findings are disputed:** The scanner is mechanical — it may flag false positives. If a finding is a false positive, add a `// harness-ignore SEC-XXX` comment on the line and document the rationale. Do not suppress without explanation.

package/dist/agents/skills/claude-code/harness-supply-chain-audit/SKILL.md

@@ -0,0 +1,281 @@
+# Harness Supply Chain Audit
+
+> 6-factor dependency risk evaluation adapted from Trail of Bits security skill patterns. Surfaces dependency risk flags for human review — not automated verdicts.
+
+## When to Use
+
+- Before a major release to assess dependency risk
+- After adding new dependencies
+- During security audits or compliance reviews
+- When `on_milestone` trigger fires (part of release gate)
+- NOT as a replacement for `npm audit` — this complements it with risk signals beyond CVEs
+- NOT for license compliance (separate concern)
+
+## Iron Law
+
+**Present findings as flags for human review, never as verdicts.** A dependency flagged as "high risk" may be entirely appropriate for a project. The skill surfaces signals; humans decide whether to act.
+
+---
+
+## Process
+
+### Phase 1: INVENTORY — Build Dependency List
+
+1. **Resolve project root.** Use the path argument or default to the current directory.
+
+2. **Detect lockfile.** Check for the following in order:
+   - `package-lock.json` (npm)
+   - `pnpm-lock.yaml` (pnpm)
+   - `yarn.lock` (yarn)
+   - If none found: report "No lockfile detected. Run `npm install` first." and stop.
+
+3. **Parse direct dependencies** from `package.json`:
+   - Read `dependencies` and `devDependencies`
+   - Build a list: `{ name, version, isDev }`
+
+4. **Parse transitive depth** from lockfile:
+   - For `package-lock.json`: read `packages` keys to extract the dependency tree. Nesting depth of `node_modules/` segments in keys indicates transitive depth.
+   - For `pnpm-lock.yaml`: read `importers` section for direct dependencies (keyed by workspace path, e.g., `.` for root). Each importer lists `dependencies` and `devDependencies` with version specifiers. Read `packages` section for resolved versions — keys are package identifiers (e.g., `/@scope/pkg@1.2.3`) with `resolution` (tarball URL + integrity hash) and `dependencies` sub-map for transitives.
+   - For `yarn.lock`: parse block-format entries. Each block header is `"pkg@version-range":` followed by indented fields: `version` (resolved), `resolved` (tarball URL), `integrity` (hash), and `dependencies` sub-block listing transitive deps as `"name" "version-range"` pairs.
+   - Assign each package a depth (0 = direct, 1 = first-level transitive, etc.)
+   - Flag packages with depth > 5 for transitive risk evaluation
+
+5. **Build inventory table:**
+
+   ```
+   INVENTORY: <project-name>
+   Direct dependencies: N
+   Dev dependencies: N
+   Total packages (including transitives): N
+   Deep transitive packages (depth > 5): N
+   ```
+
+6. Proceed to EVALUATE.
+
+---
+
+### Phase 2: EVALUATE — Score Dependencies on 6 Factors
+
+For each **direct dependency** (and any transitive with depth > 5), score on 6 factors:
+
+> Network access required: npm registry (`https://registry.npmjs.org/<pkg>`) and GitHub API (`https://api.github.com/repos/<owner>/<repo>`).
+>
+> - If npm registry returns 404: mark as "unresolvable", flag for manual review, skip remaining factors
+> - If GitHub API rate limits hit: score `maintenance-status` as "unknown", continue with other factors
+> - If no GitHub repo link in package metadata: skip `maintenance-status` factor, note in report
+
+#### Factor 1: Maintainer Concentration
+
+- Fetch: `GET https://registry.npmjs.org/<pkg>`
+- Check: `maintainers` array length
+- Score:
+  - **High risk:** 1 maintainer (bus factor = 1)
+  - **Medium risk:** 2-3 maintainers
+  - **Low risk:** 4+ maintainers
+
+#### Factor 2: Maintenance Status
+
+- Source: npm `time` field (last publish date) + GitHub API commit activity
+- npm: `GET https://registry.npmjs.org/<pkg>` → `time.modified`
+- GitHub: `GET https://api.github.com/repos/<owner>/<repo>/commits?per_page=1` → latest commit date
+- Score:
+  - **High risk:** Last publish > 12 months ago AND no GitHub commits in 6 months
+  - **Medium risk:** Last publish > 12 months ago OR no commits in 6 months (not both)
+  - **Low risk:** Active in both dimensions
+
+#### Factor 3: Popularity Signal
+
+- Fetch: `GET https://api.npmjs.org/downloads/point/last-week/<pkg>`
+- Score:
+  - **High risk:** < 1,000 weekly downloads
+  - **Medium risk:** 1,000–10,000 weekly downloads
+  - **Low risk:** > 10,000 weekly downloads
+  - **Note:** Low popularity is a signal, not a verdict — internal/niche packages are expected to be low
+
+#### Factor 4: Install Scripts
+
+- Read: `node_modules/<pkg>/package.json` (or lockfile-resolved path) → `scripts` field
+- Check for: `preinstall`, `postinstall`, `install`, `preuninstall`, `postuninstall`
+- Score:
+  - **High risk:** Any install script present
+  - **Low risk:** No install scripts
+  - **Note:** Some install scripts are legitimate (native addon compilation). Flag for review.
+
+#### Factor 5: Known CVEs
+
+- Run: `npm audit --json` or `pnpm audit --json`
+- Parse: map findings to their package name
+- Score:
+  - **Critical:** Any high/critical severity CVE
+  - **Medium risk:** Moderate severity CVE
+  - **Low risk:** No CVEs or low severity only
+
+#### Factor 6: Transitive Risk
+
+- Source: Lockfile depth analysis from INVENTORY phase
+- Score:
+  - **High risk:** Depth > 5 AND subtree size > 20 transitive packages
+  - **Medium risk:** Depth > 5 OR subtree size > 20
+  - **Low risk:** Depth ≤ 5 and subtree size ≤ 20
+
+#### Risk Scoring
+
+Combine factor scores into an overall risk level:
+
+| Overall Risk | Condition                                                      |
+| ------------ | -------------------------------------------------------------- |
+| **Critical** | Factor 5 is Critical (any high/critical CVE)                   |
+| **High**     | 2+ factors scored High, OR Factor 1 is High + Factor 2 is High |
+| **Medium**   | 1 factor scored High, OR 3+ factors scored Medium              |
+| **Low**      | All factors Low or at most 1 Medium                            |
+
+---
+
+### Phase 3: REPORT — Generate Risk Summary
+
+1. **Produce risk summary table** sorted by overall risk (Critical first):
+
+   ```
+   Supply Chain Audit: <project-name>
+   Date: <ISO date>
+   Packages evaluated: N direct + M deep transitives
+
+   ┌─────────────────────┬──────────┬────────────┬─────────────┬────────────┬──────┬─────────────┐
+   │ Package             │ Version  │ Maintainers│ Last Publish│ Downloads  │ CVEs │ Overall Risk│
+   ├─────────────────────┼──────────┼────────────┼─────────────┼────────────┼──────┼─────────────┤
+   │ example-pkg         │ 1.2.3    │ 1 (HIGH)   │ 18mo (HIGH) │ 500 (MED)  │ none │ HIGH        │
+   │ another-pkg         │ 2.0.0    │ 12         │ 2mo         │ 50k        │ 1 mod│ MEDIUM      │
+   └─────────────────────┴──────────┴────────────┴─────────────┴────────────┴──────┴─────────────┘
+   ```
+
+2. **Detail section for Critical and High risk packages:**
+
+   ```
+   HIGH RISK: example-pkg@1.2.3
+   ├── Maintainer concentration: 1 maintainer (bus factor = 1)
+   ├── Maintenance status: Last publish 18 months ago, no commits in 12 months
+   ├── Popularity: 500 weekly downloads
+   ├── Install scripts: none
+   ├── Known CVEs: none
+   └── Transitive risk: depth 2, subtree 4 packages
+   Recommendation: Consider replacing with a well-maintained alternative,
+   or pin the version and monitor for abandonment.
+   ```
+
+3. **Install script warnings** (any package with install scripts):
+
+   ```
+   INSTALL SCRIPTS DETECTED:
+   - node-gyp@9.4.0: postinstall — native addon compilation (likely legitimate)
+   - suspicious-pkg@1.0.0: postinstall — review script contents before trusting
+   ```
+
+4. **Summary line:**
+
+   ```
+   RESULT: 1 Critical, 2 High, 3 Medium, N Low — Review flagged items before release
+   ```
+
+5. **Output:** Print report to stdout. If `--output <file>` was passed, also write to that file.
+
+---
+
+## Gates
+
+- **Stop if no lockfile.** Do not evaluate without a lockfile — results will be unreliable.
+- **Present as flags, not verdicts.** Never state "this package is unsafe." State "this package has signals that warrant review."
+- **Do not block on API failures.** If npm registry or GitHub API is unavailable, note which factors were skipped and continue with available data.
+
+## Harness Integration
+
+- **`harness validate`** — Run after creating the skill files to verify they are properly placed.
+- **Triggers:** `on_milestone` fires this skill as part of the milestone completion checklist.
+- **Depends on:** `harness-security-scan` — run after mechanical scanning to complete the security picture.
+- **Output:** Stdout report, optionally written to file via `--output`. No state files written.
+
+## Evidence Requirements
+
+When reporting findings, cite the source for each factor:
+
+- Maintainer data: `registry.npmjs.org/<pkg>` → `maintainers` field
+- Publish date: `registry.npmjs.org/<pkg>` → `time.modified`
+- Downloads: `api.npmjs.org/downloads/point/last-week/<pkg>`
+- Install scripts: `node_modules/<pkg>/package.json` → `scripts`
+- CVEs: `npm audit --json` output
+- Depth: lockfile analysis
+
+Do not assert risk scores without citing the specific data point that generated the score.
+
+## Success Criteria
+
+- Running `/harness:supply-chain-audit` on a project with dependencies outputs a risk table with all 6 factors scored
+- A dependency with a sole maintainer and no commits in 12 months scores "high risk"
+- A dependency with a `postinstall` script is flagged in the install scripts section
+- API failures produce "unknown" scores with a note, not errors that stop the audit
+- All findings are framed as flags for human review, not automated verdicts
+
+## Escalation
+
+- **If a critical CVE is found:** Surface immediately — do not bury it in the table. Recommend blocking the dependency update or requiring an immediate patch before merge.
+- **If all maintainers are unresponsive:** Flag the package as abandoned and recommend finding an alternative. Include download counts to help the user assess how widely adopted the package is.
+- **If an install script has unknown behavior:** Do not guess. State that the script requires manual review and link to the script source.
+- **If the npm or GitHub API is unavailable:** Note which factors were skipped with "unknown" scores. Do not fail the audit — partial results are better than none.
+- **If the user asks for a verdict ("is this safe?"):** Decline to give a binary answer. Supply chain risk is probabilistic. Present the risk signals and let the human decide.
+
+## Examples
+
+```
+Supply Chain Audit: my-project
+Date: 2026-03-31
+Packages evaluated: 24 direct + 3 deep transitives (depth > 5)
+
+CRITICAL (1):
+  lodash@4.17.20 — CVE-2021-23337 (high severity, unpatched)
+
+HIGH (2):
+  abandoned-util@0.9.1 — sole maintainer, last publish 22 months ago
+  sketchy-helper@2.1.0 — sole maintainer, postinstall script detected
+
+MEDIUM (3):
+  small-lib@1.0.0 — 800 weekly downloads (low popularity signal)
+  ...
+
+LOW (18): no significant risk signals
+
+INSTALL SCRIPTS:
+  node-gyp@9.4.0 — postinstall (native compilation, likely legitimate)
+  sketchy-helper@2.1.0 — postinstall (REVIEW: contents unknown)
+
+RESULT: 1 Critical, 2 High, 3 Medium, 18 Low
+Next steps: Update lodash to patch CVE. Review sketchy-helper postinstall script.
+Consider alternatives to abandoned-util.
+```
+
+## Example Output
+
+```
+Supply Chain Audit: my-project
+Date: 2026-03-31
+Packages evaluated: 24 direct + 3 deep transitives (depth > 5)
+
+CRITICAL (1):
+  lodash@4.17.20 — CVE-2021-23337 (high severity, unpatched)
+
+HIGH (2):
+  abandoned-util@0.9.1 — sole maintainer, last publish 22 months ago
+  sketchy-helper@2.1.0 — sole maintainer, postinstall script detected
+
+MEDIUM (3):
+  small-lib@1.0.0 — 800 weekly downloads (low popularity signal)
+  ...
+
+LOW (18): no significant risk signals
+
+INSTALL SCRIPTS:
+  node-gyp@9.4.0 — postinstall (native compilation, likely legitimate)
+  sketchy-helper@2.1.0 — postinstall (REVIEW: contents unknown)
+
+RESULT: 1 Critical, 2 High, 3 Medium, 18 Low
+Next steps: Update lodash to patch CVE. Review sketchy-helper postinstall script.
+Consider alternatives to abandoned-util.
+```

package/dist/agents/skills/claude-code/harness-supply-chain-audit/skill.yaml

@@ -0,0 +1,51 @@
+name: harness-supply-chain-audit
+version: "1.0.0"
+description: 6-factor dependency risk evaluation for supply chain security
+cognitive_mode: meticulous-implementer
+triggers:
+  - manual
+  - on_milestone
+platforms:
+  - claude-code
+  - gemini-cli
+tools:
+  - Bash
+  - Read
+  - Write
+  - Grep
+  - Glob
+  - WebFetch
+cli:
+  command: harness skill run harness-supply-chain-audit
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: depth
+      description: Maximum dependency depth to evaluate (default 3)
+      required: false
+    - name: output
+      description: Write report to file instead of stdout
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-supply-chain-audit
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: inventory
+    description: Build dependency inventory from lockfile
+    required: true
+  - name: evaluate
+    description: Score each dependency on 6 risk factors
+    required: true
+  - name: report
+    description: Generate risk report with actionable findings
+    required: true
+state:
+  persistent: false
+  files: []
+depends_on:
+  - harness-security-scan

package/dist/agents/skills/codex/add-harness-component/SKILL.md

@@ -0,0 +1,192 @@
+# Add Harness Component
+
+> Add layers, documentation, components, or skills to an existing harness project with proper integration. Validate against existing constraints, wire into architecture, and verify the result.
+
+## When to Use
+
+- Adding a new layer to the project's architecture
+- Adding a new documentation file that harness should track
+- Adding a new component (module, service, package) that must be wired into existing layer boundaries
+- Adding a new skill to the project's skill library
+- When a plan calls for introducing a new architectural boundary or module
+- NOT when initializing a project from scratch (use initialize-harness-project)
+- NOT when modifying an existing component (use standard editing workflows)
+- NOT when removing components (manual process — removing requires careful dependency analysis)
+
+## Process
+
+### Phase 1: DETERMINE — Identify What to Add
+
+1. **Clarify the component type.** Ask if not obvious from context:
+   - **Layer:** A new architectural boundary (e.g., adding an "infrastructure" layer to a project that only has "business" and "data")
+   - **Document:** A documentation file that harness should track for drift detection (e.g., API docs, architecture decision records)
+   - **Component:** A code module, service, or package that lives within an existing layer
+   - **Skill:** A new harness skill definition for the project's workflow
+
+2. **Gather requirements.** For each type:
+   - **Layer:** Name, which directories belong to it, which layers it can import from, which layers can import from it
+   - **Document:** Path, what it documents, which code files it relates to
+   - **Component:** Name, which layer it belongs to, what it depends on, what will depend on it
+   - **Skill:** Name, purpose, type (rigid or flexible), triggers
+
+3. **Check prerequisites.** The project must already be initialized with harness. If `harness.yaml` does not exist, stop and run initialize-harness-project first.
+
+### Phase 2: VALIDATE — Check Against Existing Constraints
+
+1. **Read the current configuration.** Load `harness.yaml` and `AGENTS.md` to understand existing layers, constraints, and architecture.
+
+2. **Verify the new component does not conflict:**
+   - Does the layer name already exist?
+   - Does the component directory already exist?
+   - Would the new dependency relationships create circular imports?
+   - Does the component violate any existing forbidden-import rules?
+
+3. **If conflicts are found,** report them clearly: "Adding layer X would conflict with existing layer Y because [reason]. Options: [A] rename, [B] merge into existing layer, [C] restructure. Which do you prefer?"
+
+4. **Run `harness check-deps`** on the current state to establish a clean baseline. If it already fails, fix existing violations before adding new components.
+
+### Phase 3: ADD — Create the Component
+
+1. **Run `harness add` with appropriate arguments:**
+   - Layer: `harness add layer <name> --dirs <dir1,dir2> --imports <allowed-layers>`
+   - Document: `harness add doc <path> --tracks <related-code-paths>`
+   - Component: `harness add component <name> --layer <layer-name>`
+   - Skill: `harness add skill <name> --type <rigid|flexible>`
+
+2. **Review generated files and configuration changes.** `harness add` modifies `harness.yaml` and may generate template files. Check that the changes look correct.
+
+3. **Create the actual code or content.** `harness add` creates the configuration entry but not necessarily the implementation. Create the directories, files, and initial code as needed.
+
+### Phase 4: WIRE — Integrate into Architecture
+
+1. **Update imports and exports.** If the new component needs to be imported by existing code, add the imports. If existing code needs to be aware of the new layer, update barrel files or index modules.
+
+2. **Update `AGENTS.md`.** Add the new component to the architecture section. Document its purpose, boundaries, and relationships to other components. This keeps agent instructions accurate.
+
+3. **Update layer configuration** if the new component changes dependency relationships. Ensure `harness.yaml` reflects the actual import graph.
+
+4. **For new skills:** Write the `skill.yaml` and `SKILL.md` files following the harness skill format. Use harness-skill-authoring for guidance on writing good skill content.
+
+### Phase 5: VERIFY — Confirm Integration
+
+1. **Run `harness validate`** to verify the full project configuration is still valid after the addition.
+
+2. **Run `harness check-deps`** to verify no dependency violations were introduced. The new component's imports must respect layer boundaries.
+
+### Graph Refresh
+
+If a knowledge graph exists at `.harness/graph/`, refresh it after code changes to keep graph queries accurate:
+
+```
+harness scan [path]
+```
+
+Skipping this step means subsequent graph queries (impact analysis, dependency health, test advisor) may return stale results.
+
+3. **If validation fails,** fix the issues before committing. Common causes:
+   - New layer not properly registered in `harness.yaml`
+   - Component placed in wrong directory for its declared layer
+   - Imports from forbidden layers
+   - `AGENTS.md` references outdated architecture
+
+4. **Commit the addition.** All new and modified files in a single atomic commit.
+
+## Harness Integration
+
+- **`harness add layer <name>`** — Register a new architectural layer with directory mappings and import rules.
+- **`harness add doc <path>`** — Register a documentation file for drift tracking.
+- **`harness add component <name> --layer <layer>`** — Register a new code component within an existing layer.
+- **`harness add skill <name> --type <type>`** — Scaffold a new skill definition.
+- **`harness validate`** — Verify project configuration after the addition.
+- **`harness check-deps`** — Verify dependency constraints are respected after the addition.
+
+## Success Criteria
+
+- The new component is properly registered in `harness.yaml`
+- The component's files exist in the correct directories for its declared layer
+- `AGENTS.md` is updated to reflect the new component
+- `harness validate` passes after the addition
+- `harness check-deps` passes after the addition (no new violations)
+- No circular dependencies were introduced
+- The addition is committed as a single atomic commit
+
+## Examples
+
+### Example: Adding a New Layer
+
+```
+Human: "We need an infrastructure layer for external API clients."
+
+DETERMINE: Adding a layer. Name: infrastructure. Dirs: src/infrastructure/.
+  Imports from: (none — infrastructure is a leaf layer, no internal dependencies).
+  Imported by: business layer (services call external APIs through infrastructure).
+
+VALIDATE:
+  Read harness.yaml — existing layers: presentation, business, data.
+  No conflict with "infrastructure" name.
+  Run: harness check-deps — passes (clean baseline).
+
+ADD:
+  harness add layer infrastructure --dirs src/infrastructure --imports none
+  mkdir -p src/infrastructure
+
+WIRE:
+  Update harness.yaml: allow business → infrastructure imports.
+  Update AGENTS.md: document infrastructure layer purpose and boundaries.
+
+VERIFY:
+  harness validate    # Pass
+  harness check-deps  # Pass
+  git add harness.yaml AGENTS.md src/infrastructure/
+  git commit -m "feat: add infrastructure layer for external API clients"
+```
+
+### Example: Adding a Document for Drift Tracking
+
+```
+Human: "Track our API specification for documentation drift."
+
+DETERMINE: Adding a document. Path: docs/api-spec.md.
+  Tracks: src/routes/, src/models/response.ts.
+
+ADD:
+  harness add doc docs/api-spec.md --tracks src/routes,src/models/response.ts
+
+WIRE:
+  Update AGENTS.md: note that docs/api-spec.md is tracked for drift.
+
+VERIFY:
+  harness validate  # Pass
+  git add harness.yaml AGENTS.md
+  git commit -m "feat: track API spec for documentation drift detection"
+```
+
+### Example: Adding a Component to an Existing Layer
+
+```
+Human: "Add a notification service to the business layer."
+
+DETERMINE: Adding a component. Name: notification-service. Layer: business.
+  Depends on: data layer (notification repository). Depended on by: presentation layer (routes).
+
+VALIDATE:
+  Read harness.yaml — business layer exists, maps to src/services/.
+  No existing notification-service directory.
+  business → data is an allowed import. Presentation → business is allowed.
+  Run: harness check-deps — passes.
+
+ADD:
+  harness add component notification-service --layer business
+  Create src/services/notification-service.ts
+  Create src/services/notification-service.test.ts
+
+WIRE:
+  Add export to src/services/index.ts (if barrel file exists).
+  Update AGENTS.md: add notification service to business layer component list.
+
+VERIFY:
+  harness validate    # Pass
+  harness check-deps  # Pass
+  git add harness.yaml AGENTS.md src/services/notification-service.*
+  git commit -m "feat: add notification service to business layer"
+```

package/dist/agents/skills/codex/add-harness-component/skill.yaml

@@ -0,0 +1,33 @@
+name: add-harness-component
+version: "1.0.0"
+description: Add a component to an existing harness project
+cognitive_mode: constructive-architect
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+cli:
+  command: harness skill run add-harness-component
+  args:
+    - name: path
+      description: Project root path
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: add-harness-component
+    path: string
+type: flexible
+tier: 1
+state:
+  persistent: false
+  files: []
+depends_on:
+  - initialize-harness-project