VS Code as the workbench

VS Code is the operational centre of the workspace. It provides a common view of source code, Markdown, terminals, diffs, diagnostics, and agent activity.

Why the editor matters

An agent can change files without an editor, and Obsidian can edit Markdown without a development environment. VS Code earns its place by putting implementation and review in the same surface.

A useful session usually combines:

• the project repository and its surrounding workspace context;
• Markdown previews for documentation and project memory;
• source control diffs before commits;
• integrated terminals for builds, tests, and diagnostics;
• an agent integration that can inspect and modify the same files.

Open the right boundary

Opening only a repository gives an agent strong code context but can hide the wider goals and project memory around it. Opening the entire workspace provides continuity but increases the amount of unrelated material in view.

The practical compromise is a workspace rooted high enough to include shared guidance and project notes, paired with a clearly selected active project. Agents should read the indexes first and inspect other projects only when the task requires it.

Human review remains visible

Agent changes should arrive as ordinary files and ordinary Git diffs. This keeps review independent of the chat interface. The human can inspect a change, edit it directly, run the same verification, or discard an individual hunk without needing the agent to translate its work back into prose.

Useful defaults

• Enable format-on-save only where the repository already has a formatter.
• Exclude generated directories from search when they create noise.
• Keep Markdown line wrapping a presentation preference, not a destructive rewrite.
• Use repository-specific extensions and settings sparingly.
• Review the source-control panel before publishing changes.