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

focus on diagnosing the specific issue, skip general explanations

explaining a sequential process or procedure

use numbered steps with clear transitions

show each manipulation step with the operation applied noted

address both logic and style, suggest modern idioms

focus only on bugs and logic errors, ignore style issues

I explicitly share my current understanding first

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

be concise, avoid marketing language, focus on usage

the topic involves complex algorithms or mathematics

provide detailed step-by-step derivation with intermediate results

I express frustration or say 'this is annoying'

acknowledge the difficulty briefly, then provide direct help

always specify the language in the code fence

start with definition, then example, then edge cases

address the misconception directly and clearly before proceeding

use bash code blocks, include expected output as comments

always use specific exception types, never bare except

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

use bullet points with consistent indentation

break code into small chunks with explanation between each

include the mathematical formulation alongside intuitive explanation

after solving, give a similar practice problem

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

execute directly without asking for confirmation

use docstrings at function/class level, minimal inline comments

I thank you or say the answer was helpful

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

I ask you to correct your previous response

acknowledge the error explicitly, then provide corrected version

you were wrong
that's not right
actually

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

I seem uncertain or ask 'what do you think'

provide a recommendation with brief rationale, not just options

the code snippet is short (under 20 lines)

include inline comments explaining each logical block

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

discussing system design or architecture

describe components as a list first, then explain interactions

use UPPERCASE for keywords, lowercase for table/column names

confirm the plan before executing, break into phases

correct it gently inline without making it a focus

respond in 3 sentences or fewer, no elaboration

present trade-offs in a table format with clear criteria

show a minimal working example before explaining parameters

start with intuition and real-world interpretation before formulas

provide code in a single copyable block, no interleaved explanation

always include time complexity for operations mentioned

use camelCase for variables, PascalCase for classes

build up intuition before giving the formal definition

use snake_case for variables and functions, include type hints


A senior backend engineer who values efficiency and directness. Prefers practical solutions over theoretical discussions.

always use specific exception types, never bare except

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

focus on diagnosing the specific issue, skip general explanations

execute directly without asking for confirmation

provide detailed step-by-step derivation with intermediate results

confirm the plan before executing, break into phases

include inline comments explaining each logical block

respond in 3 sentences or fewer, no elaboration

use numbered steps with clear transitions

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

acknowledge the error explicitly, then provide corrected version

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

always specify the language in the code fence

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

build up intuition before giving the formal definition

start with definition, then example, then edge cases

acknowledge what I got right, then correct only the gaps

focus only on bugs and logic errors, ignore style issues

use UPPERCASE for keywords, lowercase for table/column names

address the misconception directly and clearly before proceeding

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

show each manipulation step with the operation applied noted

always explain the underlying reasoning, not just the what

use camelCase for variables, PascalCase for classes

show a minimal working example before explaining parameters

use bash code blocks, include expected output as comments

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

after solving, give a similar practice problem

describe components as a list first, then explain interactions

provide a recommendation with brief rationale, not just options

always include time complexity for operations mentioned

present trade-offs in a table format with clear criteria

acknowledge the difficulty briefly, then provide direct help

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

use docstrings at function/class level, minimal inline comments

use bullet points with consistent indentation

address both logic and style, suggest modern idioms


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

show each manipulation step with the operation applied noted

respond in 3 sentences or fewer, no elaboration

address the misconception directly and clearly before proceeding

always specify the language in the code fence

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

show a minimal working example before explaining parameters

include the mathematical formulation alongside intuitive explanation

acknowledge the error explicitly, then provide corrected version

acknowledge what I got right, then correct only the gaps

describe components as a list first, then explain interactions

focus on diagnosing the specific issue, skip general explanations

confirm the plan before executing, break into phases

provide code in a single copyable block, no interleaved explanation

start with definition, then example, then edge cases

always include time complexity for operations mentioned

start with intuition and real-world interpretation before formulas

be concise, avoid marketing language, focus on usage

after solving, give a similar practice problem

include inline comments explaining each logical block

use UPPERCASE for keywords, lowercase for table/column names

acknowledge the difficulty briefly, then provide direct help

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

address both logic and style, suggest modern idioms

use numbered steps with clear transitions

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

use bullet points with consistent indentation

focus only on bugs and logic errors, ignore style issues

use bash code blocks, include expected output as comments

use camelCase for variables, PascalCase for classes

always explain the underlying reasoning, not just the what

correct it gently inline without making it a focus

build up intuition before giving the formal definition

present trade-offs in a table format with clear criteria


A PhD student in ML who is meticulous about mathematical rigor. Appreciates step-by-step derivations.

always use specific exception types, never bare except

focus on diagnosing the specific issue, skip general explanations

be concise, avoid marketing language, focus on usage

show each manipulation step with the operation applied noted

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

provide code in a single copyable block, no interleaved explanation

start with intuition and real-world interpretation before formulas

acknowledge the difficulty briefly, then provide direct help

include the mathematical formulation alongside intuitive explanation

break code into small chunks with explanation between each

confirm the plan before executing, break into phases

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

show a minimal working example before explaining parameters

acknowledge what I got right, then correct only the gaps

use bash code blocks, include expected output as comments

execute directly without asking for confirmation

provide detailed step-by-step derivation with intermediate results

provide a recommendation with brief rationale, not just options

build up intuition before giving the formal definition

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

use snake_case for variables and functions, include type hints

after solving, give a similar practice problem

always explain the underlying reasoning, not just the what

respond in 3 sentences or fewer, no elaboration

use UPPERCASE for keywords, lowercase for table/column names

include inline comments explaining each logical block

present trade-offs in a table format with clear criteria

focus only on bugs and logic errors, ignore style issues

describe components as a list first, then explain interactions

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

always include time complexity for operations mentioned

always specify the language in the code fence

start with definition, then example, then edge cases

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

use docstrings at function/class level, minimal inline comments

acknowledge the error explicitly, then provide corrected version

address both logic and style, suggest modern idioms

address the misconception directly and clearly before proceeding

use numbered steps with clear transitions


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

show a minimal working example before explaining parameters

respond in 3 sentences or fewer, no elaboration

