Bounding the Problem: How to Define a Task for Claude

The issue: Researchers give Claude vague tasks and get vague results, or over-specify tasks and get mechanical ones. The art is neither tight control nor open delegation — it is bounding: defining the edges of the problem clearly enough that Claude can work within them, while leaving enough open that Claude's capabilities can contribute. Getting this wrong is one of the most consistent sources of unusable output. Getting it right is one of the highest-leverage skills in working with Claude well.

What bounding means

A problem is bounded when it has clear edges: what is inside the task and what is outside it. Not how to solve it — Claude decides that. Not every detail of the output — Claude handles that. Just: what is this task, what counts as success, what are the constraints it must respect.

A well-bounded task is auditable. When the output arrives, you can check it against the stated bounds and know whether it succeeded. An unbounded task produces output you can only evaluate by feel — which is unreliable, and which makes trust impossible.

Bounding is not about restriction. A task can be bounded and still require significant judgment and creativity from Claude. "Write a one-page argument that network ties explain heretical persistence better than individual conviction, aimed at a non-specialist reader, citing only sources I have already verified" is highly bounded — and still genuinely requires Claude's capabilities.

The spectrum: from underbounded to overbounded

Problems exist on a spectrum. Both ends fail, in different directions.

Underbounded — the open brief:

> What do you think about this source?

> Help me with my research.

> Write something about the Cathars.

Claude will produce output. It will address some question about the source, or about research generally, or about Catharism. That question may or may not be yours. The output is unevaluable because you did not state what you needed.

The failure mode is not that Claude does nothing — it is that Claude does something plausible that is not what you needed, and the plausibility makes it hard to notice the miss.

Overbounded — the answer disguised as a question:

> Read this source. I think it shows that kinship ties explain
  heretical persistence. Write an analysis confirming this.

> Summarise this chapter, making sure to emphasise the point
  about network density as the key causal mechanism.

Here the bounds are not edges around a problem — they are walls that predetermine the answer. Claude has no room to bring anything you do not already believe. The output is a more polished version of your prior view, not an independent reading.

This is the hypothesis confirmation problem (see A.critical.limitations, A.issue.context-scope) expressed as a prompting failure. The researcher thought they were asking a question; they were actually commissioning confirmation.

Well-bounded — edges without predetermined answers:

> Read this source. What is its central argument about the
  transmission of heretical belief? Identify the top three
  claims it makes and assess the evidence it offers for each.
  Note anything that surprised you or that cuts against
  common assumptions in the historiography.

This is bounded: specific task (central argument, three claims, evidence assessment, surprises), specific constraints (this source, not the literature generally), specific output shape (claims + evidence + surprises). It is not overbounded: Claude must read and judge; you have not told it what to find.

The three categories: necessary, misleading, unnecessary

When constructing a prompt for a complex task, everything you include falls into one of three categories. The skill is sorting them correctly.

What is necessary to say

The specific task. Not a topic, not a domain — the action. "Read and identify" is different from "read and summarise" is different from "read and critique." Specificity of verb matters as much as specificity of noun.

The constraints Claude cannot infer. Output format (CSV, markdown, continuous prose), length limits, audience ("aimed at a non-specialist reviewer"), what to do with uncertainty ("mark unclear cases with [?] rather than guessing"), where to write the output ("append to extractions.md, do not overwrite").

What success looks like, if it is not obvious. For extraction tasks: what a correct entry looks like. For analytical tasks: what kind of answer you are actually after (a claim? a list? a recommendation?). For writing tasks: who the reader is and what they need to take away.

Anything Claude cannot get from CLAUDE.md or persistent context. If the project CLAUDE.md already specifies output format, do not repeat it. If it does not specify the format for this particular task, say it here.

The scope of the source material. Which files, which pages, which sections. Not "the literature" when you mean "this paper." Not "my notes" when you mean "notes/network_analysis.md sections 2 and 3."

What is misleading to say

Your expected answer. "I think the source shows X — does it?" is not a question, it is a confirmation request. Ask: "What does this source suggest about X?" and let Claude answer. If your hypothesis is correct, it will emerge. If it is not, you will learn something.

Your emotional stake. "This is a really important part of my argument" signals to Claude that the most helpful thing is to support that importance. It cannot assess the argument impartially if it knows what verdict you need.

