Develop in a project
Use the coding workspace to keep requirements, source, terminal output, and diffs in one project context. This guide follows a narrow-screen project-list fix from reproduction to code handoff. For project creation, chats, and archiving, see Projects and chats.
Prepare source and reproduction material
Open the source project, enter its coding workspace, and check the actual directory. Prepare a reproducible operation, screenshot, or error output and read the repository's startup and test instructions. Preserve existing changes; use a Git worktree when the task needs its own directory and branch.
Record the baseline in the terminal:
git status --short --branch
git diff --stat
The first command establishes branch and file state; the second shows the scale of existing edits. Inspect untracked files too, including files absent from the diff.
Start an actionable task
Send this request in the target project's chat and add the real page URL and screenshot:
Fix horizontal overflow in the project list at 320px and 390px.
Read the list, menu, and nearby tests before locating the overflowing element.
Preserve sorting, filtering, desktop layout, and existing workspace changes.
Exercise the list menu, run the relevant tests, and report changed files and results.
Change local code only; do not commit, push, or deploy.
This request defines the trigger, preserved behavior, and acceptance method. The URL and screenshot supply original evidence; an aesthetic preference alone does not establish reproduction conditions.
Follow execution
The assistant reads the implementation and project rules before editing. Inspect its directory, file operations, and command output. Resolve missing dependencies, startup failures, and confirmation requests before dependent steps continue.
For this example, diagnosis should identify a concrete element and constraint: long text, fixed width, minimum width, or menu positioning. Hiding horizontal scrolling across the page can conceal clipped content and does not establish a fix.
After a directory change, recheck the project and terminal location. Switching chats does not switch Git branches, and creating a worktree does not copy every uncommitted file.
Verify code and interaction
- Start the repository's local server and open the reproduction page.
- At 320px and 390px, inspect long names, empty results, and populated lists.
- Open the menu and exercise sorting and filtering; check visibility, clickability, and results.
- Return to desktop width and check layout and interaction.
- Run the relevant tests and required repository checks in the integrated terminal, retaining actual output.
Separate failures introduced by the change from pre-existing failures. Rerun affected checks after correction. Removing tests, weakening assertions, or skipping failures does not establish completion.
Accept and hand off
Refresh Code review and changes and inspect file ownership individually. The handoff should answer:
| Evidence | What this example requires |
|---|---|
| Cause and change | The overflowing element and the constraint that changed |
| Actual interaction | Menu, sorting, and filtering results at both phone widths |
| Automated checks | Exact commands, results, and checks still failing |
| Workspace state | Existing changes preserved; unrelated files and build output excluded |
After acceptance, select commit scope and follow the project process for pushing or opening a PR. Completing a local fix does not establish those external delivery steps.