# Quick Wins in Your First 24 Hours

URL: https://developertoolkit.ai/en/start/quick-wins/
Description: Ten first-day techniques for Claude Code, Codex and Cursor, each with a copy-paste prompt and a check that proves the result without reading every line.

Quick wins with Claude Code, Codex and Cursor are ten first-day techniques that pay off in minutes: five need no configuration (explaining code, characterization tests, test-first bug fixes, guarded refactors, and a pre-push review), and five need 10–30 minutes of setup. Each win pairs a copy-paste prompt with a check that proves the result without reading every line.

This page is for a developer who installed an agent yesterday and has not trusted it with real work yet. You have a standup in an hour, a module nobody has tested, and a stack trace from last night's deploy. The prompts below work on that code today, and every one of them ends in evidence you can check in under a minute: a test that went red then green, a cited line number, a review report.

Not installed yet? Start with the [Claude Code](/en/claude-code/quick-start/), [Codex](/en/codex/quick-start/) or [Cursor](/en/cursor-ide/quick-start/) quick start.

## What you'll walk away with from your first day

- Five prompts that work on your real repository with nothing configured beyond installation
- Five one-time setups — an instructions file, live library docs, plan-first work, a reusable skill, and parallel worktrees — that improve every task after them
- A verification habit for each technique, so you judge the agent by evidence instead of by rereading its diff
- A baseline you can measure against tomorrow, instead of a feeling

## Set up your agent in five minutes

Start from a clean Git working tree (`git status` shows nothing to commit). A clean tree is your undo button: whatever the agent does, `git diff` shows it and `git restore .` removes it.

Stay on the tool's default model on day one. The rule this site follows is to start on the default, raise effort before switching model, and switch only when your own results say so; the [models hub](/en/ecosystem/models/) lists the current defaults and prices.

**Claude Code**

    1. In a terminal at the repository root, run `claude`.
    2. Run `/init`. Claude Code writes a `CLAUDE.md` describing the project, its commands and its conventions. Read it now; Win 6 improves it.
    3. Check the permission mode in the footer; Shift+Tab cycles through the modes, including Manual, Accept edits, Plan and Auto. Manual asks before Claude edits a file or runs a command.
    4. Ask `What is this project, and which commands build, test and lint it?` A correct answer means the agent can run your checks, and every win below depends on that.

    **Which mode you start in**

    From v2.1.283 (both release channels on 2026-10-12), interactive sessions on every plan and provider start in auto mode, where a classifier reviews each action before it runs. A session starts in Manual when a settings file sets `disableAutoMode` or when its model does not support auto mode (Haiku 4.5, Sonnet 4.5 and Opus 4.5 everywhere; on Bedrock, Google Cloud and Foundry anything other than Sonnet 5 or later, Opus 4.7+, Haiku 5.5 (from v2.1.293, `latest` channel only on 2026-10-12) and Fable — so a default Foundry session starts in Manual). The [permissions and sandboxing guide](/en/workflows/harness/permissions-and-sandboxing/) covers every mode.

**Codex**

    1. In a terminal at the repository root, run `codex`.
    2. Run `/init`. Codex writes an `AGENTS.md` with the project overview, commands and conventions.
    3. Keep the default approval policy, `on-request`, for the first day: Codex asks before it leaves the sandbox.
    4. Ask `What is this project, and which commands build, test and lint it?` and correct anything it gets wrong in `AGENTS.md`.

**Cursor**

    1. Open the repository in Cursor and open the Agent panel.
    2. Leave the model selection on its default for now; Cursor changes its defaults often, so compare the picker with the [models hub](/en/ecosystem/models/).
    3. Before you give it real work, open Cursor's settings, find **Run modes** (they decide which terminal commands the agent runs without asking), and choose one that stops for your approval. The [Cursor security guide](/en/cursor-ide/operate/security/) explains why.
    4. Ask `What is this project, and which commands build, test and lint it?` Win 6 turns the answer into a project rule.

## First 30 minutes: five wins with no configuration

