peer_plan
Route an implementation planning request with goals, affected modules, and constraints to the optimal peer model for review and collaborative design.
Instructions
Before calling: read relevant source files and attach full contents via files. Pass complete diffs/logs — never prose summaries. Set task with goals, affected behavior, and specific concerns. Route an implementation planning request to the best peer model(s).
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Required. Goal, success criteria, affected modules, and what 'done' looks like. | |
| repo_path | Yes | Absolute path to the repository root the peer should work in (e.g. /home/user/my-app). | |
| constraints | No | Hard limits: API compatibility, performance budgets, forbidden approaches, deadlines, out-of-scope. | |
| repo_summary | No | How the repo is structured today — key modules, patterns, and entry points relevant to this task. | |
| risk_level | No | Use high for auth, payments, migrations, concurrency, and public API changes. | |
| complexity | No | complex when the change spans multiple modules, data paths, or deployment steps. | |
| files | No | Changed source files and binary attachments (screenshots, PDFs). Use correct file extensions for images/PDFs and pass base64 or data-URI content. | |
| idempotency_key | Yes | Stable key for this operation (e.g. review-auth-jwt-1). Reuse the same key when retrying after timeout. |