Quick Wins in Your First 24 Hours

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, Codex or Cursor 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 lists the current defaults and prices.

In a terminal at the repository root, run claude.
Run /init. Claude Code writes a CLAUDE.md describing the project, its commands and its conventions. Read it now; Win 6 improves it.
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.
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.

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

Open the repository in Cursor and open the Agent panel.
Leave the model selection on its default for now; Cursor changes its defaults often, so compare the picker with the models hub.
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 explains why.
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.

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.

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 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.

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.

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.

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

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

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 reads CLAUDE.md at the start of every session. From v2.1.277 (the latest channel) it also reads AGENTS.md when a project has no CLAUDE.md, so a repository shared with Codex users can keep one file.

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.

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.

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 mcp add --scope user --transport http context7 https://mcp.context7.com/mcp

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

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

{
  "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:

# 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 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.

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

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

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 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.

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

---
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.

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 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.

# 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.

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

Each session runs in a new managed Git worktree.

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 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 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 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 The ordered reading path from your tool's quick start to specs, feedback loops and evidence-based review

Claude Code quick start Installation, configuration and your first project in the terminal agent

Codex quick start The CLI, the app, AGENTS.md and your first reviewed task

Cursor quick start From installation to your first agent-built feature in the IDE

Power-user tips The shortcuts and settings that matter once the basics are routine

Workflows for all three tools Planning, testing, review and shipping techniques shown in Claude Code, Codex and Cursor