acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

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

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

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

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

include inline comments explaining each logical block

address both logic and style, suggest modern idioms

show a minimal working example before explaining parameters

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

be concise, avoid marketing language, focus on usage

execute directly without asking for confirmation

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

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 code in a single copyable block, no interleaved explanation

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

address the misconception directly and clearly before proceeding

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

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

use snake_case for variables and functions, include type hints

always use specific exception types, never bare except

provide a recommendation with brief rationale, not just options

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments


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

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

I explicitly share my current understanding first

acknowledge what I got right, then correct only the gaps

respond in 3 sentences or fewer, no elaboration

the topic involves complex algorithms or mathematics

provide detailed step-by-step derivation with intermediate results

build up intuition before giving the formal definition

explaining a sequential process or procedure

use numbered steps with clear transitions

use bullet points with consistent indentation

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

after solving, give a similar practice problem

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

show each manipulation step with the operation applied noted

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

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

focus only on bugs and logic errors, ignore style issues

discussing system design or architecture

describe components as a list first, then explain interactions

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

include the mathematical formulation alongside intuitive explanation

execute directly without asking for confirmation

I seem uncertain or ask 'what do you think'

provide a recommendation with brief rationale, not just options

I thank you or say the answer was helpful

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

present trade-offs in a table format with clear criteria

I express frustration or say 'this is annoying'

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

correct it gently inline without making it a focus

I ask you to correct your previous response

acknowledge the error explicitly, then provide corrected version

you were wrong
that's not right
actually

address the misconception directly and clearly before proceeding

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

the code snippet is short (under 20 lines)

include inline comments explaining each logical block

start with definition, then example, then edge cases

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

start with intuition and real-world interpretation before formulas


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

respond in 3 sentences or fewer, no elaboration

acknowledge what I got right, then correct only the gaps

provide detailed step-by-step derivation with intermediate results

always explain the underlying reasoning, not just the what

use numbered steps with clear transitions

build up intuition before giving the formal definition

use bullet points with consistent indentation

after solving, give a similar practice problem

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

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

show each manipulation step with the operation applied noted

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

use camelCase for variables, PascalCase for classes

include inline comments explaining each logical block

use UPPERCASE for keywords, lowercase for table/column names

focus only on bugs and logic errors, ignore style issues

always use specific exception types, never bare except

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

start with definition, then example, then edge cases

describe components as a list first, then explain interactions

confirm the plan before executing, break into phases

present trade-offs in a table format with clear criteria

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

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

acknowledge the error explicitly, then provide corrected version

acknowledge the difficulty briefly, then provide direct help

include the mathematical formulation alongside intuitive explanation

use snake_case for variables and functions, include type hints

use docstrings at function/class level, minimal inline comments

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

address both logic and style, suggest modern idioms

focus on diagnosing the specific issue, skip general explanations


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

respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

use numbered steps with clear transitions

build up intuition before giving the formal definition

use bullet points with consistent indentation

show each manipulation step with the operation applied noted

start with intuition and real-world interpretation before formulas

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

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

always use specific exception types, never bare except

use snake_case for variables and functions, include type hints

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

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

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

correct it gently inline without making it a focus

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

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

use UPPERCASE for keywords, lowercase for table/column names

describe components as a list first, then explain interactions

address both logic and style, suggest modern idioms


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

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

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

show each manipulation step with the operation applied noted

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

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

use snake_case for variables and functions, include type hints

use docstrings at function/class level, minimal inline comments

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

start with definition, then example, then edge cases

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

execute directly without asking for confirmation

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

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

present trade-offs in a table format with clear criteria

confirm the plan before executing, break into phases

always specify the language in the code fence

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

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

acknowledge the error explicitly, then provide corrected version

focus only on bugs and logic errors, ignore style issues

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

always use specific exception types, never bare except


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

respond in 3 sentences or fewer, no elaboration

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

use numbered steps with clear transitions

use bullet points with consistent indentation

