A researcher prototyping quickly. Wants working code fast, willing to refactor later.

respond in 3 sentences or fewer, no elaboration

break code into small chunks with explanation between each

build up intuition before giving the formal definition

focus only on bugs and logic errors, ignore style issues

use bash code blocks, include expected output as comments

structure as: claim, approach sketch, formal proof, intuition recap

I ask you to correct your previous response

acknowledge the error explicitly, then provide corrected version

you were wrong
that's not right
actually

start with definition, then example, then edge cases

address both logic and style, suggest modern idioms

show each manipulation step with the operation applied noted

show a minimal working example before explaining parameters

always explain the underlying reasoning, not just the what

be concise, avoid marketing language, focus on usage

correct it gently inline without making it a focus

confirm the plan before executing, break into phases

start with intuition and real-world interpretation before formulas

present trade-offs in a table format with clear criteria

always include time complexity for operations mentioned

focus on diagnosing the specific issue, skip general explanations

execute directly without asking for confirmation

use docstrings at function/class level, minimal inline comments

discussing system design or architecture

describe components as a list first, then explain interactions

always specify the language in the code fence

check my work step by step, point out where I diverged if wrong

address the misconception directly and clearly before proceeding

use UPPERCASE for keywords, lowercase for table/column names

include the mathematical formulation alongside intuitive explanation

state the rule being applied (chain rule, integration by parts, etc.)

I express frustration or say 'this is annoying'

acknowledge the difficulty briefly, then provide direct help

always use specific exception types, never bare except

use bullet points with consistent indentation

use camelCase for variables, PascalCase for classes

explaining a sequential process or procedure

use numbered steps with clear transitions

the code snippet is short (under 20 lines)

include inline comments explaining each logical block


A DevOps engineer focused on automation. Wants concise, actionable answers with commands to run.

break code into small chunks with explanation between each

start with definition, then example, then edge cases

show a minimal working example before explaining parameters

build up intuition before giving the formal definition

the topic involves complex algorithms or mathematics

provide detailed step-by-step derivation with intermediate results

show each manipulation step with the operation applied noted

execute directly without asking for confirmation

respond in 3 sentences or fewer, no elaboration

I explicitly share my current understanding first

acknowledge what I got right, then correct only the gaps

correct it gently inline without making it a focus

confirm the plan before executing, break into phases

focus only on bugs and logic errors, ignore style issues

always include time complexity for operations mentioned

use bash code blocks, include expected output as comments

after solving, give a similar practice problem

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

provide code in a single copyable block, no interleaved explanation

I thank you or say the answer was helpful

don't add unnecessary follow-up, just acknowledge briefly

use numbered steps with clear transitions

structure as: claim, approach sketch, formal proof, intuition recap

I seem uncertain or ask 'what do you think'

provide a recommendation with brief rationale, not just options

use snake_case for variables and functions, include type hints

present trade-offs in a table format with clear criteria

be concise, avoid marketing language, focus on usage

always explain the underlying reasoning, not just the what

describe components as a list first, then explain interactions

check my work step by step, point out where I diverged if wrong

use UPPERCASE for keywords, lowercase for table/column names

include inline comments explaining each logical block

focus on diagnosing the specific issue, skip general explanations

include the mathematical formulation alongside intuitive explanation


A data scientist who thinks visually. Prefers intuition before formulas and lots of examples.

show the bug location, explain why it's wrong, provide the fix

confirm the plan before executing, break into phases

correct it gently inline without making it a focus

always include time complexity for operations mentioned

after solving, give a similar practice problem

acknowledge the difficulty briefly, then provide direct help

provide code in a single copyable block, no interleaved explanation

structure as: claim, approach sketch, formal proof, intuition recap

use bash code blocks, include expected output as comments

show each manipulation step with the operation applied noted

use snake_case for variables and functions, include type hints

acknowledge what I got right, then correct only the gaps

build up intuition before giving the formal definition

always specify the language in the code fence

