infinity-harness 2.0.0

package/harness/skills/pi-todo-adapted.md

@@ -0,0 +1,41 @@
+---
+name: pi-todo-adapted
+description: "Atomic infinity_plan pattern with omission deletion, baseRevision optimistic concurrency, cycle/missing-dep checks and compaction-safe replay (adapted from @99percentpeople/pi-todo)"
+tags: [harness, pi-todo, atomic, baseRevision, omission, deletion, compaction, widget, task-list, dependency]
+when: "implementing infinity_plan, atomic revisioning, Pi widget with session persistence or task dependencies"
+phases: [build, verify]
+provenance: { origin: "https://github.com/99percentpeople/pi-extensions", license: MIT, adapted: true, url: "https://github.com/99percentpeople/pi-extensions", contentHash: abf626df6a74a6fb }
+---
+
+# pi-todo Adapted — Atomic Task List with Compaction-Safe Replay
+
+> Adapted from [@99percentpeople/pi-todo](https://github.com/99percentpeople/pi-extensions) (MIT © 99percentpeople). Trimmed to harness core and re-pointed to `harness/features/feature-list.json` + Pi extension `harness:checkpoint`.
+
+## Rules
+
+- **One-call authoritative list.** Client sends complete desired list; server treats omission as permanent deletion. Inherit omitted fields from previous snapshot; new keys require `subject` + `status`. Validation all-or-nothing.
+- **Optimistic concurrency via baseRevision.** Compare `input.baseRevision` vs current `revision`; reject stale with expected/current numbers; increment revision only on real change; empty no-op preserves revision.
+- **Dependency guarantees.** Every `dependsOn` must exist in resulting snapshot (prune completed→completed soft refs only); detect cycles via DFS; `in_progress`/`completed` requires deps completed. Reject atomically.
+- **ToolResult.details is SSOT for branch/compaction.** Store `{rev, tasks}` in toolResult.details; reconstruct state by scanning session branch for latest valid entry on `session_start`, `session_tree`, `/reload`. Branch-aware replay — each branch has correct snapshot.
+- **Hidden checkpoint for compaction.** On `session_before_compact`, persist `{rev, tasks}` as custom entry `harness:checkpoint` outside context; inject as hidden `[{role:"user", content:[{type:"text", text: hidden}]}]` via `context` event on next prompt (or immediately as steer if overflow/continuation). No extra model turn.
+- **Periodic hidden reminder.** Every N LLM calls (default 3) inject compact reminder with `rev + key/status` list via `context` event; reset counter after successful write, restoration, checkpoint injection, or interval change; suppress for empty/completed plans; not written to session.
+- **Widget renders collapsed window via getWidgetWindowBounds.** Use WIDGET_LIMIT=8, COMPLETED_CONTEXT=3, `+N more`, wrap not truncate, `← #1` deps. State comes from reconstructed session + file; survive /reload and /tree.
+
+## Anti-patterns
+
+- **Per-field patch calls** — one call must carry full authoritative list; piecemeal updates lose atomicity.
+- **File-only persistence** — file is SSOT but session replay is required for branches/compaction; without details replay, `/tree` drifts.
+- **Eager completed cleanup without dependency check** — completed tasks that still block pending/in_progress must be retained.
+- **Stale revision retry without re-read** — on stale error, re-read current rev/tasks and retry merge.
+
+## Checklist
+
+- [ ] Stale baseRevision rejected with expected/current message, no mutation
+- [ ] Omitted keys deleted, completed→completed deps pruned, new keys validated
+- [ ] Cycle and missing dep rejected atomically
+- [ ] in_progress requires deps completed (also completed requires deps completed if strict)
+- [ ] Revision increments only on added/updated/removed/reordered; details contain {rev, tasks}
+- [ ] State replays from toolResult.details + harness:checkpoint on session_start / session_tree
+- [ ] Hidden checkpoint stored before compaction and injected via context event after compaction
+- [ ] Periodic reminder every 3 calls injects rev + key/status via context, counter resets correctly
+- [ ] Widget uses rolling window (WIDGET_LIMIT=8) with +N more, wraps long labels, shows ← #1

package/harness/skills/planning-tasks.md

@@ -0,0 +1,86 @@
+---
+name: planning-tasks
+description: Break specs into tracer-bullet vertical slices with checkable acceptance criteria
+tags: [plan, planning, slice, ticket, decompose, criteria, backlog, breakdown, refactor]
+when: writing or restructuring the feature list from a spec
+phases: [plan]
+provenance: { origin: "mattpocock/skills", license: MIT, adapted: true }
+---
+
+# Planning Tasks — Tracer-Bullet Vertical Slices
+
+> Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT © Matt Pocock, "to-tickets").
+> Use during: PLAN (writing harness/features/feature-list.json).
+
+Break the spec into **tracer-bullet vertical slices** and record them as
+features + tasks in `harness/features/feature-list.json`.
+
+## Vertical slice rules
+
+- Each slice cuts a narrow but COMPLETE path through every layer (schema,
+  logic, interface, tests) — vertical, NOT a horizontal slice of one layer.
+- A completed slice is demoable or verifiable on its own.
+- Each task is sized to fit one working session / fresh context window.
+- Prefactoring goes first: "make the change easy, then make the easy change."
+- Order features so each builds on completed ones — the harness works them
+  top to bottom.
+
+## Writing the feature list
+
+```json
+{
+  "version": "0.1",
+  "features": [
+    {
+      "id": "feature-001",
+      "name": "User can create a note",
+      "description": "End-to-end: POST /notes → stored → retrievable",
+      "passes": false,
+      "definitionOfDone": [
+        "POST /notes with valid body returns 201 + id",
+        "GET /notes/:id returns the stored note",
+        "Invalid body returns 400 with error message"
+      ],
+      "tasks": [
+        {
+          "id": "task-001",
+          "description": "Note model + storage with create/get",
+          "status": "pending",
+          "acceptanceCriteria": [
+            "createNote(data) returns note with generated id",
+            "getNote(id) returns the created note",
+            "getNote(unknown) returns null"
+          ]
+        }
+      ]
+    }
+  ]
+}
+```
+
+Rules for criteria:
+
+- **acceptanceCriteria** (task) — 1–3 concrete, checkable statements about
+  observable behavior. "Works correctly" is not a criterion; "getNote(unknown)
+  returns null" is. Gates reject empty or placeholder criteria.
+- **definitionOfDone** (feature) — user-visible outcomes proving the whole
+  slice works end-to-end.
+- Name features in **user terms** ("User can X"), not layer terms ("Add DB
+  table").
+- Use the project's domain vocabulary (`harness/docs/DOMAIN.md`).
+
+## Wide refactors — the exception
+
+A **wide refactor** (rename a shared symbol, retype a column) breaks
+thousands of call sites at once; no vertical slice can land green. Sequence
+it as **expand–contract**: one task to add the new form beside the old, then
+migration tasks in batches (per package/directory) that stay green because
+the old form still exists, then one task to delete the old form once no
+caller remains.
+
+## Sanity check before finishing PLAN
+
+- Does each feature deliver something demoable?
+- Is anything blocked by a feature that comes AFTER it? (Reorder.)
+- Too coarse (task needs multiple sessions) or too fine (trivial edits)?
+- Zero placeholder text left anywhere in the file.

package/harness/skills/prototype.md

@@ -0,0 +1,39 @@
+---
+name: prototype
+description: Throwaway code that answers a design question fast, then gets deleted
+tags: [prototype, spike, experiment, explore, poc, throwaway, design]
+when: a state model, logic shape, or UI direction cannot be judged on paper
+phases: [build, plan]
+provenance: { origin: "mattpocock/skills", license: MIT, adapted: true }
+---
+
+# Prototype
+
+> Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT © Matt Pocock).
+> Use during: BUILD (or PLAN) when a design question can't be answered on paper.
+
+A prototype is **throwaway code that answers a question**. The question
+decides the shape:
+
+- **"Does this logic / state model feel right?"** → build a tiny runnable
+  script that pushes the state machine through the cases that are hard to
+  reason about on paper.
+- **"What should this look like?"** → build several radically different
+  variations of the interface, cheaply switchable.
+
+## Rules
+
+1. **Throwaway from day one, clearly marked.** Name it so a casual reader
+   sees it's a prototype (`proto-*`, a `prototypes/` dir) — never mixed
+   into production paths.
+2. **One command to run.** Whatever the project's runner supports.
+3. **No persistence by default.** State lives in memory; persistence is
+   usually the thing being *checked*, not a dependency.
+4. **Skip the polish.** No tests, no error handling beyond runnability, no
+   abstractions. The point is to learn fast.
+5. **Surface the state.** After every action, print the full relevant state
+   so the effect of each step is visible.
+6. **Capture it when done.** Fold the validated decision into the real code
+   and record it: `infinity-harness decision "state machine X chosen because Y
+   (validated by prototype)"`. Then DELETE the prototype — the
+   anti-placeholder gate will flag leftovers, and that's by design.

