Developer workspaces that keep the setup with the task.

What belongs in a developer workspace?

Start with a task, not every application on your desktop. A workspace for a bug investigation should contain the resources needed to reproduce, understand, and test that bug.

• The repository and relevant project folder.
• Supported editor files and navigation locations.
• The issue, reproduction page, documentation, and useful reference tabs.
• Terminal working directories and explicitly approved startup commands.
• Window positions, sizes, and monitor assignments where supported.
• A note recording findings, attempted approaches, and the next check.

Stowen’s planned workspace capture lets you choose open apps and windows, then review the selection. Manual creation will let you assemble the setup from references without opening all its resources first.

Switch from a feature to a bug fix, then return.

Suppose you’re implementing a feature when an urgent bug arrives. Before moving, save your files and record the feature’s state: which behavior is complete, what is failing, and the next thing you intended to test.

Create a separate task context for the investigation. Keep its issue, reproduction steps, terminal locations, and browser references distinct from the feature work. If you need a separate checkout, use your normal Git workflow; do not assume saving a workspace isolates a repository.

Stowen is being designed to preserve the current workspace before switching and restore supported resources when you return. The restoration report should tell you what opened, what partly restored, and what needs attention, such as a moved folder or unavailable app.

That report matters even when the windows look familiar. A process may have stopped, the branch may have changed, or the files may now reflect someone else’s update. Read the task note and check the repository before continuing.

Keep startup commands explicit.

A terminal directory tells you where work was happening. It does not prove that a server is running or that a database is ready. A useful setup recipe records the working directory, command order, dependencies, and the check that indicates a service is ready.

Stowen’s planned startup recipes will run approved commands in the required order and check readiness for configured services. When finishing, stopping session-owned processes should remain under your control.

For a shared setup, document what a command does before asking a recipient to run it. Keep secrets out of the recipe and describe how the recipient supplies their own local configuration. Imported handoff commands require approval.

A saved setup is not a code backup.

Window capture and a file reference do not guarantee that unsaved editor buffers, uncommitted changes, or external data have been preserved. Save files and use version control or your normal backup process before moving away from a task.

For selected code transfers, Stowen’s handoff scope includes changes against a known base commit, applied in an isolated Git worktree. The recipient still needs repository access and must check the result. That isolation belongs to the planned code handoff flow; it is not a promise that every local workspace switch creates a worktree.

See the handoff checklist for base commits, setup requirements, selected deliverables, and completion notes.

Build a workspace from an issue or brief.

The planned assistant can create workspaces from natural-language requests, pasted briefs, supplied documents, and task context retrieved from one supported issue tracker. Ambiguous issue numbers or project names should be resolved before opening the wrong setup.

Saved editor, browser, terminal, path, and layout preferences will guide suggestions. You’ll be able to correct the selected resources, update a startup command, or ask for a summary of recorded progress. Generated summaries stay editable and distinguish recorded facts from inference.

A defined integration will also let you launch a chosen external coding agent with approved task context. This does not grant the agent access to every file or account on your computer.

Compatibility depends on the integration.

Initial coverage is planned for one desktop operating system, one browser, one editor, and one issue tracker. A supported editor may expose detailed state; another app may only reopen a file or project.

Cross-device continuation initially targets the same operating system, with paths mapped per device and readiness checks before restoration. Missing dependencies, local resources, and permissions still need to be resolved.

Core local workspace actions are planned to work offline and through normal controls without AI. Tell us which development setup you use so we can understand the workflow you need.