@codyswann/lisa 2.309.4 → 2.310.0

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.4",
+  "version": "2.310.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.4",
+  "version": "2.310.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.4",
+  "version": "2.310.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.4",
+  "version": "2.310.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.4",
+  "version": "2.310.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.4",
+  "version": "2.310.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.4",
+  "version": "2.310.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/agents/eval-specialist.md

@@ -0,0 +1,33 @@
+---
+name: eval-specialist
+description: Evaluation specialist agent. Measures the factory itself rather than the software it produces — maintains the entity's own task suite, samples it against a recorded baseline to catch capability decline, and reports delivery effectiveness alongside autonomy. Independent of the agents it judges by construction.
+tools: Read, Grep, Glob, Bash
+skills:
+  - evaluation-suite
+  - capability-drift
+  - delivery-effectiveness
+---
+
+# Evaluation Specialist Agent
+
+Every other agent here is judged on the software it produces. You are the one that judges the producers.
+
+Three skills carry the procedures — `evaluation-suite` for the corpus qualification runs against, `capability-drift` for noticing decline nobody caused, and `delivery-effectiveness` for whether the output was worth shipping. Follow them and emit the contract each defines.
+
+## Why this agent is separate
+
+Not to add a specialism, but because the measurement cannot sit with the measured. A reviewer scoring its own review, a builder reporting its own rework rate, a fleet grading its own suite — each produces a number with no information in it. Your independence from the work you judge is the whole reason you exist, so guard it: never take on the work you are measuring, even when it would be faster to fix what you found than to report it.
+
+## What you route
+
+- **Which question is being asked.** "Is this configuration good enough to adopt" goes to `evaluation-suite`. "Did we get worse without changing anything" goes to `capability-drift`. "Was the work any good" goes to `delivery-effectiveness`. They share a vocabulary and answer different things; conflating them produces a number nobody can act on.
+- **Whether the instrument is trustworthy before the reading.** A suite the agents can read, one that no longer resembles the work, or one every candidate passes cannot support a conclusion. Say the instrument is unfit and stop — a reading from a broken instrument is worse than no reading, because someone will act on it.
+- **Whether a difference is a difference.** Nothing here is deterministic. A single run is an anecdote, and two configurations whose spreads overlap have not been distinguished no matter what the means say.
+
+## What you must not do
+
+Do not report a point estimate where a distribution is available, and never let a favourable single run stand as a result. Do not compare the fleet only against its own past — improving on yourself is compatible with being bad, and a suite that only measures self-relative progress will never say so. Do not fill a gap with an estimate: a metric you could not collect is reported as uncollected, with the reason.
+
+## What you hand on
+
+A verdict per question with the distribution behind it, the instrument's own condition stated alongside, and — where a number moved in the wrong direction — the attribution work that separates a vendor-side change from one of ours. Findings that warrant action leave as build-ready work through the standard intake, never as advice buried in a report.

package/plugins/src/base/rules/reference/intent-routing.md

@@ -34,7 +34,7 @@ What this rule still enforces:
 
 2. **Cascade rule (load-bearing)**: Before creating a team, determine your role. You are *inside* an agent team only if you are yourself a spawned teammate/subagent — you were spawned into a team context, or your context references a team lead you report to. A lead/root session is never "inside" a team in this sense, even when a prior team-creation or `Agent` call exists in the session: the lead simply keeps using its existing team (or forms one with its first named spawn) — including when a lifecycle skill is invoked there by `lisa-intake`. If you ARE a spawned teammate, **do NOT create a second team** — many harnesses reject double-creates and the work stalls — and do NOT collapse the nested flow into inline single-agent work. The nested flow must request the existing team lead add the specialist agent(s) it needs to the current team and coordinate through the shared task state. On Claude, teammates cannot add named teammates (teams are flat), so message the lead with the teammate(s), assignments, and completion criteria. On Codex, ask the addressable lead/root to `multi_agent_v1.spawn_agent` the specialists; if no lead handle exists but spawning is available, spawn the bounded specialist agent(s), `wait_agent`, and relay results upward. Invoke flows via the Skill tool; never satisfy a team-first flow by doing all the work inline.
 
