@codyswann/lisa 4.55.27 → 4.55.29

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.55.27",
+  "version": "4.55.29",
   "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": "4.55.27",
+  "version": "4.55.29",
   "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": "4.55.27",
+  "version": "4.55.29",
   "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": "4.55.27",
+  "version": "4.55.29",
   "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": "4.55.27",
+  "version": "4.55.29",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/eager/report-actionability.md

@@ -1,8 +1,7 @@
 # Report Actionability — Every Report Says What the Reader Must Do (load-bearing)
 
-A report that describes real work accurately can still fail, because the reader cannot tell **which items need them and which are already handled**. Prose that mixes fixed and open items reads as a single undifferentiated pile of problems; the reader either acts on something already done, or assumes something open was handled. Both are caused by the report, not by the work.
-
-The specific failure this rule exists to prevent, observed in a review cycle: six findings were returned, three were fixed, and the report described **two of them in detail without ever stating that six existed**. Every sentence in it was true. The reader still had to ask "did you fix them?" — and the answer was partly yes, partly no, and one finding had not even been read. A subset presented in the shape of a whole is worse than silence, because silence does not create false confidence.
+Reports must distinguish completed work, remaining work, and decisions the reader
+needs to make. Account for the whole reviewed scope and clearly label any subset.
 
 ## Mandatory
 
@@ -20,4 +19,8 @@ The specific failure this rule exists to prevent, observed in a review cycle: si
 
 Code-review findings, CI failures, test results, audit output, security scans, deploy status, and any list of problems handed to a human. It applies equally to reports you are proud of and reports that expose your own mistake — the second kind is where the temptation to describe a flattering subset is strongest.
 
+## Agent attribution
+
+Follow `lisa-tracker-sync` — **Agent attribution** for agent-composed tracker comments and review messages. The short convention lives in that portable skill so agents without a rules surface receive it too.
+
 Detail, worked examples and the failure taxonomy: [reference/report-actionability.md](../reference/report-actionability.md).

package/plugins/src/base/skills/lisa-atlassian-access/SKILL.md

@@ -12,6 +12,8 @@ Single chokepoint for all Atlassian operations. Routes each op to a substrate, e
 
 The caller passes one operation plus its arguments. Operations are listed in the dispatch table below. The skill returns either the structured operation result (JSON when the substrate provides it) or a clear error.
 
+For agent-composed JIRA or Confluence comments, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 ```text
 operation: read-ticket  key: PROJ-123
 operation: write-ticket payload: {...}

package/plugins/src/base/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -63,6 +63,13 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     build-intake skills use to diagnose-and-route without fixing in place.
 
 Resolve `<owner>/<repo>` from `gh repo view --json nameWithOwner` (or the PR URL).
+
+For agent-written review submissions, dismissal reasons, merge-message text and
+existing PR updates, follow `lisa-tracker-sync` — **Agent attribution**.
+Use the same short disclosure already present; a public lane name is optional.
+Do not create an extra comment solely to attribute a label or auto-merge change,
+or turn missing attribution into a merge gate. Attribute any relayed human
+decision to its actual source; an agent's analysis is not an owner ruling.
 Use plain `gh` + `git` so Claude and Codex execute identically.
 
 ## 0. Take the babysitter lease

package/plugins/src/base/skills/lisa-github-sync/SKILL.md

@@ -44,7 +44,7 @@ Optional arguments include `pr_url=<url>` for the live pull request and `merge_s
 For `--rollup`, skip this milestone path and use Step 5's classifier decision.
 
 1. **Idempotency check** — read the issue's recent comments. If the most recent comment with the prefix `[claude-sync] <milestone>` matches the current milestone AND the body content is unchanged, skip the post (no duplicate).
-2. **Add the comment**:
+2. **Add the comment** using `lisa-tracker-sync` — **Agent attribution** for the agent-composed body; keep any existing disclosure:
 
    ```bash
    gh issue comment <number> --repo <org>/<repo> --body-file /tmp/sync-comment.md

package/plugins/src/base/skills/lisa-linear-access/SKILL.md

@@ -298,6 +298,8 @@ the same way.
 Both comment operations take **either** `issue_id:` or `project_id:`. Exactly one
 is required; passing both, or neither, is refused naming the operation.
 
+For agent-composed `save-comment` bodies, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 Linear treats a comment's target as one field on the same input type, so the
 project form is not a second mechanism — it is the same mutation with a
 different anchor. Direct introspection of `https://api.linear.app/graphql`:

package/plugins/src/base/skills/lisa-tracker-evidence/SKILL.md

@@ -10,6 +10,8 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+Apply `lisa-tracker-sync` — **Agent attribution** when composing evidence comments; a disclosure already present in the body needs no second trailer.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).
@@ -40,7 +42,7 @@ Apply this when authoring `evidence/comment.md` (and `evidence/comment.txt` for
 
 The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issues, and Linear. Vendor skills only own the post/transition mechanics; the comment body is your responsibility.
 
-1. **AI disclosure at the top.** Lead with "Update from Claude (AI agent, not a human)" and address the reporter / QA / PM by name.
+1. **AI disclosure at the top.** Lead with "Update from <actual runtime name> (AI agent)" and address the reporter / QA / PM by name when known. This satisfies the shared attribution convention without a second trailer.
 2. **Own any prior mistake explicitly.** If an earlier triage or build pass got something wrong, say so up front. Don't bury it.
 3. **Numbered step-by-step walk** of what you actually did in the browser/app, in plain language a non-engineer can follow:
    - Exact env (URL, viewport size — e.g. `402×874` for an iOS-sized mobile flow)

package/plugins/src/base/skills/lisa-tracker-sync/SKILL.md

@@ -10,6 +10,14 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+## Agent attribution
+
+In agent-composed tracker comments and review messages, include one short plain-text attribution, such as `Agent-written by Codex.` Use the actual runtime's name; add a public lane name only when already known. An existing clear disclosure is enough. Do not publish session identifiers, invent a lane, alter supplied human text, or change machine-managed comment formats such as `[lisa-pr-link]`.
+
+The account avatar identifies the credential owner, not necessarily the writer. When relaying a human decision, attribute it to the person and its actual source (a linked decision or an instruction in the current conversation). Present your own judgement as agent analysis, never as an owner ruling. Attribution itself grants no authority.
+
+This is a writing convention: missing disclosure is not a reason to block work or file a compliance issue. Do not add identity infrastructure or extra audit comments just to supply it. Preserve an existing disclosure when a vendor skill posts or retries the same body.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).