From a40c055cc4c3e7fbf391c77ffbe6c28d4b233edb Mon Sep 17 00:00:00 2001 From: Alex Clarke Date: Wed, 29 Jul 2026 11:26:55 -0600 Subject: [PATCH] docs: Documented new agents and skills --- Agents.md | 14 ++++++++++++++ Skills.md | 5 ++++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/Agents.md b/Agents.md index debdf13..f524cb3 100644 --- a/Agents.md +++ b/Agents.md @@ -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. diff --git a/Skills.md b/Skills.md index 9c7d0e2..58e24a4 100644 --- a/Skills.md +++ b/Skills.md @@ -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. |