Prior conclusions alongside material that should be read fresh. "Here are my previous notes on this source; now read it and take notes" invites synthesis with your prior view, not fresh engagement. If you want fresh engagement, give the source without the notes. If you want synthesis, ask for synthesis explicitly — but know that is what you are getting.

The "correct" framing when you are genuinely uncertain. If you are not sure whether this is a case of heresy or political dissent, do not say "analyse this as a case of heresy" — that forecloses the question. Say "how would you characterise this case?" and let Claude's framing inform yours.

Excessive hedging and qualification. "I know this might be hard and it's okay if you can't do it perfectly..." introduces uncertainty into the task definition that Claude will resolve by lowering its own standards. State what you want. If it cannot be done at the level you need, Claude will say so.

What is unnecessary to say

Anything already in CLAUDE.md. The project context, the folder structure, the conventions, the output format defaults — if these are in CLAUDE.md, repeating them in the prompt is redundant and adds noise. Claude already knows. The one exception: if this task is an exception to a CLAUDE.md convention, you must say so explicitly.

Anything already in Memory. Personal preferences, cross-project conventions, things you have asked Claude to remember — these are already loaded. Do not re-establish them in each prompt.

Anything Claude knows from the current session. If you just established something three exchanges ago, you do not need to re-state it. Claude's session memory is reliable; treat it accordingly.

Background knowledge of your field. Claude knows what a primary source is, what Chicago citation style requires, what thematic analysis means. Explaining these wastes tokens and, worse, signals to Claude that it should respond at a more basic level than your actual needs require.

Pleasantries and apologies. "Could you please possibly try to..." adds nothing. "Extract all person names from this source" is not rude; it is clear. Clarity is respectful.

The full history of why this task exists. Claude does not need to know that this extraction is for a paper due next month, that your supervisor asked you to do it, and that you have been working on this corpus for three years. It needs to know what to do with the source in front of it.

Bounding complex tasks: decomposition is yours to do

Complex tasks — "process this entire corpus and build me a network dataset" — feel like they need more context, longer prompts, fuller explanation. Usually they need the opposite: they need decomposition into bounded subtasks.

The decomposition principle: A complex task is well-bounded when you have broken it into stages where each stage has a clear input, a clear output, and a clear success criterion. The decomposition is your intellectual work. Claude executes stages; you design the sequence.

Bad:

> Read all 40 sources in /sources/, extract the social network,
  clean the data, resolve name variants, and write me a dataset
  I can use for analysis.

This is four distinct tasks with different verification needs, different failure modes, and different decision points that require your judgment. Running them as one prompt means you cannot catch errors between stages, and you cannot make the decisions that should be yours (which name variants are the same person? what counts as a social tie?).

Better:

Stage 1: > Read sources 1–10. Extract all named persons.
           Format: CSV with columns name, source_file, folio_or_page, confidence.
           Mark uncertain names [?]. Write to extractions_batch1.csv.

[Review batch 1. Check sample against sources. Confirm format works.]

Stage 2: > Read extractions_batch1.csv. Identify likely name variant clusters —
           same person appearing under different name forms.
           Do not resolve them — list the clusters for my review.
           Write to name_variants_review.md.

[Review. Decide which variants are the same person. Record decisions in _history.md.]

Each stage is bounded: clear task, clear output, clear verification point before proceeding. The decisions that require domain knowledge — which variants are the same person — stay with the researcher, where they belong.

The decomposition also distributes ownership. When you design the stages, define the inputs and outputs, and make the inter-stage decisions, the intellectual architecture of the work is yours. Claude executes within that architecture. This is the pathway to high-ownership collaboration (see B.experience) and to the trust conditions described in B.trust.

The "state your understanding" technique

For tasks where misreading the brief is consequential — a long extraction run, an analytical task where you will act on the output — ask Claude to state its understanding of the task before executing:

> Before starting: state in two sentences what you understand
  the task to be, what the output will look like, and what
  you will do if you encounter an unclear case.
  Then proceed.

This does two things. It catches misunderstandings before they produce wrong outputs at scale. And it forces you to read Claude's interpretation and notice if it differs from yours — which it sometimes will, in revealing ways.

If Claude's statement of the task is not what you intended, correct it before it runs. This is a twenty-second check that can save significant correction work.

The relationship between bounding and persistent context

One of the most common prompting inefficiencies is re-stating persistent context in every prompt. Understanding what is already loaded changes what you need to say.