These five prompts are the same in all three tools. Paste them into a Claude Code or Codex session, or into Cursor's Agent panel. Replace the file paths with a real file from your repository.

### Win 1: Understand unfamiliar code with cited line numbers

A 200-line function with cryptic names is a reading problem, not a writing problem, so keep the agent read-only. The verification is built into the prompt: every claim must cite a line, and you check two of them.

**Copy-paste prompt: explain a module without changing it**

```text
Read src/services/paymentProcessor.ts and explain it. Do not edit any file.
1) What the module does, in three sentences.
2) The happy path and each error path, with the line numbers that implement them.
3) Inputs that are not handled (null, empty, duplicate, timeout), each with the line where it would fail.
4) Which tests cover this file today, by test name. Say "none" if none do.
Cite a line number for every claim. If you are unsure, say so instead of guessing.
```

**Check it:** open two of the cited lines. If either does not say what the agent claims, discard the explanation and ask again with a smaller scope.

### Win 2: Pin down current behaviour with characterization tests

Tests for untested code are a strong first task, because they make every later change checkable. Ask for tests that record what the code does *now*, bugs included, rather than what it should do.

**Copy-paste prompt: characterization tests for an untested module**

```text
Write characterization tests for src/utils/validation.ts using the test framework this project already uses.
Record what each exported function does today, including behaviour that looks wrong; mark those tests with a comment "CURRENT BEHAVIOUR - review".
Cover empty strings, null, undefined, boundary values and every thrown error.
Do not change validation.ts.
Run the new tests and show me the output.
Then prove the tests can fail: change one comparison operator in validation.ts, run the tests, show me which test fails, and revert the change.
```

**Check it:** the last step is a one-line mutation test. If no test goes red when the code changes, the suite is decoration. The [characterization tests guide](/en/workflows/test/characterization-tests/) covers the full technique.

### Win 3: Fix a bug from the stack trace, test first

Pasting a stack trace and asking for a fix works, but the fix is only proven when a test reproduced the bug first. Order matters: red, then fix, then green.

**Copy-paste prompt: reproduce, then fix**

```text
Here is an error from production:

PASTE_STACK_TRACE_HERE

1) Find the root cause. Trace the data flow to the failing line and explain it in two sentences.
2) Write a test that reproduces this error. Run it and show me that it fails for the reason above.
3) Make the smallest fix that makes that test pass.
4) Run the full test suite and show me the result.
Do not change any existing test to make it pass.
```

Replace `PASTE_STACK_TRACE_HERE` with the full trace, including the lines from your own code. Redact tokens, emails and customer identifiers from the trace before you paste it.

**Check it:** you need two outputs, the new test failing before the fix and the whole suite passing after it. A fix with no failing test first may have fixed a different problem.

### Win 4: Refactor a long function behind a test gate

A refactor is safe when behaviour is pinned before the structure changes. The prompt makes the agent build that pin first when it is missing.

**Copy-paste prompt: behaviour-preserving refactor**

```text
Refactor processOrder in src/controllers/orderController.ts into smaller functions with one responsibility each.
Before changing anything, run the tests that cover processOrder. If fewer than three tests exercise it, write characterization tests first and show me they pass.
Keep the exported API and all observable behaviour identical.
After the refactor, run the same tests plus the type checker and the linter, and show me all three results.
```

**Check it:** the same tests pass before and after, and the type check and lint are clean. You review the shape of the new functions, not every moved line.

### Win 5: Get a review before you push

Before a human reviewer sees the change, have an agent review it. The built-in review commands read the diff and report findings with file and line references.

**Claude Code**

    Run `/code-review` in the session to review your current changes. `/security-review` runs a security-focused pass.

**Codex**

    Run `/review` in the session, or from the shell run `codex review --uncommitted` to review staged, unstaged and untracked changes without opening a session.

**Cursor**

    Paste the prompt below into the Agent panel. On pull requests, **Bugbot** is Cursor's reviewer for bugs, security issues and code-quality problems; check your plan before you enable it.

**Copy-paste prompt: pre-push review of your own diff**

