uni-harness 0.1.1 → 0.1.2

package/.claude/skills/harness-init/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: harness-init
-description: Scan the repository of a new project to fill in the PROJECT section of CLAUDE.md and .harness/commands.env, and propose initial RULES/ANTI-PATTERNS. Run once right after installing the harness, or whenever CLAUDE.md is still in placeholder state. Verifies detected commands by actually running them before applying.
+description: Scan the repository to fill in the PROJECT section of CLAUDE.md and .harness/commands.env, and propose initial RULES/ANTI-PATTERNS. Run once right after installing the harness, or whenever CLAUDE.md is still in placeholder state. Verifies detected commands by actually running them before applying. If the repo has no project code yet (greenfield), offers to scaffold a minimal project so the sensors start active from the first line of code.
 ---
 
 # Harness Init — Initialize the Harness by Scanning the Repo
@@ -16,9 +16,11 @@ running them.
   the project. Never let it drive language detection, and never propose the
   kit's self-test (`harness/tests/test_hooks.sh`) as the project's TEST_CMD:
   it verifies the harness, not the user's code, and pointing the stop gate
-  at it would "pass" every turn regardless of what broke. If no project
-  code exists outside those directories yet, say so and leave the commands
-  blank until there is something real to verify.
+  at it would "pass" every turn regardless of what broke.
+- The scan decides which mode you are in: project code exists → continue
+  with Step 2 (and the brownfield section if the project predates the
+  harness). Nothing but harness files → switch to the **New Projects
+  (greenfield)** section below. Do not stop at "nothing to configure".
 - Language/version: from manifests (package.json, pyproject.toml, go.mod,
   Cargo.toml, *.csproj, ...). Prefer versions pinned in lockfiles/config.
 - BUILD / TEST / LINT candidates: collect from manifest scripts, Makefile,
@@ -46,6 +48,32 @@ running them.
   truisms ("write good code") are forbidden — only things observable in
   this repository.
 
+## New Projects (greenfield — the harness was installed before any code)
+
+If the scan finds no project code at all (no manifest, no sources, no CI),
+the user is starting a project *with* the harness — the whole point is
+that sensors guard the very first code written. Ending with "come back
+later" leaves them off during the riskiest phase. Instead, offer to
+bootstrap:
+
+1. **Ask, don't guess:** what is being built, which language/runtime,
+   which framework and test runner (offer the ecosystem defaults, e.g.
+   pytest / vitest / go test).
+2. **Propose a minimal scaffold** and apply it only after approval: the
+   manifest (package.json / pyproject.toml / go.mod ...), a source entry
+   point, a test setup with **one real passing test**, and a
+   linter/formatter config if the ecosystem has a standard one. Announce
+   any dependency installs with the reason before running them.
+3. If it is not a git repository, offer `git init` (the guard hooks and
+   future ANTI-PATTERNS mining assume git history).
+4. Then continue with Step 2 exactly as usual: run the scaffold's
+   BUILD/TEST/LINT commands, confirm they pass, and fill CLAUDE.md and
+   commands.env with the **verified** commands.
+
+The exit criterion for greenfield: sensors ACTIVE against a real (if tiny)
+test suite. If the user declines the scaffold, leave everything blank as
+before and tell them to re-run /harness-init once code exists.
+
 ## Existing Projects (brownfield)
 
 - If CLAUDE.md existed before the harness was installed, never replace it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uni-harness",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Agent harness kit for Claude Code — installs verification sensors, destructive-command guards, checkpoint recovery, observability logs, and ratchet skills into your project",
   "bin": {
     "uni-harness": "bin/cli.js"