Merge branch 'master' of github.com:Dark-Alex-17/coyote.wiki

2026-07-23 12:36:30 -06:00
2 changed files with 15 additions and 5 deletions
+12 -3
@@ -823,6 +823,14 @@ available; only the auto-injected prompt text is suppressed.
# Built-In Agents
Coyote comes packaged with some useful built-in agents:
* `adversary`: An adversarial plan-conformance reviewer. Where `code-reviewer` asks "is this code good?",
`adversary` asks "is this the code the plan asked for — all of it, and only it?". Given a diff plus the
task/plan's acceptance criteria, it maps every criterion to evidence in the diff and hunts for silently
skipped criteria, scope drift, interface substitution, and requirements that never landed ("the dog that
didn't bark"), returning a blocking `ADVERSARIAL_REVIEW: CONFORMS`/`DIVERGES` verdict (via the
`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).
* `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,9 +846,10 @@ Coyote comes packaged with some useful built-in agents:
* `report-writer`: An agent to polish research findings into clear, citation-preserving final reports
* `sisyphus`: A powerhouse orchestrator agent for writing complex code and acting as a natural language interface for
your codebase (similar to ClaudeCode, Gemini CLI, Codex, or OpenCode). Uses sub-agent spawning to delegate to
`explore`, `librarian`, `coder`, `oracle`, and `step-runner`. Also supports plan-driven workflows: authoring phased
implementation plans (via the `plan-authoring` skill), having `oracle` review them, and executing them one reviewed
step at a time.
`explore`, `librarian`, `coder`, `oracle`, `code-reviewer`, `adversary`, and `step-runner`. On non-trivial work it
runs two complementary independent review passes — `code-reviewer` for code quality and `adversary` for plan
conformance. Also supports plan-driven workflows: authoring phased implementation plans (via the `plan-authoring`
skill), having `oracle` review them, and executing them one reviewed step at a time.
* `sql`: A universal SQL agent that enables you to talk to any relational database in natural language
* `step-runner`: A graph-based agent that executes ONE step of a phased implementation plan (a `plans/` repo authored
with the `plan-authoring` skill) with the step protocol enforced as graph edges: orient from the previous handoff ->
+3 -2
@@ -378,7 +378,7 @@ whitelist — but their processes stay cached for fast re-load.
# Built-in Skills
Coyote ships with fourteen built-in skills, installed automatically on first run:
Coyote ships with fifteen built-in skills, installed automatically on first run:
| Skill | Granted tools / MCP servers | Purpose |
|-----------------------|--------------------------------------------------------------------------|------------------------------------------------------------------------------|
@@ -393,6 +393,7 @@ Coyote ships with fourteen built-in skills, installed automatically on first run
| `verification-gates` | `execute_command` | Evidence requirements (diagnostics, builds, tests) before claiming completion. |
| `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`. |
| `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. |
@@ -450,4 +451,4 @@ When skills are enabled, the model has three tools available for managing them i
These are how the model discovers and uses skills mid-conversation. You can disable this discovery channel by setting
`skills_enabled: false` at any level; the three tools then disappear from the model's function list entirely. The same
happens if `function_calling_support: false` is set globally. Without function calling, the skill system has no surface
to operate on, so it is silently disabled across REPL, CLI, agents, and the model's tool list.
to operate on, so it is silently disabled across REPL, CLI, agents, and the model's tool list.