package/harness/skills/research.md

@@ -0,0 +1,32 @@
+---
+name: research
+description: Answer factual questions from primary sources; capture cited findings in the repo
+tags: [research, docs, documentation, investigate, source, facts, api, spec, evidence]
+when: a factual question about an API, library, protocol, or tool blocks progress
+phases: [define, plan, build]
+provenance: { origin: "mattpocock/skills", license: MIT, adapted: true }
+---
+
+# Research
+
+> Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT © Matt Pocock).
+> Use during: DEFINE, or any time a factual question blocks progress.
+
+When a question needs investigating (an API's real behavior, a library's
+limits, a protocol detail):
+
+1. Investigate against **primary sources** — official docs, source code,
+   specs, first-party APIs — never a secondary write-up of them. Follow
+   every claim back to the source that owns it.
+2. Write the findings to a single Markdown file under `docs/research/`
+   (create it if missing), citing each claim's source.
+3. Keep conclusions separate from evidence: a short "Answer" section up
+   top, the sourced detail below.
+4. Record the headline insight so future sessions inherit it:
+   `harness/lessons-decisions.md "research: X behaves like Y (see docs/research/...)"`.
+
+Rules of evidence:
+
+- A claim without a source is a guess. Label guesses as guesses.
+- Version matters: note WHICH version of the tool/API the claim covers.
+- If two sources disagree, the more primary one wins; note the conflict.

