How to Stop Claude Being Lazy or Leaving Work Unfinished

Claude leaves work unfinished when it does not know what "done" looks like. It produces a partial answer, a placeholder, or an abbreviated version and stops. This usually happens with tasks that have unclear scope, tasks that require many steps, or tasks where Claude runs out of useful context mid-session. A tool like fenbs helps by keeping the task plan, completion criteria, and where the work stopped so the next session can continue from the right place.

The fix is to make the completion criteria explicit before Claude starts. A task without a definition of done is a task Claude will interpret on its own terms, and its terms tend to be shorter than yours.

What incomplete work looks like

Some versions of incomplete work are easy to spot: Claude stops in the middle of a list, skips a required section, or produces a single paragraph where you expected a full document. Others are harder to notice: Claude writes a summary instead of the detailed breakdown you asked for, or implements one part of a specification and describes the rest in comments.

In Claude Code, incomplete work often looks like "I'll leave the rest as an exercise" or a comment saying "add error handling here" without actually adding it. In Claude.ai, it often looks like a response that is technically responsive but much shorter than the task warranted.

• A list that stops before reaching the stated number of items.
• A document with some sections written and others described but not written.
• Code with placeholder comments instead of working implementations.
• A summary of what you asked for, rather than the thing itself.
• A partial plan with a note that "the rest depends on your specific situation."

How to set explicit scope

The most useful thing you can do before giving Claude a long task is to describe the output precisely. Not "write a marketing plan" but "write a marketing plan with five sections: target audience, key messages, channel mix, quarterly milestones, and budget assumptions. Each section should be at least three paragraphs."

Specifics give Claude a checklist to work through. Without them, Claude decides when to stop, and it will often stop earlier than you want. The more detailed your description of the expected output, the less interpretation Claude needs to do.

State what is explicitly out of scope too. "Do not include competitive analysis in this document" or "skip the executive summary, I will write that separately." Scope that is left out is not necessarily excluded in Claude's reading of the task.

How to write completion criteria

Completion criteria are a list of things that must be true for the task to be finished. They are different from the description of the output. The output describes what you want. The criteria describe how you will know you have it.

For a document task: "The plan is complete when all five sections are written in full, each section includes at least one concrete example, and the budget section includes three separate cost scenarios." For a code task: "The function is complete when it passes all five test cases, handles a null input without throwing, and has no comments saying placeholder."

• List the sections, components, or items that must be present.
• State what each component must contain or demonstrate.
• Add a check: "Before you send this, confirm you have completed all items in this list."
• For code: name specific behaviors that must work, not just "implement the feature."

How to add verification steps

A verification step asks Claude to check its own output against the criteria before finishing. "Before sending, list the five required sections and confirm each is written in full." This is not a guarantee of quality, but it catches the most obvious gaps.

For code work, the verification can be a specific test: "Run the tests and confirm all pass before finishing." For written work: "Re-read your task description and list any requirement that is not addressed in your draft." Claude will usually find at least one gap it missed.

Build the verification into the task rather than asking for it afterward. "Write the report and then review it against this checklist: [list]. If anything is missing, add it before you finish." This way the verification is part of the task, not a separate pass you have to request.

What to do when a session ends early

Long tasks sometimes run into the end of a context window or a session timeout. When that happens, you have two options: resume in the same session with a summary of where the work stopped, or start a fresh session with that summary plus the original task description.

A useful summary for resuming says: which parts are complete, which part was in progress when the session ended, and the exact next step. "Sections one through three are complete. Section four was being drafted but is not finished. The next step is to finish the budget table in section four and then write section five." That is enough for a fresh session to continue without replaying the whole conversation.

The article on stopping a Claude Code task covers the options for managing long-running sessions in Claude Code specifically.

How to do this with fenbs

1. Create a free account and add the project where you are experiencing incomplete work from Claude.
2. Create a task for each significant piece of work. Add the scope, the expected output, and the completion criteria to the task plan.
3. Connect your AI apps from Integrations and ask the assistant to read the task plan at the start of the session.
4. At the end of a session, ask the assistant to record what it completed, what it started but did not finish, and the exact next step in the task.
5. The next session starts by reading the task plan and where the work stopped. It continues from the right point without you summarizing the whole conversation.