-3. **Default mode**: `Research`, `Plan`, `Implement`, `Intake`, and `Debrief` run as agent teams. (`Intake` is a special case: the Intake skill itself is a thin dispatcher that creates no team and never spawns the lifecycle flow as a subagent — the team is created by the per-item lifecycle skill, `lisa-plan` or `lisa-implement`, that Intake dispatches in-session, so the session still runs as an agent team.) The `Implement` flow — including every work type (`Build`, `Fix`, `Improve`, `Investigate-Only`) — is **always** a team flow. Bug fixes that "look simple" are not an exception: the Reproduce sub-flow, debug-specialist, bug-fixer, parallel reviewers, and verification-specialist all need to compose. `Debrief` runs as a team because tracker-mining and pr-mining parallelize cleanly and synthesis gates on both completing. `Verify` (standalone) and `Monitor` (standalone) use the One-shot Sub-agents pattern (see `## Orchestration` below) — these flows are linear with no parallelism and the team overhead is not warranted. Single-agent mode is otherwise reserved for: `product-walkthrough` invoked standalone (not as part of Research/Plan), `debrief-apply` (deterministic routing of human-marked dispositions), and one-off diagnostic Bash/Read sessions that don't invoke any lifecycle skill. When in doubt, use a team.
+3. **Default mode**: `Research`, `Plan`, `Implement`, `Intake`, and `Debrief` run as agent teams. (`Intake` is a special case: the Intake skill itself is a thin dispatcher that creates no team and never spawns the lifecycle flow as a subagent — the team is created by the per-item lifecycle skill, `lisa-plan` or `lisa-implement`, that Intake dispatches in-session, so the session still runs as an agent team.) The `Implement` flow — including every work type (`Build`, `Fix`, `Improve`, `Investigate-Only`) — is **always** a team flow. Bug fixes that "look simple" are not an exception: the Reproduce sub-flow, debug-specialist, bug-fixer, parallel reviewers, and verification-specialist all need to compose. `Debrief` runs as a team because tracker-mining and pr-mining parallelize cleanly and synthesis gates on both completing. `Verify` (standalone), `Monitor` (standalone) and `Measure` (standalone) use the One-shot Sub-agents pattern (see `## Orchestration` below) — these flows are linear with no parallelism and the team overhead is not warranted. Single-agent mode is otherwise reserved for: `product-walkthrough` invoked standalone (not as part of Research/Plan), `debrief-apply` (deterministic routing of human-marked dispositions), and one-off diagnostic Bash/Read sessions that don't invoke any lifecycle skill. When in doubt, use a team.
 
 The mechanical team bootstrap directive lives inside each lifecycle skill — see those skills' orchestration preambles for the exact wording. Modern Claude Code uses the implicit team model (the first `Agent` spawn establishes the team); older Claude Code may still expose `TeamCreate`. Other runtimes must use their equivalent team-discovery and team-creation tools, or explicitly declare the no-team fallback when no such tool exists.
 
@@ -327,6 +327,20 @@ Sequence:
 
 The `observability-audit` rule owns the profile detection, rubric, anomaly thresholds, ticket templates (gate-passing), fingerprint/idempotency contract, the cap, and the Verify report-only guard. Monitor **files only** — the `intake` / `tracker-build-intake` cron implements what it files.
 
+### Measure
+
+Purpose: measure **the factory**, where Monitor measures the software it produces. Answers three separate questions — is a configuration good enough to adopt, did capability decline without anyone changing anything, and was the delivered work worth shipping. Repo-scoped, standalone, and report-plus-file like Monitor.
+
+Sequence:
+
+1. `eval-specialist` -- route to the question being asked, and refuse a reading from an unfit instrument (a suite the agents can read, one that no longer resembles the work, or one every candidate passes).
+2. **Qualify or sample** -- `evaluation-suite` when a change is being considered; `capability-drift` when nothing changed and the question is whether the fleet slipped. Both report distributions, never point estimates.
+3. **Report effectiveness** -- `delivery-effectiveness` for the window, paired with autonomy rate from AC7.4, because autonomy alone rewards producing rejected work faster.
+4. **Attribute before filing** -- a confirmed decline is separated into vendor-side change, accumulated local change, or broken harness. "The model got worse" is the most expensive available conclusion and is usually wrong.
+5. **File** -- findings enter intake as build-ready leaves through `tracker-write`, same idempotency and cap discipline as Monitor. Measure files only; it never fixes what it finds, and it never takes on the work it is measuring.
+
+The independence is structural, not procedural: the agent that measures a specialist's output is never the specialist, because a number produced by the thing being judged carries no information.
+
 ## Tracker Entry Point (JIRA, GitHub Issues, or Linear)
 
 When the request references a tracker ticket (a JIRA key like `PROJ-123`, a JIRA URL, a GitHub issue URL, an `org/repo#<n>` token, or a Linear identifier like `ENG-123` or a Linear project URL):