package/harness/skills/resolving-merge-conflicts.md

@@ -0,0 +1,30 @@
+---
+name: resolving-merge-conflicts
+description: Resolve git merge/rebase conflicts by original intent, verify, and finish
+tags: [git, merge, rebase, conflict, branch, hunk]
+when: an in-progress git merge or rebase has conflicting hunks
+phases: []
+provenance: { origin: "mattpocock/skills", license: MIT, adapted: true }
+---
+
+# Resolving Merge Conflicts
+
+> Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT © Matt Pocock).
+> Use during: any in-progress git merge/rebase conflict.
+
+1. **See the current state** of the merge/rebase. Check git history and the
+   conflicting files.
+2. **Find the primary sources** for each conflict. Understand deeply why
+   each change was made and what the original intent was: read commit
+   messages, PRs, the feature list entries, and progress log
+   (`harness/progress.md`).
+3. **Resolve each hunk.** Preserve both intents where possible. Where
+   incompatible, pick the one matching the merge's stated goal and note the
+   trade-off. Do **not** invent new behaviour. Always resolve; never
+   `--abort`.
+4. **Run the project's automated checks** — typecheck, then tests, then
+   lint (`the infinity_validate tool` runs the configured set). Fix anything the
+   merge broke.
+5. **Finish the merge/rebase.** Stage everything and commit. If rebasing,
+   continue until all commits are rebased. Record anything surprising:
+   `harness/lessons-decisions.md "..."`.

package/harness/skills/scope-discipline.md