always explain the underlying reasoning, not just the what

use camelCase for variables, PascalCase for classes

address the misconception directly and clearly before proceeding

show a minimal working example before explaining parameters

provide detailed step-by-step derivation with intermediate results

provide a recommendation with brief rationale, not just options

state the rule being applied (chain rule, integration by parts, etc.)

address both logic and style, suggest modern idioms

start with definition, then example, then edge cases

always use specific exception types, never bare except

break code into small chunks with explanation between each

use numbered steps with clear transitions

use docstrings at function/class level, minimal inline comments

present trade-offs in a table format with clear criteria

respond in 3 sentences or fewer, no elaboration

include inline comments explaining each logical block

be concise, avoid marketing language, focus on usage

use UPPERCASE for keywords, lowercase for table/column names

use bullet points with consistent indentation

start with intuition and real-world interpretation before formulas

don't add unnecessary follow-up, just acknowledge briefly

focus only on bugs and logic errors, ignore style issues

execute directly without asking for confirmation

check my work step by step, point out where I diverged if wrong

acknowledge the error explicitly, then provide corrected version


A student preparing for technical interviews. Needs step-by-step problem solving practice.

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

always include time complexity for operations mentioned

present trade-offs in a table format with clear criteria

address the misconception directly and clearly before proceeding

use camelCase for variables, PascalCase for classes

correct it gently inline without making it a focus

provide detailed step-by-step derivation with intermediate results

structure as: claim, approach sketch, formal proof, intuition recap

focus on diagnosing the specific issue, skip general explanations

provide code in a single copyable block, no interleaved explanation

start with intuition and real-world interpretation before formulas

respond in 3 sentences or fewer, no elaboration

don't add unnecessary follow-up, just acknowledge briefly

focus only on bugs and logic errors, ignore style issues

state the rule being applied (chain rule, integration by parts, etc.)

acknowledge what I got right, then correct only the gaps

use bash code blocks, include expected output as comments

include the mathematical formulation alongside intuitive explanation

use bullet points with consistent indentation

after solving, give a similar practice problem

break code into small chunks with explanation between each

start with definition, then example, then edge cases

use numbered steps with clear transitions

show a minimal working example before explaining parameters

always specify the language in the code fence

always use specific exception types, never bare except

provide a recommendation with brief rationale, not just options

always explain the underlying reasoning, not just the what

be concise, avoid marketing language, focus on usage

use docstrings at function/class level, minimal inline comments

acknowledge the error explicitly, then provide corrected version

show each manipulation step with the operation applied noted

build up intuition before giving the formal definition


address both logic and style, suggest modern idioms

execute directly without asking for confirmation

address the misconception directly and clearly before proceeding

after solving, give a similar practice problem

break code into small chunks with explanation between each

start with intuition and real-world interpretation before formulas

show the bug location, explain why it's wrong, provide the fix

use numbered steps with clear transitions

use bullet points with consistent indentation

include the mathematical formulation alongside intuitive explanation

check my work step by step, point out where I diverged if wrong

confirm the plan before executing, break into phases

use bash code blocks, include expected output as comments

present trade-offs in a table format with clear criteria

use snake_case for variables and functions, include type hints

always specify the language in the code fence

focus on diagnosing the specific issue, skip general explanations

describe components as a list first, then explain interactions

use UPPERCASE for keywords, lowercase for table/column names

don't add unnecessary follow-up, just acknowledge briefly

always explain the underlying reasoning, not just the what

acknowledge what I got right, then correct only the gaps

respond in 3 sentences or fewer, no elaboration

show a minimal working example before explaining parameters

correct it gently inline without making it a focus

always include time complexity for operations mentioned

include inline comments explaining each logical block

state the rule being applied (chain rule, integration by parts, etc.)

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

provide detailed step-by-step derivation with intermediate results

acknowledge the difficulty briefly, then provide direct help


A tech lead reviewing code from their team. Focuses on maintainability and best practices.

