Prompt Engineering

Understand Business Logic — Code Rules in Business Terms

The discount rules live in code; the questions come from sales. This prompt explains implemented business logic to a technical manager — behavior and risk, minimal code.

Overview

Some explanations are not for the people who will edit the code — they are for the people who own the rules the code implements. This prompt pairs the function-walkthrough mode with the technical-manager audience: technically literate, not working in this code. The contract explains in terms of behavior, responsibilities, risks, and effort — not implementation mechanics — keeps code references minimal, and translates any cited code into a business statement. A quick-summary depth keeps it to what a decision-maker absorbs in two minutes: what the rules actually are, where they surprise, and which tradeoffs matter.

Workflow

Declare the real audience
Technically literate, not in this code — the assumptions change everything downstream.
Translate code to statements
Every cited condition becomes a business sentence: who qualifies, when, and why not.
Keep it two minutes deep
The rules, the surprises, and the risks — the quick-summary depth cuts everything else.

Why This Works

Business-statement translation answers the question stakeholders actually asked
Minimal-code discipline keeps the explanation readable outside engineering
Surprises-first ordering surfaces exactly the rule mismatches that caused the question

Best for

Logic that gets questioned by non-engineers
Pricing, eligibility, and policy code
Bridging the engineering-business explanation gap

Not for

Changing the rules once understood — that's the Refactor Prompt Builder (or a feature change)
Extracting the rule values into structured data — that's the Extraction Prompt Generator

Use cases

Answering "why doesn't this customer get the discount?" from the code
Explaining implemented rules to product and sales stakeholders
Checking whether the code's rules match the business's belief about them

Customize This Resource

Opens this setup in Code Explanation Prompt. Generate to get the full understanding contract — then adjust the mode, audience, and depth.

Open in Code Explanation Prompt

Prompt Template

EXPLANATION OBJECTIVE
Explain the discount eligibility rules implemented in this code, in business terms.
Explanation mode: function walkthrough — inputs, outputs, execution flow, decisions, and side effects.
The goal is understanding, not judgment: explain what this code does and why it is built this way — and clearly separate what the code shows from what you infer.

CODE CONTEXT
System context: Pricing engine; sales keeps asking engineering why certain customers do not get the loyalty discount.
Code to explain:
```
[Paste the code to explain here]
```

AUDIENCE PROFILE
Audience: a technical manager — technically literate, but not working in this code.
- Assume: comfort with technical concepts; no fluency in this language or codebase.
- Explain in terms of behavior, responsibilities, risks, and effort — not implementation mechanics.
- Keep code references minimal; where code must be cited, translate it into a business statement.

EXPLANATION STRATEGY
1. State the contract first: inputs with their expected shapes, outputs with their meaning, errors with their triggers.
2. Walk the execution flow in order, pausing at every decision point to explain both branches.
3. Surface every side effect — writes, calls to other systems, mutations of shared state — and when each happens.
4. Distinguish the happy path from the edge paths; name the conditions that route execution off the happy path.
- Depth: quick summary — the explanation must fit in a few paragraphs a reader absorbs in two minutes.
- Cover the purpose, the main flow, and the one or two things most likely to surprise — nothing else.
- Skip implementation detail unless omitting it would mislead.

KEY CONCEPTS
- Explain each non-obvious variable, structure, and helper the walkthrough touches — what it holds and why it exists.
- Order concepts by how load-bearing they are for understanding this code — not by where they appear in the file.

EXECUTION FLOW
- Present the flow as a numbered sequence; at each branch, state the condition in plain language and what each outcome means.
- Where the flow depends on state or configuration, say which, and what each setting changes.

DESIGN DECISIONS
- Where the implementation makes a visible choice — an early return, a special case, a particular ordering — explain what the choice achieves.
- Discuss only decisions actually visible in the code; rationale you cannot evidence belongs under ASSUMPTIONS, labeled as inference.

ASSUMPTIONS
- Separate what the code DOES (verifiable from the source) from why it might be that way (inference).
- Label every statement about intent, history, or rationale as an INFERENCE unless the code itself evidences it — a comment, a test, a telling name.
- Where behavior cannot be determined from the provided code, say "cannot be determined from this code" — never fill the gap with a plausible story.

TRADEOFFS
- Note only the tradeoffs that materially affect how this code is used or changed.

LEARNING NOTES
- End with the contract restated in two sentences: what you give it, what you get back, and what else changes.

NON-GOALS
- Do not review code quality — no findings, no severities, no verdicts.
- Do not debug failures — explain the behavior that exists without diagnosing it.
- Do not refactor the code or propose rewrites.
- Do not generate tests.
- Do not invent requirements or unstated intentions.
- If something looks defective, note it as a question for the team — investigating or fixing it is out of scope.
- Clearly separate facts from assumptions throughout.

OUTPUT REQUIREMENTS
- Structure the explanation with headings that mirror the sections above — a reader should be able to navigate it without reading all of it.
- Anchor every claim about behavior in the code: name the function, branch, or line it comes from when precision matters.
- Calibrate every section to the stated audience — too basic wastes their time, too advanced loses them.
- End with the open questions: what could not be determined from the provided code, and who or what could answer it.

Related Resources

Explore more resources that work well with this one.

Used in Playbooks

Complete workflows that include this resource as a step.

AI Test Generation Workflow Workflow · 5 steps

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources