@veda-hq/sarathi 0.6.0 → 0.6.1

package/README.md

@@ -111,11 +111,31 @@ every `PreToolUse` call before any handler runs, and at `SessionStart` and
 `UserPromptSubmit` tells both Claude and the user why and how to fix it. Other
 events are left alone. It acts only on events the settings route to sarathi.
 
+## The working rules
+
+`skills/working-rules/SKILL.md` holds the generic rules an agent follows to
+carry a change from first edit to merge: run started work to merge, show then
+push, commit and push without skipping or weakening checks, resolve review
+threads only once the fix is on the remote, and when to stop and ask. A
+project adds its own rules on top.
+
+It ships in the package, so a project whose dependencies are installed can
+load it every session with one import line in its `CLAUDE.md` (or in a file
+its `CLAUDE.md` imports). Claude Code reads the import at session start, so a
+checkout with no `node_modules` yet starts without it:
+
+```md
+@node_modules/@veda-hq/sarathi/skills/working-rules/SKILL.md
+```
+
+The plugin carries the same file as the skill `sarathi:working-rules`.
+
 ## The plugin
 
-`sarathi@veda`, from this repository's marketplace, carries two agents:
+`sarathi@veda`, from this repository's marketplace, carries two agents,
 `sarathi:worker` (carries out one decided task end to end) and
-`sarathi:researcher` (answers an external question with sources, read-only).
+`sarathi:researcher` (answers an external question with sources, read-only),
+and the `sarathi:working-rules` skill.
 
 ```sh
 claude plugin marketplace add veda-hq/veda

package/dist/cli.js

@@ -12,7 +12,7 @@ import { join, resolve } from 'node:path';
 import { ConfigError, compileMatcher, entriesFor, forbiddenSet, loadConfig, longestTimeout, settingsMatcher } from './config.js';
 import { merge } from './merge.js';
 import { runAll } from './run.js';
-export const VERSION = '0.6.0';
+export const VERSION = '0.6.1';
 const USAGE = `usage: sarathi hook <Event> [--config <file>]
        sarathi check [--config <file>] [--settings <file>]
        sarathi --version

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@veda-hq/sarathi",
-  "version": "0.6.0",
-  "description": "Runs a project's Claude Code hooks from one entry per event, with kavach's guards built in, and carries the sarathi plugin's agents.",
+  "version": "0.6.1",
+  "description": "Runs a project's Claude Code hooks from one entry per event, with kavach's guards built in, and carries the sarathi plugin's agents and working-rules skill.",
   "keywords": [
     "coding agents",
     "claude code",
@@ -30,6 +30,7 @@
   "files": [
     "dist",
     "hooks",
+    "skills",
     "!dist/**/*.test.js"
   ],
   "dependencies": {

package/skills/working-rules/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: working-rules
+description: How a coding agent carries a change from first edit to merge in a repository with hooks, CI and review bots - committing, pushing, review threads, and when to stop and ask. Use before the first commit or push of a task.
+---
+
+# Working rules
+
+**Started work runs to merge.** A task with a commit, exploratory ones
+included, ends only when it is merged, proven unneeded, or stuck on a person.
+Local commits are never an end state.
+
+**Show, then push.** Put the evidence (test output, a screenshot, a number)
+on the pull request, then push, without waiting for a word.
+
+**Commit.** One logical change per commit, in the repository's message format.
+Never skip the repository's hooks (`--no-verify`), never weaken a check to pass
+it (a type escape, a disabled lint rule, a skipped test): fix the source.
+
+**Push.** Push in the background; a full pre-push can outlast a foreground
+timeout. Fix everything it lists, then push again. Never edit the worktree
+while a push runs.
+
+**Review threads.** Resolve a thread only after its fix is on the remote: a
+thread resolved on a green head lets the pull request merge without the fix.
+
+**Search.** Lists and counts before contents: list or count matches first,
+then read only the lines they name.
+
+## Stop and ask when
+
+- the task and its specification disagree, or a part cannot be delivered as
+  agreed;
+- an architecture decision or a breaking change is needed;
+- a new dependency is needed;
+- anything irreversible: deleting data, changing shared configuration.
+
+Say what happened, why, and the options. Do not assume.