@@ -0,0 +1,49 @@
+---
+name: scope-discipline
+description: The contract is the boundary — park ideas, resist drive-by fixes, renegotiate explicitly
+tags: [meta, scope, creep, contract, focus, discipline, playbook]
+when: mid-task ideas, adjacent problems, or "while I'm here" temptations appear
+phases: []
+provenance: { origin: built-in, notes: frontier-playbook }
+---
+
+# Scope Discipline
+
+Scope creep is how good sessions produce unshippable diffs. The sprint
+contract and the task's acceptance criteria define what you're building —
+everything else, however good, is NOT NOW.
+
+## Rules
+
+- **The criteria are the whole job.** Done = criteria met. Not "criteria
+  met plus improvements I noticed". Extra behavior nobody asked for is
+  scope creep even when it's good — it widens the diff, the review
+  surface, and the blast radius.
+- **Park, don't pursue.** Mid-task ideas go to the parking lot in one
+  line — `harness/lessons-decisions.md "idea: ..."` or a backlog entry in the
+  feature list — and you return to the slice. Parking takes 10 seconds;
+  pursuing takes an hour and derails the task.
+- **Drive-by fixes are parked too.** Broken thing found outside the task
+  (unless it BLOCKS the task): record it, leave it. One task = one
+  concern = one reviewable diff.
+- **Blockers interrupt; everything else waits.** The only legitimate
+  mid-task detour is something the acceptance criteria cannot be met
+  without. Name it as a blocker (learn), fix the minimum, return.
+- **Renegotiate explicitly, never silently.** If the task turns out
+  wrong-sized or the contract missed something real: stop, record it, and
+  change the plan through the front door (feature-list edit in PLAN
+  terms, or contract re-negotiation) — not by quietly building something
+  different from what the contract says.
+- **Simplification has its phase.** Refactoring urges during BUILD get
+  parked for SIMPLIFY — the pipeline gives cleanup its own budgeted slot.
+
+## The test
+
+Before touching a file, ask: *which acceptance criterion needs this
+change?* No answer → you're creeping. Park it.
+
+## Checklist
+
+- [ ] Diff touches only what the criteria require
+- [ ] Every parked idea captured (learn/backlog), none pursued
+- [ ] Any scope change went through plan/contract, with a decision recorded

package/harness/skills/self-review.md

@@ -0,0 +1,45 @@
+---
+name: self-review
+description: Structured pass before claiming done — criteria re-check, real run, leftover hunt
+tags: [meta, review, verify, done, quality, check, playbook]
+when: before running validate on any task — every time
+phases: [build, verify, simplify]
+provenance: { origin: built-in, notes: frontier-playbook }
+---
+
+# Self-Review — Before You Claim Done
+
+Frontier models don't submit their first draft; they run this pass. It
+takes two minutes and catches the majority of validate failures before
+they burn a retry.
+
+## The pass
+
+1. **Re-read the acceptance criteria, one by one, against your diff.**
+   For each: point at the line(s) that satisfy it. A criterion you can't
+   point at is not met — no matter how done it feels.
+2. **Run the thing once, for real.** Not just the tests — the actual entry
+   point (start the server, invoke the CLI, render the page). Tests
+   passing while the app crashes on boot is a classic.
+3. **Hunt leftovers:** debug prints, commented-out code, TODO/FIXME stubs,
+   hardcoded test values, files you created but abandoned. (The
+   anti-placeholder gate will catch some — beat it to the punch.)
+4. **Read the diff as a skeptic:** `git diff` top to bottom. Would a
+   reviewer who dislikes you find something? Fix it now.
+5. **Check the blast radius:** what ELSE uses what you touched? One
+   caller-grep per changed public symbol.
+
+## Rules
+
+- Never validate as a formality — validate expecting to find problems.
+- The criteria are the contract; "better than asked" and "close enough to
+  asked" are both failures (see scope-discipline.md).
+- If step 2 is impossible (no runnable surface), say so in the commit
+  message rather than pretending you ran it.
+
+## Checklist
+
+- [ ] Every acceptance criterion mapped to specific lines
+- [ ] Entry point actually executed post-change
+- [ ] Leftover grep clean (debug/TODO/dead files)
+- [ ] Diff read end-to-end; caller-grep done per public change

package/harness/skills/stuck-protocol.md

