Skip to main content

Winnow

Winnow questions a codebase without changing it. Before decomposition, one typed direction turn cautiously translates the user's custom review instructions into optional user-level directions for downstream tasks. The fixed system prompts never change. This keeps a request aimed at one subsystem focused there through scouting, allocation, review, and synthesis without promoting generated text into higher-priority instructions. A deterministic inventory then gives an agent-led splitter safe orientation, the splitter chooses semantic subsystems, one scout for every inventory shard supplies concrete leads to a separate allocator, and independent rubric and freeform reviewers investigate the allocation in parallel. One clean final turn reconciles both evidence streams. Codex remains the default, while any role can instead use Claude Code or Grok Build.

Standard review remains the default. --mode cross-check instead makes every subsystem reviewer compare material abstractions and implementation decisions with high-quality production code under comparable constraints. Cross-checking treats uncommon and wrong as separate conclusions, uses check-normal when the provider exposes it, and preserves constraint differences and insufficient evidence through synthesis. It changes the agents' investigative prompts, not the full report structure or output contract.

Every Codex thread is ephemeral, denies approval requests, and runs with full local filesystem and network access instead of a Winnow sandbox. Reviews remain read-only by instruction. Codex's native web search runs in live mode. Skills are disabled in standard mode; cross-check mode exposes them only to rubric and freeform reviewers so they can use check-normal. Plugins, Codex Apps, login shells, non-core shell environment variables, and configured ambient MCP servers remain disabled on every turn.

Claude Code runs in safe, non-persistent print mode with Read, Grep, Glob, WebSearch, and WebFetch. Grok Build runs standalone without an OS sandbox and exposes read_file, grep, list_dir, web_search, and web_fetch; shell, editing, MCP, memory, and subagents remain disabled for both external providers. Grok Build currently retains its own headless session history under ~/.grok/sessions; Winnow never resumes those sessions. See the official Claude Code CLI reference and Grok Build headless reference for their underlying CLI contracts.

Setup

Winnow requires Python 3.11+, Git, and an authenticated CLI for every provider selected by the run.

Install the CLI and its optional global Codex skill:

uv tool install winnow-review
winnow install-skill
winnow --help

The installer writes ~/.codex/skills/winnow/SKILL.md. It is safe to rerun and preserves a different existing skill unless --force is explicit.

For development from a source checkout:

codex login
codex login status
# Run `claude auth login` when selecting Claude Code.
# Run `grok login` when selecting Grok Build.
uv sync
mkdir -p ~/.config/winnow
chmod 700 ~/.config/winnow

Create ~/.config/winnow/config.toml and keep it private:

provider = "codex"

# Cost and concurrency bounds.
max_work_items = 8
max_concurrency = 4

# Provider defaults are Codex Terra/xhigh, Claude Fable 5/high, and Grok 4.5/high.
# Set either value only to override those defaults for the whole run.
# model = "gpt-5.6-sol"
# effort = "high"

# Optional: route materially different roles to different providers.
# [role_providers]
# customize = "codex"
# decompose = "codex"
# scout = "codex"
# allocate = "claude-code"
# rubric = "claude-code"
# freeform = "grok-build"
# synthesize = "codex"

# Optional: model names are interpreted by each role's selected provider.
# [role_models]
# customize = "gpt-5.6-sol"
# allocate = "claude-fable-5"
# rubric = "claude-fable-5"
# freeform = "grok-4.5"
chmod 600 ~/.config/winnow/config.toml
uv run winnow run "Review the async boundaries" /path/to/git/repository --output review.md
# Or make production normality the primary review lens:
uv run winnow run "Review the async boundaries" . --mode cross-check
# Or force one provider for the whole run; its Winnow defaults apply:
uv run winnow run "Review the async boundaries" . --provider claude-code

Each adapter delegates authentication to its provider CLI; Winnow does not ask for or copy model-provider credentials. Output goes to stdout unless --output is supplied. --mode standard keeps the ordinary broad review and is the default; --mode cross-check makes production normality the primary subsystem lens. Use --workers N to override the configured worker count for one run. Role providers fall back to provider; role models fall back to model, then Winnow's default for the selected provider. An explicit effort overrides the provider-specific effort default for every role. --provider forces one provider for the run; pair it with --model when overriding the model too. For mixed-provider runs, configure model names under [role_models] because model identifiers are provider-specific.

Run uv run winnow (or uv run winnow dashboard) in another terminal to watch every run. Each winnow run stays in its foreground terminal, while an atomic record under ~/.local/state/winnow/runs lets the dashboard show concurrent runs, their prompts, current steps, and progress. Agent decomposition and scout-backed allocation each advance one stage, parallel work items fill the third stage as they finish, and synthesis completes the fourth.

Use uv run winnow path RUN_ID to print the absolute report path recorded for a run, including while that run is still active and the report file does not exist yet.

