Claude Code/Codex Prompting for Beginners: 5 Practical Patterns

Start here: strong prompts are clear work briefs

When Claude Code or Codex gives a messy answer, the problem is often not that the agent is “bad at code.” The prompt did not give it enough working boundaries. A prompt is not a magic phrase. It is a work brief for an AI coding agent: what to change, what not to touch, what counts as done, what proof to collect, and what the next person should know.

This beginner guide turns that idea into five practical prompt patterns: scope, repository context, acceptance criteria, verification evidence, and handoff. You can use them for bug fixes, small features, article generation, repository audits, and review tasks. The goal is not clever AI wording. The goal is to remove guesswork.

For official references, keep the product docs nearby. Start with the Claude Code overview, Claude Code memory, and Claude Code settings. For Codex and OpenAI coding workflows, use the OpenAI code generation guide. Product behavior changes, so evergreen prompts should point to official docs instead of hard-coding every detail.

If you are new to the tool itself, pair this article with the Claude Code getting started guide and CLAUDE.md best practices.

The five prompt patterns

Pattern	Plain meaning	What happens if it is missing
Scope	The boundary of the task	The agent edits unrelated files
Repository context	Existing project rules and examples	The output ignores local conventions
Acceptance criteria	The definition of done	”Done” means different things to you and the agent
Verification evidence	Proof that checks were run	Work ends at “I implemented it”
Handoff	A short note for the next session	Nobody knows why the change was made

Acceptance criteria are the concrete conditions a change must satisfy before you accept it. Verification evidence is the receipt: commands run, screenshots checked, manual flows tested, or limitations clearly stated. Handoff is the summary that lets tomorrow’s you, a teammate, or another agent continue without re-reading the whole conversation.

Pattern 1: Set a narrow scope

A weak prompt starts too wide.

Improve this app and make it better.

That prompt does not say whether the agent may touch UI, API, tests, copy, database schema, dependencies, or deployment settings. Claude Code and Codex can infer, but every inference increases risk.

Use this instead:

Edit only site/src/content/blog-en/5-tips-for-better-prompts.mdx.
Goal: make the article practical for Claude Code/Codex beginners.

Allowed:
- frontmatter title, description, updatedDate, tags
- article body

Do not change:
- heroImage
- slug
- other articles
- build configuration

This is especially important in monetized sites. A broad rewrite can accidentally remove internal links, product CTAs, or analytics attributes. A narrow prompt gives the agent room to work without turning one article update into a site-wide refactor.

For exploration tasks, make the boundary even stricter:

Read the related files and propose an edit plan only. Do not edit yet.
List the files you would change, why, and the verification command for each change.

The most common failure mode is saying “just inspect it” while also granting permission to edit. Separate discovery from implementation when the repository is unfamiliar.

Pattern 2: Give repository context

Claude Code and Codex can read files, but they do not automatically know your business priority, style decisions, or past failures. Repository context tells the agent what kind of project it is entering.

This site uses Astro content collections for localized MDX articles.
Use site/src/content/blog-en/claude-code-productivity-tips.mdx as the quality reference.

Project context:
- Articles should be practical evergreen tutorials, not thin AI summaries.
- Include 3 or more concrete use cases.
- Include official external links and internal links.
- Preserve the monetization path: /en/thanks/, /en/products/, /en/training/.
- Keep frontmatter valid.

Without this context, you might get a clean article that does not fit ClaudeCodeLab. For this site, the reader needs copy-paste prompts, failure examples, verification habits, and a natural next step toward the cheatsheet, products, or training.

If you repeat the same context often, move the durable part into CLAUDE.md. The daily workflow in Claude Code productivity tips shows how project memory, safe commands, and verification habits reduce repeated explanation.

Pattern 3: Write acceptance criteria before the agent starts

Acceptance criteria prevent the vague “make it good” loop. A weak prompt is:

Make this article more readable and better for SEO.

Readable and SEO-friendly are real goals, but they are not testable enough. Break them into conditions:

Acceptance criteria:
- Only the target file is changed.
- The description is 120 characters or shorter.
- Each of the five patterns has a before/after prompt example.
- Include templates for bug fixing, feature work, and article generation.
- Include concrete pitfalls and how to avoid them.
- Add official external links, internal links, and a clear CTA.
- End with verification notes and remaining risks.

For a feature task, the criteria should be more technical:

Acceptance criteria:
- Existing UI layout is preserved.
- TypeScript has no type errors.
- Validation and user-facing error states are added.
- At least one relevant test is added or updated.
- Report the result of npm test and npm run build.

The key is that every item can be checked. If the agent cannot prove it, it should say so rather than pretending the work is verified.

Pattern 4: Ask for verification evidence

“Implemented” is not enough. Ask for a verification receipt.

At the end, return a verification receipt:

- Changed files:
- Commands run:
- Results:
- Manual checks:
- Not checked:
- Remaining risks:

This habit catches many beginner mistakes. It also keeps the agent honest when a command cannot be run because dependencies are missing, a test suite is too slow, or a local service is unavailable. You can then decide whether the risk is acceptable.

Do not summarize errors too aggressively. This is weak:

The build failed. Fix it.

This is useful:

Command:
npm run build

Error:
Type error: Property 'name' does not exist on type 'User | undefined'.
File: src/components/Profile.tsx:15:22

Request:
Explain the likely cause, make the smallest safe fix, then rerun npm run build.

For a deeper workflow, read the verification receipt guide. The habit matters more than the exact format: do not let work end without proof.

Pattern 5: Request a handoff note

Agent work often spans more than one session. A handoff note keeps the next session from rediscovering everything.

At the end, write a handoff note with:
- Goal
- What changed
- What did not change
- Verification results
- Files to inspect next
- Open risks or decisions

This is valuable for article work, SEO improvements, checkout flows, and team repositories. A diff shows what changed, but it rarely explains why a CTA was placed in a specific section or why a safer implementation was chosen over a bigger refactor.

For team usage, connect this with Claude Code team handoff rules. A consistent handoff format is one of the simplest ways to make AI coding sessions reviewable.

Copy-paste templates

Bug fix template

Goal:
  Fix the bug with the smallest safe diff.

Symptom:
  What happens:
  Expected behavior:
  Actual behavior:

Reproduction steps:
  1.
  2.
  3.

Scope:
  Files you may edit:
  Files you must not edit:

Repository context:
  Similar implementation to follow:
  Local rules to preserve:

Acceptance criteria:
  Explain likely causes before editing.
  Fix the root cause, not only the visible symptom.
  Add or update a relevant test when feasible.
  Return verification evidence and remaining risk.

New feature template

Goal:
  Add one small feature safely.

Feature:
  User-visible change:
  API/database/config changes:

Constraints:
  Preserve the existing UI style.
  Follow current naming and file patterns.
  If a larger design change is needed, explain it before implementation.

Acceptance criteria:
  Implementation, types, error states, tests, and verification receipt are included.

Article generation template

Goal:
  Improve this into a beginner-friendly evergreen article.

Reader:
  Solo developer or small team starting with Claude Code/Codex.

Required elements:
  3 or more concrete use cases.
  Before/after prompt examples.
  Specific pitfalls and fixes.
  Copy-paste templates.
  Official links, internal links, and a CTA.

Acceptance criteria:
  Description is 120 characters or shorter.
  Frontmatter remains valid.
  Code fences are balanced.
  Finish with a short self-review.

Three practical use cases

The first use case is a post-login blank screen. Do not say “fix the dashboard.” Give reproduction steps, expected behavior, actual console error, editable files, and verification commands. This pushes the agent toward the root cause instead of merely hiding the symptom.

The second use case is adding a “consultation type” field to a lead form. A good prompt names the options, such as training, consulting, and other; the validation rule; the API contract; the analytics event; and the test expectation. This protects the monetization path while keeping the diff small.

The third use case is article generation. For ClaudeCodeLab, the prompt should specify body depth, concrete examples, failure modes, official links, internal links, CTA, and the final “what happened when I tried this” paragraph. That is how you avoid a generic AI summary and produce something a beginner can actually use.

A small prompt QA rubric

Before sending a prompt, score it out of 10.

Points	Area	Ask yourself
0-2	Scope	Are editable and protected files clear?
0-2	Context	Did I include local examples, reader, and business purpose?
0-2	Acceptance	Can the agent tell when the task is done?
0-2	Verification	Did I name commands or manual checks?
0-2	Handoff	Did I specify what to report at the end?

Eight or higher is usually ready. Five or lower means the agent is being asked to compensate for missing human context.

Runnable task-brief generator

Instead of asking an agent to “make it better”, create the same brief shape every time. This script writes prompt-brief.md; edit the file path and acceptance criteria, then give the brief to Claude Code or Codex so scope, constraints, and verification are clear from the first turn.

cat > prompt-brief.md <<'EOF'
# Task brief for Claude Code / Codex

Goal:
- Improve one article or feature without changing unrelated files.

Scope:
- May edit: site/src/content/blog/example.mdx
- Do not edit: hero images, routes, unrelated articles, billing code.

Context to read first:
- AGENTS.md
- A similar high-quality article
- The target file

Acceptance criteria:
- The intro explains who the reader is and why this matters.
- The draft includes at least three concrete examples.
- Code or prompt templates are copy-pasteable.
- Pitfalls and verification steps are explicit.
- Internal links and a natural CTA are included.

Verification:
- npm run build
- node scripts/check-code-fences.mjs
- Read the changed file once as a reviewer.

Return:
- What changed
- Checks run
- Remaining risks
EOF

CTA: turn the pattern into your own workflow

You do not need to rewrite these patterns from scratch every day. Start with the free Claude Code cheatsheet for daily commands and safe habits. If you want ready-to-use prompt packs and setup material, browse the ClaudeCodeLab products. If your team needs help with CLAUDE.md, permissions, review policy, verification receipts, and rollout training, use the Claude Code training and consultation page.

After trying this workflow in real ClaudeCodeLab article and site tasks, the biggest improvement came from writing scope, acceptance criteria, and verification evidence before asking for edits. Handoff notes also made the next-day review much faster because the reason behind each CTA and link was still visible.