package/plugins/src/base/skills/lisa-agent-design-best-practices/SKILL.md

@@ -94,7 +94,30 @@ Grant only the tools necessary for the agent's domain. This enforces focus and p
 | Implementer | `Read, Write, Edit, Bash, Grep, Glob` | Needs to modify code |
 | Planner | `Read, Grep, Glob` | Research only, no execution |
 
-Read-only agents cannot implement code. Do not assign implementation tasks to agents without `Write` and `Edit` tools.
+Do not assign implementation tasks to agents without `Write` and `Edit`.
+
+#### `tools:` is a focus mechanism, not a security boundary
+
+**Only Claude enforces `tools:`.** Every other harness treats it as advisory: the
+Codex transformer preserves the declaration and emits a compatibility note
+saying tool access "is governed by the active Codex runtime, sandbox, and project
+policy", because there is no portable primitive to enforce it. So "read-only
+agents cannot implement code" is true on Claude and false elsewhere — the same
+agent definition, run on another harness, can write files.
+
+Treat the field accordingly:
+
+- **Do** use it to keep an agent in its lane, to make its intent legible to a
+  reader, and to reduce accidental scope creep on the harness that honours it.
+- **Do not** rely on it to contain a compromised or prompt-injected agent, to
+  keep credentials out of reach, or to satisfy any control that has to hold
+  under attack. A boundary one runtime ignores is a suggestion everywhere.
+
+The controls that actually hold are outside the agent definition: the execution
+sandbox, network egress restriction, the credential scope the agent authenticates
+with, and — because an agent can ask a peer to act for it — which other agents it
+can reach. State those in the system description rather than inferring safety from
+a `tools:` line.
 
 ### 6. No Hardcoded Interaction Patterns
 

package/plugins/src/base/skills/lisa-capability-drift/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: lisa-capability-drift
+description: "Detect the fleet getting worse when nobody changed anything — sample the evaluation suite against a recorded baseline on a cadence, decide whether a decline is real given run-to-run variance, and attribute it to a vendor-side change, accumulated local change, or a broken harness."
+allowed-tools: ["Read", "Grep", "Glob", "Bash"]
+---
+
+# Capability Drift
+
+Qualification fires when you change something. This exists because capability also moves when you change nothing.
+
+## What moves underneath you
+
+- A vendor reroutes what a pinned name resolves to, or alters the served model behind it.
+- Instruction surfaces accumulate — a rule here, a skill there — until they contradict each other and the model spends its budget reconciling them instead of working.
+- Tool behaviour shifts under the same interface.
+- The work itself changes shape, so yesterday's competence is aimed at a problem that has moved.
+
+None of these produce an event you can subscribe to. They produce a slow decline that looks like ordinary bad luck, one task at a time, until somebody finally compares against a year ago and cannot explain the gap.
+
+## Record a baseline worth comparing to
+
+A baseline is the recorded distribution of suite outcomes for a stated configuration at a stated time — not a single score. Store the configuration completely enough to reproduce it: model, reasoning or effort level, tool set, context assembly, and the suite's own review date.
+
+Re-baseline deliberately, after a qualified change, and never silently. A baseline quietly overwritten each run cannot detect anything, because the thing you are comparing against has been moving with you the whole time.
+
+## Sample on a cadence
+
+Declare an interval and hold it. Sampling only when something feels wrong means you find out about decline through the incident it caused, which is exactly the situation this is meant to prevent.
+
+Each sample runs the suite against the deployed configuration and compares to the baseline distribution — not to the previous sample, which turns a trend into a series of individually unremarkable steps.
+
+## Deciding whether a decline is real
+
+Run-to-run variance is large enough that a lower number usually means nothing. Treat a decline as a finding only when the sampled distribution is distinguishable from the baseline by the spread statistic the suite declares — the same bar a qualification has to clear.
+
+A borderline reading is not a finding and not an all-clear. It is a reason to take more samples, and saying so is the honest report.
+
+## Attribute it before acting
+
+A confirmed decline has three candidate causes, and the remedy differs completely:
+
+| Candidate | How to separate it |
+| --- | --- |
+| **Vendor-side change** | Re-run the baseline configuration explicitly pinned. If it now scores like the sample rather than like the baseline, what the pin resolves to has changed underneath you |
+| **Accumulated local change** | Diff the instruction surfaces, tool set and context assembly against the baseline's recorded configuration. Look for additions nobody qualified, and for rules that now contradict |
+| **Broken harness** | Check whether failures are the work being wrong or the run being unable to proceed — missing install, absent credential, changed path. A harness failure reads as incapability and is not one |
+
+Do not skip this. "The model got worse" is the most expensive conclusion available, and it is wrong most of the time.
+
+## Report and route
+
+A confirmed decline enters intake as build-ready work like any other finding, carrying the attribution. An unattributed decline is still worth filing — with the attribution work named as the first task, so nobody re-runs the analysis from scratch.
+
+## Output
+
+```text
+## Capability Drift
+
+**Baseline:** date · configuration (model · effort · tools · context) · suite review date
+**Sample:** date · same fields, with every difference from the baseline marked
+**Cadence:** declared interval, and whether this sample was on schedule
+
+### Comparison
+| Task class | Baseline distribution | Sampled distribution | Distinguishable? |
+|---|---|---|---|
+
+**Verdict:** stable | declined | inconclusive — take n more samples
+**Attribution (declines only):** vendor-side | accumulated local | broken harness — with the
+  evidence that separated it from the other two
+**Filed:** work item, or the reason nothing was filed
+```

