@hobin/developer 0.1.3 → 0.1.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hobin/developer",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "description": "Adaptive product-development reasoning and evidence for Pi.",
   "type": "module",
   "keywords": ["pi-package", "pi", "developer", "skills"],
@@ -28,7 +28,9 @@
   "scripts": {
     "check": "node scripts/check-package.mjs && node --test tests/*.test.ts",
     "eval": "node scripts/eval-rpc.mjs",
-    "eval:json": "node scripts/eval-json.mjs"
+    "eval:json": "node scripts/eval-json.mjs",
+    "eval:live": "node scripts/eval-live.mjs --transport rpc",
+    "eval:live:json": "node scripts/eval-live.mjs --transport json"
   },
   "pi": {
     "extensions": ["./extensions/developer.ts"],
@@ -39,5 +41,8 @@
     "@earendil-works/pi-coding-agent": "*",
     "@earendil-works/pi-tui": "*",
     "typebox": "*"
+  },
+  "dependencies": {
+    "xstate": "5.32.5"
   }
 }

package/skills/abstraction-review/SKILL.md

@@ -21,11 +21,12 @@ rejected, or deferred?
 
 ## Output
 
-Lead with the caller's concrete failure mode; keep review labels secondary.
-Produce review timing, layer, contract, hidden detail, output artifact, stop
-check, evidence and gaps, and one decision: `keep`, `revise-surface`,
-`revise-model`, `split`, `reject`, or `defer`. When used inside a larger task,
-return:
+Lead with the caller's concrete failure mode; keep review labels secondary. Use
+a review card or table with `Candidate`, `Pressure`, `Caller contract`, `Hidden
+detail`, `Failure`, `Stop check`, and `Evidence gap`. Add a boundary diagram or
+before/after interface snippet when the candidate changes layers or callers.
+End with one prominent decision: `keep`, `revise-surface`, `revise-model`,
+`split`, `reject`, or `defer`. When used inside a larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked

package/skills/adversarial-eval/SKILL.md

@@ -21,9 +21,13 @@ What adversarial evidence would expose the target's real failure modes?
 ## Output
 
 Lead with the target claim and observed failure mode; keep eval labels secondary.
-Produce target provenance, claims and risk model, an escalating fixture ladder,
-execution matrix, observed feedback, failure taxonomy, stop rule, and residual
-risks. When used inside a larger task, return:
+Render the escalation ladder as an ordered matrix with source/version,
+fixture, verifier, expected falsifier, mutation scope, and stop condition. After
+execution, append observations to the evidence table below and show round
+progression as a compact `smoke → visible → … → stop` line. Do not replace exact
+commands or fixture provenance with narrative summaries. Produce target
+provenance, claims and risk model, observed feedback, failure taxonomy, stop
+rule, and residual risks. When used inside a larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked

package/skills/model/SKILL.md

@@ -19,10 +19,19 @@ Which cases, rules, states, or transitions make the claim precise?
 
 ## Output
 
-Lead with the user's product language; keep modeling labels secondary.
-Produce the lightest useful model: domain, predicates or cases, facts, rules,
-forbidden cases, transitions or objectives when relevant, guarantee placement,
-and verification targets. When used inside a larger task, return:
+Lead with the user's product language; keep modeling labels secondary. Render
+the lightest executable model, not a prose-only explanation. Choose the surface
+that matches the condition space:
+
+- case, decision, or truth table for finite combinations;
+- state-transition table or ASCII state diagram when order matters;
+- rules plus forbidden-state table for policy and invariants;
+- guarantee map linking each rule to its owner and verification target.
+
+Show predicates, data shapes, equations, or solver-like rules in a fenced code
+block when they are part of the model. Produce domain, facts, rules, forbidden
+cases, transitions or objectives when relevant, guarantee placement, and
+verification targets. When used inside a larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked

package/skills/naming-judgment/SKILL.md