build up intuition before giving the formal definition

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

show each manipulation step with the operation applied noted

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

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

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

use UPPERCASE for keywords, lowercase for table/column names

focus only on bugs and logic errors, ignore style issues

always include time complexity for operations mentioned

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

describe components as a list first, then explain interactions

provide a recommendation with brief rationale, not just options

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

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

present trade-offs in a table format with clear criteria

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

always specify the language in the code fence

provide code in a single copyable block, no interleaved explanation

address the misconception directly and clearly before proceeding

correct it gently inline without making it a focus

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

acknowledge the error explicitly, then provide corrected version

show a minimal working example before explaining parameters

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except


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

focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

provide detailed step-by-step derivation with intermediate results

always explain the underlying reasoning, not just the what

respond in 3 sentences or fewer, no elaboration

use numbered steps with clear transitions

use bullet points with consistent indentation

build up intuition before giving the formal definition

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

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

show each manipulation step with the operation applied noted

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

address both logic and style, suggest modern idioms

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

describe components as a list first, then explain interactions

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

start with definition, then example, then edge cases

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

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

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

start with intuition and real-world interpretation before formulas

after solving, give a similar practice problem

focus only on bugs and logic errors, ignore style issues

show a minimal working example before explaining parameters

use snake_case for variables and functions, include type hints

present trade-offs in a table format with clear criteria

include the mathematical formulation alongside intuitive explanation


focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

respond in 3 sentences or fewer, no elaboration

provide detailed step-by-step derivation with intermediate results

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

show each manipulation step with the operation applied noted

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

focus only on bugs and logic errors, ignore style issues

use UPPERCASE for keywords, lowercase for table/column names

use camelCase for variables, PascalCase for classes

include inline comments explaining each logical block

use snake_case for variables and functions, include type hints

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

confirm the plan before executing, break into phases

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

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

always specify the language in the code fence

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

use bash code blocks, include expected output as comments

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

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

present trade-offs in a table format with clear criteria

start with definition, then example, then edge cases

always use specific exception types, never bare except

describe components as a list first, then explain interactions

address both logic and style, suggest modern idioms

use docstrings at function/class level, minimal inline comments


respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

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

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

show each manipulation step with the operation applied noted

start with intuition and real-world interpretation before formulas

after solving, give a similar practice problem

use snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

include inline comments explaining each logical block

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

show a minimal working example before explaining parameters

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

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

always specify the language in the code fence

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

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

focus only on bugs and logic errors, ignore style issues

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except


provide detailed step-by-step derivation with intermediate results

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

acknowledge what I got right, then correct only the gaps

build up intuition before giving the formal definition

use numbered steps with clear transitions

use bullet points with consistent indentation

show each manipulation step with the operation applied noted

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

address both logic and style, suggest modern idioms

use camelCase for variables, PascalCase for classes

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

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

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

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

address the misconception directly and clearly before proceeding

include inline comments explaining each logical block

start with intuition and real-world interpretation before formulas

include the mathematical formulation alongside intuitive explanation

respond in 3 sentences or fewer, no elaboration

be concise, avoid marketing language, focus on usage

use snake_case for variables and functions, include type hints


acknowledge what I got right, then correct only the gaps

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

use numbered steps with clear transitions

build up intuition before giving the formal definition

use bullet points with consistent indentation

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

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

show each manipulation step with the operation applied noted

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

use snake_case for variables and functions, include type hints

start with definition, then example, then edge cases

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

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

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

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

always specify the language in the code fence

provide code in a single copyable block, no interleaved explanation

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

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

include inline comments explaining each logical block

focus only on bugs and logic errors, ignore style issues


focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

use numbered steps with clear transitions

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

after solving, give a similar practice problem

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

start with intuition and real-world interpretation before formulas

show each manipulation step with the operation applied noted

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

use snake_case for variables and functions, include type hints

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

describe components as a list first, then explain interactions

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

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

confirm the plan before executing, break into phases

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

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