@@ -0,0 +1,51 @@
+---
+name: stuck-protocol
+description: What to do after repeated failures — stop, write down, reframe once, escalate cleanly
+tags: [meta, stuck, retry, failure, escalate, blocked, playbook]
+when: the same step has failed 2-3 times, or you notice you are looping
+phases: []
+provenance: { origin: built-in, notes: frontier-playbook }
+---
+
+# Stuck Protocol
+
+Thrashing — trying variations of the same failing approach — burns retries
+and context while teaching nothing. Frontier models notice the loop and
+break it deliberately.
+
+## The trigger
+
+**Three failed attempts at the same step = STOP.** Also stop when you
+catch any of these tells:
+
+- You're re-running the same command hoping for a different result
+- Each "fix" is a small mutation of the last failed fix
+- You can no longer say what NEW information the last attempt produced
+
+## The protocol
+
+1. **Write down what you know** (before trying anything else):
+   what you're trying to achieve, the exact error/failure, the attempts
+   made, and what each attempt ruled out. Writing this usually exposes the
+   gap — half the time you solve it here.
+2. **Re-read the brief and the skill** (`the infinity_brief tool`; the skill it
+   references). Stuck often means a constraint was missed, not that the
+   problem is hard.
+3. **Reframe ONCE** — one genuinely different angle, not a variation:
+   different seam, smaller slice, different tool, the inverse operation,
+   or build the feedback loop you skipped (`diagnosing-bugs.md` Phase 1).
+4. **Escalate cleanly** if the reframe fails:
+   - `harness/lessons-decisions.md "BLOCKED <step>: tried A, B, C; ruled out X, Y; suspect Z"`
+   - Leave the tree committed and green-adjacent (no half-applied change)
+   - Let validate fail honestly — the retry ladder and the human exist for
+     exactly this. A clean escalation with evidence is a GOOD outcome;
+     a fourth identical attempt is not.
+
+## Rules
+
+- Never delete the failing evidence (test, error output) to make the step
+  "pass".
+- Never widen scope to route around the blocker ("I'll just rewrite the
+  module") — that's thrash with more damage.
+- The write-down in step 1 is mandatory, not optional — it's what makes
+  the human's (or next session's) job possible.

package/harness/skills/tdd.md

