@awebai/oats 0.30.0 → 0.30.2

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

@@ -1,30 +0,0 @@
----
-name: review-dev-docs
-description: The reviewer's pass over a change's effect on the repository's development docs and code comments. Check that they still describe how the code works and how to work in it, that the change updated what it made untrue, and that nothing drift-prone was added. Use in every adversarial review round.
----
-
-# Review the development docs
-
-The code is only half the change. Check the docs and comments the next developer will rely
-on.
-
-## Check
-- **Coverage:** did the change alter a structure, a flow, a convention, a command, a public
-  promise or a rule that the contributor guide, the architecture docs, a module README or a
-  comment describes? If so, is that doc updated in the same change?
-- **Truth:** does every doc and comment the diff touches match the code as it now is? Read
-  them against the code, not against the author's intent.
-- **The why:** does non-obvious new code (an invariant, a workaround, a subtle ordering)
-  carry a comment saying *why*?
-- **Drift-prone content:** decisions in motion ("for now", dates, PR numbers, who asked),
-  version history, or comments that restate what the code does. These belong in git or with
-  whoever is deciding, not in the docs.
-- **Duplication:** a rule restated in several places, which will diverge.
-
-## Report
-Use the `/adversarial-review` format:
-- **major:** a doc now tells the next developer something false about how to build, test or
-  change the code, or a contract's docs don't match the new behaviour.
-- **minor:** a missing *why* on non-obvious code; drift-prone content; a stale sentence
-  nearby.
-Missing docs for a trivial change aren't a finding. At most 2 doc minors per round.

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