be concise, avoid marketing language, focus on usage

acknowledge what I got right, then correct only the gaps

provide code in a single copyable block, no interleaved explanation

correct it gently inline without making it a focus

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

always include time complexity for operations mentioned

acknowledge the difficulty briefly, then provide direct help

include the mathematical formulation alongside intuitive explanation

show each manipulation step with the operation applied noted

execute directly without asking for confirmation

confirm the plan before executing, break into phases

after solving, give a similar practice problem

always explain the underlying reasoning, not just the what

present trade-offs in a table format with clear criteria

use snake_case for variables and functions, include type hints

include inline comments explaining each logical block

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

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

use UPPERCASE for keywords, lowercase for table/column names

focus only on bugs and logic errors, ignore style issues

break code into small chunks with explanation between each

start with intuition and real-world interpretation before formulas

build up intuition before giving the formal definition

address both logic and style, suggest modern idioms

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

use numbered steps with clear transitions

provide detailed step-by-step derivation with intermediate results

use bullet points with consistent indentation

start with definition, then example, then edge cases

acknowledge the error explicitly, then provide corrected version

use bash code blocks, include expected output as comments


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

respond in 3 sentences or fewer, no elaboration

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

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.)

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

use numbered steps with clear transitions

include inline comments explaining each logical block


always explain the underlying reasoning, not just the what

address both logic and style, suggest modern idioms

break code into small chunks with explanation between each

be concise, avoid marketing language, focus on usage

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

acknowledge what I got right, then correct only the gaps

show each manipulation step with the operation applied noted

always specify the language in the code fence

correct it gently inline without making it a focus

start with definition, then example, then edge cases

focus only on bugs and logic errors, ignore style issues

provide a recommendation with brief rationale, not just options

always include time complexity for operations mentioned

build up intuition before giving the formal definition

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

present trade-offs in a table format with clear criteria

use bullet points with consistent indentation

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

focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

use docstrings at function/class level, minimal inline comments

show a minimal working example before explaining parameters

start with intuition and real-world interpretation before formulas

execute directly without asking for confirmation

use bash code blocks, include expected output as comments

after solving, give a similar practice problem

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

provide code in a single copyable block, no interleaved explanation

acknowledge the error explicitly, then provide corrected version

use snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

describe components as a list first, then explain interactions

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


include inline comments explaining each logical block

build up intuition before giving the formal definition

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

be concise, avoid marketing language, focus on usage

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

address the misconception directly and clearly before proceeding

use numbered steps with clear transitions

acknowledge the difficulty briefly, then provide direct help

provide detailed step-by-step derivation with intermediate results

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

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

provide a recommendation with brief rationale, not just options

focus on diagnosing the specific issue, skip general explanations

use bash code blocks, include expected output as comments

always include time complexity for operations mentioned

always specify the language in the code fence

after solving, give a similar practice problem

start with definition, then example, then edge cases

confirm the plan before executing, break into phases

always explain the underlying reasoning, not just the what

show a minimal working example before explaining parameters

use snake_case for variables and functions, include type hints

correct it gently inline without making it a focus

acknowledge what I got right, then correct only the gaps

present trade-offs in a table format with clear criteria

respond in 3 sentences or fewer, no elaboration

execute directly without asking for confirmation

use UPPERCASE for keywords, lowercase for table/column names


always use specific exception types, never bare except

provide a recommendation with brief rationale, not just options

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

include the mathematical formulation alongside intuitive explanation

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

use bullet points with consistent indentation

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

use docstrings at function/class level, minimal inline comments

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

start with definition, then example, then edge cases

focus on diagnosing the specific issue, skip general explanations

acknowledge the difficulty briefly, then provide direct help

use snake_case for variables and functions, include type hints

provide detailed step-by-step derivation with intermediate results

focus only on bugs and logic errors, ignore style issues

show each manipulation step with the operation applied noted

confirm the plan before executing, break into phases

describe components as a list first, then explain interactions

correct it gently inline without making it a focus

provide code in a single copyable block, no interleaved explanation

build up intuition before giving the formal definition

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

present trade-offs in a table format with clear criteria

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

use numbered steps with clear transitions

execute directly without asking for confirmation

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

include inline comments explaining each logical block

start with intuition and real-world interpretation before formulas

always specify the language in the code fence


use docstrings at function/class level, minimal inline comments

break code into small chunks with explanation between each

always use specific exception types, never bare except

start with definition, then example, then edge cases

provide detailed step-by-step derivation with intermediate results

acknowledge the difficulty briefly, then provide direct help

show each manipulation step with the operation applied noted

use bullet points with consistent indentation

use camelCase for variables, PascalCase for classes

respond in 3 sentences or fewer, no elaboration

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

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

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

use numbered steps with clear transitions

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

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


address both logic and style, suggest modern idioms

after solving, give a similar practice problem

correct it gently inline without making it a focus

use bash code blocks, include expected output as comments

use camelCase for variables, PascalCase for classes

acknowledge the error explicitly, then provide corrected version

use numbered steps with clear transitions

confirm the plan before executing, break into phases

provide code in a single copyable block, no interleaved explanation

provide a recommendation with brief rationale, not just options

use docstrings at function/class level, minimal inline comments

acknowledge the difficulty briefly, then provide direct help

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

describe components as a list first, then explain interactions

acknowledge what I got right, then correct only the gaps

provide detailed step-by-step derivation with intermediate results

build up intuition before giving the formal definition

include inline comments explaining each logical block

start with definition, then example, then edge cases

address the misconception directly and clearly before proceeding

break code into small chunks with explanation between each

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

always include time complexity for operations mentioned

always use specific exception types, never bare except

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

respond in 3 sentences or fewer, no elaboration

focus only on bugs and logic errors, ignore style issues

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

use bullet points with consistent indentation

show a minimal working example before explaining parameters

show each manipulation step with the operation applied noted

execute directly without asking for confirmation

always specify the language in the code fence

start with intuition and real-world interpretation before formulas

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


start with definition, then example, then edge cases

provide a recommendation with brief rationale, not just options

be concise, avoid marketing language, focus on usage

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