```text
Review the uncommitted changes in this repository as a strict senior reviewer.
Report only real problems: bugs, missing error handling, security issues, and behaviour changes that no test covers.
For each finding give file, line, severity (high, medium or low), and a one-line fix.
Do not edit files. If you find nothing above low severity, say so in one line.
```

**Check it:** fix every high finding, or write down why it is wrong. A review that finds nothing on a large diff is a signal to ask again with a narrower scope.

## Rest of the day: five wins that need 10 to 30 minutes of setup

These take a one-time investment and improve every task after them. Do them in this order: the instructions file first, because every later win reads it.

### Win 6: Tune the instructions file the agent reads every session

The file from `/init` is a draft. It becomes useful when it holds the rules the agent cannot infer from the code: which commands prove a change, which directories are off limits, and what "done" means.

**Claude Code**

    Claude Code reads `CLAUDE.md` at the start of every session. From v2.1.277 (both release channels on 2026-10-12) it also reads `AGENTS.md` when a project has no `CLAUDE.md`, so a repository shared with Codex users can keep one file.

**Codex**

    Codex reads `AGENTS.md`. Codex ignores `AGENTS.md` in projects you have not trusted (from 0.150.0), so trust the project when Codex asks.

**Cursor**

    Cursor reads **Rules**. Ask the Agent to create a project rule and to tell you the file it wrote, paste the output of the prompt below into that file, and commit it. The [Cursor project rules guide](/en/cursor-ide/quick-start/project-rules/) covers scoping rules to paths.

**Copy-paste prompt: turn the draft into working instructions**

```text
Improve the project instructions file for this repository. Keep it under 80 lines.
Include only what you cannot infer from the code:
- the exact commands for build, test, lint and type check, and which of them must pass before a task is done
- directories and files never to edit (generated code, vendored code, migrations already applied)
- conventions that differ from the framework's defaults, each with one real file as an example
Verify every command by running it. Delete any line you could not verify.
Show me the diff of the file.
```

**Check it:** every command in the file ran successfully during this prompt. A shorter, verified file beats a long, guessed one; see [pruning context files](/en/workflows/context/pruning-context-files/).

### Win 7: Give the agent current library docs with Context7

Models know library APIs as of their training data. The Context7 MCP server from Upstash fetches version-specific documentation on demand. The server works without an API key; a free key raises the rate limits.

**Claude Code**

    ```bash
    claude mcp add --scope user --transport http context7 https://mcp.context7.com/mcp
    ```

**Codex**

    ```bash
    codex mcp add context7 -- npx -y @upstash/context7-mcp
    ```

**Cursor**

    Add the server to `.cursor/mcp.json` in the repository:

    ```json
    {
      "mcpServers": {
        "context7": { "url": "https://mcp.context7.com/mcp" }
      }
    }
    ```

To add a key, remove the keyless entry first (`claude mcp remove context7` or `codex mcp remove context7`) and read the key from an environment variable that your secret store fills. Never type the key itself into a command:

```bash
# Claude Code: the shell expands the variable, and user scope stores the value in your user config, not the repository
claude mcp add --scope user --header "Authorization: Bearer $CONTEXT7_API_KEY" --transport http context7 https://mcp.context7.com/mcp
# Codex: stores only the variable name and reads the key when it connects
codex mcp add context7 --url https://mcp.context7.com/mcp --bearer-token-env-var CONTEXT7_API_KEY
```

In Cursor, put a keyed entry in your user-level `~/.cursor/mcp.json` instead of the project file. Never commit a key to `.cursor/mcp.json` or `.mcp.json`: both live in the repository, so the key would land in Git history.

Then name the library and version in the prompt: `Use Context7 to check the current Next.js routing API for the version in package.json before you change this file.`

Each MCP server adds tools the agent has to choose between, and in some clients their definitions as well, so add servers one at a time as a task needs them. The [Context7 guide](/en/ecosystem/mcp/context7/) covers pinning a library ID and the no-MCP CLI mode.

### Win 8: Plan a feature and agree acceptance criteria before code

