@sassywares/agents 0.1.0 → 0.1.2

package/CONCEPTS.md

@@ -2,7 +2,7 @@
 
 ## Source of truth
 
-`pi/` is the only copy of the pi roster. `scripts/install.sh` symlinks each file into `~/.pi/agent/agents/`, so the running agents are the working tree. Editing a file takes effect on the next subagent dispatch.
+Each harness directory is the only copy of that harness's roster. `scripts/install.sh <harness>` symlinks each file into the harness's user agent directory (`~/.pi/agent/agents/`, `~/.claude/agents/`), so the running agents are the working tree.
 
 ## Agent
 
@@ -10,7 +10,7 @@ A Markdown file with `name` and `description` frontmatter, plus optional `tools`
 
 ## Harness
 
-A directory at the repo root named after the tool that consumes it: `pi/` for pi. Each harness directory holds that harness's version of the roster. Harnesses differ in frontmatter and discovery, so a role may exist in more than one directory with a harness-appropriate definition.
+A directory at the repo root named after the tool that consumes it: `pi/` for pi, `claude/` for Claude Code. Every harness directory holds the full roster. Harnesses differ in frontmatter and discovery only: an agent's body — what it does — is identical in every harness, and CI fails when it drifts.
 
 ## Roster
 
@@ -42,4 +42,4 @@ A skill from `sassy-skills` that coordinates: it decides which agents to dispatc
 
 ## Upstream derivation
 
-The roster under `pi/` is a modified version of pi's MIT-licensed examples and documentation. `NOTICE` records the attribution; `LICENSE` covers this repository.
+The roster is a modified version of pi's MIT-licensed examples and documentation. `NOTICE` records the attribution; `LICENSE` covers this repository.

package/GROUNDING.md

@@ -7,7 +7,7 @@ Every subagent in a run reads one shared grounding brief instead of exploring th
 A per-user temp directory, keyed by the absolute repo or worktree root:
 
 ```bash
-ROOT="/tmp/pi-grounding-$(id -u)"
+ROOT="/tmp/sassy-grounding-$(id -u)"
 [ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
 [ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
 chmod 700 "$ROOT" 2>/dev/null
@@ -16,7 +16,7 @@ KEY=$(printf '%s' "$ROOT_ABS" | shasum -a 256 | cut -d' ' -f1)
 BRIEF="$ROOT/$KEY.md"
 ```
 
-For example, `tap2-workspace` resolves to `/tmp/pi-grounding-501/<sha>.md`. The directory is `0700` and owned by the current user; a symlinked or foreign-owned root aborts rather than being followed, because the brief is read as trusted-ish context by later agents.
+For example, `tap2-workspace` resolves to `/tmp/sassy-grounding-501/<sha>.md`. The directory is `0700` and owned by the current user; a symlinked or foreign-owned root aborts rather than being followed, because the brief is read as trusted-ish context by later agents.
 
 Keying on the worktree root means:
 

package/NOTICE

@@ -1,6 +1,6 @@
 # Notice
 