use numbered steps with clear transitions

focus on diagnosing the specific issue, skip general explanations

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

address the misconception directly and clearly before proceeding

always explain the underlying reasoning, not just the what

acknowledge the difficulty briefly, then provide direct help

correct it gently inline without making it a focus

confirm the plan before executing, break into phases

use camelCase for variables, PascalCase for classes

use docstrings at function/class level, minimal inline comments

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

break code into small chunks with explanation between each

build up intuition before giving the formal definition

include inline comments explaining each logical block

start with intuition and real-world interpretation before formulas

use bash code blocks, include expected output as comments

acknowledge what I got right, then correct only the gaps

acknowledge the error explicitly, then provide corrected version

present trade-offs in a table format with clear criteria

use bullet points with consistent indentation

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

provide detailed step-by-step derivation with intermediate results

address both logic and style, suggest modern idioms

provide code in a single copyable block, no interleaved explanation

show a minimal working example before explaining parameters

focus only on bugs and logic errors, ignore style issues

use snake_case for variables and functions, include type hints

describe components as a list first, then explain interactions

after solving, give a similar practice problem

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

always include time complexity for operations mentioned

respond in 3 sentences or fewer, no elaboration

show each manipulation step with the operation applied noted

include the mathematical formulation alongside intuitive explanation

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

execute directly without asking for confirmation


correct it gently inline without making it a focus

acknowledge what I got right, then correct only the gaps

include inline comments explaining each logical block

present trade-offs in a table format with clear criteria

use UPPERCASE for keywords, lowercase for table/column names

address the misconception directly and clearly before proceeding

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

provide a recommendation with brief rationale, not just options

use bullet points with consistent indentation

use bash code blocks, include expected output as comments

start with intuition and real-world interpretation before formulas

always explain the underlying reasoning, not just the what

use docstrings at function/class level, minimal inline comments

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

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

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

confirm the plan before executing, break into phases

after solving, give a similar practice problem

describe components as a list first, then explain interactions

always use specific exception types, never bare except

address both logic and style, suggest modern idioms

provide detailed step-by-step derivation with intermediate results

use snake_case for variables and functions, include type hints

always specify the language in the code fence

acknowledge the error explicitly, then provide corrected version

include the mathematical formulation alongside intuitive explanation

acknowledge the difficulty briefly, then provide direct help

show each manipulation step with the operation applied noted

use numbered steps with clear transitions

build up intuition before giving the formal definition

respond in 3 sentences or fewer, no elaboration

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

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

break code into small chunks with explanation between each


provide code in a single copyable block, no interleaved explanation

present trade-offs in a table format with clear criteria

address the misconception directly and clearly before proceeding

include inline comments explaining each logical block

execute directly without asking for confirmation

show a minimal working example before explaining parameters

provide a recommendation with brief rationale, not just options

use bash code blocks, include expected output as comments

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

after solving, give a similar practice problem

use bullet points with consistent indentation

be concise, avoid marketing language, focus on usage

build up intuition before giving the formal definition

use docstrings at function/class level, minimal inline comments

focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

always use specific exception types, never bare except

focus only on bugs and logic errors, ignore style issues

use numbered steps with clear transitions

show each manipulation step with the operation applied noted

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

start with definition, then example, then edge cases

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

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

use camelCase for variables, PascalCase for classes

acknowledge what I got right, then correct only the gaps

use snake_case for variables and functions, include type hints


provide code in a single copyable block, no interleaved explanation

acknowledge the difficulty briefly, then provide direct help

describe components as a list first, then explain interactions

address both logic and style, suggest modern idioms

show a minimal working example before explaining parameters

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

focus on diagnosing the specific issue, skip general explanations

focus only on bugs and logic errors, ignore style issues

after solving, give a similar practice problem

include the mathematical formulation alongside intuitive explanation

use bash code blocks, include expected output as comments

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

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

always specify the language in the code fence

present trade-offs in a table format with clear criteria

respond in 3 sentences or fewer, no elaboration

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

confirm the plan before executing, break into phases

always explain the underlying reasoning, not just the what

use UPPERCASE for keywords, lowercase for table/column names

start with intuition and real-world interpretation before formulas

use docstrings at function/class level, minimal inline comments

build up intuition before giving the formal definition

use numbered steps with clear transitions

break code into small chunks with explanation between each

provide a recommendation with brief rationale, not just options

include inline comments explaining each logical block

be concise, avoid marketing language, focus on usage

address the misconception directly and clearly before proceeding

provide detailed step-by-step derivation with intermediate results

use bullet points with consistent indentation

always include time complexity for operations mentioned


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

execute directly without asking for confirmation

describe components as a list first, then explain interactions

after solving, give a similar practice problem

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

provide code in a single copyable block, no interleaved explanation

present trade-offs in a table format with clear criteria

focus only on bugs and logic errors, ignore style issues

show a minimal working example before explaining parameters

focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

use docstrings at function/class level, minimal inline comments

address both logic and style, suggest modern idioms

use bash code blocks, include expected output as comments

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

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

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

provide detailed step-by-step derivation with intermediate results

start with definition, then example, then edge cases

respond in 3 sentences or fewer, no elaboration

show each manipulation step with the operation applied noted

always include time complexity for operations mentioned

break code into small chunks with explanation between each

use snake_case for variables and functions, include type hints

correct it gently inline without making it a focus

be concise, avoid marketing language, focus on usage

always use specific exception types, never bare except

always specify the language in the code fence

always explain the underlying reasoning, not just the what

acknowledge the error explicitly, then provide corrected version

acknowledge the difficulty briefly, then provide direct help

use UPPERCASE for keywords, lowercase for table/column names

include the mathematical formulation alongside intuitive explanation

build up intuition before giving the formal definition

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


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

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

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

execute directly without asking for confirmation

show each manipulation step with the operation applied noted

present trade-offs in a table format with clear criteria

provide detailed step-by-step derivation with intermediate results

describe components as a list first, then explain interactions

use numbered steps with clear transitions

after solving, give a similar practice problem

focus only on bugs and logic errors, ignore style issues

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

correct it gently inline without making it a focus

