Context is assembled manually.
Developers pass the same background into repeated runs.
Solutions
Memory for OpenCode
OpenCode gives developers a flexible way to run AI coding workflows. Windy gives those workflows the project memory they need first: specs, architecture, diagrams, decisions, plans, tasks, and execution history served through project-scoped MCP.Agent-agnostic project memory · Works with OpenCode, Claude Code, Cursor, Codex, and MCP-aware coding agents.
OpenCode runs the workflow. Windy preserves the project memory.
Open coding agents are useful because they are flexible, scriptable, and close to the developer workflow. But flexibility does not remove the need for durable context. The agent still needs to know the project’s specs, architecture, decisions, constraints, current plan, and what happened in previous runs. Windy keeps that memory in one project-scoped source of truth.
Windy does not replace OpenCode. It gives OpenCode the shared project memory it should build from.
The problem
Open agent workflows still start from the context they can reach.
An open coding agent can be wired into many workflows, but each run still depends on the context available at that moment. If design intent lives across chats, tickets, repo docs, diagrams, and decisions in someone’s head, the agent has to reconstruct the project from fragments.
Architecture is easy to infer incorrectly.
The agent may follow local code patterns while missing the intended system shape.
Plans are not durable.
A useful task sequence can disappear into a terminal session or chat history.
Execution history is scattered.
Later runs may not know what already changed or failed.
Tool flexibility can create memory fragmentation.
Different agents or scripts may each carry a partial version of the project.
Open workflows are strongest when they share one durable project memory.
Project memory
Put the source of truth where OpenCode can reach it.
Windy stores the project artifacts that explain what the system is, why it is shaped that way, what work is planned, and what happened in previous runs. OpenCode workflows can use that memory as grounding context before code changes.
- Specs and requirements — intended behavior, edge cases, and acceptance criteria.
- Architecture notes — components, boundaries, dependencies, ownership, and constraints.
- Diagrams — system maps, data flows, ER diagrams, state machines, and cloud architecture.
- Contracts and schemas — APIs, events, database models, payload shapes, JSON, YAML, and interface definitions.
- Decision records — tradeoffs, rejected alternatives, and the reasons behind current design choices.
- Plans and tasks — ordered work with objectives, dependencies, acceptance criteria, and implementation prompts.
- Execution history — what ran, what changed, what passed, what failed, and what still needs review.
The repository shows what exists. Windy explains what OpenCode should preserve while changing it.
Workflow
Keep the open workflow grounded in one source of truth.
Windy turns OpenCode sessions into a repeatable design-first loop: capture intent, expose memory, run the agent, review the change, and update the source of truth.
01
Capture the design in Windy.
Store specs, architecture, diagrams, contracts, constraints, and decisions.
02
Create a plan for large work.
Break broad changes into ordered tasks with objectives, dependencies, acceptance criteria, and prompts.
03
Let OpenCode use the project memory.
The agent reads the relevant docs and task context before editing code.
04
Review against the memory.
Humans compare the implementation to the spec, architecture, plan, and acceptance criteria.
05
Update the source of truth.
Docs, plans, decisions, and execution notes stay aligned with the implementation.
The next OpenCode run starts from the current project truth, not a reconstructed prompt.
Agent-agnostic
The project memory should outlive any one coding tool.
Developers often use more than one AI coding tool. OpenCode may be part of a workflow alongside Claude Code, Cursor, Codex, scripts, or future MCP-aware agents. If each tool keeps its own private memory, the project drifts into multiple versions of the truth.
- OpenCode reads the same architecture note as Claude Code.
- Cursor-assisted edits use the same requirements and diagrams.
- Codex-style task execution follows the same Windy Plan.
- A future agent reads the same execution history before continuing work.
Windy makes the memory belong to the project, not to one agent runtime.
What this looks like in practice.
You want OpenCode to help migrate a billing schema without breaking existing subscriptions, invoices, and webhook processing.
Without Windy
The prompt says “migrate billing schema.” The agent has to infer lifecycle states, webhook ordering, backfill behavior, rollback needs, and acceptance criteria from partial repo context.
With Windy
- The billing architecture note explains ownership of subscription and invoice state.
- The schema contract defines current and target models.
- The diagrams show checkout, webhook, invoice, and backfill flows.
- The migration plan breaks the work into schema change, compatibility layer, backfill, API updates, tests, and docs tasks.
- OpenCode reads the relevant docs and current task before editing code.
- Execution notes record what changed, what passed, and what still needs review.
- Docs and decisions are updated as the migration evolves.
OpenCode is no longer executing a broad instruction from partial context. It is following a project memory the team can inspect.
Setup
Connect the workflow to project-scoped memory.
The simplest way to use Windy with OpenCode is to create a Windy project for the codebase, capture the design context, and use the project’s MCP-accessible memory as grounding context for OpenCode runs.
01
Create or open a Windy project.
Add the requirements, architecture notes, diagrams, decisions, and constraints that explain the system.
02
Create a plan for the active work.
Break large changes into ordered tasks with acceptance criteria.
03
Connect or reference Windy from the OpenCode workflow.
Use the relevant Windy docs, diagrams, and task context before implementation.
04
Record execution notes.
Preserve what happened so later runs can start from the current truth.
Suggested workflow instruction
Before making code changes, read the relevant Windy Docs and current Windy Plan
as the source of truth for behavior, architecture, constraints, acceptance
criteria, and task order. After implementation, update Windy docs or execution
notes if behavior changed.Control
Flexible automation still needs a reviewable source of truth.
Windy keeps humans in control of the design. The project memory is visible in the web app, available to agents through MCP, and organized around docs, plans, tasks, and execution history. That makes open agent workflows easier to inspect, resume, and trust.
- Project-scoped source of truth — OpenCode reads the connected project's memory.
- Human-readable docs — the design is visible, not hidden inside a run.
- Reviewable plans — large work is broken into tasks and acceptance criteria.
- Execution history — previous runs leave a durable record.
- Agent portability — the same memory can support multiple coding agents.
Windy gives open coding workflows the memory and review surface they need to scale beyond one-off prompts.
Best-fit use cases
When Windy helps most with OpenCode.
Scriptable agent workflows
repeatable OpenCode runs that need durable context.
Architecture-sensitive changes
APIs, schemas, service boundaries, event flows, and data ownership.
Large migrations
work that needs sequencing, acceptance criteria, and execution history.
Multi-agent teams
projects where OpenCode is used alongside Claude Code, Cursor, Codex, or other agents.
Long-running implementation plans
tasks that span multiple sessions or branches.
Projects where docs must stay current
codebases future agents will need to understand and modify safely.
FAQ
Questions, answered.
No. OpenCode runs coding workflows. Windy provides the shared project memory, specs, plans, and execution record those workflows should use.
Each run depends on the context it can reach. Windy gives OpenCode durable access to specs, architecture, decisions, diagrams, plans, and execution history.
No. Windy is agent-agnostic project memory for coding agents, so the same source of truth can support OpenCode, Claude Code, Cursor, Codex, and future MCP-aware agents.
Yes. Repository docs are useful, but Windy also holds diagrams, plans, tasks, acceptance criteria, and execution history as a shared project memory for humans and agents.
Start with the active requirement, architecture notes, diagrams, contracts, constraints, acceptance criteria, and the plan for the change.
Windy preserves execution notes and keeps docs or plans updated when behavior changes, so future runs start from current project memory.
Related
Keep exploring.
OpenCode runs the workflow. Windy gives it the project memory.
Create a project, connect the MCP endpoint, and let OpenCode build from your source of truth instead of a reconstructed prompt.
windylogic.ai