An agent consistently generates overly verbose commit messages — each message contains 5-7 sentences describing implementation details when the team standard is a single-line imperative statement under 72 characters. The agent's system prompt says: 'Write clear, descriptive commit messages that help developers understand the changes.' Analysis of 200 failing cases shows no tool errors or context issues. Which revision to the agent's instruction would MOST effectively correct this behavior?

The original instruction 'Write clear, descriptive commit messages that help developers understand the changes' is ambiguous in two critical ways: 'Clear and descriptive' in natural language often means detailed and thorough — the opposite of the team's one-line standard, and there is no format constraint: without a maximum length, line count, or format specification, the agent defaults to what it considers 'helpful,' which is typically more content rather than less.

The correct revision is to replace the vague instruction with a precise, constrained specification: 'Write commit messages as a single imperative sentence in the format: <verb> <what was changed>. Maximum 72 characters. Example: Add null check to user authentication handler. Do not include implementation details, reasoning, or multi-sentence descriptions.'

Effective instruction revision follows the principle of maximum constraint specification: 1. Format template: '<verb> <what was changed>' eliminates ambiguity about structure 2. Hard numeric constraint: '72 characters maximum' is objective and verifiable — the agent can self-check compliance 3. Concrete example: 'Add null check to user authentication handler' shows the exact style expected, conveying length, verb tense, and level of abstraction simultaneously 4. Explicit exclusions: 'Do not include implementation details, reasoning, or multi-sentence descriptions' closes the specific loopholes the agent was using

The vague instruction to make commit messages 'concise and not excessively long' is still relative and vague — it does not define what 'concise' means quantitatively and still leaves room for 3-sentence commit messages. The word 'excessively' is especially undefined. The post-processing step where a second agent truncates any commit message longer than 72 characters treats the symptom without addressing the root cause in the instruction. Truncated multi-sentence messages would be semantically incomplete rather than properly formatted. Fine-tuning the model on a dataset of 1,000 correctly formatted commit messages from the team's repository is a significant investment that is disproportionate to the problem — this is an instruction quality issue, not a model capability issue. Fine-tuning is appropriate when the model lacks the capability, not when the instruction lacks precision.