Creating & Editing Files

Simple file creation:

> Create a .gitignore file for a Node.js project

Claude generates the file and shows you what it will create. You approve with y.

More specific creation:

> Create src/utils/formatDate.ts that exports a function to format 
> dates in "Jan 15, 2025" format. Use Intl.DateTimeFormat, not 
> external libraries. Include TypeScript types.

Complex file with requirements:

> Create src/components/DataTable.tsx:
> - Props: columns (array of {key, label, width}), data (array of objects), onSort
> - Sortable column headers (click to sort)
> - Zebra-striped rows
> - Use our existing Tailwind classes
> - Loading state with skeleton rows
> - Empty state with a message

The pattern: Be more specific for more complex files. Simple files need simple prompts.

Claude never modifies your filesystem without permission. Every file operation shows you what will happen:

Create: Shows the full file content before writing Edit: Shows a diff (what will change, what stays the same) Delete: Confirms what will be removed

Your options:

• y (yes) — approve this change
• n (no) — reject, Claude will try a different approach
• e (edit) — modify the proposed change before applying
• You can also type feedback: "Almost, but change X to Y"

Batch approvals: When Claude proposes multiple file changes, you can:

• Approve all at once
• Approve individually
• Reject specific ones

Pre-approving operations (in .claude/settings.json):

{
  "permissions": {
    "allow": [
      "Edit(*)"
    ]
  }
}

Start restrictive (approve everything) and relax as you build trust.

Editing is where Claude really shines. You describe what to change, Claude figures out how:

Targeted edits:

> In src/api/users.ts, add input validation to the createUser 
> function. Validate email format and ensure password is at least 
> 8 characters. Use zod for validation.

Refactoring:

> Refactor the handleSubmit function in LoginForm.tsx — it's too 
> long. Extract the API call into a separate async function and 
> the validation into its own function.

Adding to existing code:

> Add a "lastLogin" field to the User type in src/types/user.ts 
> and update all places that create a User object to include it.

Fixing issues:

> The loading spinner never disappears in Dashboard.tsx. The issue 
> is that setLoading(false) isn't called in the error path of the 
> fetch. Fix it.

Claude shows a diff for every edit — lines removed in red, lines added in green. Read the diff before approving.

Claude handles multi-file changes naturally:

Rename across codebase:

> Rename the "getUserData" function to "fetchUserProfile" everywhere 
> it's used in the project. Update all imports and references.

Add a pattern to multiple files:

> Add error boundary wrapping to all page components in src/app/. 
> Use our ErrorBoundary component from src/components/ErrorBoundary.tsx

Consistent formatting:

> All API route handlers in src/api/ should return responses in the 
> format { data, error, meta }. Update any that don't match this shape.

Project scaffolding:

> Create a new feature module for "notifications":
> - src/components/notifications/NotificationList.tsx
> - src/components/notifications/NotificationItem.tsx
> - src/api/notifications.ts
> - src/types/notification.ts
> - src/hooks/useNotifications.ts
> Follow the same patterns as the existing "messages" feature.

Claude will propose all files and let you approve them as a batch or individually.

Things go wrong. Here's how to recover:

Undo the last change (before committing):

> Undo the last edit you made

Claude can revert its own changes within the session.

Using git to undo (most reliable):

# See what changed
git diff

# Undo all uncommitted changes
git checkout -- .

# Undo changes to a specific file
git checkout -- src/api/users.ts

Best practice: commit before big changes:

> Before we start, commit the current state with message "checkpoint before refactor"

Then if things go wrong:

git reset --hard HEAD  # Go back to the checkpoint

The "oops" workflow:

1. Ask Claude to make a change
2. Approve it
3. Realise it's wrong
4. Option A: Tell Claude "That's not right, revert it and try X instead"
5. Option B: git checkout -- . to discard all changes

Pattern: Show an example, then replicate

> Here's how our UserCard component is structured:
> [paste existing component]
> Create a ProjectCard component following the same pattern but for 
> project data.

Pattern: Describe the interface first

> First, create the TypeScript interface for a Notification in 
> src/types/notification.ts. Then create the API functions that 
> return that type. Then create the component that displays it.

Pattern: Edit by describing the problem

> The checkout page crashes when the cart is empty. Find and fix 
> the component that renders the cart items — it needs a check for 
> empty arrays.

Anti-patterns to avoid:

• "Edit everything" — too vague, Claude doesn't know what to change
• "Make it better" — better how? Be specific.
• "Rewrite the file" — usually you want targeted edits, not a full rewrite
• Editing files you haven't committed — always commit your good state first