docs: Documented new agents and skills

2026-07-29 11:26:55 -06:00
parent 7a1b77892a
commit a40c055cc4
2 changed files with 18 additions and 1 deletions
@@ -831,6 +831,13 @@ Coyote comes packaged with some useful built-in agents:
   `adversarial-review` skill). The post-implementation counterpart to `oracle`'s pre-implementation
   `plan-review`. Designed to be delegated to by `sisyphus` alongside `code-reviewer` (they cover different
   failure modes: quality vs. conformance).
 * `architect`: A design-doc orchestrator for large-scale implementation jobs. Consumes a high-level design
   doc, decomposes it into a quality-gated plan (`gatekeeper` self-containedness gate + `oracle`
   plan-review) and ~1-engineer-day task files (via the `design-session` and `task-tracking` skills,
   tracked on disk in a `plans/` directory), spawns one `sisyphus` per task on a single run branch with a
   per-task `adversary` conformance check, and finishes with ONE draft PR — CI checks watched to green —
   plus follow-up task files for every manual action the code can't do for itself. Supports opt-in
   worktree-based parallel task execution.
 * `coder`: An agent to assist you with all your coding tasks
 * `code-reviewer`: A [CodeRabbit](https://coderabbit.ai)-style code reviewer that spawns per-file reviewers using the 
   teammate messaging pattern
@@ -838,6 +845,13 @@ Coyote comes packaged with some useful built-in agents:
 * `deep-research`: A graph-based agent designed to perform deep web research 
 * `explore`: An agent designed to help you explore and understand your codebase
 * `file-reviewer`: An agent designed to perform code-review on a single file (used by the `code-reviewer` agent)
 * `gatekeeper`: A plan self-containedness gate (via the `plan-gatekeeping` skill). Audits a plan against
   the "sealed container" standard — every question a context-free implementer will hit is either answered
   inline or delegated via a VERIFIED pointer to the exact code/docs that answer it (where infra code goes,
   what DB tech, which layout to mirror, exact test commands) — and returns a blocking
   `PLAN_GATE: SEALED`/`LEAKY` verdict with the missing questions. The pre-implementation context
   counterpart to `plan-review` (executability) and `adversary` (post-implementation conformance).
   Designed to be delegated to by `architect`.
 * `librarian`: A graph-based agent that researches external references. It finds official docs, production OSS examples, 
   and web best practices. The "external grep" sibling of `explore` (which handles internal/codebase grep). Designed to 
   be delegated to by `sisyphus` whenever an unfamiliar library, API, or framework is involved.
@@ -378,7 +378,7 @@ whitelist — but their processes stay cached for fast re-load.
 # Built-in Skills
-Coyote ships with fifteen built-in skills, installed automatically on first run:
+Coyote ships with eighteen built-in skills, installed automatically on first run:
 | Skill                 | Granted tools / MCP servers                                              | Purpose                                                                     |
 |-----------------------|--------------------------------------------------------------------------|------------------------------------------------------------------------------|
@@ -394,6 +394,9 @@ Coyote ships with fifteen built-in skills, installed automatically on first run:
 | `plan-authoring`      | `fs_read, fs_grep, fs_glob, fs_ls, fs_cat, fs_write`                     | Author executable high-level plans and per-step implementation plans for phased work; defines the plan repo layout and step-plan schema. |
 | `plan-review`         | `fs_read, fs_grep, fs_glob, fs_ls, fs_cat`                               | Adversarial review of implementation plans against executability, verifiability, and completeness standards. |
 | `adversarial-review`  | `fs_read, fs_grep, fs_glob, fs_cat, fs_ls`                               | Adversarial plan-conformance review of an *implementation* against the plan it should satisfy (skipped criteria, scope drift, interface substitution); verdict `CONFORMS`/`DIVERGES`. Complements `code-review` (quality) and is the post-implementation counterpart to `plan-review`. |
 | `plan-gatekeeping`    | `fs_read, fs_grep, fs_glob, fs_cat, fs_ls`                               | Gatekeep a plan for *self-containedness* before finalization: the "sealed container" test — every implementer question answered inline or via a verified pointer; verdict `PLAN_GATE: SEALED`/`LEAKY` with the missing questions. |
 | `design-session`      | `fs_read, fs_grep, fs_glob, fs_ls, fs_cat, fs_write`                     | AI-first design decomposition: ground a design doc in the actual codebase, produce a PLAN file with approach, alternatives, and a ~1-engineer-day task breakdown with measurable acceptance criteria. |
 | `task-tracking`       | `fs_read, fs_grep, fs_glob, fs_ls, fs_cat, fs_write, fs_patch, fs_mkdir` | File-based task tracking for plan-driven runs: TASK-NNN directory schema (`index.md` + append-only `log.md`), frontmatter lifecycle, numbering, follow-up tasks, and end-of-run consistency checks. |
 | `step-implementation` | `execute_command`                                                        | End-to-end protocol for executing one step of a phased implementation plan. |
 | `handoff-protocol`    | `fs_read, fs_cat, fs_ls, fs_write`                                       | Schema and discipline for writing and reading step handoff documents between implementation steps. |
 | `iwe-knowledge-base`  | MCP server: `iwe`                                                        | Navigate and curate large markdown knowledgebases (plans, specs, notes) via [IWE](https://github.com/iwe-org/iwe) graph tools. Requires the `iwec` binary. |