For anything larger than a bug fix, make the agent plan first and write acceptance criteria you can check. You approve three pages of plan instead of reviewing three hundred lines of wrong code.

**Claude Code**

    Enter Plan mode with `/plan` or Shift+Tab, then paste the prompt. The agent reads and plans but does not edit.

**Codex**

    Run `/plan` to switch to Plan mode, then paste the prompt.

**Cursor**

    Switch the Agent to **Plan Mode**, which creates an implementation plan before writing any code, then paste the prompt.

**Copy-paste prompt: plan with checkable acceptance criteria**

```text
I need email notifications when an order ships. Do not write code yet.
Read the order and email code first, then give me:
1) Acceptance criteria as Given/When/Then statements, each one checkable by an automated test.
2) The files you will change or add, and why.
3) The edge cases: duplicate events, email provider timeout, user without an email address.
4) An implementation order in which each step ends with a test run.
Wait for my approval before implementing anything.
```

**Check it:** each acceptance criterion maps to at least one test in the final change, and the tests ran green. That mapping is what you sign off on. The [acceptance criteria guide](/en/workflows/plan/acceptance-criteria/) shows how to write criteria an agent cannot misread.

### Win 9: Save a prompt you repeat as a skill

By mid-afternoon you will have pasted the Win 5 review prompt three times. A skill turns it into a named, versioned file the agent loads on demand. Skills follow the open Agent Skills format (a folder with a `SKILL.md`), which all three tools support.

**Claude Code**

    Create `.claude/skills/pre-push-review/SKILL.md`:

    ```markdown
    ---
    name: pre-push-review
    description: Review uncommitted changes for bugs, missing error handling, security issues and untested behaviour changes before a push.
    ---
    Review the uncommitted changes as a strict senior reviewer.
    Report only real problems, each with file, line, severity (high, medium, low) and a one-line fix.
    Do not edit files. If nothing is above low severity, say so in one line.
    ```

    Invoke it with `/pre-push-review`, or let Claude Code load it when a request matches the description. Commit the folder so the team gets it too.

**Codex**

    Ask Codex to use its bundled `skill-creator` skill to turn the Win 5 prompt into a project skill named `pre-push-review`, then run `/skills` to confirm it is listed. Codex reads repository skills from `.agents/skills/` (checked against the 0.157.1 binary), so commit that folder.

**Cursor**

    Cursor supports **Agent Skills**. Ask the Agent to create a project skill named `pre-push-review` from the Win 5 prompt and to tell you where it saved it, then check that it appears in the Agent's skill list and commit that folder.

**Check it:** run the skill on a diff with a known bug, such as a removed null check. If the report misses it, tighten the skill text before you rely on it. Community skills install with `npx skills add OWNER/REPO`; read the `SKILL.md` before installing, because a skill is instructions your agent follows.

### Win 10: Run independent tasks in parallel worktrees

Three unrelated tasks — a feature, a bug fix and a docs update — do not have to wait for each other. Each agent gets its own Git worktree, so their edits never collide and each lands as its own branch.

**Claude Code**

    ```bash
    # Terminal 1
    claude --worktree order-emails
    # Terminal 2
    claude --worktree token-refresh-fix
    # Terminal 3
    claude --worktree api-docs
    ```

    Each session runs in its own checkout on its own branch.

**Codex**

    ```bash
    # Run once per task, each in its own terminal
    codex --worktree
    ```

    Each session runs in a new managed Git worktree.

**Cursor**

    Use **Worktrees** to let local agents work in isolated Git checkouts, or hand a task to a **Cloud Agent**, which runs in an isolated cloud VM with a full development environment while you keep working locally.

**Check it:** parallel work multiplies review load, so give each task a gate before you look at it: tests, type check and lint must pass on the branch. Merge the branch whose checks are green; send the others back with the failing output. Start with two tasks, not five. [Parallel agents](/en/ecosystem/agent-tools/parallel-agents/) covers the tooling beyond day one.

## How do you know the day's output is right?

The habit behind every win is the same: ask for evidence, then check the evidence instead of the code. This table is the whole review workflow for your first day.