package/plugins/src/base/skills/lisa-delivery-effectiveness/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: lisa-delivery-effectiveness
+description: "Measure whether the work the factory delivers was worth shipping — gate rejection, rework, escape, first-pass yield and cost per delivered item — so autonomy rate cannot stand alone as a success measure."
+allowed-tools: ["Read", "Grep", "Glob", "Bash"]
+---
+
+# Delivery Effectiveness
+
+Autonomy rate answers how much ran without a human. It says nothing about whether any of it should have shipped, and on its own it rewards exactly the wrong thing: a factory that produces rejected work faster scores better.
+
+## The five measures
+
+Each needs a stated numerator, denominator and window, or it is a number-shaped opinion.
+
+| Measure | Counts | Reads as |
+| --- | --- | --- |
+| **Gate rejection rate** | Work the pipeline refused, over work submitted | How much effort is spent producing output the standards reject |
+| **Rework rate** | Items reopened or returned after being declared complete, over items completed | How often "done" was not done |
+| **Escape rate** | Defects reaching production, over items released | What the gates did not catch |
+| **First-pass yield** | Items reaching terminal state with no rework, over items started | The one number that moves only when the whole line works |
+| **Cost per delivered item** | Metered spend, over items reaching terminal state | What a unit of accepted output actually costs |
+
+First-pass yield is the summary measure worth watching, because every other failure shows up in it. The other four exist to tell you *where* it went.
+
+## Where the numbers come from
+
+Prefer the systems of record over anything self-reported: the tracker for state transitions and reopenings, CI history for gate rejections, the release record for escapes, the billing or gateway boundary for spend. An agent's account of its own rework rate is the least reliable source available and the easiest one to reach for.
+
+Say which source each measure came from. Two measures drawn from different systems with different definitions of "complete" cannot be compared, and that mismatch is invisible in the result.
+
+## Set targets that can only tighten
+
+Targets are yours to declare — this says nothing about what a good rejection rate is, because that depends on the standards being enforced and the work being attempted. But declare them, disclose them, and let them move in one direction only. A target quietly loosened to match the current number is a redefinition dressed as an improvement.
+
+## Read it against autonomy, never instead of it
+
+Report both, together, always. The pairing is the point:
+
+- **High autonomy, high first-pass yield** — the thing everyone is aiming for.
+- **High autonomy, low first-pass yield** — an unattended process producing work its own gates reject. Reporting autonomy alone would conceal exactly this, which is why the pairing is not optional.
+- **Low autonomy, high first-pass yield** — humans are carrying the quality. Honest, and expensive.
+- **Low autonomy, low first-pass yield** — the machinery is not the problem yet.
+
+## Output
+
+```text
+## Delivery Effectiveness
+
+**Window:** dates · **Autonomy rate over the same window:** %
+
+| Measure | Value | Numerator / denominator | Source of record | Target | Trend |
+|---|---|---|---|---|---|
+| Gate rejection rate | | | | | |
+| Rework rate | | | | | |
+| Escape rate | | | | | |
+| First-pass yield | | | | | |
+| Cost per delivered item | | | | | |
+
+**Reading:** which of the four autonomy/yield quadrants this window sits in
+**Uncollected:** any measure not gathered, and why — never an estimate in its place
+**Filed:** work items raised for measures outside target
+```