-The agent definitions under `pi/` are derived from the examples and
+The agent definitions under `pi/` and `claude/` are derived from the examples and
 documentation of [pi](https://github.com/earendil-works/pi), Copyright (c) Mario
 Zechner and contributors, licensed under the MIT License.
 

package/README.md

@@ -1,6 +1,6 @@
 # Sassy Agents
 
-**The Sassy subagent roster — one directory per harness, one roster on every provider.**
+**The Sassy subagent roster — one directory per harness, one behavior in every harness, one roster on every provider.**
 
 Sassy Agents is the source of truth for the subagents the Sassywares workflow dispatches: a grounding scout, an implementation worker, a reviewer, and a validator. Each agent is a Markdown file with frontmatter; each declares a `profiles:` list, so the same roster runs on DeepSeek by default and on Anthropic when a project opts in.
 
@@ -32,13 +32,16 @@ The repo is `sassy-agents`. The npm mirror is `@sassywares/agents`.
 
 ## Quick start
 
-Clone the repo next to your work and link the pi roster:
+Clone the repo next to your work and link the roster for your harness:
 
 ```bash
 git clone https://github.com/sassywares/sassy-agents.git
-./sassy-agents/scripts/install.sh
+./sassy-agents/scripts/install.sh          # pi → ~/.pi/agent/agents/
+./sassy-agents/scripts/install.sh claude   # Claude Code → ~/.claude/agents/
 ```
 
+`sassy-setup` (in `sassy-skills`) checks for the roster and offers this link, or a per-project copy into `.pi/agents/` / `.claude/agents/`.
+
 `install.sh` symlinks `pi/*.md` into `~/.pi/agent/agents/`. Editing this repo changes the running agents on the next subagent invocation — there is no copy to keep in sync.
 
 Then install the extensions that dispatch them, if you have not already:
@@ -60,18 +63,20 @@ Pi does not load agents from packages on its own; the link step is what makes th
 
 ## Agents
 
-| Agent | Role | `deepseek` profile | `anthropic` profile |
-|---|---|---|---|
-| `scout` | Grounding scout: writes the shared grounding brief other agents read, including matching prior learnings from the project's `.sassywares/config.yaml` knowledge paths. | `deepseek/deepseek-flash` | `anthropic/claude-haiku-4-5` |
-| `worker` | General-purpose implementation in an isolated context. | `deepseek/deepseek-flash` | `anthropic/claude-sonnet-4-5` |
-| `reviewer` | Quality, correctness, security, project-rule, and design-system review, diff-scoped. | `deepseek/deepseek-flash` | `anthropic/claude-opus-4-5` |
-| `validator` | Checks that the diff matches the plan, independent of review. | `deepseek/deepseek-flash` | `anthropic/claude-sonnet-4-5` |
+| Agent | Role | pi `deepseek` profile | pi `anthropic` profile | Claude Code `model` |
+|---|---|---|---|---|
+| `scout` | Grounding scout: writes the shared grounding brief other agents read, including matching prior learnings from the project's `.sassywares/config.yaml` knowledge paths. | `deepseek/deepseek-flash` | `anthropic/claude-haiku-4-5` | `haiku` |
+| `worker` | General-purpose implementation in an isolated context. | `deepseek/deepseek-flash` | `anthropic/claude-sonnet-4-5` | `sonnet` |
+| `reviewer` | Quality, correctness, security, project-rule, and design-system review, diff-scoped. | `deepseek/deepseek-flash` | `anthropic/claude-opus-4-5` | `opus` |
+| `validator` | Checks that the diff matches the plan, independent of review. | `deepseek/deepseek-flash` | `anthropic/claude-sonnet-4-5` | `sonnet` |
 
-Each file's body is the system prompt. Keep it to the role, hard rules, scope, and return shape — the orchestrating skill supplies the task.
+Each file's body is the system prompt. Keep it to the role, hard rules, scope, and return shape — the orchestrating skill supplies the task. The body is identical in every harness directory; only the frontmatter is harness-specific, and CI fails on drift.
 
 ## How agents are found
 
-The `subagent` extension discovers agents from:
+Claude Code discovers agents from `~/.claude/agents/` (user) and the project's `.claude/agents/` (project, which wins on a name clash).
+
+In pi, the `subagent` extension discovers agents from:
 
 - `~/.pi/agent/agents/` — user scope, where `scripts/install.sh` links this roster.
 - The nearest project `.pi/agents/` — project scope, which overrides a user agent with the same name.
@@ -124,7 +129,7 @@ Every agent in a run reads one shared brief instead of exploring the repo for it
 
 ## Harness layout
 
-One directory per harness. Only `pi/` exists today; the layout leaves room for others without changing the roster's meaning.
+One directory per harness: `pi/` and `claude/`. Every directory carries the full roster with identical bodies; only frontmatter differs.
 
 ```text
 sassy-agents/
@@ -133,6 +138,7 @@ sassy-agents/
 │   ├── worker.md
 │   ├── reviewer.md
 │   └── validator.md
+├── claude/              # Claude Code subagent definitions (same four)
 ├── scripts/
 │   ├── install.sh       # links one harness's agents into place
 │   ├── sync.sh          # bump, commit, push, tag
@@ -140,17 +146,17 @@ sassy-agents/
 └── …
 ```
 
-`scripts/install.sh <harness>` defaults to `pi` and rejects a harness it does not know, rather than guessing a target directory.
+`scripts/install.sh <harness>` takes `pi` (the default) or `claude` and rejects a harness it does not know, rather than guessing a target directory.
 
 ## Adding or editing an agent
 
-1. Create or edit `pi/<name>.md` with `name`, `description`, optional `tools`, and either a `profiles:` list or a pinned `model:`.
+1. Create or edit the agent in every harness directory: `pi/<name>.md` (`profiles:` or a pinned `model:`) and `claude/<name>.md` (Claude Code `tools` and a `model:` alias).
 2. Keep the frontmatter `name` equal to the file name.
-3. Keep the body focused on the role, hard rules, scope, and return shape.
+3. Keep the body focused on the role, hard rules, scope, and return shape — and byte-identical across harnesses.
 4. Update the roster table in `README.md`.
 5. Run `./scripts/install.sh` once if the agent is new, then `./scripts/sync.sh` to commit and release.
 
-Agents that write should say so in `tools:`: `scout` needs `write` for the brief, `worker` needs the full toolset. Reviewer and validator stay read-only so a review cannot change the diff it is judging.
+Agents that write should say so in `tools:`: `scout` needs `write` (`Write` in Claude Code) for the brief, `worker` needs the full toolset. Reviewer and validator stay read-only so a review cannot change the diff it is judging.
 
 ## Repository layout
 
@@ -158,6 +164,8 @@ Agents that write should say so in `tools:`: `scout` needs `write` for the brief
 sassy-agents/
 ├── pi/
 │   └── *.md
+├── claude/
+│   └── *.md
 ├── scripts/
 │   ├── install.sh
 │   ├── sync.sh
@@ -176,6 +184,7 @@ sassy-agents/
 | Path | Role |
 |---|---|
 | `pi/*.md` | The pi roster. Linked into `~/.pi/agent/agents/`. |
+| `claude/*.md` | The Claude Code roster. Linked into `~/.claude/agents/`. |
 | `scripts/install.sh` | Symlinks one harness's agents into that harness's user directory. |
 | `scripts/sync.sh` | Bumps, commits, pushes, tags, and releases. |
 | `scripts/test-profiles.mjs` | Checks agent parsing and profile resolution against the real roster plus malformed fixtures. |
@@ -211,7 +220,7 @@ Releases only happen on `main`. On any other branch the script commits and pushe
 
 ### Releasing
 
-Publishing is tag-driven and uses npm trusted publishing (OIDC). `publish.yml` validates every `pi/*.md`, checks that the tag matches `package.json`, refuses a tag that is not an ancestor of `main`, and publishes `@sassywares/agents` with the dist-tag derived from the version.
+Publishing is tag-driven and uses npm trusted publishing (OIDC). `publish.yml` validates every harness's agents and their sync, checks that the tag matches `package.json`, refuses a tag that is not an ancestor of `main`, and publishes `@sassywares/agents` with the dist-tag derived from the version.
 
 `scripts/sync.sh` does this for you on `main`. The manual sequence is the fallback for recovering a failed run:
 
@@ -227,4 +236,4 @@ The first publish of a new package needs a manual `npm publish --access public`
 
 ## Provenance
 
-The agent definitions under `pi/` are derived from pi's MIT-licensed examples and documentation, modified for this workflow. See [NOTICE](NOTICE).
+The agent definitions under `pi/` and `claude/` are derived from pi's MIT-licensed examples and documentation, modified for this workflow. See [NOTICE](NOTICE).

package/claude/reviewer.md

@@ -0,0 +1,116 @@
+---
+name: reviewer
+description: Code review specialist for quality, correctness, security, project-rule conformance, and design-system conformance
+tools: Read, Grep, Glob, Bash
+model: opus
+---
+
+You are a senior code reviewer. Analyze the changed code for quality, correctness, security, maintainability, and conformance to the project's own rules and design system.
+
+Bash is for read-only commands only: `git diff`, `git log`, `git show`. Do NOT modify files or run builds.
+
+## Scope — the diff only
+
+You review the change, never the repository. Your working set is:
+
+1. The diff (`git diff`, `git diff --stat`, or the commit range you were given).
+2. Files the diff touches.
+3. Files whose symbols the changed lines call or implement, read only enough to judge the changed lines.
+4. The rule and design-system files the conformance checks name.
+
+Everything else is out of scope. Do not grep the repo to orient yourself, do not run a discovery pass, do not audit unchanged files, and do not summarise the surrounding architecture. If a finding needs a file outside this set, report the finding with what you would need to confirm it and stop — do not go exploring.
+
+## Grounding
+
+Before reading anything, read the shared grounding brief — the `scout` writes it and it exists so you do not re-derive project context. Locate and check it in one call:
+
+```bash
+ROOT="/tmp/sassy-grounding-$(id -u)"
+[ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
+[ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
+chmod 700 "$ROOT" 2>/dev/null
+ROOT_ABS=$(cd "$(git rev-parse --show-toplevel 2>/dev/null || echo "$PWD")" && pwd -P)
+KEY=$(printf '%s' "$ROOT_ABS" | shasum -a 256 | cut -d' ' -f1)
+BRIEF="$ROOT/$KEY.md"
+HEAD=$(git rev-parse HEAD 2>/dev/null || echo none)
+DIRTY=$( { git status --porcelain; git diff; git diff --cached; } 2>/dev/null | shasum -a 256 | cut -d' ' -f1)
+if [ -f "$BRIEF" ]; then
+  for _ in $(seq 1 30); do
+    { grep -qx "head: $HEAD" "$BRIEF" && grep -qx "dirty: $DIRTY" "$BRIEF"; } && break
+    sleep 2
+  done
+fi
+echo "$BRIEF"
+```
+
+Read the brief if it exists. If it is fresh and covers the diff's area, use it and skip your own discovery. If it is missing, report `grounding: missing` in your output and do at most 5 bounded reads. If it is stale and not refreshed within the wait, report `grounding: stale` and do the same. Never become a second scout.
+
+You review four dimensions, none optional:
+
+1. **Correctness and security** — bugs, regressions, injection, auth gaps, data loss.
+2. **Project-rule conformance** — does the change follow the workspace and package rules?
+3. **Design-system conformance** — do UI changes use the project's components, tokens, and patterns?
+4. **Quality and maintainability** — duplication, clarity, dead code. Simplification opportunities (a needless abstraction, a one-use helper, dead branches) belong here under Suggestions; there is no separate simplify pass.
+
+You review the result, not the plan. Whether the work matches what was planned is the validator's job.
+
+Rules:
+- Be specific with file paths and line numbers.
+- Distinguish real defects from style preferences. Do not pad the list.
+- Ground every rule or design-system finding in something you actually read: quote the rule file and section, or name the shared component/token the code bypasses. Never invent a standard.
+- If a dimension has no applicable surface (no rules, no UI), say so instead of padding.
+- Contradictory rules are a finding. Report the conflict; do not silently pick a side.
+
+## Project-rule conformance
+
+1. Read the governing rules before judging: the nearest `AGENTS.md` or `CLAUDE.md` at the repo root and in each touched package, plus the conventions they reference (`CONCEPTS.md`, `docs/`, contributor guides, `.editorconfig`, lint and TS config).
+2. Check the rules that apply to the touched areas, for example:
+   - package manager, language, and typing rules (no `any`, explicit types, immutable patterns, early returns)
+   - required argument validators and auth checks on public functions
+   - forbidden or gated commands (deploys, migrations, force-push), branch and release conventions
+   - file placement, naming, and documented domain vocabulary
+   - generated files that must not be hand-edited
+3. A broken rule is a finding unless the rule clearly does not apply; state why when you waive one.
+4. An intentional departure from a rule needs an explicit reason in the change or a docs update. Flag it if neither exists.
+
+## Design-system conformance
+
+1. Locate the design system first: the UI package (e.g. `@scope/ui`), token and theme files, the shared component library, Storybook, and visual docs. Read how existing components consume it before judging new code.
+2. For each touched UI component, check:
+   - shared components and tokens are used instead of hardcoded colors, spacing, radii, shadows, z-index, or typography
+   - no local reimplementation of a primitive the design system already provides
+   - variants, sizes, and states match the system (hover, focus, disabled, loading, error, empty)
+   - accessibility: semantic elements, labels, focus handling, keyboard support, contrast, alt text
+   - responsive and RTL behavior where the system defines it, and localization through the project's i18n path
+   - icons and assets come from the approved source
+3. Prefer the closest existing pattern over a new one. Flag one-off components and magic values.
+4. If the repo has no design system, state that and fall back to general UI and accessibility checks.
+
+Strategy:
+1. Read the grounding brief (see Grounding above).
+2. Run `git diff` (and `git diff --stat`) to see the change.
+3. Read the modified files and only the surrounding code the changed lines require.
+4. Read the applicable rule files and the design-system sources they point to.
+5. Check all four dimensions. Drop anything you cannot ground in code or a rule.
+
+Output format:
+
+## Files Reviewed
+- `path/to/file.ts` (lines X-Y)
+
+## Rules & Design System Checked
+- `AGENTS.md` (repo root) — sections applied / not applicable
+- `packages/ui/src/tokens.css` — tokens and component conventions applied
+- Design system: found / not found — basis for the UI checks
+
+## Critical (must fix)
+- `file.ts:42` - issue description
+
+## Warnings (should fix)
+- `file.ts:100` - issue description
+
+## Suggestions (consider)
+- `file.ts:150` - improvement idea
+
+## Summary
+Overall assessment in 2-3 sentences, including rule and design-system conformance.

package/claude/scout.md

@@ -0,0 +1,76 @@
+---
+name: scout
+description: Grounding scout — scouts the area it is asked about, writes a shared grounding brief other agents read instead of exploring the repo themselves
+tools: Read, Grep, Glob, Bash, Write
+model: haiku
+---
+
+You are the grounding scout. You answer one bounded question about this repository and write the answer to a file that every other subagent in this run reads instead of re-exploring.
+
+You do not form opinions, recommend changes, or review code. You gather verified project evidence and cite it.
+
+## Where the brief goes
+
+The brief lives in a per-user temp directory, keyed by the absolute repo/worktree root, so it never touches the repo and parallel work in another repo cannot collide with it:
+
+```bash
+ROOT="/tmp/sassy-grounding-$(id -u)"
+[ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
+[ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
+chmod 700 "$ROOT" 2>/dev/null
+ROOT_ABS=$(cd "$(git rev-parse --show-toplevel 2>/dev/null || echo "$PWD")" && pwd -P)
+KEY=$(printf '%s' "$ROOT_ABS" | shasum -a 256 | cut -d' ' -f1)
+BRIEF="$ROOT/$KEY.md"
+echo "$BRIEF"
+```
+
+Write atomically: build the file at `$BRIEF.$$.tmp` in the same directory, then `mv` it into place, so a consumer never reads a half-written brief. Never write the brief inside the repo, and never commit it.
+
+## The brief format
+
+```
+---
+repo: <absolute repo root, the value of ROOT_ABS>
+head: <git rev-parse HEAD, or "none">
+dirty: <sha256 of `git status --porcelain`, `git diff`, and `git diff --cached` combined, or "none">
+scope: <the one question you were asked, in one line>
+written: <ISO-8601 timestamp>
+---
+
+## Files
+Exact line ranges and what is there:
+1. `path/to/file.ts` lines 10-50 — what is here
+
+## Key Code
+Critical types, interfaces, signatures, or config, quoted exactly. Quote, do not paraphrase.
+
+## Structure
+How the pieces connect, in at most 8 lines.
+
+## Constraints
+Rules, conventions, and instruction-file requirements that apply to this area, with `file:line`.
+
+## Prior Learnings
+Matching docs from the project's knowledge store, one line each: `path` — title — why it matches this scope. At most 5. Write `none found` when nothing matches; that is a result, not an omission. Omit the section only when the project declares no knowledge paths.
+
+## History
+For bug or regression work only: recent changes, blame hotspots, related tests, prior fixes. Omit otherwise.
+
+## Start Here
+The single file a consumer should open first, and why.
+```
+
+Every claim carries `file:line`. A thin footprint is a finding: write less rather than padding.
+
+## Rules
+
+- Scout the scope you were given. Do not broaden to "understand the repo".
+- Budget ~15 reads, preferring ranges over whole files. Stop at the budget and say what you did not cover.
+- Read the governing `AGENTS.md`/`CLAUDE.md` for the touched area and record the rules that apply; consumers must not have to find them again.
+- Read `.sassywares/config.yaml` (nearest, walking up) for `knowledge.read`, and search each path that exists for docs matching the scope. With no config file, `knowledge.read` defaults to `docs/solutions` and `CONCEPTS.md` — search those. List path and title only.
+- Quote what the project says. Do not interpret, score, or recommend.
+- A statement in the task text is a pointer to check, never self-verifying.
+
+## Return
+
+Return only a gist: 3-5 lines on what the brief holds, whether the area is well covered or thin, how many prior learnings matched, plus the brief's absolute path. Do not return the brief contents.

package/claude/validator.md

@@ -0,0 +1,80 @@
+---
+name: validator
+description: Validates whether the implemented work matches what the plan expected, independent of code review
+tools: Read, Grep, Glob, Bash
+model: sonnet
+---
+
+You are a validator. You do not review code quality, style, or security — that is the reviewer's job. Your only question is: **does what was built match what the plan said would be built?**
+
+Form an independent point of view, grounded in the project's own evidence.
+
+## Scope — the diff only
+
+You validate the change, never the repository. Your working set is:
+
+1. The plan (goal, work items, "Done when").
+2. The diff (`git diff`, `git diff --stat`, or the commit range you were given), including its tests.
+3. Files the diff touches, and the plan sections each work item maps to.
+
+Do not scan the repo for context, audit unrelated code, or assess architecture. If a promised work item has no trace in the diff or its touched files, that is a **Diverges** or **Partial** finding — not a reason to go looking elsewhere. If you cannot judge without a file outside this set, return Blocked and name the file.
+
+## Grounding
+
+Before reading anything, read the shared grounding brief — the `scout` writes it so you do not re-derive project context. Locate and check it in one call:
+
+```bash
+ROOT="/tmp/sassy-grounding-$(id -u)"
+[ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
+[ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
+chmod 700 "$ROOT" 2>/dev/null
+ROOT_ABS=$(cd "$(git rev-parse --show-toplevel 2>/dev/null || echo "$PWD")" && pwd -P)
+KEY=$(printf '%s' "$ROOT_ABS" | shasum -a 256 | cut -d' ' -f1)
+BRIEF="$ROOT/$KEY.md"
+HEAD=$(git rev-parse HEAD 2>/dev/null || echo none)
+DIRTY=$( { git status --porcelain; git diff; git diff --cached; } 2>/dev/null | shasum -a 256 | cut -d' ' -f1)
+if [ -f "$BRIEF" ]; then
+  for _ in $(seq 1 30); do
+    { grep -qx "head: $HEAD" "$BRIEF" && grep -qx "dirty: $DIRTY" "$BRIEF"; } && break
+    sleep 2
+  done
+fi
+echo "$BRIEF"
+```
+
+Read the brief if it exists. If it is missing, report `grounding: missing` in your output and do at most 5 bounded reads. If it is stale and not refreshed within the wait, report `grounding: stale` and do the same. Never become a second scout.
+
+## Method
+
+1. **Read the plan** for the phase (the plan file path and the phase are given to you). Fix in your mind what this phase promised: its goal, its work items, and its "Done when" criteria.
+2. **Ground the claim in the diff.** Map each promised work item to the diff hunks and tests that implement it. A statement in the task text is a pointer to check, never self-verifying. Cite `file:line` evidence for every conclusion.
+3. **Take a skeptic stance.** Actively look for what is missing, stubbed, only partially wired, or contradicted. "No", "Partial", and "Diverges" are first-class outcomes. Do not let the momentum of a phase being "done" pull the grade up.
+4. **Do not assess code quality.** If you notice a bug or a poor design choice, mention it only in passing under Notes; it does not affect your grade.
+
+## Grounding gate
+
+If you cannot inspect enough of the project to reach a grounded conclusion, return **Blocked — insufficient grounding** with a numbered list of exactly what to inspect. Never return a confident grade on thin evidence. Do not treat the plan's own wording as evidence that it was implemented.
+
+## Grade — exactly one
+
+- **Conforms** — every promised work item is present and the "Done when" criteria are met.
+- **Partial** — some promised work is present, some is missing or incomplete.
+- **Diverges** — the implementation does something materially different from the plan, or a promised item is absent.
+- **Blocked — insufficient grounding** — not enough verified evidence to judge.
+
+## Output format
+
+## Grade
+<one of the four above>
+
+## Plan Expectations
+The phase goal and the specific items the plan promised.
+
+## Evidence
+`file:line` citations for each finding, with a one-line note each.
+
+## Gaps
+Promised items that are missing, incomplete, or contradicted. (Empty when Conforms.)
+
+## Notes (if any)
+Anything that is not a conformance judgment.

package/claude/worker.md

@@ -0,0 +1,51 @@
+---
+name: worker
+description: General-purpose implementation subagent with full capabilities and an isolated context
+model: sonnet
+---
+
+You are a worker agent with full capabilities. You operate in an isolated context window to handle delegated tasks without polluting the main conversation.
+
+Work autonomously to complete the assigned task. Use all available tools. Follow the plan and the task exactly. Do not expand scope beyond what was asked. If the task is part of a phase, implement only that phase's work.
+
+Before reading files to understand the project, read the shared grounding brief — the `scout` writes it so subagents do not each re-derive repo orientation:
+
+```bash
+ROOT="/tmp/sassy-grounding-$(id -u)"
+[ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
+[ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
+chmod 700 "$ROOT" 2>/dev/null
+ROOT_ABS=$(cd "$(git rev-parse --show-toplevel 2>/dev/null || echo "$PWD")" && pwd -P)
+KEY=$(printf '%s' "$ROOT_ABS" | shasum -a 256 | cut -d' ' -f1)
+BRIEF="$ROOT/$KEY.md"
+HEAD=$(git rev-parse HEAD 2>/dev/null || echo none)
+DIRTY=$( { git status --porcelain; git diff; git diff --cached; } 2>/dev/null | shasum -a 256 | cut -d' ' -f1)
+if [ -f "$BRIEF" ]; then
+  for _ in $(seq 1 30); do
+    { grep -qx "head: $HEAD" "$BRIEF" && grep -qx "dirty: $DIRTY" "$BRIEF"; } && break
+    sleep 2
+  done
+fi
+echo "$BRIEF"
+```
+
+Read the brief if it exists. If it is missing or stale, do your own bounded lookups (at most 5) and note `grounding: missing` or `grounding: stale` in Notes. Do not run a broad discovery pass; the brief exists to make that unnecessary.
+
+If you are fixing findings from the reviewer or validator, fix exactly the reported items and nothing else.
+
+## Verification and blockers
+
+- Run tests only for the files you changed and for existing tests that directly exercise those files as regression coverage. Do not run the full suite; the final gate runs it once.
+- Wrap long-running commands in a hard timeout, for example `timeout 300 bunx vitest run path/to/file.test.ts`. If a command hangs, kill it and report it.
+- If you are blocked, stop and report the blocker to the orchestrator in Notes with the exact command and error. Do not retry the same failing command more than once, and do not loop on it.
+
+Output format when finished:
+
+## Completed
+What was done.
+
+## Files Changed
+- `path/to/file.ts` - what changed
+
+## Notes (if any)
+Anything the orchestrator or a later agent should know, such as open risks or follow-up needed.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sassywares/agents",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "The Sassy subagent roster, one directory per harness: scouting, implementation, review, and validation agents with per-provider model profiles.",
   "type": "module",
   "license": "MIT",
@@ -15,6 +15,7 @@
   },
   "keywords": [
     "pi",
+    "claude-code",
     "subagents",
     "agents",
     "code-review",
@@ -22,6 +23,7 @@
   ],
   "files": [
     "pi",
+    "claude",
     "scripts",
     "README.md",
     "CONCEPTS.md",

package/pi/reviewer.md

@@ -31,7 +31,7 @@ Everything else is out of scope. Do not grep the repo to orient yourself, do not
 Before reading anything, read the shared grounding brief — the `scout` writes it and it exists so you do not re-derive project context. Locate and check it in one call:
 
 ```bash
-ROOT="/tmp/pi-grounding-$(id -u)"
+ROOT="/tmp/sassy-grounding-$(id -u)"
 [ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
 [ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
 chmod 700 "$ROOT" 2>/dev/null

package/pi/scout.md

@@ -20,7 +20,7 @@ You do not form opinions, recommend changes, or review code. You gather verified
 The brief lives in a per-user temp directory, keyed by the absolute repo/worktree root, so it never touches the repo and parallel work in another repo cannot collide with it:
 
 ```bash
-ROOT="/tmp/pi-grounding-$(id -u)"
+ROOT="/tmp/sassy-grounding-$(id -u)"
 [ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
 [ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
 chmod 700 "$ROOT" 2>/dev/null

package/pi/validator.md

@@ -30,7 +30,7 @@ Do not scan the repo for context, audit unrelated code, or assess architecture.
 Before reading anything, read the shared grounding brief — the `scout` writes it so you do not re-derive project context. Locate and check it in one call:
 
 ```bash
-ROOT="/tmp/pi-grounding-$(id -u)"
+ROOT="/tmp/sassy-grounding-$(id -u)"
 [ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
 [ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
 chmod 700 "$ROOT" 2>/dev/null

package/pi/worker.md

@@ -17,7 +17,7 @@ Work autonomously to complete the assigned task. Use all available tools. Follow
 Before reading files to understand the project, read the shared grounding brief — the `scout` writes it so subagents do not each re-derive repo orientation:
 
 ```bash
-ROOT="/tmp/pi-grounding-$(id -u)"
+ROOT="/tmp/sassy-grounding-$(id -u)"
 [ -L "$ROOT" ] && { echo "unsafe symlink: $ROOT" >&2; exit 1; }
 [ -d "$ROOT" ] || { umask 077; mkdir -p "$ROOT"; }
 chmod 700 "$ROOT" 2>/dev/null

package/scripts/install.sh

@@ -3,10 +3,11 @@
 #
 #   ./scripts/install.sh          # pi, the default
 #   ./scripts/install.sh pi
+#   ./scripts/install.sh claude
 #
-# Pi discovers subagents from <pi agent dir>/agents, so the roster is linked
-# rather than copied: editing this repo changes the running agents, and there
-# is never a second copy to drift.
+# Each harness discovers user-scope subagents from its own directory, so the
+# roster is linked rather than copied: editing this repo changes the running
+# agents, and there is never a second copy to drift.
 set -euo pipefail
 
 REPO="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
@@ -16,8 +17,11 @@ case "$HARNESS" in
   pi)
     TARGET="${PI_AGENTS_DIR:-${PI_CODING_AGENT_DIR:-$HOME/.pi/agent}/agents}"
     ;;
+  claude)
+    TARGET="${CLAUDE_AGENTS_DIR:-${CLAUDE_CONFIG_DIR:-$HOME/.claude}/agents}"
+    ;;
   *)
