I’m getting a bit fed up with the constant “Fable 5 doesn’t work” or “Fable 5 is shit” posts.

It works perfectly fine for me. So does Opus 4.8, the problem is not the model, it’s vague prompts, missing context, unclear requirements, and no proper acceptance criteria.

This is the prompt template I made and use. It has worked great for me across coding, Unreal Engine, debugging, and larger project tasks.

Sharing it here in case anyone wants to try it, and always check what Claude did because it doesn't always align with what you want, I do it this way cause sometimes he jumps the MD file instructions, you can always use a hook as well, inside .claude/settings.json

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Your job is to complete the specific task below exactly as requested.

Do not redesign the whole project, change the overall direction, or replace my decisions with what you personally think would be better.

Task

[DESCRIBE EXACTLY WHAT YOU WANT DONE]

Intended result

When finished, it should:

• [EXPECTED RESULT 1]
• [EXPECTED RESULT 2]
• [EXPECTED RESULT 3]

The main goal is:

[EXPLAIN WHAT THE FINAL RESULT SHOULD LOOK LIKE, FEEL LIKE, OR DO]

Current situation

This is what currently exists:

[DESCRIBE THE CURRENT STATE]

This is already working and must not be broken:

• [WORKING FEATURE 1]
• [WORKING FEATURE 2]
• [WORKING FEATURE 3]

Relevant files, folders, assets, screenshots, references, or documentation:

• [FILE OR FOLDER]
• [REFERENCE]
• [DOCUMENTATION]
• [SCREENSHOT OR EXAMPLE]

Exact instructions

Follow these instructions:

1. [INSTRUCTION 1]
2. [INSTRUCTION 2]
3. [INSTRUCTION 3]
4. [INSTRUCTION 4]

Important details:

• [DETAIL THAT MUST NOT BE MISSED]
• [DETAIL THAT MUST NOT BE MISSED]
• [DETAIL THAT MUST NOT BE MISSED]

What not to do

Do not:

• Change unrelated systems.
• Rewrite working code without a clear need.
• replace my requested design with a different one.
• Add features I did not request.
• Remove existing functionality.
• Use placeholder implementations when the real implementation is possible.
• Claim something works without testing it.
• Stop after only describing what needs to be done.

How to approach the task

First, inspect the existing implementation and understand how the relevant part currently works.

Use the project’s existing structure, patterns, assets, and tools where possible.

Before changing something, confirm that it is connected to the task.

When the instructions are clear, proceed without repeatedly asking for permission.

If a small detail is unclear, inspect the project and use the interpretation that best matches the existing implementation, references, and intended result.

Only stop to ask me when missing information would create two significantly different results and the project provides no evidence for either option.

Reference priority

When deciding how the result should work or look, use this order:

1. My written instructions.
2. The references, screenshots, or examples I provided.
3. The existing project style and behaviour.
4. Official documentation for the exact version in use.
5. Your own judgement only when none of the above answers the question.

Do not ignore a direct instruction because another approach is more conventional.

Verification

The task is not complete until you have checked the actual result.

Where applicable:

• Build or compile the project.
• Run the relevant tests.
• Launch the project or application.
• Test the feature directly.
• Check for errors and warnings.
• Confirm existing related behaviour still works.
• Compare the result against every requirement in this prompt.
• Test the most likely failure cases.
• Repeat the setup or generation process when duplicate protection or repeatability matters.

Do not treat a successful build as proof that the feature works correctly.

Do not report something as completed if it was only implemented but not tested.

Completion conditions

The task is complete only when:

• Every requested change is implemented.
• The final result matches the intended outcome.
• Unrelated behaviour has not been changed.
• The relevant build, test, editor, or runtime checks pass.
• No temporary workaround or placeholder remains.
• Every requirement has been reviewed one final time.

Progress messages

Keep progress updates brief.

Tell me:

• What you inspected.
• What you found.
• What you changed.
• What you tested.
• Whether the test passed or failed.

Do not fill progress updates with generic explanations or repeated plans.

Final response

Start with whether the task was completed successfully.

Then include:

• What you changed.
• Which files, assets, or settings were affected.
• How you tested it.
• The actual test results.
• Anything that could not be verified.

Be honest about anything that remains incomplete.

Do not end with suggestions for unrelated improvements or ask whether you should continue with work that was already part of this task.