Use uv run winnow transcript RUN_ID for a polished human view that follows an active run, renders newly completed turns into terminal scrollback, keeps live progress at the bottom, and exits when the run finishes. Agents should use uv run winnow transcript RUN_ID --agent to receive the current original Markdown immediately without rendering or watching. Transcripts include developer instructions, prompts, SDK-visible activity, and responses. Runs created by older Winnow versions have no recoverable transcript.

Use uv run winnow report RUN_ID for the same polished live status and Markdown rendering around the final report. Agents should use uv run winnow report RUN_ID --agent for raw Markdown. Every new run persists its report by ID even when --output is omitted; --output remains an optional additional destination.

Every role can use its selected provider's native web search, but no MCP server is enabled. Each role's prompt ties research to its own decision: scope, questions, allocation, review evidence, or final verification. Agents never include source code, file contents, secrets, or non-public repository details in search queries.

What runs

  1. customize receives the user's request and the exact fixed system prompts for decomposition, scouting, allocation, both reviewer modes, and synthesis as read-only role descriptions. With the selected provider's reasoning effort, it returns a strict Pydantic object containing one optional user-level task direction per role. An empty direction preserves that role's task prompt exactly; a direction is justified only by a concrete scope, priority, exclusion, or role-specific interpretation that the existing prompt does not express. The fixed system prompts are never modified.
  2. decompose asks Git for a bounded inventory, then gives that seed, the invoked repository-relative scope, and its generated direction to a splitting agent instructed not to modify the repository. The agent inspects the repository and splits a whole codebase into semantic subsystems, or treats an explicitly requested subsystem as the target and divides it into smaller parts.
  3. plan preserves one directed scout per deterministic inventory shard. A separate directed allocation turn combines every scout's questions with the semantic subsystem plan and covers each subsystem with balanced rubric and freeform assignments plus deliberate overlaps.
  4. execute fans out one independent provider turn per directed assignment, each instructed not to modify the repository. Half apply the complete production rubric and check-normal evidence process. Half retain Winnow's existing open professional review. In cross-check mode, both lanes make production normality core work for every subsystem, use the check-normal skill when available, and compare only production examples with relevant constraints. With an odd worker bound, the extra worker is freeform; a bound of one keeps the original freeform lane.
  5. synthesize gives the subsystem plan, role-labelled assignments, selected providers and models, unchanged WorkResult records, and the generated reporting direction to one clean provider turn. It collapses repeated mechanisms, preserves disagreements and coverage gaps, and emits the most actionable Markdown report first. Cross-check mode returns the same full report with the same structure and finding standard; its prompts preserve normal, context-dependent, out-of-the-ordinary, and insufficient-evidence verdicts without treating rarity as severity.

The allocation—not peer findings—is shared with workers. This keeps the two review modes independent and leaves cross-agent reconciliation to the synthesis stage. Every downstream review turn receives guidance to start from the charitable prior that the author is a highly capable programmer, reconstruct the strongest coherent rationale, and then try to falsify it against actual behavior. This is agent guidance, not a deterministic intent mechanism; it cannot excuse a demonstrated gap or turn inferred intent into fact. Each turn is also told the exact target path, that it is working locally on the user's machine, and which provider-specific read-only instructions and tool restrictions apply.

Development

Review standards are documented in Repository guidance and engineering practice, with testing details in Test quality and suite stewardship.

uv run ruff check .
uv run pytest

Metadata

Release files for winnow-review 0.1.5

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for winnow-review 0.1.5
File Size Uploaded Provenance Actions
winnow_review-0.1.5.tar.gz 42.4 kB With provenance Details for winnow_review-0.1.5.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for winnow-review 0.1.5
File Interpreter ABI Platform Actions
winnow_review-0.1.5-py3-none-any.whl Python 3 none any Details for winnow_review-0.1.5-py3-none-any.whl

Total release size: 91.5 kB

Release files / winnow_review-0.1.5.tar.gz

Download URL winnow_review-0.1.5.tar.gz
Size 42.4 kB
Tags Source
SHA-256 checksum
How to use checksums
6e7621df802ef4dbdba4ec61d2d6be7530cffa5e5ed14b76a069ef744548cd13
BLAKE2b-256 checksum
How to use checksums
67123b13bd59c7b002a940ae80a549407dd373d3bc3d090150a1c702b5230c75
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 17, 2026.

Transparency log

Release files / winnow_review-0.1.5-py3-none-any.whl

Download URL winnow_review-0.1.5-py3-none-any.whl
Size 49.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
a64d6a9b3a0b59db43230c3fa0730103819e4c18dce78bc1e2bfa5daf905dc7e
BLAKE2b-256 checksum
How to use checksums
c97a7ebe1107d9a5ff624aa1f6fd5165d3190661038f4d73a56d58005faa6cb5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 17, 2026.

Transparency log

Security for winnow-review 0.1.5

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for winnow_review-0.1.5.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 17, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page