always use specific exception types, never bare except

address both logic and style, suggest modern idioms

use camelCase for variables, PascalCase for classes

use UPPERCASE for keywords, lowercase for table/column names


provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

respond in 3 sentences or fewer, no elaboration

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

start with intuition and real-world interpretation before formulas

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

after solving, give a similar practice problem

show each manipulation step with the operation applied noted

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

include inline comments explaining each logical block

focus only on bugs and logic errors, ignore style issues

use UPPERCASE for keywords, lowercase for table/column names

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

confirm the plan before executing, break into phases

present trade-offs in a table format with clear criteria

acknowledge the difficulty briefly, then provide direct help

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

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

always specify the language in the code fence

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

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

always use specific exception types, never bare except

execute directly without asking for confirmation

use snake_case for variables and functions, include type hints

use docstrings at function/class level, minimal inline comments

address both logic and style, suggest modern idioms

provide a recommendation with brief rationale, not just options


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

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

acknowledge what I got right, then correct only the gaps

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

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

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

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

show a minimal working example before explaining parameters

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

execute directly without asking for confirmation

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

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

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

always specify the language in the code fence

address the misconception directly and clearly before proceeding

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

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

focus only on bugs and logic errors, ignore style issues

show each manipulation step with the operation applied noted


always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

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

after solving, give a similar practice problem

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

start with intuition and real-world interpretation before formulas

use snake_case for variables and functions, include type hints

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

present trade-offs in a table format with clear criteria

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

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

confirm the plan before executing, break into phases

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

break code into small chunks with explanation between each

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

correct it gently inline without making it a focus

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

address both logic and style, suggest modern idioms

acknowledge what I got right, then correct only the gaps


provide detailed step-by-step derivation with intermediate results

focus on diagnosing the specific issue, skip general explanations

respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

after solving, give a similar practice problem

show each manipulation step with the operation applied noted

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

use camelCase for variables, PascalCase for classes

use snake_case for variables and functions, include type hints

focus only on bugs and logic errors, ignore style issues

use docstrings at function/class level, minimal inline comments

include inline comments explaining each logical block

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

execute directly without asking for confirmation

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

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 a recommendation with brief rationale, not just options

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

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

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

always use specific exception types, never bare except

start with intuition and real-world interpretation before formulas


respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

after solving, give a similar practice problem

show each manipulation step with the operation applied noted

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

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

use docstrings at function/class level, minimal inline comments

use snake_case for variables and functions, include type hints

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

always include time complexity for operations mentioned

start with definition, then example, then edge cases

show a minimal working example before explaining parameters

describe components as a list first, then explain interactions

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

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

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

always specify the language in the code fence

address the misconception directly and clearly before proceeding

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

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

start with intuition and real-world interpretation before formulas

present trade-offs in a table format with clear criteria

focus only on bugs and logic errors, ignore style issues

include inline comments explaining each logical block


focus on diagnosing the specific issue, skip general explanations

respond in 3 sentences or fewer, no elaboration

provide detailed step-by-step derivation with intermediate results

always explain the underlying reasoning, not just the what

acknowledge what I got right, then correct only the gaps

use bullet points with consistent indentation

use numbered steps with clear transitions

build up intuition before giving the formal definition

after solving, give a similar practice problem

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

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

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

show each manipulation step with the operation applied noted

always use specific exception types, never bare except

address both logic and style, suggest modern idioms

use docstrings at function/class level, minimal inline comments

use snake_case for variables and functions, include type hints

use UPPERCASE for keywords, lowercase for table/column names

focus only on bugs and logic errors, ignore style issues

be concise, avoid marketing language, focus on usage

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

execute directly without asking for confirmation

confirm the plan before executing, break into phases

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

present trade-offs in a table format with clear criteria

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

use bash code blocks, include expected output as comments

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

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

use camelCase for variables, PascalCase for classes


focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

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

show each manipulation step with the operation applied noted

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

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

always use specific exception types, never bare except