@@ -0,0 +1,80 @@
+---
+name: tdd
+description: Red → green test-driven loop — what a good test is, seams, anti-patterns
+tags: [tdd, test, testing, unit, integration, red-green, seam, mock, coverage]
+when: implementing any BUILD task, or fixing a bug that needs a regression test
+phases: [build, verify]
+provenance: { origin: "mattpocock/skills", license: MIT, adapted: true }
+---
+
+# TDD — Test-Driven Development
+
+> Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT © Matt Pocock).
+> Use during: BUILD (every task).
+
+TDD is the red → green loop. This skill makes that loop produce tests worth
+keeping. Every section applies on every cycle.
+
+Before exploring the codebase, read `harness/docs/DOMAIN.md` (if present) so
+test names and interface vocabulary match the project's domain language, and
+respect decisions recorded in `harness/docs/DECISIONS.md`.
+
+## Rules of the loop
+
+- **Red before green.** Write the failing test first, then only enough code
+  to pass it. Don't anticipate future tests or add speculative features.
+- **One slice at a time.** One seam, one test, one minimal implementation
+  per cycle.
+- **Refactoring is not part of the loop.** It belongs to SIMPLIFY/REVIEW,
+  not the red → green cycle.
+
+## What a good test is
+
+Tests verify behavior through public interfaces, not implementation details.
+Code can change entirely; tests shouldn't. A good test reads like a
+specification — "user can checkout with valid cart" tells you exactly what
+capability exists — and survives refactors because it doesn't care about
+internal structure.
+
+```js
+// GOOD: observable behavior through the public API
+test('user can checkout with valid cart', async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe('confirmed');
+});
+
+// BAD: implementation detail — breaks on refactor, catches nothing real
+test('checkout calls paymentService.process', async () => {
+  const mockPayment = mock(paymentService);
+  await checkout(cart, payment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+## Seams — where tests go
+
+A **seam** is the public boundary you test at: the interface where you
+observe behavior without reaching inside. Tests live at seams, never against
+internals. Before writing any test, write down the seams under test — the
+task's acceptance criteria usually name them. Testing effort goes to critical
+paths and complex logic, not every edge case.
+
+Mock **only at external seams** (network, clock, filesystem, third-party
+APIs) — never mock your own internal collaborators.
+
+## Anti-patterns
+
+- **Implementation-coupled** — mocks internal collaborators, tests private
+  methods, or verifies through a side channel (querying the database instead
+  of using the interface). Tell: the test breaks when you refactor but
+  behavior hasn't changed.
+- **Tautological** — the assertion recomputes the expected value the way the
+  code does (`expect(add(a, b)).toBe(a + b)`), so it passes by construction.
+  Expected values must come from an independent source of truth — a
+  known-good literal, a worked example, the spec.
+- **Horizontal slicing** — writing all tests first, then all implementation.
+  Bulk tests verify *imagined* behavior. Work in **vertical slices**: one
+  test → one implementation → repeat, each test a tracer bullet that responds
+  to what the last cycle taught you.

package/harness/skills/testing-infra.md

@@ -0,0 +1,57 @@
+---
+name: testing-infra
+description: Test infrastructure — fixtures, isolation, flaky-test policy, CI hygiene, coverage sanity
+tags: [test, testing, fixture, ci, flaky, coverage, mock, isolation, pipeline, suite]
+when: task sets up test tooling, fixtures, CI, or fights slow/flaky suites
+phases: [build, verify]
+provenance: { origin: built-in }
+---
+
+# Testing Infrastructure
+
+(`tdd.md` covers what a good test IS; this covers the machinery around them.)
+
+## Rules
+
+- **Tests are order-independent and parallel-safe.** Each test creates its
+  own data and cleans up (or runs in a transaction rolled back / fresh
+  tmpdir). If running one test alone changes its result, the suite is
+  broken even while green.
+- **Fixtures are builders, not blobs.** `makeUser({overrides})` beats a
+  500-line fixtures.json — tests state only what matters, defaults carry
+  the rest, schema changes touch one builder.
+- **Determinism is manufactured:** pin the clock (fake timers), seed RNG,
+  freeze network (record/replay or fakes at the seam), isolate filesystem
+  (tmpdir per test). Anything you didn't pin will flake at 2am.
+- **Flaky-test policy — zero tolerance:** a flaky test is a P1 against the
+  suite. Quarantine it the day it flakes (skip with a linked issue),
+  diagnose with `diagnosing-bugs.md` (usually: unpinned time, shared
+  state, real network, race). A retried-until-green suite verifies nothing.
+- **The pyramid is a budget:** many fast unit/integration tests at seams,
+  few end-to-end smoke tests. E2E for "the wiring works", not for every
+  edge case — edges belong at the seam where they live.
+- **CI runs what developers run:** same command (`npm test`), same
+  versions, fresh checkout, no network by default. "Works locally" bugs
+  are environment drift — fix the environment, not the test.
+- **Coverage is a smoke detector, not a target.** Use it to FIND untested
+  branches; never write assertion-free tests to move the number. The
+  gate's threshold is a floor, not a goal.
+
+## Anti-patterns
+
+- **Shared mutable fixtures** ("the test database user") → per-test data
+  with unique keys; suites die by a thousand shared rows.
+- **Sleeping to wait** (`sleep 2` then assert) → poll with timeout or
+  await the actual signal; sleeps are both slow AND flaky.
+- **Mocking the world** — suite passes while the app is down → integration
+  tests at real seams (real DB, real HTTP server in-process).
+- **Snapshot everything** — giant snapshots nobody reads, updated with
+  `--update` reflexively → snapshot small, stable, reviewed outputs only.
+
+## Checklist
+
+- [ ] Any single test runs alone: same result
+- [ ] Suite passes twice in a row AND with a different order/seed
+- [ ] No real network/clock/RNG unpinned anywhere
+- [ ] Flaky tests quarantined with linked issues (count: 0 is the goal)
+- [ ] CI command identical to the local test command

package/harness/skills/writing-skills.md

@@ -0,0 +1,60 @@
+---
+name: writing-skills
+description: How to author a skill worth keeping — scope, structure, frontmatter, quality bar
+tags: [meta, skill, writing, author, documentation, checklist]
+when: creating a new skill or adapting an acquired one
+phases: []
+provenance: { origin: "mattpocock/skills writing-great-skills", license: MIT, adapted: true }
+---
+
+# Writing Skills
+
+A skill is a reusable instruction file that changes how the work gets done.
+The test: **would a weak model do the right thing following ONLY this
+file?** If not, it's not done.
+
+## Rules
+
+- **One job per skill.** "databases" not "backend-development". If you're
+  writing "and also…", split it.
+- **Rules + anti-patterns + checklist** — that structure, every time.
+  Rules are imperative and checkable. Anti-patterns show what going wrong
+  looks like AND the fix. The checklist is how the reader verifies they
+  applied it.
+- **≤120 lines of body.** Longer means it's two skills or it's a tutorial.
+- **Concrete over abstract.** One short example beats three paragraphs of
+  principle. Name real commands, real file paths, real error messages.
+- **Frontmatter required** (the matcher is blind without it):
+
+```yaml
+---
+name: kebab-case-name
+description: One line, 10-300 chars — what this teaches
+tags: [five, or, more, search, keywords]        # ≥3 required; think "what words appear in tasks that need this?"
+when: the task signal that should trigger this skill
+phases: [build]                                  # optional phase affinity
+provenance: { origin: self-authored, authoredBy: agent }
+---
+```
+
+Frontmatter uses a strict subset: `key: value`, `key: [a, b]`,
+`key: { k: v }` — no multiline YAML.
+
+- **Tag for the matcher.** Tags are matched against task text — use the
+  nouns a task description would actually contain ("postgres", "auth",
+  "migration"), not categories ("backend").
+
+## Anti-patterns
+
+- **The essay** — background, history, philosophy. Delete everything that
+  doesn't change what the reader does next.
+- **The mirror** — restating what the harness already enforces (gates,
+  phases). Skills teach craft, not process.
+- **The wishlist** — "consider…", "you might…". Skills say DO and DON'T.
+
+## Checklist
+
+- [ ] Frontmatter passes: `infinity-harness capability add skill <path>` (it validates)
+- [ ] A cold reader knows exactly what to do and how to check they did it
+- [ ] Every rule is checkable; every anti-pattern has a fix
+- [ ] Attribution line present if adapted from elsewhere

package/package.json

@@ -0,0 +1,61 @@
+{
+  "name": "infinity-harness",
+  "version": "2.0.0",
+  "description": "A pi agent extension that runs a gated build pipeline unattended \u2014 enforces phases, validates with deterministic gates, and keeps working for hours or days without losing the plan.",
+  "type": "module",
+  "keywords": [
+    "pi-package",
+    "pi-extension",
+    "harness",
+    "agent-pipeline",
+    "autonomous",
+    "continuous-development"
+  ],
+  "license": "MIT",
+  "author": "Bakr Bagaber",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/bakr-bagaber/infinity-harness.git"
+  },
+  "pi": {
+    "extensions": [
+      "./extensions"
+    ],
+    "skills": [
+      "./harness/skills"
+    ]
+  },
+  "files": [
+    "extensions/",
+    "src/",
+    "types/",
+    "harness/skills/",
+    "harness/docs/",
+    "harness/model-router.json",
+    "README.md",
+    "LICENSE",
+    "CHANGELOG.md"
+  ],
+  "engines": {
+    "node": ">=22.0.0"
+  },
+  "dependencies": {
+    "proper-lockfile": "^4.1.2",
+    "string-width": "^7.1.0"
+  },
+  "devDependencies": {
+    "@earendil-works/pi-coding-agent": "*",
+    "@types/node": "^22.0.0",
+    "typescript": "^5.5.0"
+  },
+  "scripts": {
+    "test": "node scripts/run-tests.mjs",
+    "check": "tsc --noEmit",
+    "build": "tsc --noEmit",
+    "e2e": "node scripts/e2e.mjs"
+  },
+  "homepage": "https://github.com/bakr-bagaber/infinity-harness#readme",
+  "bugs": {
+    "url": "https://github.com/bakr-bagaber/infinity-harness/issues"
+  }
+}