Getting started
From sign-up to your first reviewed change.
Windy is the workspace the coding agent you already use does its work inside. Here's the whole path — set Windy up, tell your agent it's there, open a Work item and shape the proposal, then run a Task List and merge.
Step 1 · Set up
Connect Windy to the agent you already use.
Sign up — your first project is ready
Signing up spins up your first project automatically, named My Project. Rename it to match what you're building — and add more projects anytime you want a separate space, one per system you'd rather keep apart.
Create a per-(user, project) MCP endpoint
Inside your project, create a per-(user, project) MCP endpoint. It's revocable, token-scoped, and bound to you — so any agent you connect sees exactly this one project, and every change it makes is attributed to you.
Connect your coding agent
Point Claude Code, Codex, or any MCP-aware agent at that endpoint. The endpoint page in your dashboard gives you the exact, copy-paste config for each agent.
Step 2 · Point the agent at Windy
Tell your agent the workflow lives in Windy.
Add a short note to your CLAUDE.md / AGENTS.md so every session reads the knowledge base from Windy and moves real work through a Work item — not straight into the repo.
## This project uses Windy (MCP) for agent-native development
The specs, designs, and architecture are Documents in the `windy` MCP
knowledge base — the source of truth, not the repo. Before you change code or
make a design decision, read the relevant Document with the `mcp__windy__docs_*`
tools (start at index.md), and keep the knowledge base current as behaviour
changes.
Don't edit code or docs ad hoc — drive real work through the workflow. Open a
Work item, then call `get_how_to(work_id, step)` and follow each step it hands
back: author the proposal + verification spec, address review, stage the
knowledge-base Changeset, create the Task List, and run the Execution —
committing per task with its SHA — then merge the changeset once approved.Step 3 · Propose
Open a Work item. Review as the architect.
Create a Work item and pick a Work Type
Start a Work item for the change you want and choose its Work Type— Feature, Bug Fix, Refactoring, and more. It's the container for the proposal, task list, and execution that follow.
Copy the prompt, let the agent propose
Copy the Work item's author-proposal promptinto your agent. It writes the proposal and verification specs into the Work's proposal store — what to build, and how you'll know it works. You set the direction; it does the writing.
Review with inline comments
Open the proposal in the Windy dashboard and leave inline comments. The agent answers the threads and revises — you stay the architect throughout.
Gap-check, then approve and mark ready
Ask the agent whether the proposal is detailed enough to build from. Decide which gaps are real, have it fill them, then approve and mark the proposal ready.
Step 4 · Build
Stage the changeset, then run a Task List.
Stage the knowledge-base changeset
From the approved proposal, have the agent derive a changeset — a staged, reviewable edit to the knowledge base — or record that no doc change is needed. This gate stands between the proposal and the build.
Turn the proposal into a Task List
Ask the agent to create a Task List from the ready proposal: the work broken into small, ordered implementation and verification tasks. Review it in your dashboard and have the agent iterate on any feedback.
Run the execution, then merge
Tell the agent to start executing. It works task by task, committing each with its own SHA, while you watch live progress across the whole run. Review the code and the changeset together, then merge the changeset into the knowledge base.
Keep going