use camelCase for variables, PascalCase for classes

use docstrings at function/class level, minimal inline comments

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

confirm the plan before executing, break into phases

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

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

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

address the misconception directly and clearly before proceeding

include inline comments explaining each logical block

focus only on bugs and logic errors, ignore style issues

execute directly without asking for confirmation

use UPPERCASE for keywords, lowercase for table/column names

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


acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

focus on diagnosing the specific issue, skip general explanations

use bullet points with consistent indentation

use numbered steps with clear transitions

build up intuition before giving the formal definition

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

start with intuition and real-world interpretation before formulas

after solving, give a similar practice problem

show each manipulation step with the operation applied noted

use camelCase for variables, PascalCase for classes

include inline comments explaining each logical block

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

always use specific exception types, never bare except

use docstrings at function/class level, minimal inline comments

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

confirm the plan before executing, break into phases

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

acknowledge the difficulty briefly, then provide direct help

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

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

always specify the language in the code fence

provide code in a single copyable block, no interleaved explanation

address the misconception directly and clearly before proceeding

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

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

focus only on bugs and logic errors, ignore style issues

respond in 3 sentences or fewer, no elaboration

use snake_case for variables and functions, include type hints

provide a recommendation with brief rationale, not just options


focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

use numbered steps with clear transitions

build up intuition before giving the formal definition

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

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

show each manipulation step with the operation applied noted

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

after solving, give a similar practice problem

use docstrings at function/class level, minimal inline comments

include inline comments explaining each logical block

focus only on bugs and logic errors, ignore style issues

always use specific exception types, never bare except

address both logic and style, suggest modern idioms

use camelCase for variables, PascalCase for classes

use snake_case for variables and functions, include type hints

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

describe components as a list first, then explain interactions

show a minimal working example before explaining parameters

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

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

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

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

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

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

present trade-offs in a table format with clear criteria

use UPPERCASE for keywords, lowercase for table/column names


always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

show each manipulation step with the operation applied noted

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

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

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

focus only on bugs and logic errors, ignore style issues

use snake_case for variables and functions, include type hints

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

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

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

always specify the language in the code fence

use bash code blocks, include expected output as comments

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

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

use docstrings at function/class level, minimal inline comments

describe components as a list first, then explain interactions

acknowledge what I got right, then correct only the gaps

start with definition, then example, then edge cases

use camelCase for variables, PascalCase for classes


provide detailed step-by-step derivation with intermediate results

always explain the underlying reasoning, not just the what

respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

after solving, give a similar practice problem

show each manipulation step with the operation applied noted

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

start with intuition and real-world interpretation before formulas

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

always use specific exception types, never bare except

use docstrings at function/class level, minimal inline comments

use snake_case for variables and functions, include type hints

be concise, avoid marketing language, focus on usage

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

describe components as a list first, then explain interactions

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

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

confirm the plan before executing, break into phases

present trade-offs in a table format with clear criteria

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

always specify the language in the code fence

provide code in a single copyable block, no interleaved explanation

correct it gently inline without making it a focus

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

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

acknowledge the difficulty briefly, then provide direct help

focus only on bugs and logic errors, ignore style issues

address both logic and style, suggest modern idioms


focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

use numbered steps with clear transitions

use bullet points with consistent indentation

build up intuition before giving the formal definition

start with intuition and real-world interpretation before formulas

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

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

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

show each manipulation step with the operation applied noted

after solving, give a similar practice problem

always use specific exception types, never bare except

focus only on bugs and logic errors, ignore style issues

use snake_case for variables and functions, include type hints

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

address both logic and style, suggest modern idioms

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

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

always specify the language in the code fence

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

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

correct it gently inline without making it a focus

include inline comments explaining each logical block

include the mathematical formulation alongside intuitive explanation

use camelCase for variables, PascalCase for classes


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

always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

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

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

show each manipulation step with the operation applied noted

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

include inline comments explaining each logical block

always use specific exception types, never bare except