| Win | Evidence you check | Time to check |
| --- | --- | --- |
| 1. Explain code | Two cited line numbers match the claims | 1 minute |
| 2. Characterization tests | Tests pass, and one deliberate mutation turns a test red | 1 minute |
| 3. Bug fix | New test fails before the fix, full suite passes after | 1 minute |
| 4. Refactor | Same tests green before and after; type check and lint clean | 1 minute |
| 5. Review | Every high finding fixed or rejected with a reason | 5 minutes |
| 6. Instructions file | Every listed command ran during the prompt | 2 minutes |
| 7. Library docs | Generated code compiles against the installed library version (type check passes) | 1 minute |
| 8. Planned feature | Each acceptance criterion maps to a passing test | 5 minutes |
| 9. Skill | Skill report catches a planted bug (a removed null check) | 2 minutes |
| 10. Parallel work | Checks green on each branch before you open the diff | 1 minute per branch |

You still own what you merge. The evidence tells you where to spend your reading: on the finding the reviewer flagged, the test that was hard to write, and the file that changed shape. [Reading evidence instead of code](/en/ladder/evidence-not-diffs/) turns this habit into a working method.

## Measure your first day against a baseline

A feeling of speed is not a measurement. Controlled studies disagree: METR's late-2025 follow-up with open-source developers found point estimates of about 18% less time with AI for returning developers and 4% for new recruits, but both confidence intervals cross zero, and METR says the results are hard to interpret (METR, published 2026-02-24). Your own numbers are the only ones that apply to your codebase.

| What to record | How | What it tells you |
| --- | --- | --- |
| Tasks closed | Count tickets merged today and on a normal day last week | Throughput |
| Time per task | Start and end time for three to five tasks | Where the agent helps and where it does not |
| Rework | Changes reverted or reopened within a week | Whether speed cost quality |
| Coverage | Run your coverage tool before Win 2 and at the end of the day | Whether the checkable surface grew |

## When quick wins go wrong, and how to recover

- **The agent edits files you did not ask it to touch.** Run `git diff --stat` to see the blast radius and `git restore <path>` to drop the unwanted files. In Claude Code, Esc Esc (or `/rewind`) rolls the session back to an earlier checkpoint. Then add the off-limits paths to your instructions file (Win 6).
- **Tests pass, but the behaviour is wrong.** The agent wrote tests that match its own implementation. Re-run the mutation step from Win 2; if nothing goes red, write the acceptance criteria yourself (Win 8) and ask for tests from those, without showing the implementation.
- **The agent changed an existing test to make it pass.** Reject the change and restore the test file. Add `Never edit an existing test to make it pass; report the conflict instead.` to your instructions file. The [protect the oracle](/en/workflows/test/protect-the-oracle/) guide covers enforcing this with hooks and CI.
- **The code uses an API that no longer exists.** Install Context7 (Win 7) and name the library version in the prompt. If the error persists, paste the relevant page of the library's changelog into the prompt.
- **The agent repeats the same mistake.** The session context is polluted with failed attempts. Start fresh (`/clear` in Claude Code, `/new` in Codex, a new chat in Cursor) and restate the task with the constraint the agent kept breaking.
- **Parallel branches conflict at merge.** The tasks were not independent. Merge the branch with the smallest diff first, then ask the other agent to rebase onto it and re-run its checks.

## Where to go next after your first day

- [Developer track](/en/start/developer/) — The ordered reading path from your tool's quick start to specs, feedback loops and evidence-based review
- [Claude Code quick start](/en/claude-code/quick-start/) — Installation, configuration and your first project in the terminal agent
- [Codex quick start](/en/codex/quick-start/) — The CLI, the app, AGENTS.md and your first reviewed task
- [Cursor quick start](/en/cursor-ide/quick-start/) — From installation to your first agent-built feature in the IDE
- [Power-user tips](/en/start/power-user-tips/) — The shortcuts and settings that matter once the basics are routine
- [Workflows for all three tools](/en/workflows/) — Planning, testing, review and shipping techniques shown in Claude Code, Codex and Cursor