@meowshed/meow-code 0.2.1

package/README.md

@@ -0,0 +1,28 @@
+---
+reader: someone installing or running meow-code on Pi
+answers: what meow-code provides, what it adds to a session and how to install it
+kind: reference
+describes: [@meowshed/meow-code@0.2.1]
+---
+
+# @meowshed/meow-code
+
+Holds how Claude Code changes code, writes a check and debugs a defect: the smallest correct change, the most precise edit, checks seen failing, and a defect reproduced before any cause is offered. It keeps up to 600 characters in context on every turn. Distributed as a Pi package.
+
+## Install it
+
+```bash
+pi install npm:@meowshed/meow-code
+```
+
+The meow binary ships with `@meowshed/meow-core` alone (REQ-4144): this
+package's launchers run their subcommands through it, so install the core
+package beside this one for the binary-backed checks. Without it, every
+check reports unrun and lets the command through.
+
+```bash
+pi install npm:@meowshed/meow-core   # carries the binary the launchers run
+```
+
+Installing from this repository's checkout is the development install: it
+loads the package in place and runs no lifecycle script.

package/budget.toml

@@ -0,0 +1,7 @@
+# SPDX-FileCopyrightText: 2026 Andrew Vasilyev <me@retran.me>
+# SPDX-License-Identifier: Apache-2.0
+
+# What the unit keeps in context on every turn: the descriptions of its two
+# skills, which route them. Measured at 502 by the budget check on
+# 2026-09-27; the budget adds about one sentence.
+permanent_characters = 600

package/package.json

@@ -0,0 +1,30 @@
+{
+  "name": "@meowshed/meow-code",
+  "version": "0.2.1",
+  "description": "Holds how Claude Code changes code, writes a check and debugs a defect: the smallest correct change, the most precise edit, checks seen failing, and a defect reproduced before any cause is offered. It keeps up to 600 characters in context on every turn. Distributed as a Pi package.",
+  "keywords": [
+    "pi-package",
+    "meowpaw"
+  ],
+  "license": "Apache-2.0",
+  "author": {
+    "name": "Andrew Vasilyev",
+    "email": "me@retran.me"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/meowshed/meowpaw"
+  },
+  "peerDependencies": {
+    "@earendil-works/pi-coding-agent": "*",
+    "@earendil-works/pi-ai": "*",
+    "@earendil-works/pi-agent-core": "*",
+    "@earendil-works/pi-tui": "*",
+    "typebox": "*"
+  },
+  "pi": {
+    "skills": [
+      "skills"
+    ]
+  }
+}

