Work / wine-harness
wine-harness: /wine — Claude Code harness: one model plans, another builds
A harness skill that splits a task in two: one model plans it, another builds it.
Source on GitHub ↗ · Need one like it? →
How does it work?
A harness skill that splits a task in two: one model plans it, another builds it.
Planning and execution reward different things. Planning is exploratory — it wants breadth, cheap tokens, and permission to be wrong on the way to being right. Execution wants depth, care, and a model you trust with production code. Most agent setups use a single model for both and overpay for one half while underserving the other.
/wine separates them.
/wine add rate limiting to the public API
/wine --ultra migrate the billing service to a new payment provider
/wine --max fix the flaky auth integration testHow it works
Triage. The execution model sizes up the goal and picks a planning depth — one planner for bounded work, a parallel fan-out for anything broad or cross-cutting. Flags override the call when you already know which you want.
Plan. A fast planning model investigates the real codebase and writes the plan to disk as Markdown: a brief, research findings with concrete file paths, a phased task breakdown, one self-contained prompt per task, and the checks that will prove each task landed.
The planner is sandboxed by its tool list rather than by instructions — it can read and it can write Markdown into the plan directory, and that is all. It has no edit tool and no shell, so it cannot touch your source or run a build no matter how the prompt is worded.
Execute. The primary model picks up the plan cold and works it in order: read the named files, make the change, run that task's check, tick the ledger. A failing check is not a finished task. Where reality contradicts the plan, it adapts and records the deviation and its reason — the plan serves the goal, not the other way around.
Why the plan lives on disk
Because the planner will not be there when the plan is executed, and cannot answer questions about it. Writing the plan out as files forces it to be complete enough to act on without the author present. It also means you can read it, edit it, or throw it away before a single line of code gets written — and that the run leaves an audit trail behind it.
Notes
The interesting constraint is that a slash command cannot switch models partway through — the model is fixed for the whole invocation. The two-model split therefore has to come from subagents: the command runs on the session model and spawns the planning half with a model override.
The other one worth knowing is that scoping the planner's tools is a much stronger guarantee than telling it to behave. Prompts get argued with. A missing tool does not.
What else did I build?
GXBridge-MCP
Control Mitsubishi GX Works3 and your PLC with AI — an MCP server for any agent GX Works3 · Industrial Automation
eplanbridge
Drive EPLAN Pro Panel 2022.0.3 from outside the application — and build a 6-axis robot-arm control schematic with it. C# · EPLAN
tovex-cli-showcase
tovex-cli: command-line control of Siemens TIA Portal and live S7 PLCs, built for AI agents. Public overview; source is private.