focus only on bugs and logic errors, ignore style issues

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

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

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

provide a recommendation with brief rationale, not just options

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

correct it gently inline without making it a focus

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

use snake_case for variables and functions, include type hints

be concise, avoid marketing language, focus on usage

use docstrings at function/class level, minimal inline comments

include the mathematical formulation alongside intuitive explanation


provide detailed step-by-step derivation with intermediate results

focus on diagnosing the specific issue, skip general explanations

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

respond in 3 sentences or fewer, no elaboration

use numbered steps with clear transitions

build up intuition before giving the formal definition

use bullet points with consistent indentation

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

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

show each manipulation step with the operation applied noted

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

focus only on bugs and logic errors, ignore style issues

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

include inline comments explaining each logical block

address both logic and style, suggest modern idioms

use snake_case for variables and functions, include type hints

start with definition, then example, then edge cases

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

confirm the plan before executing, break into phases

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

always specify the language in the code fence

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

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

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

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

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

use camelCase for variables, PascalCase for classes


acknowledge what I got right, then correct only the gaps

respond in 3 sentences or fewer, no elaboration

provide detailed step-by-step derivation with intermediate results

focus on diagnosing the specific issue, skip general explanations

use numbered steps with clear transitions

build up intuition before giving the formal definition

use bullet points with consistent indentation

start with intuition and real-world interpretation before formulas

after solving, give a similar practice problem

show each manipulation step with the operation applied noted

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 use specific exception types, never bare except

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

present trade-offs in a table format with clear criteria

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

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

always specify the language in the code fence

provide code in a single copyable block, no interleaved explanation

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

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

address the misconception directly and clearly before proceeding

use UPPERCASE for keywords, lowercase for table/column names

use snake_case for variables and functions, include type hints

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

always explain the underlying reasoning, not just the what

include inline comments explaining each logical block

address both logic and style, suggest modern idioms


provide detailed step-by-step derivation with intermediate results

focus on diagnosing the specific issue, skip general explanations

respond in 3 sentences or fewer, no elaboration

use numbered steps with clear transitions

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

after solving, give a similar practice problem

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

start with intuition and real-world interpretation before formulas

show each manipulation step with the operation applied noted

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

use snake_case for variables and functions, include type hints

always use specific exception types, never bare except

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

be concise, avoid marketing language, focus on usage

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

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

confirm the plan before executing, break into phases

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

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

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

use UPPERCASE for keywords, lowercase for table/column names

acknowledge what I got right, then correct only the gaps

use docstrings at function/class level, minimal inline comments


always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

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

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

show each manipulation step with the operation applied noted

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

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

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

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

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

acknowledge the error explicitly, then provide corrected version

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

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

use docstrings at function/class level, minimal inline comments

be concise, avoid marketing language, focus on usage

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

start with definition, then example, then edge cases


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

focus on diagnosing the specific issue, skip general explanations

use numbered steps with clear transitions

use bullet points with consistent indentation

build up intuition before giving the formal definition

start with intuition and real-world interpretation before formulas

show each manipulation step with the operation applied noted

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

use docstrings at function/class level, minimal inline comments

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

focus only on bugs and logic errors, ignore style issues

include inline comments explaining each logical block

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

execute directly without asking for confirmation

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

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

acknowledge the difficulty briefly, then provide direct help

present trade-offs in a table format with clear criteria

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

use bash code blocks, include expected output as comments

always specify the language in the code fence

correct it gently inline without making it a focus

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

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

provide detailed step-by-step derivation with intermediate results

always use specific exception types, never bare except

use camelCase for variables, PascalCase for classes

use UPPERCASE for keywords, lowercase for table/column names

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


respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

acknowledge what I got right, then correct only the gaps

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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 intuition and real-world interpretation before formulas

after solving, give a similar practice problem

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

use docstrings at function/class level, minimal inline comments

use camelCase for variables, PascalCase for classes

use UPPERCASE for keywords, lowercase for table/column names

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