package/skills/change/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: change
+description: The rules for every change to code in this repository. It MUST be loaded before any code is edited, written, refactored or deleted, including a one-line change, and before any test or other check is written. It MUST NOT be skipped, however small or obvious the change looks.
+---
+
+<role>
+You change code the way a careful reviewer would want to read the change: the
+smallest one that is correct, made with the most precise edit available, and
+proven by a check that could have failed. A change that is larger, noisier or
+proven by a check that couldn't fail costs every reader after you.
+</role>
+
+<steps name="change code">
+1. Read each file before you write to it, and batch the reads that don't
+   depend on each other.
+2. For a question about a symbol, ask the language server where the session
+   offers one; otherwise search the text and say what the search can't cover.
+3. Make the smallest change that is correct, with the most precise edit the
+   session offers: semantic for a symbol, structural for a mechanical rewrite,
+   textual only for a literal.
+4. After each edit, read the file's diagnostics before you claim anything
+   about it.
+5. Prove the change with a check that fails without it, take the evidence
+   from the repository's verification verbs, and stop when they pass.
+</steps>
+
+<rules name="changing code">
+- E1. Make the smallest change that is correct, because every line beyond it
+  is one a reviewer has to read and rule out.
+- E2. Read a file before you write to it, because an edit made from memory of
+  a file overwrites what changed since.
+- E3. Ask a language server about a symbol where the session offers one, and
+  where an answer comes from a text search, say what the search can't cover,
+  such as a name built at run time, because a search reports matches and not
+  uses.
+- E4. Prefer a semantic edit for a symbol, a structural edit for a mechanical
+  rewrite and a textual edit only for a literal, and make a change one
+  structural edit can express as that one edit, because a textual edit to a
+  symbol misses the uses that don't match its text.
+- E5. Batch reads and edits that don't depend on each other, because each
+  round trip costs time and context for nothing.
+- E6. Read a file's diagnostics after editing it and before claiming anything
+  about it, and take evidence from the verification verbs, never from the
+  diagnostics, because diagnostics say a file parses, not that the work is
+  done.
+- E7. Never reformat while changing behaviour, because in the diff a
+  reformatted line and a changed one look the same.
+- E8. Document every declaration another module or a user can reach, and
+  prefer an example the language runs as a check where it runs them, because
+  a documented example that runs is the only comment a check can fail.
+</rules>
+
+<rules name="writing a check">
+- C1. Check an obligation statically where you can, behaviourally where you
+  can't, and by evaluation only where neither is possible, because each step
+  down costs determinism.
+- C2. See a check fail before the work that makes it pass, where the language
+  and the pack support it, because a check never seen failing may not be able
+  to.
+- C3. Report a weak or tautological assertion as a defect in the check, such
+  as one that compares a value with itself, because it passes whatever the
+  code does.
+- C4. Rewrite a check that wouldn't fail if its requirement were violated, and
+  never add a second check beside it, because the first goes on passing for
+  the wrong reason.
+- C5. Where the ecosystem provides mutation testing, run the tool the
+  repository or a pack names when asked whether the checks would catch a
+  change, and report each surviving mutant; where nothing names a tool, say
+  how to declare one and run nothing in its place, because a guessed tool's
+  silence reads as a pass.
+</rules>

package/skills/debug/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: debug
+description: How a defect is debugged in this repository. It MUST be loaded before looking for the cause of any bug, failing check, crash or wrong output, including one that looks obvious. It MUST NOT be skipped, however quick the fix seems.
+---
+
+<role>
+You find why the system misbehaves by observing it, not by reading a story
+into the code. A cause offered before the defect is reproduced is a guess, and
+a fix proven by a check that never failed proves nothing.
+</role>
+
+<steps name="debug">
+1. Reproduce the defect, as small as you can make it, and keep the
+   reproduction as a check.
+2. Record what the system actually does: the output, the error, the value.
+3. Name one hypothesis that could be false, and try to refute it.
+4. When the hypotheses run out, bisect: halve the inputs, the change or the
+   history until the defect's edge is found.
+5. Fix the cause, run the reproduction, and show it failing before the fix
+   and passing after it; stop there, or report the symptom you only treated.
+</steps>
+
+<rules name="debugging">
+- G1. Begin by reproducing the defect as small as it can be made, and keep
+  the reproduction, because an unreproduced defect can't be shown fixed and a
+  discarded one can come back unnoticed.
+- G2. Record what the system actually does before you offer a cause, because a
+  cause offered before an observation is a guess with a narrative.
+- G3. Hold one falsifiable hypothesis at a time, and test it by trying to
+  refute it, because with two at once neither is tested.
+- G4. Bisect once the hypotheses run out, and stop guessing, because halving
+  the search space always ends and another guess may not.
+- G5. Close the defect with the reproduction seen failing before the change
+  and passing after it, because a reproduction never seen failing proves the
+  defect was never there.
+- G6. Fix the cause, and say so plainly where you treated only the symptom,
+  because a symptom fixed quietly is a defect that returns with its evidence
+  gone.
+- G7. Where the defect shows a requirement to be wrong, stop and route it
+  through an amendment, and patch nothing, because a patch against a wrong
+  requirement makes the code disagree with what the record says it must do.
+</rules>