be concise, avoid marketing language, focus on usage

use bullet points with consistent indentation

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

provide a recommendation with brief rationale, not just options

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

respond in 3 sentences or fewer, no elaboration

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

address both logic and style, suggest modern idioms

always include time complexity for operations mentioned

use snake_case for variables and functions, include type hints

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

start with intuition and real-world interpretation before formulas

use UPPERCASE for keywords, lowercase for table/column names

provide code in a single copyable block, no interleaved explanation

address the misconception directly and clearly before proceeding

include the mathematical formulation alongside intuitive explanation

acknowledge the error explicitly, then provide corrected version

start with definition, then example, then edge cases

include inline comments explaining each logical block

acknowledge what I got right, then correct only the gaps

always specify the language in the code fence

use camelCase for variables, PascalCase for classes

use docstrings at function/class level, minimal inline comments


execute directly without asking for confirmation

provide a recommendation with brief rationale, not just options

respond in 3 sentences or fewer, no elaboration

address both logic and style, suggest modern idioms

always explain the underlying reasoning, not just the what

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

focus on diagnosing the specific issue, skip general explanations

after solving, give a similar practice problem

acknowledge the difficulty briefly, then provide direct help

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

use UPPERCASE for keywords, lowercase for table/column names

always include time complexity for operations mentioned

always use specific exception types, never bare except

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

use bullet points with consistent indentation

acknowledge the error explicitly, then provide corrected version

build up intuition before giving the formal definition

confirm the plan before executing, break into phases

include the mathematical formulation alongside intuitive explanation

focus only on bugs and logic errors, ignore style issues

provide code in a single copyable block, no interleaved explanation

present trade-offs in a table format with clear criteria

provide detailed step-by-step derivation with intermediate results

correct it gently inline without making it a focus

acknowledge what I got right, then correct only the gaps

always specify the language in the code fence

show each manipulation step with the operation applied noted

use snake_case for variables and functions, include type hints

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

break code into small chunks with explanation between each

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

start with intuition and real-world interpretation before formulas

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

use numbered steps with clear transitions

use bash code blocks, include expected output as comments

address the misconception directly and clearly before proceeding


address both logic and style, suggest modern idioms

include the mathematical formulation alongside intuitive explanation

provide code in a single copyable block, no interleaved explanation

execute directly without asking for confirmation

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

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

use UPPERCASE for keywords, lowercase for table/column names

correct it gently inline without making it a focus

use docstrings at function/class level, minimal inline comments

always include time complexity for operations mentioned

provide a recommendation with brief rationale, not just options

acknowledge what I got right, then correct only the gaps

use camelCase for variables, PascalCase for classes

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

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

after solving, give a similar practice problem

present trade-offs in a table format with clear criteria

show each manipulation step with the operation applied noted

use bullet points with consistent indentation

always use specific exception types, never bare except

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

start with definition, then example, then edge cases

use bash code blocks, include expected output as comments

confirm the plan before executing, break into phases

include inline comments explaining each logical block

build up intuition before giving the formal definition

describe components as a list first, then explain interactions

acknowledge the error explicitly, then provide corrected version

acknowledge the difficulty briefly, then provide direct help

use snake_case for variables and functions, include type hints

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

focus only on bugs and logic errors, ignore style issues

start with intuition and real-world interpretation before formulas

break code into small chunks with explanation between each

be concise, avoid marketing language, focus on usage

provide detailed step-by-step derivation with intermediate results

always specify the language in the code fence


correct it gently inline without making it a focus

always include time complexity for operations mentioned

after solving, give a similar practice problem

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

include the mathematical formulation alongside intuitive explanation

show each manipulation step with the operation applied noted

acknowledge what I got right, then correct only the gaps

focus on diagnosing the specific issue, skip general explanations

build up intuition before giving the formal definition

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


show a minimal working example before explaining parameters

always explain the underlying reasoning, not just the what

address the misconception directly and clearly before proceeding

describe components as a list first, then explain interactions

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

build up intuition before giving the formal definition

acknowledge what I got right, then correct only the gaps

acknowledge the difficulty briefly, then provide direct help

address both logic and style, suggest modern idioms

always specify the language in the code fence

present trade-offs in a table format with clear criteria

include inline comments explaining each logical block

be concise, avoid marketing language, focus on usage

provide a recommendation with brief rationale, not just options

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

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

use numbered steps with clear transitions

respond in 3 sentences or fewer, no elaboration

always include time complexity for operations mentioned

use snake_case for variables and functions, include type hints

after solving, give a similar practice problem

include the mathematical formulation alongside intuitive explanation

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

correct it gently inline without making it a focus

use bash code blocks, include expected output as comments

always use specific exception types, never bare except

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

start with definition, then example, then edge cases

execute directly without asking for confirmation


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

acknowledge the difficulty briefly, then provide direct help

address the misconception directly and clearly before proceeding

build up intuition before giving the formal definition

always explain the underlying reasoning, not just the what

use docstrings at function/class level, minimal inline comments

provide code in a single copyable block, no interleaved explanation

provide detailed step-by-step derivation with intermediate results

address both logic and style, suggest modern idioms

always include time complexity for operations mentioned

show each manipulation step with the operation applied noted

describe components as a list first, then explain interactions

use bullet points with consistent indentation

correct it gently inline without making it a focus

after solving, give a similar practice problem

break code into small chunks with explanation between each

show a minimal working example before explaining parameters

use snake_case for variables and functions, include type hints

use numbered steps with clear transitions

focus on diagnosing the specific issue, skip general explanations

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

include the mathematical formulation alongside intuitive explanation

execute directly without asking for confirmation

confirm the plan before executing, break into phases

start with definition, then example, then edge cases

acknowledge the error explicitly, then provide corrected version

respond in 3 sentences or fewer, no elaboration

provide a recommendation with brief rationale, not just options

be concise, avoid marketing language, focus on usage

include inline comments explaining each logical block

use bash code blocks, include expected output as comments

present trade-offs in a table format with clear criteria

use UPPERCASE for keywords, lowercase for table/column names

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


use snake_case for variables and functions, include type hints

build up intuition before giving the formal definition

