Opus 4 7 Prompt Writer

Opus 4.7 Prompt Writer

Write one prompt that another Claude model can execute with minimal ambiguity. Optimize for action, persistence, and verification, not for prose elegance.

Read references/anthropic-claude-prompting.md when the task is long-horizon, tool-heavy, or expensive enough that prompt quality matters materially.

Workflow

1. Capture the real task.
2. Identify the execution environment.
3. Define hard constraints and done criteria.
4. Decide whether the prompt must explicitly push tool use, persistence, and validation.
5. Write the prompt in XML-style sections.
6. Add an execution loop and verification gate.
7. Remove vague or conflicting instructions.

Capture The Real Task

Before writing the prompt, extract:

• The objective: what must be changed, fixed, implemented, or reviewed.
• The environment: repo path, branch, local services, tools, runtime, secrets assumptions.
• The constraints: files or systems that must not be touched, style rules, required docs, approval limits.
• The validation surface: tests, build, lint, integration suites, smoke checks, manual verification, or whatever the project actually uses. Let the user name their own checks instead of assuming any specific stack.
• The completion rule: what must be true before the model may stop.

If the user supplied a spec or earlier review findings, turn those into explicit required work items. Do not leave them implicit.

Prompt Shape

Use XML-like sections because Claude responds well to explicit structure:

• <role>: who the model is for this task.
• <mission>: the concrete outcome.
• <context>: repo, branch, docs, prior findings, environment.
• <requirements>: the non-negotiables.
• <workflow>: the order of work.
• <tooling>: how and when to use tools.
• <validation>: exact commands and checks.
• <done>: stop condition.
• <output>: how to report results.

Use short, imperative bullets inside each section. Keep the prompt concrete.

Model-Specific Rules

Apply these Opus 4.7-specific patterns:

• Be explicit. Claude Opus 4.7 follows instructions literally, especially at lower effort. Do not rely on implied behavior.
• Use high-level reasoning guidance before detailed micromanagement. Prefer "reason carefully, then act" over a brittle human-written hidden algorithm.
• If tool use is important, say so plainly. Current Anthropic docs note that Claude Opus 4.7 tends to use fewer tools and fewer subagents by default than Opus 4.6, while high or xhigh effort increases tool use in agentic search and coding.
• For coding and long-horizon agent prompts, recommend claude-opus-4-7 with thinking: {type: "adaptive"} and output_config.effort: "xhigh" when quality matters, or at least "high" for intelligence-sensitive work. Use "low" only for short, scoped, latency-sensitive tasks.
• Do not recommend manual extended-thinking budgets for Opus 4.7. thinking: {"type": "enabled", "budget_tokens": N} is removed for Opus 4.7 and returns an error.
• Do not recommend sampling parameters (temperature, top_p, top_k) or assistant-message prefill for Opus 4.7. Prefer prompt instructions and structured output configuration.
• Opus 4.7 has built-in progress updates in long agentic traces. Ask for specific progress-update behavior only when the user needs a particular cadence or format.
• If the harness supports context compaction or external memory, say that explicitly and instruct the model not to stop early due to token budget.
• Require self-checking before final output. Tell the model to verify against concrete criteria and rerun checks after material fixes.

Execution Loop

For long-running coding prompts, include a loop like this in the prompt:

1. Read the relevant repo instructions and source files first.
2. Build a concrete implementation plan from the actual code, not assumptions.
3. Make the smallest correct change set that resolves the required items.
4. Run the required validations.
5. If validation fails, fix the cause and rerun until green or until blocked by a real external dependency.
6. Do not stop at partial implementation, analysis-only output, or "here is what I would do."

If persistence matters, tell Claude to continue until the work is implemented and validated end-to-end.

Validation Rules

Name the exact commands and required services. Good prompts do not say "test thoroughly"; they say exactly what must run.

For tasks with local infrastructure, spell out startup expectations using whatever the project actually uses, named by the user, not assumed:

• Start any required services (databases, queues, container runtimes, dev servers).
• Apply any required schema or data migrations.
• Start any worker or background processes the workflow depends on.
• Run end-to-end or browser checks only against the correct local environment.

If the prompt requires running multiple services or end-to-end checks, say that success is not complete until those paths have been exercised and any failures addressed or reported with evidence.

Template

<role>
You are Claude Opus 4.7 acting as a persistent senior software engineer in this repository.
</role>

<mission>
Implement the required changes fully. Do not stop at analysis or partial fixes. Continue until the required items are implemented, validated, and reported clearly.
</mission>

<context>
- Repository: {{repo_path}}
- Branch: {{branch}}
- Key repo instructions: {{repo_instructions}}
- Required work items: {{required_items}}
- Relevant files/docs: {{relevant_files_and_docs}}
</context>

<requirements>
- Follow the repository instructions exactly.
- Read the relevant code before changing it.
- Make the smallest correct changes that fully resolve the required items.
- Do not claim success without running the required validations.
- Do not stop early because of token budget or task length. If the harness compacts context or supports memory files, persist state and continue.
</requirements>

<workflow>
1. Read the relevant docs, specs, and code paths first.
2. Confirm the real implementation gaps from the code, not assumptions.
3. Implement the missing items.
4. Run the required local services and validations.
5. If a check fails, fix the cause and rerun.
6. Only finish once the done criteria are satisfied or a real external blocker remains.
</workflow>

<tooling>
- Use tools proactively when they are needed to inspect files, run commands, start services, exercise the app, and verify behavior.
- For this task, do not stay in reasoning-only mode. Take action.
- After each tool result, reflect on what changed and choose the best next action.
- When independent checks can run in parallel, do that.
</tooling>

<validation>
- Required commands:
  - {{command_1}}
  - {{command_2}}
  - {{command_3}}
- Required services or environments: {{services_named_by_user}}
- Rerun the relevant checks after material fixes.
</validation>

<done>
Do not finish until all required items are implemented and the required validation path has run successfully. If something cannot be completed, state the exact blocker, the evidence, and what remains.
</done>

<output>
Report:
- what changed
- what validations ran and their outcomes
- any remaining blockers or risks
</output>

Anti-Patterns

Avoid these prompt mistakes:

• Vague goals with no acceptance criteria.
• Asking for persistence without naming the validation loop.
• Asking for tool use only indirectly when tool use is actually required.
• Overstuffing the prompt with background that does not change execution.
• Mixing contradictory instructions like "be extremely proactive" and "only use tools when absolutely necessary" without task-specific guidance.
• Letting the model decide whether validation matters.

Final Check

Before returning a prompt, verify that it:

• names the exact implementation scope
• names the exact validation commands
• names any required services or environments and how to start them
• tells Claude not to stop at analysis
• tells Claude what counts as done
• uses no tech-stack names the user did not mention