Every session starts with:

This means a prompt does not need to establish who you are, what the project is, where to write output, or what conventions apply — unless this task is an exception. The prompt needs only: the specific task, the specific source or material, and any task-specific constraints not covered by standing context.

A well-maintained CLAUDE.md effectively pre-bounds every task in the project. The work of bounding in the prompt is reduced to the task-specific layer. This is one of the concrete ways that project infrastructure pays dividends in prompt quality: not just that Claude knows the context, but that your prompts can be sharper because you are not carrying context overhead.

The exception signal: When this task differs from what CLAUDE.md specifies, say so explicitly: "For this task only, output in JSON rather than CSV." The explicit exception overrides the standing context. Without it, Claude will follow the standing context even if the prompt implies something different.

When the form is the bound: using official structures as context

There is a specific class of task where the bounding work has already been done — by someone else, in an official document you have not yet given Claude. The failure mode is consistent and easy to miss: you ask Claude to draft a section of a grant proposal, a journal cover letter, an institutional report, a compliance statement. Claude produces something that looks exactly right. It has the correct register, plausible section headings, an appropriate tone. What it does not have is the actual structure — the specific section labels your funder requires, the 1,100-character abstract limit, the mandatory subsections that must all be present or the application is disqualified.

Claude's sense of what a GAČR proposal looks like, or what a Nature submission requires, is approximate — a trained average of what it has seen, not your actual call or your actual journal's current author guidelines. That average is useful for generating a plausible draft; it is not reliable for generating a compliant one.

The pattern: For any task where you are producing output for a defined external specification, give Claude that specification as context before asking it to produce content. The form does the bounding work so you do not have to reconstruct it from memory or from Claude's approximation.

In practice: 1. Find the official requirements — the tender document, the submission guidelines, the institutional template 2. Convert the structural parts to a reference file in your project folder (not the full PDF; a markdown summary of section names, character limits, required fields, forbidden deviations) 3. Reference it at the start of the drafting session: "Read _gacr.structure.md. Draft Part C1 section (b) — substance and methods. Respect the 10-page total limit for Part C1."

The reference file serves two purposes: it gives Claude the actual constraints to work within, and it stays in the project folder so every drafting session starts from the same specification rather than from Claude's approximation of it.

A concrete case: The GAČR Standard Project proposal is submitted via an online web application; there is no downloadable template. Asked to draft "the state of the art section," Claude would produce a plausible research justification — but would not know that this section is Part C1(a), that the section must also include the applicant's prior contributions to the topic, that the total Part C1 document is limited to 10 A4 pages, or that omitting any of the eleven required subsections (a through k) renders the application incomplete. Giving Claude a structured reference extracted from the 88-page Tender Document before drafting resolves all of this. See _gacr.standard.proposal.md in this repository for the pattern applied directly.

Where this intersects with context scope: The official specification belongs in a separate reference file, not in CLAUDE.md (it is task-specific, not always-true project context) and not pasted raw into the prompt (too long, mixed with irrelevant administrative text). A clean structural summary — section names, limits, required content per section — is the right unit. See A.issue.context-scope — execution tasks require format context; this is what that principle looks like for compliance-sensitive output.

Quick diagnostic

Output is generically right but not specifically useful — the task was underbounded. Claude addressed a broader version of your question than you intended. Add specificity: narrower task, named source material, defined output shape.

Output confirms what you already thought, feels like your view back at you — you included your expected answer in the prompt. Remove hypothesis, prior conclusions, or emotional framing. Ask the question cleanly.

Output is technically correct but inflexible, misses important edge cases — the task was overbounded. You specified so much that Claude had no room to bring judgment. Loosen the specification; give bounds, not answers.

Output for a long task went wrong partway through and you cannot pinpoint where — the task was not decomposed. Run it in stages with verification between them.

You are repeating the same context in every prompt — that context belongs in CLAUDE.md or Memory, not in the prompt. Extract it once, maintain it persistently, stop carrying it by hand.

Output for a compliance-sensitive task looks right but misses required fields, violates length limits, or uses the wrong section structure — Claude worked from its approximate knowledge of the form rather than the actual specification. Extract the official requirements into a reference file and give it to Claude before drafting. The form should do the bounding, not your memory of what the form requires.

Claude's output addressed a different question than you asked — try the "state your understanding" step before execution. Claude's interpretation of the brief differs from yours.

Related