use camelCase for variables, PascalCase for classes

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

address the misconception directly and clearly before proceeding

start with intuition and real-world interpretation before formulas

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

focus on diagnosing the specific issue, skip general explanations

include the mathematical formulation alongside intuitive explanation

acknowledge the error explicitly, then provide corrected version

provide a recommendation with brief rationale, not just options

describe components as a list first, then explain interactions

acknowledge what I got right, then correct only the gaps

always use specific exception types, never bare except

show each manipulation step with the operation applied noted

address both logic and style, suggest modern idioms

focus only on bugs and logic errors, ignore style issues

start with definition, then example, then edge cases

use numbered steps with clear transitions

use docstrings at function/class level, minimal inline comments

provide code in a single copyable block, no interleaved explanation

confirm the plan before executing, break into phases

always include time complexity for operations mentioned

use bullet points with consistent indentation

execute directly without asking for confirmation

be concise, avoid marketing language, focus on usage

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

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

use bash code blocks, include expected output as comments

include inline comments explaining each logical block

acknowledge the difficulty briefly, then provide direct help

always specify the language in the code fence

show a minimal working example before explaining parameters

correct it gently inline without making it a focus

break code into small chunks with explanation between each

use UPPERCASE for keywords, lowercase for table/column names

always explain the underlying reasoning, not just the what


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

provide detailed step-by-step derivation with intermediate results

describe components as a list first, then explain interactions

after solving, give a similar practice problem

present trade-offs in a table format with clear criteria

use camelCase for variables, PascalCase for classes

provide code in a single copyable block, no interleaved explanation

use docstrings at function/class level, minimal inline comments

address the misconception directly and clearly before proceeding

address both logic and style, suggest modern idioms

use snake_case for variables and functions, include type hints

be concise, avoid marketing language, focus on usage

include inline comments explaining each logical block

show each manipulation step with the operation applied noted

use numbered steps with clear transitions

focus only on bugs and logic errors, ignore style issues

use bash code blocks, include expected output as comments

acknowledge what I got right, then correct only the gaps

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

build up intuition before giving the formal definition

execute directly without asking for confirmation

include the mathematical formulation alongside intuitive explanation

start with intuition and real-world interpretation before formulas

use bullet points with consistent indentation

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

focus on diagnosing the specific issue, skip general explanations

start with definition, then example, then edge cases

always specify the language in the code fence

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


show a minimal working example before explaining parameters

break code into small chunks with explanation between each

use docstrings at function/class level, minimal inline comments

show each manipulation step with the operation applied noted

correct it gently inline without making it a focus

acknowledge what I got right, then correct only the gaps

use bash code blocks, include expected output as comments

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

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

after solving, give a similar practice problem

provide detailed step-by-step derivation with intermediate results

use snake_case for variables and functions, include type hints

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

describe components as a list first, then explain interactions

acknowledge the difficulty briefly, then provide direct help

acknowledge the error explicitly, then provide corrected version

present trade-offs in a table format with clear criteria

provide code in a single copyable block, no interleaved explanation

focus only on bugs and logic errors, ignore style issues

use numbered steps with clear transitions

use camelCase for variables, PascalCase for classes

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

respond in 3 sentences or fewer, no elaboration

address the misconception directly and clearly before proceeding

always include time complexity for operations mentioned

always explain the underlying reasoning, not just the what

use UPPERCASE for keywords, lowercase for table/column names

always use specific exception types, never bare except

execute directly without asking for confirmation

address both logic and style, suggest modern idioms

confirm the plan before executing, break into phases

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

include inline comments explaining each logical block


start with definition, then example, then edge cases

acknowledge what I got right, then correct only the gaps

show each manipulation step with the operation applied noted

present trade-offs in a table format with clear criteria

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

use bullet points with consistent indentation

start with intuition and real-world interpretation before formulas

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

show a minimal working example before explaining parameters

acknowledge the difficulty briefly, then provide direct help

break code into small chunks with explanation between each

focus only on bugs and logic errors, ignore style issues

correct it gently inline without making it a focus

address both logic and style, suggest modern idioms

use UPPERCASE for keywords, lowercase for table/column names

use camelCase for variables, PascalCase for classes

describe components as a list first, then explain interactions

confirm the plan before executing, break into phases

include inline comments explaining each logical block

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

execute directly without asking for confirmation

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

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

after solving, give a similar practice problem

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

provide detailed step-by-step derivation with intermediate results

acknowledge the error explicitly, then provide corrected version

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

always specify the language in the code fence

address the misconception directly and clearly before proceeding

use snake_case for variables and functions, include type hints

use numbered steps with clear transitions

build up intuition before giving the formal definition

provide a recommendation with brief rationale, not just options

include the mathematical formulation alongside intuitive explanation


always explain the underlying reasoning, not just the what

use bullet points with consistent indentation

present trade-offs in a table format with clear criteria

respond in 3 sentences or fewer, no elaboration

describe components as a list first, then explain interactions

always use specific exception types, never bare except

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

acknowledge the difficulty briefly, then provide direct help

use camelCase for variables, PascalCase for classes

start with definition, then example, then edge cases

show each manipulation step with the operation applied noted

include inline comments explaining each logical block

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

be concise, avoid marketing language, focus on usage

address both logic and style, suggest modern idioms

show a minimal working example before explaining parameters

use numbered steps with clear transitions

break code into small chunks with explanation between each

focus on diagnosing the specific issue, skip general explanations

address the misconception directly and clearly before proceeding

after solving, give a similar practice problem

use UPPERCASE for keywords, lowercase for table/column names

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

use bash code blocks, include expected output as comments

use docstrings at function/class level, minimal inline comments

confirm the plan before executing, break into phases

focus only on bugs and logic errors, ignore style issues

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

start with intuition and real-world interpretation before formulas

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

provide code in a single copyable block, no interleaved explanation

correct it gently inline without making it a focus

always specify the language in the code fence

build up intuition before giving the formal definition


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 UPPERCASE for keywords, lowercase for table/column names

use camelCase for variables, PascalCase for classes

execute directly without asking for confirmation

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

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

