Composer and Multi-file Editing

This chapter retains the older “Composer” name used in the Chinese source. Current interfaces may place coordinated edits within an Agent workflow. Check the installed commands rather than assuming an old feature table still describes the product.

#Choose a coordinated task

Use discussion when deciding direction and a multi-file workflow when a defined change must keep related components, types, services and imports aligned. A one-line fix may be simpler through inline editing.

#Example: a form

textCopy
Create a login form with email/password fields, validation,
a submit button and loading state.
Use the existing project's React Hook Form and styling patterns.
List affected files and show the diff.

A useful result aligns the component, types, form logic and imports. It is not complete just because a file was created.

#Example: an existing component

textCopy
Update @src/components/UserList.tsx with pagination and search.
Keep the existing API contract.
Identify expensive derived calculations before introducing useMemo.

#Example: service changes

textCopy
Review @src/services/api.ts.
Propose consistent error handling and request interceptors,
with explicit TypeScript response types.
Reuse the current HTTP client unless a migration is explicitly required.

#Bound the file scope

Attach the relevant files or directories. For broad state changes, explain why the change is necessary; replacing every useState with useReducer is not a goal by itself.

An agent may inspect the project, propose files, create missing modules and update imports. Review that plan and the diff rather than treating autonomy as a reason to skip inspection.

#Review before applying

Inspect each file, accept individual changes where supported, edit the proposed patch when necessary, and apply the whole set only after review.

#A precise registration brief

textCopy
Create src/components/RegisterForm.tsx.
Fields: username, email, password and confirmation.
Validate required fields, email format and matching passwords.
Use the project's password policy and existing register API
in src/services/auth.ts.
Reuse LoginForm's validation/styling patterns.
Show loading and error states.

The original example uses an eight-character minimum; a real application should follow its actual policy.

#Implement in phases

Types/data model, service integration, UI, state management and tests are distinct reviewable steps. Reuse existing ProductCard patterns when adding related cards instead of inventing a parallel design system.

Typical coordinated tasks include a dashboard using the existing layout, a favorites feature spanning model/service/API/button, or an approved payment integration with checkout and webhook handling. Each needs its own permissions and acceptance criteria.

#Troubleshooting

Provide library versions and working examples when code is wrong. Narrow @ context and split work when the scope is excessive. Check paths and requirements when the intended edit is missing. Remove unnecessary files from the proposed change and review before using “apply all.”

#Next steps

• Tab completion
• Project rules