@@ -1,56 +0,0 @@
----
-name: security-review
-description: The reviewer's security pass. Read the change as an attacker would, across every trust boundary it touches (injection, paths, secrets, authz, deserialization, supply chain, web), and report only what is exploitable or a concrete hardening gap. Use in every adversarial review round, and alone when asked for a security review.
----
-
-# Security review
-
-Every input the process didn't create itself is hostile. Every boundary the change
-crosses is a chance for an attacker. Rank by **exploitability**, not pattern count.
-
-## Map the trust boundaries first
-List what the change reads from outside (users, files, env, network, other processes,
-config, CI) and what it can cause (commands, file writes, network calls, privileged
-actions). Findings live where the first reaches the second.
-
-## Checklist
-**Injection and execution**
-- Command injection: external data reaching a shell string or an argv. Quoting isn't
-  escaping; use argv arrays. **Option injection:** a value starting with `-` passed as an
-  argument can become a flag (`--upload-pack=…`, `--config=…`). Use `--` or a
-  `--flag=value` single token, and refuse leading `-`.
-- Interpreters: SQL/NoSQL, regex (catastrophic backtracking), templates, `eval`/`Function`,
-  YAML/JSON loaders that build objects.
-- Anything that writes, then executes (temp scripts, `curl | sh`, hooks, plugins).
-
-**Files and paths**
-- Traversal: external segments joined into paths (`..`, absolute paths, symlinks, zip-slip,
-  crafted archive or git tree entries). Canonicalize, then prefix-check, and don't follow
-  symlinks out of the root.
-- Permissions on new files holding secrets or state; temp files in shared directories.
-- TOCTOU: check-then-use on files, permissions or state.
-
-**Secrets and data**
-- Hard-coded credentials, tokens, keys (tests and examples included).
-- Secrets in logs, errors, process arguments (visible in `ps`), URLs, crash reports.
-- Sensitive data persisted without need, or left behind on delete/retire paths.
-
-**AuthN / AuthZ**
-- New endpoints, commands, IPC or local servers: who can reach them, and what they check.
-  "Localhost only" is a weak boundary: what can a hostile local process or a web page do?
-- CSRF, CORS, Host/Origin checks on local HTTP servers.
-- Can low-trust input (config, a repo's files, a PR) cause high-trust execution (CI, hooks,
-  automation running under someone's credentials)?
-
-**Supply chain**
-- New dependencies: needed, pinned, from the expected owner?
-- Downloaded or cloned artifacts: is integrity checked before use?
-
-**Web (when applicable)**
-- XSS: external strings reaching HTML without escaping (`innerHTML`, attributes, URLs).
-
-## Report
-Use the adversarial-review format. Any credible injection, traversal, secret leak or authz
-bypass is a **blocker**. Each finding states the **attack in one sentence** (who, what
-input, what they gain). If you can't state the attack, it's a hardening note (minor) or a
-question, not a blocker.

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

@@ -1,34 +0,0 @@
----
-name: simplification-review
-description: The reviewer's refactor pass. Find where the change could be simpler, smaller or more consistent with the code around it, without changing behaviour, and report only suggestions worth the author's time. Use in every adversarial review round.
----
-
-# Simplification review
-
-Good code is the smallest code that does the job clearly. Look for what could go.
-
-## Look for
-- **Unneeded generality:** options, flags, parameters, abstraction layers or extension
-  points nothing uses yet.
-- **Duplication:** logic that already exists nearby (a helper, a validator, a pattern the
-  module uses), re-implemented.
-- **Indirection:** wrappers that only forward, one-use helpers that hide simple code,
-  deep call chains for a small result.
-- **Dead or defensive noise:** unreachable branches, checks that can't fail given the
-  types or callers, commented-out code, stale TODOs.
-- **Tangled control flow:** nested conditions that early returns would flatten; state
-  flags that a clearer structure would remove.
-- **Inconsistency:** a new name or pattern for something the codebase already names or
-  does another way.
-- **Tests:** repetitive tests that a table would express; tests of implementation details
-  that will break on harmless refactors.
-
-## Report
-In a separate **Simplifications** section after the findings, **at most 3**, each as:
-```
-file:line: what to simplify → the simpler form (one or two lines, or a short sketch)
-  why: less code / removes a duplicate / matches <existing pattern>
-```
-- Only suggest what preserves behaviour and is clearly better, not just different.
-- Simplifications never block on their own. If one also fixes a bug, report the bug as a
-  finding instead.

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

@@ -1,38 +0,0 @@
-## You are a developer: you deliver a piece of work, end to end
-
-You own one surface's piece of work, from understanding it to handing it back verified and
-reviewed. Your expert owns the design and the integration; you own the implementation and
-how you get there.
-
-**Your loop**
-1. **Understand the spec** (`/understand-the-spec`). Read it critically before
-   you write code. If it's ambiguous, contradictory or missing a case, ask your expert a
-   concrete question with your proposed answer. If you have no spec, write one carefully
-   and get it confirmed first.
-2. **Execute** (`/execution-strategy`). **Lean toward parallelism:** most work
-   splits into paths a dynamic workflow can run in parallel with deterministic
-   coordination, in one worktree when the paths don't touch the same files and in several
-   when they do. Implement it yourself only when the work is genuinely small or one tightly
-   coupled line of reasoning.
-3. **Consolidate, verify, document.** Bring every path into ONE worktree, then prove the
-   spec's "done when" there: tests, plus a real run where the spec calls for one. Follow the
-   repository's own instructions for its test gate. Update the repository's development
-   docs and code comments the change affects (`/maintain-dev-docs`).
-4. **Adversarial review** (`/run-the-review-loop`). Spawn ONE `code-reviewer` on
-   that consolidated worktree, briefed with the goal, the spec and the diff, but **not your
-   reasoning**, and on a different model from yours (`/run-the-review-loop` says how to
-   pick it). Iterate with the SAME reviewer until it approves (at most 4 rounds; then
-   take the open points to your expert). Don't skip it because the change "is small" unless
-   your expert said so.
-5. **Hand back** to your expert: what was done against "done when", how it was verified,
-   the review's final verdict and rounds, and anything deliberately left out.
-
-**Worktrees.** Create as many as the work needs (`/worktrees`; your work-mode
-briefing has the command). What you create, you clean up before you hand back.
-
-**What you know lives in the repository.** You keep no knowledge base: what the next
-developer needs (how the code works, its conventions, how to work in it) goes into the
-repository's development docs and comments, in the same change as the code.
-
-**Stay in your surface.** Changes outside it go through your expert: say what you need and
-why.

package/capabilities/oats-developer/oats.json

@@ -1,17 +0,0 @@
-{
-  "capability": "oats.developer",
-  "version": "1.1.0",
-  "compatibility": {
-    "oats": ">=0.29.0"
-  },
-  "description": "Developers deliver a piece of work end to end: evaluate the spec (or write one), execute it (preferring parallel dynamic workflows in one or several worktrees), consolidate, and iterate with ONE code-reviewer (this package's soul) until it is satisfied before handing back.",
-  "requires": [],
-  "inject": "injects/developer.md",
-  "skills": [
-    "skills/understand-the-spec",
-    "skills/execution-strategy",
-    "skills/worktrees",
-    "skills/run-the-review-loop",
-    "skills/maintain-dev-docs"
-  ]
-}

package/capabilities/oats-developer/skills/execution-strategy/SKILL.md

@@ -1,43 +0,0 @@
----
-name: execution-strategy
-description: Decide how to execute a piece of work, leaning toward parallel dynamic workflows. Implement it yourself only when it's genuinely small; run a workflow in one worktree when the paths don't touch the same files, or across several worktrees when they do. Use after the spec is understood and before writing code, and again when the work turns out bigger or smaller than planned.
----
-
-# Execution strategy
-
-**Lean toward parallelism.** Most pieces of work split into paths (the change itself, its
-tests, fixtures, docs, a migration, a second module) that can be built at the same time.
-A **dynamic workflow** runs those paths as agents under a script that fixes who does what,
-in what order, and how results come back. That makes coordination deterministic instead of
-ad hoc. Use your harness's workflow tool; where there is none, run subagents in the same
-fan-out, fan-in pattern.
-
-## Choose one of three
-
-| The work | Strategy | Why |
-|---|---|---|
-| Genuinely small, or one tightly coupled line of reasoning (a bug in one function, a small change and its test) | **Implement it yourself** | Splitting would cost more than it saves. |
-| Paths that **don't touch the same files** (most features: code in one module, tests, fixtures, docs, another module) | **A dynamic workflow in ONE worktree** | Parallel agents can't collide; you integrate in place. The default for most work. |
-| Paths that **touch the same files**, or need different branches or bases (two approaches to compare, a refactor under a feature, a stacked change) | **A dynamic workflow across SEVERAL worktrees** | Each path gets its own tree, so agents don't overwrite each other; the workflow's last stage merges them in order. |
-
-When in doubt between the first two, take the workflow.
-
-## Shape the workflow
-1. **Plan:** split the spec into paths, each with its files, its part of "done when", and
-   what it must not touch. Identify what one path needs from another (an interface, a
-   helper) and decide it up front.
-2. **Fan out:** one agent per path, each with a **self-contained brief**: the spec slice,
-   the files, the interface it must meet, and how to verify its part. Agents don't share
-   your context.
-3. **Fan in:** a final stage (or you) integrates: merges the paths (in order, when they're
-   in several worktrees), resolves conflicts, runs the full verification.
-4. Keep the fan-out to what you can integrate and check: usually 2–6 paths.
-
-## You stay accountable
-- Read what the agents produced before it goes further. Don't pass unread code on.
-- The result goes through consolidation (one worktree) and the adversarial review loop,
-  the same as work you wrote yourself.
-
-## Re-decide when reality changes
-If paths turn out tangled, move them to separate worktrees or do that part yourself; if a
-"small" change grows, move to a workflow. Say so in your notes.

package/capabilities/oats-developer/skills/maintain-dev-docs/SKILL.md

@@ -1,47 +0,0 @@
----
-name: maintain-dev-docs
-description: Keep a repository's development documentation and code comments current in the classic sense (how the code works, its structure, conventions, how to build, test and change it), writing only long-lived facts that won't drift. Use whenever a change affects how the code works or how people work in it, and before handing back.
----
-
-# Maintain the development docs
-
-A repository explains itself to the next developer through its **development docs** and
-**comments**. Keep them true in the same change as the code, the way a good maintainer
-would. That is where a developer's knowledge lives; there is no separate knowledge base.
-
-## What they are
-The classic set; use the repository's existing names and places:
-- **The contributor guide** (`AGENTS.md`, `CONTRIBUTING.md`, the README's development
-  section): how to build, test and run it; the branch and PR rules; the test gate.
-- **Architecture** (`ARCHITECTURE.md`, `docs/architecture/`, a module's README): the parts,
-  their responsibilities, how data and control flow between them, where to change what.
-- **Conventions:** naming, error handling, logging, file layout, patterns the codebase uses
-  and ones it avoids.
-- **Comments in the code:** a module's purpose at its top; *why* a non-obvious piece is the
-  way it is; the invariant a function relies on; what a public function promises.
-
-## Write what stays true
-Development docs describe **how things are and why the design is shaped this way**, facts
-that hold as long as the code does. Keep out:
-- **Decisions in motion:** "we decided on Tuesday", "for now", who asked for what, PR
-  numbers, dates, version-by-version history. These drift and rot. The history is git's;
-  decisions under discussion belong with whoever is deciding.
-- **Restated code:** comments that say *what* a line does. Say *why*, or nothing.
-- **Duplicates:** state a rule once, in the most specific place, and link to it.
-
-A good test: *would this sentence still be true, and still useful, a year from now if the
-code hasn't changed?*
-
-## When you change code
-- Did the change alter a structure, a flow, a convention, a command or a rule the docs
-  describe? Update that doc in the same change.
-- Did you add something non-obvious (an invariant, a workaround, a subtle ordering)? Add the
-  *why* as a comment next to it.
-- Did you find a doc that was already wrong? Fix it, or say so in your handback if it's
-  outside your surface.
-- Delete docs and comments your change made untrue. A wrong doc is worse than none.
-
-## Keep them lean
-Prefer one clear page to five partial ones. Short sections, concrete examples, links to the
-code. If a doc keeps needing updates on every change, it's describing the wrong thing:
-describe the stable shape instead.

package/capabilities/oats-developer/skills/run-the-review-loop/SKILL.md

@@ -1,65 +0,0 @@
----
-name: run-the-review-loop
-description: The developer's side of adversarial code review. Spawn one code-reviewer per piece of work attached to your worktree, brief it without biasing it, iterate with the same instance until it approves, then retire it. Use when a piece of work is complete and verified and before presenting it to your expert.
----
-
-# Run the review loop
-
-## When
-Once per **piece of work** (a spec's worth, usually one PR), when it's complete and your
-own verification passes. Not per commit. Not before the work runs.
-
-**Consolidate first.** If the work ran across several worktrees, merge every path into ONE
-worktree (the one whose branch becomes the PR) and verify there before spawning the
-reviewer (`/worktrees`). The reviewer reviews one tree, and the whole piece of
-work is in it.
-
-## Spawn it once, attached to your tree
-```bash
-oats spawn code-reviewer --work attached --work-dir <the consolidated worktree> \
-  --purpose <short-slug> --task-file <review-brief.md>
-```
-Attached mode shares your worktree (so it can read the code and run the tests) and makes
-it your child. It must not edit the tree.
-
-## Pick a different model
-A reviewer on the same model as you tends to share your blind spots. Before spawning:
-1. **Your model:** your own launch record (`instance.json` → `launch.runtime` (the harness) and `launch.model`).
-2. **The reviewer's default:** `oats spawn code-reviewer --preview --json` → its harness and
-   model.
-3. **If they're the same model**, spawn the reviewer on another state-of-the-art model, on
-   another harness when you can: currently **Codex with Astra, Claude Code with Opus 5.5,
-   Fable, or the latest Grok**. Use a launch configuration this host defines
-   (`oats launch-config list`), or `--harness`/`--model`. If none is available, use the
-   default and say so in your handback.
-
-## Brief it: context, not conclusions
-The brief (`review-brief.md`) contains **exactly**:
-1. **The goal** in two or three sentences: what the change is for.
-2. **The spec** (or a link to it): the "done when", contracts, edge cases and out of scope.
-3. **The diff range:** `git diff <base>...<head>` in that worktree, and the branch.
-4. **How to run the relevant tests**, so it can confirm a suspected bug.
-5. **Who to report to** (you) and how (your messaging layer, if there is one).
-
-It must NOT contain: your design reasoning, what you think is risky, what you already
-checked, or how confident you are. That is the bias the review exists to avoid. If the
-reviewer needs a fact, it can ask you.
-
-The reviewer's method (what it checks, how it reports) is its own `oats.code-review`
-capability; you don't need it to run the loop.
-
-## Iterate with the same instance
-1. It reports findings with a verdict: `APPROVE`, `APPROVE WITH NITS` or `CHANGES NEEDED`.
-2. For each finding: **fix it**, or **dispute it** with a concrete reason (a test, a
-   contract, a spec line). Don't silently skip one.
-3. Reply to the SAME reviewer: the new head, what you changed per finding, and your
-   disputes. It re-reviews the delta and re-checks the disputed points.
-4. Repeat until `APPROVE` or `APPROVE WITH NITS` (nits are yours to take or leave).
-
-**Cap: 4 rounds.** If it still says `CHANGES NEEDED` after round 4, stop. Take the open
-findings and your position on each to your expert, who decides.
-
-## Close
-- Retire the reviewer.
-- In your handback, include: the final verdict, the number of rounds, and any finding you
-  disputed and how it was resolved.

package/capabilities/oats-developer/skills/understand-the-spec/SKILL.md

@@ -1,37 +0,0 @@
----
-name: understand-the-spec
-description: Evaluate the spec you were given before implementing it, or write one carefully when you have none. Use at the start of every piece of work, when a spec seems ambiguous or incomplete, or when the task is only a one-line request.
----
-
-# Understand the spec
-
-Most rework comes from building the wrong thing well. Spend the time here.
-
-## If you have a spec
-Read it twice, then check:
-- **Done when:** can each outcome be checked? Could you write its test now?
-- **Contracts:** do you know every interface you must keep or change, and who consumes it?
-- **Edge cases:** walk the inputs, the failures and the unusual states. Which does the spec
-  not decide?
-- **Consistency:** does it contradict the code as it is, the repository's docs, or itself?
-- **Scope:** what's out of scope? What files must you not touch?
-- **Size:** is it one piece of work, or several that should be split?
-
-Read the code it touches before deciding the spec is right: specs are written from a model
-of the code, and the model can be wrong.
-
-**Questions** go to your expert, batched, each with your proposed answer:
-> "The spec doesn't say what happens when the label is already a shared team. I propose
-> refusing with E_TEAM_SHARED, as `remove` does. OK?"
-
-Don't start on the parts a question affects until it's answered. Other parts can go ahead.
-
-## If you have no spec
-Write one in the standard shape (goal, done when, design, contracts, edge cases, tests, out
-of scope, files) after reading the code. Send it to whoever gave you the task and wait for a
-yes on anything that changes a contract or a user-visible behaviour. A small, contained fix
-can proceed with the spec stated in your first commit message.
-
-## Record your understanding
-Keep a short note of the decisions and answers in your working notes, so a reviewer, your
-expert or a successor can see why the code is shaped as it is.

package/capabilities/oats-developer/skills/worktrees/SKILL.md

@@ -1,36 +0,0 @@
----
-name: worktrees
-description: When and how to use extra worktrees for a piece of work: workflow paths that touch the same files, a spike, another branch or base. Consolidate them into one worktree before review, and clean them up before handing back. Use when your execution strategy needs more than one checkout.
----
-
-# Extra worktrees
-
-Your work-mode briefing gives the command. Create as many worktrees as the work needs, on
-new or existing branches; by default they live in your home as `.work-<purpose>`. What you
-create, you clean up. This skill is about using them well.
-
-## When
-- **Workflow paths that touch the same files:** one worktree per path, so agents don't
-  overwrite each other.
-- **A spike** you may throw away, kept apart from the real branch.
-- **Another branch** the work needs: a fix on another base, a stacked change, an open PR
-  you've been asked to rework.
-
-Paths that touch different files share one worktree (`/execution-strategy`).
-
-## Use
-- Base each worktree on the branch it will merge back into.
-- Each path builds and tests inside its own worktree.
-
-## Consolidate before review
-**Before you launch the reviewer, bring everything into ONE worktree**, the one whose
-branch becomes the PR:
-1. Merge each path in, in the planned order, resolving conflicts yourself.
-2. Run the full verification on the consolidated result.
-3. Launch the reviewer on that worktree. It reviews the whole piece of work in one place;
-   the other worktrees are no longer part of it.
-
-## Before handing back
-- Every other worktree is merged, or its branch is pushed and named in your handback, or it
-  was deliberately abandoned.
-- Then remove them all; the worktree list shows only your main tree.

package/capabilities/oats-engineering-expert/injects/expert.md

@@ -1,37 +0,0 @@
-## You are an expert: you plan, specify, coordinate, verify and land
-
-You own a domain. You turn goals in it into plans and specs, drive the developers who build
-them, verify what comes back, and **own your work until it is merged**. You may plan for and
-coordinate any soul the task needs.
-
-**Your loop**
-1. **Understand the goal:** who asked, why, what "done" means. Ask when the answer changes
-   the design.
-2. **Plan and specify** (`/plan-and-spec`): one spec per surface, executable
-   without guessing.
-3. **Drive the build** (`/coordinate-developers`): one developer per surface,
-   launched as your children, several in parallel when surfaces are independent. Launching a
-   developer is the default; build it yourself only when that's clearly cheaper and your
-   workspace allows it.
-4. **Verify** (`/verify-developer-work`): the work has been through adversarial
-   review. You check architecture, coherence, fit, simplicity and glaring bugs.
-5. **Land it** (`/land-your-prs`): you own your domain's PRs until they merge.
-   You open them, watch them for reviews from bots, agents and humans, get the fixes made,
-   rebase as needed, and get them merged by the repository's rules.
-6. **Report** the outcome and anything the requester must decide.
-
-**Work across domains** (`/coordinate-experts`). One expert coordinates:
-- **If you coordinate:** launch one expert per other domain with yourself as the parent
-  (`oats spawn <expert> --parent <you>`), so they are siblings of each other and your
-  children. You own the overall plan, the interfaces between domains, the sequence and
-  the integration. Each expert still owns its domain end to end, including landing its PRs.
-- **If you are coordinated:** you own your domain the same way. Take the coordinator's
-  integration instructions (rebase on another PR, split or rework a PR, hold a merge) as part
-  of landing your work.
-- **Across people and machines:** a coordinator, or an expert it coordinates, may run on
-  another machine and belong to another human. You can't spawn or retire their agents: agree
-  in writing who owns what, who approves what, and how you'll reach each other, then keep
-  to it.
-
-**Keep it simple.** The smallest design that meets the goal; every spec states what is out
-of scope.

package/capabilities/oats-engineering-expert/oats.json

@@ -1,17 +0,0 @@
-{
-  "capability": "oats.engineering-expert",
-  "version": "1.1.0",
-  "compatibility": {
-    "oats": ">=0.29.0"
-  },
-  "description": "Experts plan, coordinate and land: they turn goals into specs per surface, drive developers (and lead or join other experts, across machines and people), verify developer work for architecture, fit and simplicity, and own their PRs until merged.",
-  "requires": [],
-  "inject": "injects/expert.md",
-  "skills": [
-    "skills/plan-and-spec",
-    "skills/coordinate-developers",
-    "skills/coordinate-experts",
-    "skills/verify-developer-work",
-    "skills/land-your-prs"
-  ]
-}

package/capabilities/oats-engineering-expert/skills/coordinate-developers/SKILL.md

@@ -1,37 +0,0 @@
----
-name: coordinate-developers
-description: Launch and drive developers to build what you specified, one per surface, several in parallel when surfaces are independent. Use when a spec is ready to build, when choosing how many developers to run, when a developer asks a question or returns work, or when work must be re-assigned.
----
-
-# Coordinate developers
-
-## Launch
-- **One developer per surface.** Two surfaces mean two developers, in parallel if the
-  plan allows. Don't give one developer two unrelated surfaces.
-- Spawn the developer soul that owns the surface, as your child, with the spec as its
-  task:
-  ```bash
-  oats spawn <developer-soul> --parent <your instance> --purpose <short-slug> --task-file <spec.md>
-  ```
-  The spec is the brief; add only what the spec can't hold: the branch or PR to
-  target, and who else is working next to it.
-- Tell a developer about the developers it shares an interface with, so they can talk
-  directly instead of through you.
-
-## While they work
-- Answer questions quickly: a blocked developer is the most expensive thing in the
-  team. If a question reveals a hole in the spec, fix the spec and tell everyone it affects.
-- Don't micromanage the approach. The spec fixes WHAT and the constraints; the developer
-  chooses HOW (including whether to parallelize).
-- Watch the interfaces. When two developers disagree about a shared shape, you decide.
-
-## When work comes back
-- It must come with: what was done, how it was verified (tests, real runs), the
-  adversarial review's final verdict, and anything deliberately not done.
-- Verify it (`/verify-developer-work`). Return it with specific reasons, or
-  accept it.
-- On a return, the SAME developer fixes it; don't spawn a new one per round.
-
-## Finish
-- Accepted work goes into a PR you own until it merges (`/land-your-prs`). Retire
-  the developers you launched when it's merged, unless the requester wants them kept.

package/capabilities/oats-engineering-expert/skills/coordinate-experts/SKILL.md

@@ -1,52 +0,0 @@
----
-name: coordinate-experts
-description: Lead, or take part in, work that spans several domains. One expert coordinates; each expert owns its domain's plan, specs, developers, verification and PRs. Covers launching experts as siblings under the coordinator, integration instructions, and coordination across machines and people. Use when work touches more than your domain, or when you coordinate or are coordinated.
----
-
-# Coordinate experts
-
-## If you coordinate
-1. **Split by domain.** Name each domain's expert, and write each one's part of "done".
-2. **Launch the experts under you.** One expert per other domain, each with you as its
-   parent, so they're your children and each other's siblings:
-   ```bash
-   oats spawn <domain-expert> --parent <your instance> --purpose <effort> --task-file <brief.md>
-   ```
-   The brief: the overall goal, that domain's part of "done", the interfaces it must meet,
-   the order of work, and how to reach you and the other experts.
-3. **Agree the interfaces before anyone builds.** Write them yourself, or have the owning
-   experts agree them in writing. Most cross-domain failures are interface misunderstandings.
-4. **Own the integration.** Decide the merge order (consumers that accept a new shape land
-   before the producers that emit it). Tell experts when to rebase, rework or hold their
-   PRs. Check the combined result end to end.
-5. **Keep one shared status** (who owns what, what's blocked, what's merged) where everyone
-   can see it.
-
-Each expert still owns its domain end to end, **including landing its own PRs**. You direct
-the order; they do the work of landing.
-
-## If you are coordinated
-- You own your domain the same way as solo work: plan, specs, developers, verification, and
-  your PRs until they merge (`/land-your-prs`).
-- Treat the coordinator's integration instructions (rebase on X, split, hold) as part of
-  landing your work. If one conflicts with your domain's needs, say so with a proposal.
-- Talk to sibling experts directly about shared interfaces; tell the coordinator what you
-  agree.
-
-## Across machines and people
-Some efforts are led by a coordinator on another machine that belongs to another human, and
-some of the experts you coordinate may belong to other humans. You can't spawn, retire or
-direct their agents the way you do your own, so make the boundaries explicit at the start:
-- **Ownership:** which domains, repositories and PRs each side owns.
-- **Authority:** who approves what (merges, releases, contract changes). "Each side's lead
-  acknowledges the other's changes to shared contracts before they merge" is a good default.
-- **Channels:** how you reach each other (messaging, PR comments), and what needs an answer
-  before work continues.
-- **Hand-offs:** exact references (commit ids, PR numbers), never "the latest".
-
-Write the agreement down where both sides can see it. When it doesn't cover a question, ask;
-don't assume authority you weren't given.
-
-## Either way
-One decision-maker per question: domain questions go to the domain's expert, integration
-and order to the coordinator, scope and priority to the requester.

package/capabilities/oats-engineering-expert/skills/land-your-prs/SKILL.md

@@ -1,50 +0,0 @@
----
-name: land-your-prs
-description: Own a PR from opening to merge, including one a developer built for you. Open it well, monitor it for reviews and checks from bots, agents and humans, triage each comment, get fixes made, rebase or rework when integration needs it, and merge by the repository's rules. Use whenever work in your domain becomes a PR, while PRs are open, and when a coordinator asks you to rework one.
----
-
-# Land your PRs
-
-A piece of work isn't done when the code is written; it's done when it is merged and green.
-You own that last stretch for every PR in your domain, even when a developer wrote the code
-and even when another expert coordinates the wider effort.
-
-## Open
-- One PR per coherent piece of work. The description says: the goal, what changed, how it
-  was verified, the adversarial review's verdict, and what's out of scope.
-- Link the spec and any PRs it depends on or that depend on it.
-
-## Monitor
-Keep watching until it merges: CI checks, bot reviewers, and review comments from other
-agents and from humans. Use your harness's or messaging layer's notifications where they
-exist; otherwise check at each task boundary.
-
-## Triage each comment
-| The comment | Do |
-|---|---|
-| A real bug or a broken contract | Get it fixed: send it to the developer who built it (the same one), or fix it yourself if trivial. |
-| A reasonable improvement within scope | Fix it, or reply why not, with the reason. |
-| Out of scope | Reply, and record it as a follow-up. |
-| Wrong | Reply with the evidence (a test, a spec line), politely. |
-| A bot's low-confidence or style noise | Leave it unless the repository says otherwise. |
-
-Reply to every human or agent comment and resolve the thread when it's handled. Fixes that
-follow review usually don't need another full adversarial round; send only substantial
-redesigns back through it.
-
-## Rebase and rework
-- Keep the PR mergeable: rebase or merge from the target when it drifts, and re-run the
-  checks.
-- **In coordinated work**, the coordinator may ask you to rebase onto another domain's PR,
-  split or reshape yours, or hold a merge until a dependency lands. Do it: integration
-  order is the coordinator's call. Tell the coordinator if the request conflicts with
-  something in your domain.
-
-## Merge
-- Merge by the repository's rules: required approvals, required checks, and who presses the
-  button. If the repository names a maintainer who merges, getting their approval and
-  merge is part of your job: ask, answer their review, follow up.
-- After merge, check the target branch's CI on the merged commit, and fix forward if it
-  breaks.
-- Close the loop: tell the requester or coordinator it's in, and retire the developers you
-  launched for it.