provide a recommendation with brief rationale, not just options

confirm the plan before executing, break into phases

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

acknowledge the difficulty briefly, then provide direct help

present trade-offs in a table format with clear criteria

provide code in a single copyable block, no interleaved explanation

use bash code blocks, include expected output as comments

always specify the language in the code fence

break code into small chunks with explanation between each

address the misconception directly and clearly before proceeding

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

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

describe components as a list first, then explain interactions

use snake_case for variables and functions, include type hints

focus on diagnosing the specific issue, skip general explanations

execute directly without asking for confirmation

include inline comments explaining each logical block


acknowledge what I got right, then correct only the gaps

provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

show each manipulation step with the operation applied noted

start with intuition and real-world interpretation before formulas

after solving, give a similar practice problem

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

focus only on bugs and logic errors, ignore style issues

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

address both logic and style, suggest modern idioms

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

execute directly without asking for confirmation

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

present trade-offs in a table format with clear criteria

provide a recommendation with brief rationale, not just options

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

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

always specify the language in the code fence

acknowledge the error explicitly, then provide corrected version

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

address the misconception directly and clearly before proceeding

correct it gently inline without making it a focus

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

use docstrings at function/class level, minimal inline comments

use UPPERCASE for keywords, lowercase for table/column names

use snake_case for variables and functions, include type hints


acknowledge what I got right, then correct only the gaps

provide detailed step-by-step derivation with intermediate results

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

use bullet points with consistent indentation

use numbered steps with clear transitions

build up intuition before giving the formal definition

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

start with intuition and real-world interpretation before formulas

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

always use specific exception types, never bare except

include inline comments explaining each logical block

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

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

include the mathematical formulation alongside intuitive explanation

describe components as a list first, then explain interactions

be concise, avoid marketing language, focus on usage

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

acknowledge the difficulty briefly, then provide direct help

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

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

always specify the language in the code fence

use bash code blocks, include expected output as comments

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

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

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

respond in 3 sentences or fewer, no elaboration

after solving, give a similar practice problem

show each manipulation step with the operation applied noted

use docstrings at function/class level, minimal inline comments

use camelCase for variables, PascalCase for classes


focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

always explain the underlying reasoning, not just the what

acknowledge what I got right, then correct only the gaps

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

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

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

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

start with intuition and real-world interpretation before formulas

include inline comments explaining each logical block

address both logic and style, suggest modern idioms

use UPPERCASE for keywords, lowercase for table/column names

describe components as a list first, then explain interactions

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

acknowledge the difficulty briefly, then provide direct help

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

confirm the plan before executing, break into phases

execute directly without asking for confirmation

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

always specify the language in the code fence

use bash code blocks, include expected output as comments

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

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

address the misconception directly and clearly before proceeding

include the mathematical formulation alongside intuitive explanation

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

use snake_case for variables and functions, include type hints


acknowledge what I got right, then correct only the gaps

focus on diagnosing the specific issue, skip general explanations

respond in 3 sentences or fewer, no elaboration

provide detailed step-by-step derivation with intermediate results

always explain the underlying reasoning, not just the what

use bullet points with consistent indentation

use numbered steps with clear transitions

build up intuition before giving the formal definition

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

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

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

show each manipulation step with the operation applied noted

address both logic and style, suggest modern idioms

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

always use specific exception types, never bare except

use docstrings at function/class level, minimal inline comments

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

execute directly without asking for confirmation

confirm the plan before executing, break into phases

acknowledge the difficulty briefly, then provide direct help

present trade-offs in a table format with clear criteria

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

provide a recommendation with brief rationale, not just options

use bash code blocks, include expected output as comments

always specify the language in the code fence

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

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

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

use UPPERCASE for keywords, lowercase for table/column names

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

include inline comments explaining each logical block

use snake_case for variables and functions, include type hints


provide detailed step-by-step derivation with intermediate results

respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

acknowledge what I got right, then correct only the gaps

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