@@ -21,9 +21,15 @@ change boundary should it preserve?
 
 ## Output
 
-Lead with the user's product language; keep naming theory secondary.
-Produce the naming pressure, current sense, hidden or overexposed detail,
-failure mode, proposed name or placement move, affected scope, and intentionally
+Lead with the user's product language; keep naming theory secondary. Use a
+rename map as the primary inspection surface:
+
+| Current | What it says | What callers rely on | Proposed | Scope |
+| --- | --- | --- | --- | --- |
+
+For callable APIs or placement moves, add a minimal before/after caller snippet
+showing how the proposed name reads in context. Keep prose for the decisive
+sense boundary, hidden or overexposed detail, failure mode, and intentionally
 deferred names. When used inside a larger task, return:
 
 ```text

package/skills/schedule/SKILL.md

@@ -30,9 +30,12 @@ timing follows directly from the current invariant does not need the reference.
 ## Output
 
 Lead with the user's current risk and cost of delay; keep timing labels secondary.
-Produce `now`, `after`, or `never` with rationale, evidence, invariant pressure,
-risks, and a reopen condition for deferred work. When used inside a larger task,
-return:
+Use a compact timing matrix with `Pressure`, `Do now`, `Delay`, `Reversibility`,
+and `Evidence`, followed by a prominent `now`, `after`, or `never` decision. For
+`after`, show the reopen condition as an observable trigger; use a short timeline
+only when ordering between behavior and structure is consequential. Produce the
+rationale, invariant pressure, risks, and reopen condition for deferred work.
+When used inside a larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked

package/skills/signal/SKILL.md

@@ -30,9 +30,12 @@ observation with no proposed movement does not need the reference.
 ## Output
 
 Lead with the observed code or product pressure; keep signal labels secondary.
-Produce a judgment of `no-signal`, `horizontal`, `vertical`, or `ambiguous`,
-with confidence, evidence, selected comparison, smallest meaningful difference,
-smallest behavior-preserving movement, model-code mismatch, and a concrete
+Make the comparison visible. For two or more artifacts, use a table with
+`Artifact`, `Same responsibility`, `Smallest difference`, and `Evidence`; then
+show the proposed behavior-preserving movement as a compact before/after code
+snippet or ASCII relation map when code or boundaries are involved. Finish with
+a one-line classification card containing `no-signal`, `horizontal`, `vertical`,
+or `ambiguous` plus confidence. Include model-code mismatch and a concrete
 review candidate only when vertical or ambiguous. When used inside a larger
 task, return:
 

package/skills/sketch/SKILL.md

@@ -57,10 +57,23 @@ purpose, cases, data flow, and first item are already clear needs none.
 
 ## Output
 
-Lead with the user's product language; keep design labels secondary.
-Produce purpose, relevant data definitions, representative cases, a template,
-wishful top level, wished interfaces, checks, a small implementation queue, and
-explicitly deferred abstractions. When used inside a larger task, return:
+Lead with the user's product language; keep design labels secondary. A resolved
+sketch must be inspectable as an implementation shape, not only narrated in
+paragraphs. Produce:
+
+1. a compact case/check table;
+2. concrete data or state definitions;
+3. wishful top-level code, pseudocode, or an interaction skeleton in a fenced
+   code block;
+4. a wished-interface table with contract, owner, hidden detail, and stop check;
+5. a small ordered implementation queue and explicitly deferred abstractions;
+6. an ASCII flow, relation map, state transition, or boundary diagram whenever
+   two or more components, states, or collaborations are materially related.
+
+Use prose only to explain why those artifacts have their shape. Route
+`visualize` separately when choosing the visual form is itself consequential;
+do not require that extra route for a straightforward inline table or ASCII
+map. When used inside a larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked
@@ -77,8 +90,10 @@ routing to the caller.
 
 Finish when the first implementation item is small enough to execute and check,
 and non-local or invariant-bearing candidates are explicit rather than silently
-assumed. Revisit when implementation evidence breaks the ownership or data-flow
-assumptions.
+assumed. `resolved` is not valid for a prose-only sketch: the output must show
+the code or interaction skeleton and the checks that make the first item
+executable. Revisit when implementation evidence breaks the ownership or
+data-flow assumptions.
 
 ## Method
 
@@ -87,11 +102,15 @@ assumptions.
 3. Derive relevant data or state definitions and their ownership pressure.
 4. List representative cases before choosing code shape.
 5. Derive the template from data, state, traversal, or ownership flow.
-6. Write wishful top-level code, pseudocode, or interaction flow.
+6. Write wishful top-level code, pseudocode, or interaction flow in a fenced
+   code block. Show every wished interface in context rather than merely naming
+   helpers in prose.
 7. For each wished interface, state its purpose, contract, owner, hidden detail,
-   and representative stop check.
-8. Separate design artifacts, implementation items, and deferred candidates.
-9. Keep the queue small; do not turn the sketch into a project plan.
+   and representative stop check in a table.
+8. Draw the smallest inline map that exposes non-trivial data flow,
+   collaboration, state movement, or ownership boundaries.
+9. Separate design artifacts, implementation items, and deferred candidates.
+10. Keep the queue small; do not turn the sketch into a project plan.
 
 ## Missing Evidence
 

package/skills/specify/SKILL.md

@@ -21,8 +21,17 @@ What must be true, in scope, and not guessed?
 ## Output
 
 Lead with the user's product language; keep specification labels secondary.
-Produce product meaning, invariant, scope and non-scope, constraints,
-counterexamples, and blocking unknowns. When used inside a larger task, return:
+Make the contract inspectable rather than burying it in prose. Default to:
+
+- a scope table separating in scope, out of scope, and intentionally unchanged;
+- a contract table with `Must be true`, `Evidence or owner`, and `Violating counterexample`;
+- a short assumptions/decisions list that visibly distinguishes provisional facts
+  from human-owned choices.
+
+A single obvious invariant may use compact bullets, but multiple constraints or
+scope boundaries must use the tables. Produce product meaning, invariant, scope
+and non-scope, constraints, counterexamples, and blocking unknowns. When used
+inside a larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked

package/skills/verify/SKILL.md

@@ -30,10 +30,16 @@ relevant evidence does not need the reference.
 ## Output
 
 Lead with the user's claim and observed evidence; keep verification labels secondary.
-Produce a scoped satisfaction judgment, evidence map, target and counterexample
-coverage, evidence strength, wrong implementations that could still pass,
-assumptions, unverified claims, and residual risk. When used inside a larger
-task, return:
+Use an evidence matrix as the primary surface:
+
+| Claim | Evidence | Strength/relevance | Wrong case that could pass | Status |
+| --- | --- | --- | --- | --- |
+
+Follow it with a concise residual-risk and unverified-claims list. When source
+compatibility matters, add requested-versus-exercised provenance as a separate
+row or table. Produce the strongest scoped satisfaction judgment, target and
+counterexample coverage, assumptions, and residual risk. When used inside a
+larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked

package/skills/visualize/SKILL.md

@@ -21,9 +21,11 @@ What visual surface would materially lower judgment cost?
 ## Output
 
 Use the user's concepts as labels; keep visualization terminology secondary.
-Produce whether a visual is useful, the inspection question, recommended form,
-visual content, what it reveals, and what it must not imply. When used inside a
-larger task, return:
+When a visual is useful, render the completed table, ASCII/Mermaid diagram,
+timeline, tree, or matrix in the response; do not stop at recommending a form.
+When prose is better, state that decision and use the smallest structured list
+that answers the inspection question. Include what the surface reveals and what
+it must not imply. When used inside a larger task, return:
 
 ```text
 Status: resolved | needs-evidence | not-applicable | blocked