Dark-Alex-17/coyote
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

docs: Documented new agents and skills

Dark-Alex-17
2026-07-29 11:26:55 -06:00
parent 7a1b77892a
commit a40c055cc4
2 changed files with 18 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Agents.md
+14
@@ -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.
Skills.md
+4 -1
@@ -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. |