use numbered steps with clear transitions

provide code in a single copyable block, no interleaved explanation

focus only on bugs and logic errors, ignore style issues

include the mathematical formulation alongside intuitive explanation

check my work step by step, point out where I diverged if wrong

present trade-offs in a table format with clear criteria

focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

describe components as a list first, then explain interactions

use bash code blocks, include expected output as comments

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

build up intuition before giving the formal definition

always include time complexity for operations mentioned

show each manipulation step with the operation applied noted

show the bug location, explain why it's wrong, provide the fix

include inline comments explaining each logical block

acknowledge the error explicitly, then provide corrected version

use UPPERCASE for keywords, lowercase for table/column names

confirm the plan before executing, break into phases

use docstrings at function/class level, minimal inline comments

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

use camelCase for variables, PascalCase for classes

address the misconception directly and clearly before proceeding

execute directly without asking for confirmation

don't add unnecessary follow-up, just acknowledge briefly

always explain the underlying reasoning, not just the what

always use specific exception types, never bare except

use bullet points with consistent indentation

provide detailed step-by-step derivation with intermediate results

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

structure as: claim, approach sketch, formal proof, intuition recap

always specify the language in the code fence

break code into small chunks with explanation between each

start with definition, then example, then edge cases


show each manipulation step with the operation applied noted

check my work step by step, point out where I diverged if wrong

after solving, give a similar practice problem

use UPPERCASE for keywords, lowercase for table/column names

use snake_case for variables and functions, include type hints

respond in 3 sentences or fewer, no elaboration

address the misconception directly and clearly before proceeding

use numbered steps with clear transitions

confirm the plan before executing, break into phases

always use specific exception types, never bare except

always explain the underlying reasoning, not just the what

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

use camelCase for variables, PascalCase for classes

show a minimal working example before explaining parameters

show the bug location, explain why it's wrong, provide the fix

always include time complexity for operations mentioned

execute directly without asking for confirmation

start with intuition and real-world interpretation before formulas

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

describe components as a list first, then explain interactions

acknowledge the difficulty briefly, then provide direct help

break code into small chunks with explanation between each

acknowledge the error explicitly, then provide corrected version

state the rule being applied (chain rule, integration by parts, etc.)

use bash code blocks, include expected output as comments

include the mathematical formulation alongside intuitive explanation

focus on diagnosing the specific issue, skip general explanations

don't add unnecessary follow-up, just acknowledge briefly

build up intuition before giving the formal definition


A junior developer learning full-stack. Prefers patient, incremental explanations with examples.

provide a recommendation with brief rationale, not just options

structure as: claim, approach sketch, formal proof, intuition recap

use UPPERCASE for keywords, lowercase for table/column names

show a minimal working example before explaining parameters

show the bug location, explain why it's wrong, provide the fix

confirm the plan before executing, break into phases

always include time complexity for operations mentioned

show each manipulation step with the operation applied noted

provide detailed step-by-step derivation with intermediate results

acknowledge the difficulty briefly, then provide direct help

use docstrings at function/class level, minimal inline comments

check my work step by step, point out where I diverged if wrong

present trade-offs in a table format with clear criteria

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

use snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

build up intuition before giving the formal definition

describe components as a list first, then explain interactions

correct it gently inline without making it a focus

break code into small chunks with explanation between each

always specify the language in the code fence

focus only on bugs and logic errors, ignore style issues

include the mathematical formulation alongside intuitive explanation

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

focus on diagnosing the specific issue, skip general explanations

address both logic and style, suggest modern idioms

always use specific exception types, never bare except

use bullet points with consistent indentation

include inline comments explaining each logical block

always explain the underlying reasoning, not just the what

respond in 3 sentences or fewer, no elaboration

start with intuition and real-world interpretation before formulas

state the rule being applied (chain rule, integration by parts, etc.)

acknowledge what I got right, then correct only the gaps

after solving, give a similar practice problem

use numbered steps with clear transitions