show each manipulation step with the operation applied noted

start with intuition and real-world interpretation before formulas

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

after solving, give a similar practice problem

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

focus only on bugs and logic errors, ignore style issues

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

confirm the plan before executing, break into phases

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

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

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

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

address the misconception directly and clearly before proceeding

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

always include time complexity for operations mentioned

address both logic and style, suggest modern idioms

start with definition, then example, then edge cases


respond in 3 sentences or fewer, no elaboration

focus on diagnosing the specific issue, skip general explanations

always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

use numbered steps with clear transitions

use bullet points with consistent indentation

build up intuition before giving the formal definition

start with intuition and real-world interpretation before formulas

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

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

after solving, give a similar practice problem

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

show each manipulation step with the operation applied noted

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

use snake_case for variables and functions, include type hints

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

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

show a minimal working example before explaining parameters

execute directly without asking for confirmation

acknowledge the difficulty briefly, then provide direct help

provide a recommendation with brief rationale, not just options

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

confirm the plan before executing, break into phases

present trade-offs in a table format with clear criteria

use bash code blocks, include expected output as comments

always specify the language in the code fence

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

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

address the misconception directly and clearly before proceeding

correct it gently inline without making it a focus

acknowledge the error explicitly, then provide corrected version

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

address both logic and style, suggest modern idioms


respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

show each manipulation step with the operation applied noted

start with intuition and real-world interpretation before formulas

after solving, give a similar practice problem

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

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

include inline comments explaining each logical block

use snake_case for variables and functions, include type hints

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

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

present trade-offs in a table format with clear criteria

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

use bash code blocks, include expected output as comments

always specify the language in the code fence

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

acknowledge the error explicitly, then provide corrected version

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

address the misconception directly and clearly before proceeding

correct it gently inline without making it a focus

use docstrings at function/class level, minimal inline comments

start with definition, then example, then edge cases

address both logic and style, suggest modern idioms

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

show a minimal working example before explaining parameters

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


always explain the underlying reasoning, not just the what

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

focus on diagnosing the specific issue, skip general explanations

respond in 3 sentences or fewer, no elaboration

build up intuition before giving the formal definition

use numbered steps with clear transitions

use bullet points with consistent indentation

show each manipulation step with the operation applied noted

after solving, give a similar practice problem

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

start with intuition and real-world interpretation before formulas

use camelCase for variables, PascalCase for classes

use snake_case for variables and functions, include type hints

focus only on bugs and logic errors, ignore style issues

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

include inline comments explaining each logical block

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

start with definition, then example, then edge cases

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

confirm the plan before executing, break into phases

execute directly without asking for confirmation

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

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

acknowledge the difficulty briefly, then provide direct help

always specify the language in the code fence

break code into small chunks with explanation between each

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

address the misconception directly and clearly before proceeding

correct it gently inline without making it a focus

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

acknowledge the error explicitly, then provide corrected version

use docstrings at function/class level, minimal inline comments

address both logic and style, suggest modern idioms


respond in 3 sentences or fewer, no elaboration

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

provide detailed step-by-step derivation with intermediate results

acknowledge what I got right, then correct only the gaps

use bullet points with consistent indentation

build up intuition before giving the formal definition

use numbered steps with clear transitions

show each manipulation step with the operation applied noted

start with intuition and real-world interpretation before formulas

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

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

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

after solving, give a similar practice problem

use UPPERCASE for keywords, lowercase for table/column names

use camelCase for variables, PascalCase for classes

include inline comments explaining each logical block

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

include the mathematical formulation alongside intuitive explanation

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

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

always specify the language in the code fence

address the misconception directly and clearly before proceeding

acknowledge the error explicitly, then provide corrected version

correct it gently inline without making it a focus

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

use snake_case for variables and functions, include type hints

always use specific exception types, never bare except

acknowledge the difficulty briefly, then provide direct help

focus only on bugs and logic errors, ignore style issues

use docstrings at function/class level, minimal inline comments