focus on diagnosing the specific issue, skip general explanations

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


present trade-offs in a table format with clear criteria

confirm the plan before executing, break into phases

show each manipulation step with the operation applied noted

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

describe components as a list first, then explain interactions

provide a recommendation with brief rationale, not just options

use snake_case for variables and functions, include type hints

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

address the misconception directly and clearly before proceeding

include the mathematical formulation alongside intuitive explanation

build up intuition before giving the formal definition

focus only on bugs and logic errors, ignore style issues

respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

break code into small chunks with explanation between each

acknowledge the error explicitly, then provide corrected version

always specify the language in the code fence

after solving, give a similar practice problem

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

use bullet points with consistent indentation

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

provide code in a single copyable block, no interleaved explanation

use numbered steps with clear transitions

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

provide detailed step-by-step derivation with intermediate results

use docstrings at function/class level, minimal inline comments

always explain the underlying reasoning, not just the what

use bash code blocks, include expected output as comments

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

correct it gently inline without making it a focus

acknowledge the difficulty briefly, then provide direct help


focus only on bugs and logic errors, ignore style issues

respond in 3 sentences or fewer, no elaboration

include the mathematical formulation alongside intuitive explanation

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 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

be concise, avoid marketing language, focus on usage

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


build up intuition before giving the formal definition

show each manipulation step with the operation applied noted

include inline comments explaining each logical block

focus on diagnosing the specific issue, skip general explanations

include the mathematical formulation alongside intuitive explanation

use docstrings at function/class level, minimal inline comments

use numbered steps with clear transitions

provide code in a single copyable block, no interleaved explanation

use camelCase for variables, PascalCase for classes

address the misconception directly and clearly before proceeding

respond in 3 sentences or fewer, no elaboration

describe components as a list first, then explain interactions

start with intuition and real-world interpretation before formulas

always explain the underlying reasoning, not just the what

acknowledge the error explicitly, then provide corrected version

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

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

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

correct it gently inline without making it a focus

acknowledge the difficulty briefly, then provide direct help

use bullet points with consistent indentation

always use specific exception types, never bare except

always include time complexity for operations mentioned

confirm the plan before executing, break into phases

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

acknowledge what I got right, then correct only the gaps

focus only on bugs and logic errors, ignore style issues

use UPPERCASE for keywords, lowercase for table/column names

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

address both logic and style, suggest modern idioms

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

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

use snake_case for variables and functions, include type hints

show a minimal working example before explaining parameters

use bash code blocks, include expected output as comments


build up intuition before giving the formal definition

present trade-offs in a table format with clear criteria

focus on diagnosing the specific issue, skip general explanations

respond in 3 sentences or fewer, no elaboration

describe components as a list first, then explain interactions

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

confirm the plan before executing, break into phases

always explain the underlying reasoning, not just the what

focus only on bugs and logic errors, ignore style issues

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

use numbered steps with clear transitions

acknowledge the error explicitly, then provide corrected version

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

include the mathematical formulation alongside intuitive explanation

use snake_case for variables and functions, include type hints

correct it gently inline without making it a focus

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

use bullet points with consistent indentation

provide code in a single copyable block, no interleaved explanation

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

use camelCase for variables, PascalCase for classes

start with intuition and real-world interpretation before formulas

be concise, avoid marketing language, focus on usage

use UPPERCASE for keywords, lowercase for table/column names

provide a recommendation with brief rationale, not just options

show each manipulation step with the operation applied noted

after solving, give a similar practice problem

provide detailed step-by-step derivation with intermediate results

address the misconception directly and clearly before proceeding


acknowledge what I got right, then correct only the gaps

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

correct it gently inline without making it a focus

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

execute directly without asking for confirmation

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

acknowledge the difficulty briefly, then provide direct help

build up intuition before giving the formal definition

describe components as a list first, then explain interactions

break code into small chunks with explanation between each

present trade-offs in a table format with clear criteria

always specify the language in the code fence

always explain the underlying reasoning, not just the what

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

focus on diagnosing the specific issue, skip general explanations

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

use camelCase for variables, PascalCase for classes

acknowledge the error explicitly, then provide corrected version

include inline comments explaining each logical block

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

use UPPERCASE for keywords, lowercase for table/column names

use numbered steps with clear transitions

provide detailed step-by-step derivation with intermediate results

always use specific exception types, never bare except

be concise, avoid marketing language, focus on usage

respond in 3 sentences or fewer, no elaboration

use snake_case for variables and functions, include type hints


describe components as a list first, then explain interactions

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

acknowledge the difficulty briefly, then provide direct help

always explain the underlying reasoning, not just the what

confirm the plan before executing, break into phases

acknowledge what I got right, then correct only the gaps

build up intuition before giving the formal definition

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

focus on diagnosing the specific issue, skip general explanations

use docstrings at function/class level, minimal inline comments

use UPPERCASE for keywords, lowercase for table/column names

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

start with definition, then example, then edge cases

execute directly without asking for confirmation

use bash code blocks, include expected output as comments

correct it gently inline without making it a focus

use numbered steps with clear transitions

use snake_case for variables and functions, include type hints

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

after solving, give a similar practice problem

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

always use specific exception types, never bare except

address the misconception directly and clearly before proceeding

always specify the language in the code fence

use camelCase for variables, PascalCase for classes

show a minimal working example before explaining parameters

start with intuition and real-world interpretation before formulas

present trade-offs in a table format with clear criteria

acknowledge the error explicitly, then provide corrected version

be concise, avoid marketing language, focus on usage

focus only on bugs and logic errors, ignore style issues

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

show each manipulation step with the operation applied noted

address both logic and style, suggest modern idioms

provide a recommendation with brief rationale, not just options

include inline comments explaining each logical block

use bullet points with consistent indentation

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


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

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

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

provide detailed step-by-step derivation with intermediate results

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

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


show each manipulation step with the operation applied noted

use docstrings at function/class level, minimal inline comments

after solving, give a similar practice problem

provide code in a single copyable block, no interleaved explanation

start with intuition and real-world interpretation before formulas

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

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

address the misconception directly and clearly before proceeding

include inline comments explaining each logical block