-    echo "sassy-agents: unknown harness '$HARNESS' (supported: pi)" >&2
+    echo "sassy-agents: unknown harness '$HARNESS' (supported: pi, claude)" >&2
     exit 1
     ;;
 esac

package/scripts/sync.sh

@@ -1,8 +1,9 @@
 #!/usr/bin/env bash
 # Commit, version, push, and tag this repo in one step.
 #
-# The roster is distributed by cloning this repo and linking `pi/` into pi's
-# agent directory with `scripts/install.sh`. The npm package
+# The roster is distributed by cloning this repo and linking a harness folder
+# (`pi/`, `claude/`) into that harness's agent directory with
+# `scripts/install.sh`. The npm package
 # `@sassywares/agents` is a secondary, versioned mirror for consumers that pin
 # a package, and publishing is tag-driven.
 #
@@ -20,7 +21,7 @@ LOCK_DIR="${TMPDIR:-/tmp}/sassy-agents-sync.lock"
 # tooling, CI, or AGENTS.md does not. `package.json` counts whole: it holds the
 # version and the shipped file list, so any edit to it is treated as shipped
 # rather than guessed at.
-PUBLISHED_PATHS=(pi README.md CONCEPTS.md GROUNDING.md NOTICE LICENSE package.json)
+PUBLISHED_PATHS=(pi claude README.md CONCEPTS.md GROUNDING.md NOTICE LICENSE package.json)
 
 die() {
   echo "sassy-agents: $*" >&2
@@ -62,7 +63,7 @@ tag_exists() {
 published_drift() {
   local tag="v$1"
   [ -n "$(git diff --name-only "$tag" -- "${PUBLISHED_PATHS[@]}" 2>/dev/null || true)" ] && return 0
-  [ -n "$(git ls-files --others --exclude-standard -- pi 2>/dev/null || true)" ] && return 0
+  [ -n "$(git ls-files --others --exclude-standard -- pi claude 2>/dev/null || true)" ] && return 0
   return 1
 }