Coding Workflows
"Explain this code" gets line-by-line narration. Pick an explanation mode, an audience, and a learning depth — and get an understanding contract: six explanation strategies with different educational objectives, audience profiles that change the assumptions (not just the wording), and an honesty rule where intent is labeled as inference, never narrated as fact.
What code, explained for what purpose? E.g. "Explain the order processing module to a developer who joined this week."
Deep Dive demands rationale, tradeoffs, and alternatives — and forbids fabricated design stories.
What the system is for — the context "explain this code" always loses. One or two sentences.
Explain the idea before the implementation: numbered steps with their contribution, honest best/worst-case complexity, and the alternatives each decision point rejected.
Explain a system's shape, not its statements: layers and their owners, boundary contracts, dependency direction, and one request traced through every handoff.
For developers in their first year: one concept at a time, every term defined before use, real values traced through every step — and "simplified" said when simplifying.
Before touching a shared module: what it depends on, what depends on it, and which of those dependencies are risky — direction mapped, cycles flagged.
What actually happens when a client calls POST /orders: the contract, every decision point, every side effect, and the conditions that route off the happy path.
Build a prompt that walks through a function line by line — what each line does and why — calibrated for a developer still learning the codebase.
"Explain this code" gets line-by-line narration. The understanding contract gets strategy, audience-fit, design decisions, and inference labeled as inference.
The class everyone avoids: its actual responsibilities, its key methods, its side effects, and the paths through it — understood before anyone proposes splitting it.
Build a prompt that breaks a regular expression down piece by piece in plain language — what it matches, what each part does, and what it rejects.
For code whose authors are gone: reconstruct likely intent as labeled inference, hunt undocumented assumptions, and end with a maintenance brief — what's safe to touch.
A capable engineer with zero context on your codebase needs different explanations than a junior: conventions, vocabulary, and where everything connects — not syntax.
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.
A complete AI-assisted review pass — not one prompt — that ends with ranked findings, tests guarding behavior, and a refactor plan when one is warranted.
The order that actually finds bugs instead of guessing at them — so you end with a verified fix, not a plausible one that quietly returns next week.
Work a live production incident in the right order — triage and stabilize first, then find the cause, then write the summary and postmortem — so the fire is out before the writeup begins.
Recover a legacy system's architecture before you change it — package the codebase context, explain the current structure, surface the risks and seams, then document the recovered architecture.
Update old, risky code you didn't write — safely — by understanding and pinning its behavior in tests before you change a single line.
Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps.
Speed up code that works but drags — find the actual hot path instead of guessing, understand why it's slow, optimize it, and prove with tests that you changed the speed and nothing else.
Get up to speed on an unfamiliar codebase in an afternoon — ground the AI in the project, have it explain the hard parts, and keep what you learn.
Generate documentation that matches the code instead of drifting from it — have AI explain what the code really does, write it up as structured docs, then validate the format holds.
The full path to taming an inherited codebase — understand it, document its architecture, pin its behavior with tests, then refactor, modernize, review, speed up, and ship it without breaking what works.
The full path to docs people can actually navigate — plan the doc set, structure the site, write the guides and the API reference, then ship it as a coherent documentation site.
The full path to knowledge that's findable by people and AI — plan the taxonomy, structure it for search, write the articles, tag the metadata, make it retrievable, then ship it maintainable.
Type "refactor this" on code you don't fully understand and the AI — which understands it no better — rewrites a load-bearing line. Here's how to run an explanation pass first: what the code does, what it assumes, and which lines are risky to touch, before you change anything.
Ask AI to "explain this codebase" and you get generic architecture and "read the controllers" — no reading order, no flow, nothing to act on. Here's how to explain a codebase for onboarding: a map of folders and flow, a reading path, safe first tasks, and the unknowns to confirm.
State the explanation objective, pick the mode — High-Level Overview, Function Walkthrough, Architecture Explanation, Legacy Code Analysis, Algorithm Breakdown, or Beginner Friendly — and choose the audience and learning depth. Each mode is a different educational objective with its own strategy, execution-flow treatment, and learning notes; each audience changes the assumptions, not the wording — a senior developer gets rationale instead of narration, a technical manager gets behavior and risk with minimal code. Optionally add the business context that "explain this code" always loses, and paste the code itself (carried verbatim in a fenced block). The live Explanation Preview shows the contract's shape. Click Generate Explanation Prompt for the full understanding contract: strategy, key concepts, execution flow, design decisions, an assumptions discipline where intent is labeled as inference, tradeoffs scaled to the chosen depth, and learning notes. Nothing leaves your browser.
No — it builds the contract. The output is a prompt that tells an AI how to explain: which strategy to follow, what the reader already knows, how deep to go, and how to handle what it cannot determine. The flagship is the audience-aware system: the same code explained for a junior developer, a senior developer, and a technical manager produces three genuinely different explanations, because the assumptions differ — not just the tone.
Because it produces line-by-line narration: a restatement of what the code visibly does, with no business context, no architecture context, and no learning value. The contract replaces narration with an educational objective — purpose and system role for an overview, contract and side effects for a walkthrough, likely intent and hidden assumptions for legacy code — plus an audience profile so the explanation lands at the right level.
Different verbs. Review JUDGES — it asks "what is wrong?" and produces findings with severities. Explanation TEACHES — it asks "how does this work and why?" and produces understanding. The contract's non-goals state it directly: no findings, no severities, no verdicts. And in this category: Debugging investigates failures, Refactor transforms code, Test Case validates it — Explanation understands it.
The contract tells the model to note it as a question for the team — and stop there. Investigating a failure is the Debugging Prompt Generator's job; explaining behavior is this tool's. The same discipline applies to legacy oddities: a strange special case is treated as evidence of a forgotten requirement, inferred carefully and labeled as an inference, never "fixed" in the retelling.
The assumptions. Junior: syntax is known, patterns and terms are not — everything defined on first use, concrete examples required. Senior: anything readable from the code is assumed understood — the explanation spends itself on rationale, constraints, and fragility, and is forbidden from line-by-line walking. New team member: strong engineer, zero codebase context — conventions and domain vocabulary explained like an onboarding buddy would. Technical manager: behavior, responsibilities, risks — minimal code, and what code appears gets translated into a business statement.
Rationale. Detailed covers behavior and structure thoroughly. Deep Dive additionally demands, for every significant design decision: the rationale, the tradeoffs accepted, and at least one alternative approach with why it likely lost — plus the assumptions the design rests on and what breaks if they stop holding. And it carries the honesty rule that keeps it trustworthy: where rationale cannot be recovered from the code, say so — do not fabricate a design story.
To prepare for it, yes — the Documentation Preparation preset exists exactly for that: explain the subsystem thoroughly enough that its documentation could be written from the answer. But generating the documentation itself — README structure, API docs, changelogs — is the Markdown Output Builder's space. Explanation produces understanding; the Markdown Output Builder structures documents.