- Ask five people editing your prompts what a good prompt looks like and you get five opinions - and these days those five sit across engineering, product, and business.
- Asking your coding agent does not settle it either: it gives a different answer every run, usually by adding, and usually fixated on whatever failed last.
- When Hosho reviews a prompt it answers with a research-backed, structured approach instead: four factors, twelve sub-factors, and under each a set of concrete pass/fail checks drawn from published studies and each provider’s own documentation.
- The Hosho MCP and prompt editor bring those checks to life, connected to your coding agent with the full context of your repo to land the right fixes.
Four fundamental questions
| Factor | The question it asks |
|---|
| Scope | Is this the right amount of work for one pass? |
| Structure | Is it arranged so the model can follow it? |
| Guidance | Is the model equipped to produce the right thing? |
| Coherence | Does it hold together as one clean signal? |
These four fail independently - a prompt can be beautifully written yet overloaded, tightly scoped yet unparseable - so polish in one buys nothing in the others.
Scope: is this the right amount for one pass?
Focus - one job per call
- Instruction-following degrades as unrelated demands pile into one call, with earlier demands satisfied at the expense of later ones1.
- A single coherent objective, sized for one pass, removes that competition.
Structure: is it arranged so the model can follow it?
Layout - labelled, ordered sections
- Formatting alone can swing accuracy by double digits2, and unlabelled or mislabelled boundaries invite instructions landing on the wrong content.
- Clear labels, with stable instructions before per-call content, keep interpretation consistent.
Tools - descriptions drive selection
- A tool’s written description is what the model selects on: precise descriptions improve invocation, while vague or overlapping ones cause wrong-tool choices as the toolset grows3.
- Every description needs purpose, inputs, and when to use it.
Output & validation - defined format, anchored checks
- An unstated output format varies between runs and breaks whatever parses it downstream4; an explicit format with a minimal example produces consistent output.
- Self-review helps only against a stated, verifiable criterion - an unanchored “double-check your work” adds cost without benefit5.
Guidance: is the model equipped to produce the right thing?
Goal & role - success defined, voice set
- An explicit success condition gives generation and verification a common target; “good” or “helpful” is interpreted differently every run.
- A persona shapes voice and audience fit but does not improve factual accuracy6 - roles belong where tone matters.
Inputs - every block identified
- Models do not reliably distinguish instructions from data7: examples get treated as source material, reference text gets obeyed as instructions.
- Say what each block is inside the prompt itself; labels that live only in your code are invisible to the model.
Method & reasoning - decision rules stated
- Where a task has a genuine decision point and no stated rule, outputs diverge as the model resolves it differently each run4.
- State the rule or explicitly delegate the choice - and giving the reason behind a preference rule lets the model cover cases the wording misses.
Provider fit - matched to the target model
- Each provider publishes its own guidance on delimiters, ordering, examples, and reasoning scaffolding - and one provider’s recommendation is sometimes another’s anti-pattern8.
- Alignment is scored against the target provider’s current documentation, including whether the target is a standard or reasoning model.
Coherence: does it hold together as one clean signal?
Clarity - one reading only
- Models do not surface ambiguity: a controlling phrase with two readings is resolved silently, and differently across runs9.
- Sentences with interwoven conditions and exceptions fail the same way, the core action dropped or misapplied.
Criteria & precedence - decidable rules, stated priority
- When rules conflict or a threshold is vague, models resolve the tension silently - they detect the conflict and say nothing10.
- Priority must be stated in words (list position is not precedence), and any qualifier gating a decision needs an operational definition.
Consistency - parts that agree
- Two names for one referent get treated as two things, and two stated values for one fact leave no correct output to converge on.
- Examples carry particular weight: a demonstration that violates a stated rule can override the rule11.
Anti-bloat - no dead weight
- Even one off-task sentence degrades performance on problems the model otherwise solves12, and clusters of narrow rules that one general rule would cover invite contradiction.
- The exception: deliberate repetition of outcome-critical constraints earns its place.
Sign in and see how your prompt scores against all twelve.
Sources
- 1.IFScale: How Many Instructions Can LLMs Follow at Once? arXiv:2507.11538 ↑
- 2.Sclar et al., Quantifying Language Models’ Sensitivity to Spurious Features in Prompt Design (FormatSpread), ICLR 2024. arXiv:2310.11324 ↑
- 3.Patil et al., Gorilla: Large Language Model Connected with Massive APIs. arXiv:2305.15334 ↑
- 4.What Prompts Don’t Say: Understanding and Managing Underspecified Prompts. arXiv:2505.13360 ↑
- 5.Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024. arXiv:2310.01798 ↑
- 6.Zheng et al., When “A Helpful Assistant” Is Not Really Helpful: Personas in System Prompts Do Not Improve Performance, Findings of EMNLP 2024. arXiv:2311.10054 ↑
- 7.Zverev et al., Can LLMs Separate Instructions From Data? And What Do We Want Them To? arXiv:2403.06833 ↑
- 8.Provider prompting documentation: Anthropic (docs.claude.com), OpenAI developer docs, Google (ai.google.dev), DeepSeek (official R1 paper and README), read July 2026. link ↑
- 9.Liu et al., We’re Afraid Language Models Aren’t Modeling Ambiguity (AmbiEnt), EMNLP 2023. arXiv:2304.14399 ↑
- 10.ConInstruct: conflict detection and resolution under conflicting instructions. arXiv:2511.14342 ↑
- 11.Do as I Say, Not as I Do: in-context demonstrations under pressure against written instructions. arXiv:2605.20382 ↑
- 12.Shi et al., Large Language Models Can Be Easily Distracted by Irrelevant Context, ICML 2023. arXiv:2302.00093 ↑