DESIGN.md for Devin Desktop (formerly Windsurf)

If you searched for what happened to Windsurf, the short answer is that Cognition announced Devin Desktop as its next generation on June 2, 2026. The product direction moved from an AI-first editor identity toward an agent-management workspace. Existing Windsurf users were moved through the product update with their plans and repository workflows preserved, while the new default surface became the Agent Command Center.

The Agent Command Center is designed to manage local and cloud agents, pull requests, and shared context in one place. Spaces let related agents share context, and Agent Client Protocol (ACP) support allows compatible agents to run alongside Devin. The IDE foundation remains important: extensions, keybindings, language servers, terminal workflows, and the familiar editor surface remain available for last-mile review.

Devin Desktop can coordinate broad work, but a UI task still needs a precise visual contract. Keep DESIGN.md in the repository and mention it at the beginning of a task. Ask Devin Local to read the file and inspect existing components before it plans. This prevents a multi-file change from turning into an accidental redesign and gives the agent a clear way to resolve small decisions about hierarchy, density, states, and motion.

Read AGENTS.md for engineering rules and DESIGN.md for visual rules.
Inspect the closest existing component before planning.
Implement the smallest coherent change with existing tokens and primitives.
Verify desktop, mobile, loading, empty, error, focus-visible, and reduced-motion states.

The prompt should name the route and the outcome, but it should not duplicate the whole design file. If the task conflicts with DESIGN.md, ask the agent to explain the conflict before editing. That short pause is valuable when Devin is managing several agents at once: the team can decide whether the product rule is outdated or the requested feature needs a different pattern.

Agent management makes it tempting to split a feature into many parallel tasks. Split by surface and acceptance criteria: one task can handle the page shell, another the table states, and another the responsive pass. Every task should reference the same DESIGN.md and the same established primitives. When the changes return, review the seams between them: spacing between sections, duplicated controls, inconsistent labels, and different interpretations of semantic color.

Include a concise product mood, semantic color roles, typography, spacing rhythm, radius and shadow rules, component variants, page patterns, accessibility requirements, and explicit anti-patterns. Add examples for the surfaces Devin is likely to touch: dashboards, tables, forms, settings, detail pages, empty states, and error states. A rule such as “use the primary color only for the primary action” is more useful than a palette with no usage guidance.

Finally, describe the review contract. Devin should preserve existing primitives, list the affected routes, verify key states, and report anything it could not inspect. The best result is not a dramatic new style; it is a series of fast, coherent changes that still look like one product after several agents have worked on it.