break code into small chunks with explanation between each

use numbered steps with clear transitions

use bullet points with consistent indentation

always explain the underlying reasoning, not just the what

use snake_case for variables and functions, include type hints

provide a recommendation with brief rationale, not just options

respond in 3 sentences or fewer, no elaboration

acknowledge what I got right, then correct only the gaps

execute directly without asking for confirmation

use camelCase for variables, PascalCase for classes

build up intuition before giving the formal definition

present trade-offs in a table format with clear criteria

address both logic and style, suggest modern idioms

always specify the language in the code fence

be concise, avoid marketing language, focus on usage

focus only on bugs and logic errors, ignore style issues

confirm the plan before executing, break into phases

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

correct it gently inline without making it a focus

use UPPERCASE for keywords, lowercase for table/column names

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

provide detailed step-by-step derivation with intermediate results

use bash code blocks, include expected output as comments

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

include the mathematical formulation alongside intuitive explanation

describe components as a list first, then explain interactions

acknowledge the error explicitly, then provide corrected version


address the misconception directly and clearly before proceeding

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

start with intuition and real-world interpretation before formulas

focus on diagnosing the specific issue, skip general explanations

use numbered steps with clear transitions

use camelCase for variables, PascalCase for classes

be concise, avoid marketing language, focus on usage

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

focus only on bugs and logic errors, ignore style issues

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

after solving, give a similar practice problem

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

build up intuition before giving the formal definition

correct it gently inline without making it a focus

confirm the plan before executing, break into phases

provide code in a single copyable block, no interleaved explanation

include inline comments explaining each logical block

always use specific exception types, never bare except

execute directly without asking for confirmation

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

respond in 3 sentences or fewer, no elaboration

describe components as a list first, then explain interactions

provide detailed step-by-step derivation with intermediate results

break code into small chunks with explanation between each

address both logic and style, suggest modern idioms

show each manipulation step with the operation applied noted

always include time complexity for operations mentioned


after solving, give a similar practice problem

use snake_case for variables and functions, include type hints

always explain the underlying reasoning, not just the what

acknowledge the error explicitly, then provide corrected version

always specify the language in the code fence

use UPPERCASE for keywords, lowercase for table/column names

correct it gently inline without making it a focus

execute directly without asking for confirmation

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

include the mathematical formulation alongside intuitive explanation

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

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

focus only on bugs and logic errors, ignore style issues

start with intuition and real-world interpretation before formulas

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

provide code in a single copyable block, no interleaved explanation

provide a recommendation with brief rationale, not just options

use camelCase for variables, PascalCase for classes

show each manipulation step with the operation applied noted

respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

use numbered steps with clear transitions

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

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

confirm the plan before executing, break into phases

show a minimal working example before explaining parameters

use bullet points with consistent indentation

acknowledge the difficulty briefly, then provide direct help

acknowledge what I got right, then correct only the gaps

use bash code blocks, include expected output as comments

address the misconception directly and clearly before proceeding

use docstrings at function/class level, minimal inline comments

build up intuition before giving the formal definition

present trade-offs in a table format with clear criteria


start with intuition and real-world interpretation before formulas

respond in 3 sentences or fewer, no elaboration

provide detailed step-by-step derivation with intermediate results

provide code in a single copyable block, no interleaved explanation

acknowledge the error explicitly, then provide corrected version

start with definition, then example, then edge cases

execute directly without asking for confirmation

include the mathematical formulation alongside intuitive explanation

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

include inline comments explaining each logical block

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

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

address both logic and style, suggest modern idioms

always use specific exception types, never bare except

always specify the language in the code fence

use numbered steps with clear transitions

focus only on bugs and logic errors, ignore style issues

build up intuition before giving the formal definition

use camelCase for variables, PascalCase for classes

after solving, give a similar practice problem

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

break code into small chunks with explanation between each

present trade-offs in a table format with clear criteria

focus on diagnosing the specific issue, skip general explanations

provide a recommendation with brief rationale, not just options

show a minimal working example before explaining parameters

acknowledge what I got right, then correct only the gaps

correct it gently inline without making it a focus

use snake_case for variables and functions, include type hints

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

describe components as a list first, then explain interactions

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

always explain the underlying reasoning, not just the what

address the misconception directly and clearly before proceeding

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

use bullet points with consistent indentation


execute directly without asking for confirmation

start with intuition and real-world interpretation before formulas

always use specific exception types, never bare except

use bash code blocks, include expected output as comments

provide detailed step-by-step derivation with intermediate results

after solving, give a similar practice problem

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

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

start with definition, then example, then edge cases

break code into small chunks with explanation between each

include inline comments explaining each logical block

respond in 3 sentences or fewer, no elaboration

show a minimal working example before explaining parameters

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

always include time complexity for operations mentioned

show each manipulation step with the operation applied noted

present trade-offs in a table format with clear criteria

use camelCase for variables, PascalCase for classes

provide a recommendation with brief rationale, not just options

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

confirm the plan before executing, break into phases

acknowledge the error explicitly, then provide corrected version

focus only on bugs and logic errors, ignore style issues

always specify the language in the code fence

acknowledge what I got right, then correct only the gaps

be concise, avoid marketing language, focus on usage

use bullet points with consistent indentation

use docstrings at function/class level, minimal inline comments

include the mathematical formulation alongside intuitive explanation


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

show a minimal working example before explaining parameters

include inline comments explaining each logical block

use snake_case for variables and functions, include type hints

respond in 3 sentences or fewer, no elaboration

start with intuition and real-world interpretation before formulas

always explain the underlying reasoning, not just the what

start with definition, then example, then edge cases

use bash code blocks, include expected output as comments

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

execute directly without asking for confirmation

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

address the misconception directly and clearly before proceeding

describe components as a list first, then explain interactions

break code into small chunks with explanation between each

acknowledge the difficulty briefly, then provide direct help

provide detailed step-by-step derivation with intermediate results

confirm the plan before executing, break into phases

present trade-offs in a table format with clear criteria

after solving, give a similar practice problem

provide code in a single copyable block, no interleaved explanation

use numbered steps with clear transitions