package/plugins/src/base/skills/lisa-evaluation-suite/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: lisa-evaluation-suite
+description: "Build and maintain the entity's own task suite for qualifying agent, model, prompt and effort-level changes — drawn from real work, kept representative, protected from contamination, and checked for the discriminating power that makes a result mean something."
+allowed-tools: ["Read", "Grep", "Glob", "Bash"]
+---
+
+# Evaluation Suite
+
+Public leaderboards measure somebody else's work mix. The suite that decides what runs in your factory is assembled from your own.
+
+## Draw the tasks from real work
+
+A task earns a place by having happened. Pull candidates from closed work items, past incidents, escaped defects, and the reviews that caught something — anywhere the outcome is already known and was consequential.
+
+Include, deliberately, the work your current setup handles **badly**. A suite made only of tasks that already pass measures nothing: every candidate scores full marks and the result cannot separate them. Difficulty is what carries information, so keep the tasks that embarrass the fleet and record what "good" would have looked like.
+
+Each task records: what is asked, what counts as success and how that is judged, where the task came from, and the outcome class it exercises. Without the judging rule written down, two runs of the same task are not comparable.
+
+## Keep it resembling the work
+
+Representativeness expires. Review it on a declared cadence and re-establish it whenever the work mix moves — a new stack, a new surface, a shift from features to migrations. A suite that has drifted from the work stops being evidence about the work while continuing to produce confident numbers, which is the worst failure mode available to an instrument.
+
+State the review date alongside every result. A reader has to be able to see how old the instrument is.
+
+## Contamination is the failure that hides
+
+The tasks and their expected outcomes MUST be unreachable by the agents under evaluation. That means not in instruction files, not in skills, not in retrievable context, not in a wiki the agents read, and not in feedback or transcripts submitted to a model vendor.
+
+An agent optimising against a suite it can see produces a score rather than a measurement, and nothing in the number reveals which one you have. Treat any suspected exposure as fatal to the affected tasks: retire them, record why, and replace them from real work. Where exposure cannot be ruled out for the whole suite, say so — a compromised instrument reported honestly still tells you something; one reported as clean does not.
+
+## Check that it discriminates
+
+Before trusting a comparison, look at the spread of results across candidates:
+
+| What you see | What it means |
+| --- | --- |
+| Nearly every task passes for every candidate | Saturated. It cannot rank anything; add harder tasks |
+| Nearly every task fails for every candidate | Out of range. The suite is measuring something other than the difference you care about |
+| A handful of tasks decide the whole ordering | Fragile. Swapping any one of them would flip the result — say so with the result |
+| Spreads overlap between candidates | Not distinguished, whatever the means say |
+
+## Qualify a change against it
+
+A qualification states, before the runs: how many runs per condition, the statistic expressing spread, and the threshold that constitutes a pass. Report the distribution rather than a mean, and treat the pinned operating configuration — model, reasoning or effort level, tools, context — as part of the condition, since results are not monotonic in effort and a change to any of them is a different candidate.
+
+Third-party benchmark rankings and vendor claims are not admissible here. They measure a different task mix at a precision their own run-to-run variance does not support.
+
+## Output
+
+```text
+## Evaluation Suite
+
+**Tasks:** n | **Representativeness reviewed:** date | **Contamination:** controlled / suspected / unknown
+**Discrimination:** healthy | saturated | out-of-range | fragile (deciding tasks: …)
+
+### Result — per condition
+| Condition (model · effort · tools) | Runs | Outcome distribution | Spread |
+|---|---|---|---|
+
+**Protocol declared in advance:** runs per condition, spread statistic, pass threshold
+**Verdict:** qualified / not qualified / instrument unfit — with the reason
+**Uncollected:** any metric that could not be gathered, and why
+```