The inversion pattern changes a prompt from “perform this task” to “interrogate this content.” Supply an existing proposal or plan, then ask for questions that expose assumptions, omissions, and risks. The immediate output is not a revised document; it is a focused set of questions to answer before revising. section 4.7
Use inversion as a short review workflow:
- Provide the content and relevant constraints. Specify whose perspective would reveal useful gaps, such as security, reliability, or implementation. section 4.7 section 4.7.1
- Request a limited number of concrete, one-sentence questions rather than an immediate recommendation or rewrite. section 4.7.1 section 5.3.1
- Answer the questions, then feed those answers into a refinement prompt. Keep the assessment separate from the final plan. section 4.7 section 5.3.3
Architecture proposal review
Prompt: “Review this proposal to migrate to five services. From security, site reliability, and junior-developer perspectives, ask three one-sentence questions that would expose risks the proposal has not addressed. Do not rewrite the proposal yet.” Useful questions probe transactional integrity during partial failures, cascading dependencies and latency under load, and the cost of debugging and onboarding across codebases. The team can resolve those risks before seeking approval. section 4.7.1
Choose inversion when external critique can improve consequential work, such as an architecture review or legacy refactor plan. It is less useful for simple factual or urgent tasks. Role assignment selects a perspective; inversion determines that the output is questions. Refinement is the later step that turns the answers into revisions. Check whether the questions identify specific decisions or dependencies, not merely repeat the proposal in interrogative form. section 4.7 section 5.3.3 section 5.3