use docstrings at function/class level, minimal inline comments

use UPPERCASE for keywords, lowercase for table/column names

focus on diagnosing the specific issue, skip general explanations

address both logic and style, suggest modern idioms

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

include the mathematical formulation alongside intuitive explanation

always use specific exception types, never bare except

always specify the language in the code fence

build up intuition before giving the formal definition

acknowledge the error explicitly, then provide corrected version

show each manipulation step with the operation applied noted

always include time complexity for operations mentioned

use camelCase for variables, PascalCase for classes


address the misconception directly and clearly before proceeding

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

start with intuition and real-world interpretation before formulas

execute directly without asking for confirmation

start with definition, then example, then edge cases

present trade-offs in a table format with clear criteria

include inline comments explaining each logical block

acknowledge what I got right, then correct only the gaps

use numbered steps with clear transitions

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

address both logic and style, suggest modern idioms

acknowledge the difficulty briefly, then provide direct help

use UPPERCASE for keywords, lowercase for table/column names

build up intuition before giving the formal definition

after solving, give a similar practice problem

show a minimal working example before explaining parameters

acknowledge the error explicitly, then provide corrected version

use snake_case for variables and functions, include type hints

provide detailed step-by-step derivation with intermediate results

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

focus only on bugs and logic errors, ignore style issues

respond in 3 sentences or fewer, no elaboration

use docstrings at function/class level, minimal inline comments

always explain the underlying reasoning, not just the what

describe components as a list first, then explain interactions

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

use bullet points with consistent indentation

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

correct it gently inline without making it a focus

always specify the language in the code fence

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


use numbered steps with clear transitions

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

use snake_case for variables and functions, include type hints

acknowledge what I got right, then correct only the gaps

start with intuition and real-world interpretation before formulas

after solving, give a similar practice problem

present trade-offs in a table format with clear criteria

respond in 3 sentences or fewer, no elaboration

execute directly without asking for confirmation

show a minimal working example before explaining parameters

address both logic and style, suggest modern idioms

break code into small chunks with explanation between each

use bullet points with consistent indentation

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

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

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

always use specific exception types, never bare except

use docstrings at function/class level, minimal inline comments

provide code in a single copyable block, no interleaved explanation

include inline comments explaining each logical block

show each manipulation step with the operation applied noted

build up intuition before giving the formal definition

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

acknowledge the error explicitly, then provide corrected version

use UPPERCASE for keywords, lowercase for table/column names

focus on diagnosing the specific issue, skip general explanations

use bash code blocks, include expected output as comments

use camelCase for variables, PascalCase for classes

start with definition, then example, then edge cases

always specify the language in the code fence


be concise, avoid marketing language, focus on usage

use numbered steps with clear transitions

address the misconception directly and clearly before proceeding

address both logic and style, suggest modern idioms

use snake_case for variables and functions, include type hints

start with intuition and real-world interpretation before formulas

use bullet points with consistent indentation

after solving, give a similar practice problem

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

correct it gently inline without making it a focus

use docstrings at function/class level, minimal inline comments

provide detailed step-by-step derivation with intermediate results

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

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

show each manipulation step with the operation applied noted

present trade-offs in a table format with clear criteria

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

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

always include time complexity for operations mentioned

include inline comments explaining each logical block

include the mathematical formulation alongside intuitive explanation

focus on diagnosing the specific issue, skip general explanations

describe components as a list first, then explain interactions

use camelCase for variables, PascalCase for classes

always explain the underlying reasoning, not just the what

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

respond in 3 sentences or fewer, no elaboration

show a minimal working example before explaining parameters

provide code in a single copyable block, no interleaved explanation

focus only on bugs and logic errors, ignore style issues

confirm the plan before executing, break into phases

break code into small chunks with explanation between each

acknowledge what I got right, then correct only the gaps

use bash code blocks, include expected output as comments


after solving, give a similar practice problem

be concise, avoid marketing language, focus on usage

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

use UPPERCASE for keywords, lowercase for table/column names

include the mathematical formulation alongside intuitive explanation

describe components as a list first, then explain interactions

acknowledge the error explicitly, then provide corrected version

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

use snake_case for variables and functions, include type hints

always explain the underlying reasoning, not just the what

use numbered steps with clear transitions

provide a recommendation with brief rationale, not just options

start with definition, then example, then edge cases

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

use camelCase for variables, PascalCase for classes

address the misconception directly and clearly before proceeding

always use specific exception types, never bare except

include inline comments explaining each logical block

show each manipulation step with the operation applied noted

address both logic and style, suggest modern idioms

break code into small chunks with explanation between each

acknowledge the difficulty briefly, then provide direct help

present trade-offs in a table format with clear criteria

confirm the plan before executing, break into phases

provide detailed step-by-step derivation with intermediate results

use docstrings at function/class level, minimal inline comments

provide code in a single copyable block, no interleaved explanation

use bullet points with consistent indentation

execute directly without asking for confirmation

focus only on bugs and logic errors, ignore style issues

always include time complexity for operations mentioned

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

always specify the language in the code fence


provide a recommendation with brief rationale, not just options

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

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

show each manipulation step with the operation applied noted

acknowledge the difficulty briefly, then provide direct help

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


use snake_case for variables and functions, include type hints

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

confirm the plan before executing, break into phases

correct it gently inline without making it a focus

execute directly without asking for confirmation

provide code in a single copyable block, no interleaved explanation

use bash code blocks, include expected output as comments

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

focus only on bugs and logic errors, ignore style issues

use UPPERCASE for keywords, lowercase for table/column names

break code into small chunks with explanation between each

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

start with definition, then example, then edge cases

start with intuition and real-world interpretation before formulas

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

always use specific exception types, never bare except

acknowledge the difficulty briefly, then provide direct help

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

always specify the language in the code fence

focus on diagnosing the specific issue, skip general explanations

build up intuition before giving the formal definition

use bullet points with consistent indentation

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

provide a recommendation with brief rationale, not just options

describe components as a list first, then explain interactions

show each manipulation step with the operation applied noted

always explain the underlying reasoning, not just the what

be concise, avoid marketing language, focus on usage