@awebai/oats 0.29.4 → 0.30.1

package/capabilities/oats-okf-maintenance/skills/okf-authoring/SKILL.md

@@ -1,151 +0,0 @@
----
-name: okf-authoring
-description: >-
-  Open Knowledge Format (OKF) authoring craft for knowledge-operations souls:
-  how to write, edit, move and validate concepts in an OKF bundle (markdown
-  concepts with YAML frontmatter, per Google Cloud's OKF v0.1 spec), keep
-  index.md and log.md honest, supersede instead of silently rewriting, and run
-  the bundled validator. Use when staging or amending concepts in a knowledge
-  base, fixing index/log entries, reviewing a knowledge PR's Markdown, or when
-  asked to validate a bundle. Promotion judgment (what belongs in a base) is
-  the knowledge-theory skill.
----
-
-# OKF craft — author, maintain, consume
-
-An OKF **bundle** is a directory tree of markdown files. Each non-reserved `.md`
-file is **one concept**; links between files form the knowledge graph. No
-database, no SDK — plain git-versionable text. Spec: OKF v0.1 (Google Cloud).
-An external base is one bundle and link namespace. Owned nodes are
-nonoverlapping subdirectories, not separate root-link namespaces. Instance
-`notes/` files are task-local concepts; no knowledge lives in the soul.
-
-## The format in one screen
-
-- **Concept = one file.** Concept ID = path minus `.md`. Small and specific
-  beats long and general — split rather than grow.
-- **Frontmatter** (`---` delimited): only **`type`** is required (short,
-  freeform — the spec ships no vocabulary. Fleet core: `Lesson`, `Decision`,
-  `Playbook`, `Reference`; souls also grow role-specific types like
-  `Area Guide` or `Roadmap` — see the knowledge-theory skill for routing).
-  Recommended,
-  in order: `title`, `description` (ONE sentence — it's what index listings
-  and skimming agents see), `resource` (URI, only if a real asset backs the
-  concept), `tags` (YAML list), `timestamp` (ISO date of last meaningful change).
-- **Links** are ordinary markdown, keep the `.md`, prefer bundle-root-absolute:
-  `[clearing playbook](/node/playbooks/clearing-fields.md)`. Links are untyped
-  directed edges; the surrounding prose carries the relationship's meaning.
-- **Reserved files** at any level: `index.md` (navigation) and `log.md`
-  (history). They carry **no `type`**; only the bundle-root `index.md` may
-  have frontmatter, and only `okf_version: "0.1"`.
-- **Conventional headings** when applicable: `# Schema`, `# Examples`,
-  `# Citations` (numbered external sources backing claims).
-
-## Honesty rules (non-negotiable)
-
-- **Never invent** a `resource`, `timestamp`, or `description` — leave a field
-  out rather than guess it.
-- Every claim you write down should be something you verified or observed;
-  cite sources under `# Citations` when the claim came from outside.
-- Never create a link to a concept you didn't create or verify exists —
-  except deliberate not-yet-written knowledge, which is allowed by spec but
-  should be rare and intentional.
-- **Supersede, don't silently rewrite.** When a concept's meaning changes,
-  update it AND log the change; when it's wrong, correct it and say so in
-  log.md (`**Fix**: …`). History must stay reconstructible.
-
-## Maintaining a bundle
-
-**Adding a concept:**
-1. Write the file in the right section dir with valid frontmatter.
-2. Link it to/from related concepts (edit those files' bodies).
-3. Add a line to the section's `index.md`: `* [Title](file.md) - description`.
-4. Append to the bundle's `log.md` (see conventions below).
-
-**Renaming/moving a concept:** update **every inbound link** — search the
-whole bundle for the old path (`grep -rn "old-name.md" <bundle>`) — EXCEPT
-links inside historical `log.md` entries: never rewrite log history; dangling
-links there are expected.
-
-**Removing:** delete the file, remove its index.md line, fix inbound links,
-log a `**Removal**` or `**Deprecation**` entry saying why.
-
-**log.md conventions** (newest first, `## YYYY-MM-DD` headings):
-`* **Creation|Update|Removal|Fix|Deprecation|Harvest|Triage**: prose with
-[links](/path.md).` One line per event; the bold word makes logs greppable.
-
-**index.md discipline:** every concept reachable from an index; descriptions
-in listings match the concept's frontmatter `description`. Indexes are
-navigation, not content — keep them to listings.
-
-## Consuming a bundle (answering from knowledge)
-
-1. **Index-first, always.** Start at the root `index.md`; follow only links
-   relevant to the question. Never bulk-read a bundle — progressive
-   disclosure is the point of the format.
-2. Frontmatter (`type`, `tags`, `description`) is the quick filter layer;
-   open bodies only for concepts that survive the filter.
-3. `log.md` answers "what changed recently" — check it when freshness matters.
-4. Cite concepts by path when reporting answers.
-5. Tolerate imperfect concepts: unknown types and stale links are
-   never a reason to reject or ignore a bundle — that permissiveness is spec.
-
-## Validating
-
-Run the bundled validator (node, no deps) after non-trivial maintenance:
-
-```bash
-node <skill-dir>/scripts/okf-validate.mjs <bundle-dir>            # conformance
-node <skill-dir>/scripts/okf-validate.mjs <bundle-dir> --strict   # + producer lints
-```
-
-- **Conformance errors** (must fix): unparseable/missing frontmatter, missing
-  or empty `type`, reserved files carrying a `type`.
-- **Producer lints** (`--strict`, should fix in bundles you produce): broken
-  intra-bundle links (log.md exempt), links missing `.md`, concepts
-  unreachable from any index.md, missing `title`/`description`.
-
-Lints in a bundle you're *consuming* are noise — read on regardless.
-
-## Portable source and store declarations
-
-When the portable binding interface is active (planned OATS >=0.24.0; not yet a
-published provider baseline), treat the source declaration as policy and the
-captured ProviderBinding as execution authority:
-
-- In `oats.okf.locations@1`, `fixed` is source-owned, `default` is rebindable,
-  and `inherit` requires an external binding such as `write.default`.
-- Qualify every read and owned node by its declared store. A read grants no
-  write authority. Never infer the sole readable store as a destination.
-- Workspace store envelopes put concrete provider choices under
-  `payload.bindings`. Workspace, adoption, and operator values remain separate
-  inputs to the shared resolver; OKF does not select their precedence.
-- Durable placement is explicit selected settings: physical absolute
-  `bindings-file` and `state-dir`, plus selected `harvest-runtime`, optional
-  `harvest-model` and optional `git-timeout` (seconds for remote Git
-  operations, default 600). Never derive state from an instance home.
-- Provider codecs run only after exact retained executable approval. Their
-  populated binding is not proof of readiness, enrollment, credentials, privacy
-  or publication authority. Respect typed non-ready results.
-- Captured source descriptors freeze binding/runtime/source identity. Later
-  reads and workers use those bytes after source/config deletion. Never replace
-  them with today's soul, workspace, settings or bindings file.
-- `responsibleHuman: null` means messaging was explicitly disabled. Missing is
-  unknown, not disabled.
-- New captured source schedules are definition v2 with `capture`, explicit
-  deployment/resolution selectors and saved `--json`; they do not use `--soul`.
-- Captured `setup`, `init`, `migrate`, and `unlock` are deliberate refusals.
-  Provisioning/migration remains a separate explicit operator path.
-
-The broker-owned `binding-normalize`, `binding-bind`, and `binding-check`
-manifest commands are not manual recipes. Do not invoke them from a working
-agent or copy transient `OATS_BINDING_FILE`/`OATS_SOURCE_RECEIPT_FILE` paths.
-Those private mode-0600 files exist only for one synchronous captured invocation.
-
-## External bases and native tools
-
-A harvester stages writes with native file tools only under the roots listed
-in work/staging.json. A maintainer amends a PR branch in its own checkout.
-Either way, validate the WHOLE base, not an isolated node: absolute Markdown
-links can cross node boundaries. The harvester's completion command validates
-again and refuses any errors or producer warnings.

package/capabilities/oats-okf-maintenance/skills/okf-authoring/scripts/okf-validate.mjs

@@ -1,123 +0,0 @@
-#!/usr/bin/env node
-/**
- * okf-validate.mjs — OKF v0.1 bundle validator (no dependencies).
- *
- * Usage: node okf-validate.mjs <bundle-dir> [--strict] [--json]
- *
- * Conformance (errors): frontmatter parses; non-empty `type` on concepts;
- * reserved files (index.md, log.md) carry no `type`.
- * Producer lints (--strict, warnings): broken intra-bundle links (log.md exempt),
- * links missing .md, concepts unreachable from any index.md, missing title/description.
- * Exit: 0 conformant, 1 errors (or warnings with --strict), 2 usage.
- */
-import { existsSync, readFileSync, readdirSync, statSync } from "node:fs";
-import { join, relative, resolve, dirname, posix } from "node:path";
-
-const args = process.argv.slice(2);
-const strict = args.includes("--strict");
-const asJson = args.includes("--json");
-const dir = args.find((a) => !a.startsWith("--"));
-if (!dir || !existsSync(dir)) { console.error("usage: okf-validate.mjs <bundle-dir> [--strict] [--json]"); process.exit(2); }
-const root = resolve(dir);
-
-const files = [];
-(function walk(d) {
-  for (const e of readdirSync(d, { withFileTypes: true })) {
-    if (e.name.startsWith(".")) continue;
-    const p = join(d, e.name);
-    if (e.isDirectory()) walk(p);
-    else if (e.name.endsWith(".md")) files.push(p);
-  }
-})(root);
-
-const errors = [], warnings = [];
-const rel = (p) => relative(root, p).split("\\").join("/");
-const isReserved = (p) => ["index.md", "log.md"].includes(posix.basename(rel(p)));
-
-function parseFrontmatter(text) {
-  if (!text.startsWith("---")) return { present: false };
-  const m = text.match(/^---\r?\n([\s\S]*?)\r?\n---(\r?\n|$)/);
-  if (!m) return { present: true, parsed: false };
-  const meta = {};
-  for (const line of m[1].split("\n")) {
-    if (/^\s*#/.test(line) || !line.trim()) continue;
-    const kv = line.match(/^([A-Za-z_][A-Za-z0-9_-]*):\s*(.*)$/);
-    if (kv) meta[kv[1]] = kv[2].replace(/\s+#.*$/, "").replace(/^["']|["']$/g, "").trim();
-    else if (!/^\s+/.test(line)) return { present: true, parsed: false };
-  }
-  return { present: true, parsed: true, meta, body: text.slice(m[0].length) };
-}
-
-const concepts = new Map(); // rel path -> { meta, body }
-for (const f of files) {
-  const r = rel(f);
-  const text = readFileSync(f, "utf8");
-  const fm = parseFrontmatter(text);
-  if (isReserved(f)) {
-    if (fm.present && fm.parsed && fm.meta.type) errors.push(`${r}: reserved file must not carry a 'type'`);
-    if (fm.present && fm.parsed && posix.basename(r) === "index.md" && r !== "index.md") {
-      const keys = Object.keys(fm.meta);
-      if (keys.some((k) => k !== "okf_version")) warnings.push(`${r}: only the bundle-root index.md may carry frontmatter`);
-    }
-    concepts.set(r, { reserved: true, body: fm.parsed ? fm.body : text });
-    continue;
-  }
-  if (!fm.present) { errors.push(`${r}: missing YAML frontmatter`); continue; }
-  if (!fm.parsed) { errors.push(`${r}: unparseable YAML frontmatter`); continue; }
-  if (!fm.meta.type) errors.push(`${r}: missing or empty required field 'type'`);
-  if (strict) {
-    if (!fm.meta.title) warnings.push(`${r}: missing recommended field 'title'`);
-    if (!fm.meta.description) warnings.push(`${r}: missing recommended field 'description'`);
-  }
-  concepts.set(r, { meta: fm.meta, body: fm.body });
-}
-
-if (strict) {
-  // Link checks (log.md bodies exempt) + reachability from index files.
-  const reachable = new Set();
-  const linkRe = /\[[^\]]*\]\(([^)\s]+)\)/g;
-  const resolveLink = (fromRel, target) => {
-    if (/^[a-z]+:\/\//i.test(target) || target.startsWith("mailto:")) return null; // external
-    const clean = target.split("#")[0];
-    if (!clean) return null;
-    const abs = clean.startsWith("/")
-      ? posix.normalize(clean.slice(1))
-      : posix.normalize(posix.join(posix.dirname(fromRel), clean));
-    return abs;
-  };
-  for (const [r, c] of concepts) {
-    const body = c.body ?? "";
-    const fromLog = posix.basename(r) === "log.md";
-    for (const m of body.matchAll(linkRe)) {
-      const t = resolveLink(r, m[1]);
-      if (t === null) continue;
-      const isDir = t.endsWith("/") || concepts.has(posix.join(t, "index.md")) || existsSync(join(root, t)) && statSync(join(root, t)).isDirectory?.();
-      if (posix.basename(r) === "index.md" || !fromLog) {
-        if (!t.endsWith(".md") && !isDir) { if (!fromLog) warnings.push(`${r}: link missing .md extension: ${m[1]}`); continue; }
-      }
-      if (fromLog) continue; // history exempt from broken-link lint
-      if (t.endsWith(".md") && !concepts.has(t)) warnings.push(`${r}: broken link: ${m[1]}`);
-      if (posix.basename(r) === "index.md" && t.endsWith(".md") && concepts.has(t)) reachable.add(t);
-      if (posix.basename(r) === "index.md" && isDir) reachable.add(posix.join(t.replace(/\/$/, ""), "index.md"));
-    }
-  }
-  // Reachability: walk index closure (an index that lists a subdir makes that subdir's index reachable).
-  for (const [r, c] of concepts) {
-    if (c.reserved || reachable.has(r)) continue;
-    // root-level concepts listed in root index handled above; report the rest
-    const anyIndex = [...concepts.keys()].some((k) => posix.basename(k) === "index.md");
-    if (anyIndex) warnings.push(`${r}: unreachable from any index.md`);
-  }
-}
-
-const conceptCount = [...concepts.values()].filter((c) => !c.reserved).length;
-if (asJson) {
-  console.log(JSON.stringify({ bundle: root, concepts: conceptCount, errors, warnings, conformant: errors.length === 0 }, null, 2));
-} else {
-  console.log(`OKF validate — ${root}`);
-  console.log(`  ${conceptCount} concept(s), ${errors.length} error(s), ${warnings.length} warning(s)`);
-  for (const e of errors) console.log(`  ERROR ${e}`);
-  for (const w of warnings) console.log(`  warn  ${w}`);
-  console.log(errors.length === 0 ? (strict && warnings.length ? "PASS (with lints)" : "PASS — conformant") : "FAIL — nonconformant");
-}
-process.exit(errors.length > 0 ? 1 : strict && warnings.length > 0 && process.env.OKF_STRICT_EXIT ? 1 : 0);

package/capabilities/oats-okf-maintenance/skills/okf-trigger-setup/SKILL.md

@@ -1,146 +0,0 @@
----
-name: okf-trigger-setup
-description: >-
-  Set up and verify the OKF harvest-review trigger, which spawns a knowledge
-  maintainer for each harvest PR: declare it as a workspace automation
-  (`oats-triggers/okf-harvest-review.yaml` in a member repo, `from:
-  oats.okf:harvest-review`, with `runsOn` naming the one host and `owner` the
-  GitHub account that can merge on the knowledge-base repo), or locally with
-  `oats trigger add` for a machine-private setup. Covers the okf team, the
-  self-approval limit and `oats trigger test`. Use when setting up knowledge
-  operations, when harvest PRs are not being reviewed, when moving the
-  reviewer to another host, or when asked whether a host may run the
-  maintainer.
----
-
-# Setting up the harvest-review trigger
-
-The trigger makes a harvest PR get reviewed: when a PR labelled `okf-harvest`
-opens on the knowledge-base (KB) repository, the host tick spawns a new
-`oats.okf/knowledge-maintainer` in the `okf` team to review it. It runs on one
-machine, acting as one GitHub account, and that account must be able to
-**merge** on the KB repository.
-
-## 1. Choose the host and the account
-
-- **The account (`owner`)** must be able to merge on the KB repository (push,
-  maintain or admin). Check from the host:
-  `gh api repos/<owner>/<repo> --jq .permissions`.
-- **The host (`runsOn`)** is the one machine that runs the trigger, named by
-  its `oats-local.yaml` `host: { name: <slug> }`, and logged in with `gh` as
-  that account.
-- **The harvest switch is independent**: a review host need not harvest (its
-  `harvest` setting can stay `off`), and a harvesting host need not review.
-
-## 2. The self-approval limit
-
-GitHub forbids approving your own account's PR. If the harvester's host and
-the reviewer's account are the same GitHub account, then either:
-- the KB repository's `main` must not require approving reviews (merge
-  permission is enough; the maintainer records its verdict as a PR comment,
-  not an approval), or
-- the trigger's `owner` is a separate reviewer account or machine user.
-
-Say which one applies when you report the setup.
-
-## 3. The okf team
-
-The package souls carry `team: okf`. The workspace must declare it, with its
-messaging mapping. Messaging is aweb (`oats.aweb`, the workspace default);
-it needs oats.aweb 1.15.0 or later, which honours the `join=okf` the
-harvester spawn and the trigger's `teams: [okf]` pass:
-
-```yaml
-# oats-workspace.yaml
-teams:
-  okf: { description: Knowledge operations }
-defaults:
-  messaging: { oats.aweb: { from: package } }
-messaging:
-  byTeam:
-    okf: { team: aweb:<your-org>.okf }
-```
-
-Another messaging provider works the same way if it honours `join`.
-
-Without it, the souls list with `E_TEAM_UNKNOWN`, and the harvester and the
-maintainer cannot message each other.
-
-## 4. Declare it in the workspace (the default)
-
-A team relies on the review, so declare it in Git, in a member repository (the
-workspace's host repo), in its `oats-triggers/` folder:
-
-```yaml
-# <member>/oats-triggers/okf-harvest-review.yaml
-kind: oats-trigger
-schemaVersion: 1
-description: Review every OKF harvest PR on the knowledge base
-from: oats.okf:harvest-review
-set: { repo: github.com/<owner>/<kb-repo> }     # optional: base, harness, model
-runsOn: <host.name of the one machine>
-owner: github.com/<the merge-capable account>
-```
-
-- `kind: oats-trigger` and `schemaVersion: 1` make the file self-describing; a
-  wrong kind is `E_AUTOMATION_SCHEMA`.
-- The id is `id:` if present, else the filename stem (`okf-harvest-review`).
-  Two files with the same id in one member are `E_AUTOMATION_DUPLICATE`.
-- A file named `*.oats-trigger.yaml` anywhere in the member works too (never
-  under `oats-package/`, `.git/` or `node_modules/`); `oats-triggers/` is the
-  canonical place.
-
-Or let the CLI write it: `oats trigger add --from oats.okf:harvest-review
---set repo=github.com/<owner>/<kb-repo> --workspace <member>` (it prints the
-file when that repository is not the current checkout). Commit and merge it
-like any other change.
-
-A host runs it only when **both** its `host.name` equals `runsOn` **and** its
-`gh` account equals `owner`. Everywhere else it is listed with the reason:
-`assigned-elsewhere`, `owner-mismatch` or `host-unnamed`. That keeps exactly
-one machine on it, and the operator's consent explicit. A host can opt out
-without a commit: `automations.disabled: [<member>/okf-harvest-review]` in its
-`oats-local.yaml`. Changes reach the host within about ten minutes (after
-`oats sync`, or the tick's refresh).
-
-## 5. Or add it locally (machine-private)
-
-For a personal or experimental setup, add it to this deployment only. It runs
-on this host with this host's `gh`, with no `runsOn` or `owner`:
-
-```sh
-oats trigger add --from oats.okf:harvest-review --set repo=github.com/<owner>/<kb-repo>
-#   optional: --set base=main --set harness=claude --set model=opus --id okf-harvest-review
-```
-
-Never run the same review from two places: one workspace declaration, or one
-local trigger on one host.
-
-## 6. Test it on the host that runs it
-
-```sh
-oats trigger test <member>/okf-harvest-review   # or: oats trigger test okf-harvest-review (local)
-oats schedule host install                      # the host timer, if the test says it is missing
-oats trigger status
-```
-
-- `oats trigger test` checks gh auth and where its credential comes from, the
-  repository and your merge permissions, the soul, its messaging capability,
-  the okf team, the host/owner match, and what would fire now. It spawns
-  nothing. It must pass before you report the setup done; fix what it names.
-- **Credentials reach the tick through the host timer, not your shell.** A
-  `GH_TOKEN` exported in your shell does not reach it; `gh auth login` with the
-  keyring or config file does.
-- Pause with `oats trigger disable <id>`; `remove` leaves running maintainers
-  alone.
-
-## 7. Labels
-
-Harvest PRs carry `okf-harvest` (the harvester's completion creates the label
-if the repository lacks it). The maintainer adds `okf-needs-human` when a PR
-would supersede a human-accepted decision. To pre-create both:
-
-```sh
-gh label create okf-harvest --repo <owner>/<repo> --force --color 0E8A16 --description "OKF harvest PR (oats.okf)"
-gh label create okf-needs-human --repo <owner>/<repo> --force --color D93F0B --description "OKF: needs a human decision"
-```

package/capabilities/oats-review/injects/review.md

@@ -1,69 +0,0 @@
-## Review discipline: oats.review
-
-**After every substantive commit, launch the reviewer** — and, when a knowledge
-layer is active, run its promotion step alongside (whatever command that layer
-documents; omit the line entirely if you have no knowledge layer):
-
-```bash
-<your knowledge layer's promotion command>   # omit when no knowledge layer is active
-oats spawn reviewer --work attached --work-dir "$PWD/work" \
-  --purpose "<short-sha>" \
-  --task "Review commit <sha> on branch <branch>. Report to <your-instance> per your operating loop."
-```
-
-- `reviewer` is the oats.dev package's soul (`oats.dev/reviewer`).
-  `--purpose "<short-sha>"` gives it a unique, commit-relevant instance name
-  (`oats-dev-reviewer-<short-sha>`); attached mode shares your work tree
-  and automatically makes the reviewer your child (attached agents are always
-  children of the work-tree owner — no relation flags needed or allowed).
-- The reviewer reviews **that commit's diff only** and reports its verdict
-  (`APPROVE` / `APPROVE WITH NITS` / `NEEDS CHANGES`) back to you the way your
-  deployment delivers messages: over your messaging layer when one is active,
-  and otherwise in its own session transcript, which is where you read it.
-  When a messaging layer IS active, do not wait actively — finish your turn and
-  go idle; the layer wakes you when the verdict arrives. `NEEDS CHANGES` means
-  fix, commit, and re-review before the work is ready.
-- Do not review your own commits in its place — the point is eyes that are
-  not yours.
-- Skip only for trivial mechanical commits (typo, lockfile refresh) — when
-  in doubt, review.
-
-## Delivery discipline (all OATS developers)
-
-- You work in a dedicated worktree on your own branch. **Main only moves
-  through PRs** — never push to main.
-- **Single-developer features**: branch from main (`agents/<instance>` or as
-  tasked), open the PR yourself (`gh pr create`) when review-clean, then
-  **spawn a fresh maintainer instance for it** — one per PR, always, even if
-  another oats-expert instance is live:
-
-  ```bash
-  oats spawn oats-expert --purpose "pr<n>" --relation parent --relative-to "$OATS_INSTANCE" \
-    --task "Maintainer review of PR #<n>: run your pr-review gates. You own this PR to its terminal outcome — on RETURN stay alive and idle for my fix notice, re-review, repeat; on merge/close record the delivery in your stewardship knowledge and retire yourself. Report verdicts to <your-instance>."
-  ```
-
-  Go idle for the verdict. **The maintainer instance stays alive across
-  RETURN rounds** — when you push fixes, notify the SAME maintainer, continuing
-  the existing exchange rather than starting a new one; do not spawn another for
-  this PR. You never merge to main
-  yourself.
-
-  **Reviewers are the opposite: one per commit, then gone.** The post-commit
-  reviewer reviews its one diff, reports its verdict, and retires — it no
-  longer exists when you fix its findings. To re-review a fix, spawn a NEW
-  reviewer on the fix commit (`--purpose <new-short-sha>`); never message a
-  retired reviewer or expect it to follow up.
-- **Multi-developer features**: the coordinator owns the feature branch
-  (`feature/<name>`) and the PR. Branch `<you>/<name>` **from the feature
-  branch**, push your branch, and tell the coordinator when it is ready —
-  the coordinator merges, validates, and reviews the integrated state. Never
-  merge into the feature branch yourself.
-- **If you need another developer's unmerged code, ask the coordinator** —
-  never fetch or merge a peer's branch yourself. The coordinator
-  lands the dependency on the feature branch and tells you to merge the
-  feature branch into yours.
-- Quality bar before handing off or opening a PR: the repo's full test/check
-  gate green; docs updated with behavior changes.
-- While waiting on the reviewer, the coordinator, or a peer: **do not sleep,
-  poll, or busy-wait** — go idle. An active messaging layer wakes you when the
-  answer arrives; with none, read the reviewer's own session when it finishes.

package/capabilities/oats-review/oats.json

@@ -1,10 +0,0 @@
-{
-  "capability": "oats.review",
-  "private": true,
-  "version": "1.3.0",
-  "compatibility": { "oats": ">=0.28.0" },
-  "description": "Post-commit review discipline: a fresh reviewer (this package's soul `reviewer`) reviews each new commit's diff, reports its verdict to its spawner over the deployment's messaging layer (or in its transcript when there is none), and retires — plus the shared developer delivery discipline and the reviewer's code-review and security-review skills.",
-  "requires": [],
-  "skills": ["skills/code-review", "skills/security-review"],
-  "inject": "injects/review.md"
-}

package/capabilities/oats-review/skills/code-review/SKILL.md

@@ -1,44 +0,0 @@
----
-name: code-review
-description: General code review discipline for reviewing a diff or commit range — correctness, design, readability, tests, and API surface, with severity-ranked, actionable findings. Use when asked to review code changes, a commit, a diff, or a PR for quality.
----
-
-# Code review
-
-Review the CHANGE, not the codebase. The standard (from Google's engineering
-practices): approve when the change **improves overall code health**, even if
-imperfect — demand blockers, suggest the rest.
-
-## Pass order (read the diff twice)
-
-**Pass 1 — does it work?**
-- Correctness: logic errors, off-by-one, inverted conditions, wrong operator.
-- Edge cases: empty/null/undefined inputs, zero/negative counts, unicode,
-  concurrent access, timeouts, partial failure mid-operation.
-- Error handling: swallowed exceptions, missing cleanup on the error path,
-  errors that lie about the cause. Every catch must justify itself.
-- State: mutation of shared state, stale caches, ordering assumptions.
-- Resource lifecycle: files/handles/processes/listeners opened but not closed.
-
-**Pass 2 — should it be this way?**
-- Design: is this the simplest change that solves the problem? Flag
-  speculative generality and dead configurability.
-- Consistency: does it follow the codebase's existing patterns, naming, and
-  error conventions? (Local consistency beats personal preference.)
-- Readability: could a maintainer six months from now follow it without the
-  PR description? Names carry meaning; comments explain WHY, not what.
-- API surface: new exports/flags/config keys are forever — are they earned?
-- Tests: does the change carry tests that would FAIL if the logic regressed?
-  Tests that mirror the implementation instead of the behavior are findings.
-- Performance: only flag measurable problems (N+1, unbounded growth,
-  sync-blocking hot paths) — not micro-optimizations.
-
-## Reporting
-
-- Verdict: `APPROVE` / `APPROVE WITH NITS` / `NEEDS CHANGES`.
-- Each finding: `severity — file:line — what + why + concrete fix`.
-  Severities: **blocker** (wrong/unsafe/regression), **important** (should
-  fix before merge), **nit** (better, not required — prefix "Nit:").
-- Ask questions where intent is unclear instead of asserting a fault.
-- Do not pad: no restating the diff, no praise quotas, no style opinions a
-  formatter could hold. If it's clean, say APPROVE and one line why.

package/capabilities/oats-review/skills/security-review/SKILL.md

@@ -1,59 +0,0 @@
----
-name: security-review
-description: Security-focused review of a diff or commit range — injection, secrets, trust boundaries, authz, unsafe deserialization, supply chain, and path/command safety, ranked by exploitability. Use when asked to security-review changes or as the second pass of a full review.
----
-
-# Security review
-
-Review the change as an attacker would read it: every new input is hostile,
-every boundary crossing is an opportunity. Grounded in the OWASP code-review
-model — findings ranked by exploitability, not by pattern-match count.
-
-## Checklist by trust boundary
-
-**Inputs (anything the process didn't create itself)**
-- Command injection: user/config/network data reaching `exec`/`spawn`/shell
-  strings. Quoting is not escaping; prefer argv arrays. Flag every
-  interpolated shell string that carries external data.
-- Path traversal: joins with external segments (`../`), symlink following,
-  zip-slip in extraction. Require canonicalize-then-prefix-check.
-- Injection into interpreters: SQL/NoSQL/LDAP/regex/eval/Function/template
-  engines fed external strings.
-- Deserialization: YAML/JSON/pickle-style loads of untrusted bytes with
-  type resolution or object construction.
-- SSRF: URLs from outside fetched by the server; check scheme/host pinning.
-
-**Secrets & data**
-- Hardcoded credentials, tokens, private keys — including in tests, fixtures,
-  and example configs. Entropy-looking strings deserve a question.
-- Secrets in logs, error messages, process args (visible in `ps`), URLs.
-- New persistence of sensitive data: is it needed, is it protected, is it
-  cleaned up on retire/delete paths?
-
-**AuthN/AuthZ**
-- New endpoints/commands/IPC surfaces: who can reach them, and what do they
-  authorize against? "Bound to localhost" is a real but WEAK boundary — note
-  what a local malicious process could do.
-- Privilege boundaries: does the change let low-trust config/data cause
-  high-trust execution (hooks, plugins, migrations, CI)?
-- TOCTOU: check-then-use on files/permissions/state.
-
-**Supply chain & execution**
-- New dependencies: are they necessary, pinned, and from expected owners?
-- Downloaded/cloned artifacts: integrity-checked before execution?
-- Anything that writes then executes (temp scripts, curl|sh patterns).
-
-**Web-facing (when applicable)**
-- XSS: external strings reaching innerHTML/attributes without escaping.
-- CSRF on state-changing endpoints; CORS wildcards; missing content-type
-  discipline on APIs.
-
-## Reporting
-
-- Verdict shares the scale: `APPROVE` / `APPROVE WITH NITS` / `NEEDS CHANGES`
-  — any credible injection/secret/authz finding is a **blocker**.
-- Each finding: `severity — file:line — attack scenario in one sentence +
-  concrete fix`. If you cannot articulate the attack, downgrade to a
-  question rather than inventing a threat.
-- Distinguish "exploitable now" from "hardening" — both are reportable,
-  only the first blocks.