use docstrings at function/class level, minimal inline comments

include inline comments explaining each logical block

acknowledge the difficulty briefly, then provide direct help

provide detailed step-by-step derivation with intermediate results

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

break code into small chunks with explanation between each

use snake_case for variables and functions, include type hints

always use specific exception types, never bare except

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

include the mathematical formulation alongside intuitive explanation

confirm the plan before executing, break into phases

provide a recommendation with brief rationale, not just options

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

show each manipulation step with the operation applied noted

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

execute directly without asking for confirmation

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

start with definition, then example, then edge cases

focus only on bugs and logic errors, ignore style issues

use bullet points with consistent indentation

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

always specify the language in the code fence

use numbered steps with clear transitions

always explain the underlying reasoning, not just the what

present trade-offs in a table format with clear criteria

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

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

start with intuition and real-world interpretation before formulas

show a minimal working example before explaining parameters

respond in 3 sentences or fewer, no elaboration


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

be concise, avoid marketing language, focus on usage

after solving, give a similar practice problem

always use specific exception types, never bare except

execute directly without asking for confirmation

address the misconception directly and clearly before proceeding

discussing system design or architecture

use UPPERCASE for keywords, lowercase for table/column names

show each manipulation step with the operation applied noted

I seem uncertain or ask 'what do you think'

provide a recommendation with brief rationale, not just options

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

include the mathematical formulation alongside intuitive explanation

always specify the language in the code fence

the code snippet is short (under 20 lines)

include inline comments explaining each logical block

explaining a sequential process or procedure

use numbered steps with clear transitions

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

use camelCase for variables, PascalCase for classes

focus on diagnosing the specific issue, skip general explanations

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 both logic and style, suggest modern idioms

I explicitly share my current understanding first

acknowledge what I got right, then correct only the gaps

always include time complexity for operations mentioned

use bullet points with consistent indentation

break code into small chunks with explanation between each

use docstrings at function/class level, minimal inline comments

confirm the plan before executing, break into phases

correct it gently inline without making it a focus

focus only on bugs and logic errors, ignore style issues

start with definition, then example, then edge cases

I express frustration or say 'this is annoying'

acknowledge the difficulty briefly, then provide direct help

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

build up intuition before giving the formal definition

start with intuition and real-world interpretation before formulas

use bash code blocks, include expected output as comments

use snake_case for variables and functions, include type hints


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

present trade-offs in a table format with clear criteria

acknowledge the error explicitly, then provide corrected version

the topic involves complex algorithms or mathematics

provide detailed step-by-step derivation with intermediate results

include inline comments explaining each logical block

I thank you or say the answer was helpful

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

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

confirm the plan before executing, break into phases

use camelCase for variables, PascalCase for classes

after solving, give a similar practice problem

always use specific exception types, never bare except

provide code in a single copyable block, no interleaved explanation

respond in 3 sentences or fewer, no elaboration

execute directly without asking for confirmation

acknowledge the difficulty briefly, then provide direct help

start with intuition and real-world interpretation before formulas

use bullet points with consistent indentation

break code into small chunks with explanation between each

always explain the underlying reasoning, not just the what

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

use numbered steps with clear transitions

focus on diagnosing the specific issue, skip general explanations

show each manipulation step with the operation applied noted

be concise, avoid marketing language, focus on usage

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

start with definition, then example, then edge cases

provide a recommendation with brief rationale, not just options

address the misconception directly and clearly before proceeding

focus only on bugs and logic errors, ignore style issues

include the mathematical formulation alongside intuitive explanation

correct it gently inline without making it a focus

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


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

confirm the plan before executing, break into phases

show a minimal working example before explaining parameters

acknowledge the error explicitly, then provide corrected version

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

describe components as a list first, then explain interactions

after solving, give a similar practice problem

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

provide detailed step-by-step derivation with intermediate results

use snake_case for variables and functions, include type hints

use bullet points with consistent indentation

include inline comments explaining each logical block

use numbered steps with clear transitions

always specify the language in the code fence

start with intuition and real-world interpretation before formulas

execute directly without asking for confirmation

always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

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

be concise, avoid marketing language, focus on usage

use bash code blocks, include expected output as comments

acknowledge what I got right, then correct only the gaps

use docstrings at function/class level, minimal inline comments

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

show each manipulation step with the operation applied noted

provide code in a single copyable block, no interleaved explanation

focus only on bugs and logic errors, ignore style issues

always include time complexity for operations mentioned

address both logic and style, suggest modern idioms

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

provide a recommendation with brief rationale, not just options

respond in 3 sentences or fewer, no elaboration

break code into small chunks with explanation between each


provide detailed step-by-step derivation with intermediate results

always explain the underlying reasoning, not just the what

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

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

include inline comments explaining each logical block

always use specific exception types, never bare except

address both logic and style, suggest modern idioms

describe components as a list first, then explain interactions

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

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

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

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

start with definition, then example, then edge cases

focus only on bugs and logic errors, ignore style issues

use camelCase for variables, PascalCase for classes

after solving, give a similar practice problem

use snake_case for variables and functions, include type hints

acknowledge the difficulty briefly, then provide direct help

always include time complexity for operations mentioned

use docstrings at function/class level, minimal inline comments

confirm the plan before executing, break into phases


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

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

use bullet points with consistent indentation

use numbered steps with clear transitions

build up intuition before giving the formal definition

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

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

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

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

use docstrings at function/class level, minimal inline comments

show a minimal working example before explaining parameters

describe components as a list first, then explain interactions

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

present trade-offs in a table format with clear criteria

acknowledge the difficulty briefly, then provide direct help

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

provide code in a single copyable block, no interleaved explanation

use bash code blocks, include expected output as comments

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

use snake_case for variables and functions, include type hints

provide a recommendation with brief rationale, not just options

focus only on bugs and logic errors, ignore style issues

confirm the plan before executing, break into phases

use UPPERCASE for keywords, lowercase for table/column names

always use specific exception types, never bare except


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

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

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

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

use docstrings at function/class level, minimal inline comments

use snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

start with definition, then example, then edge cases

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

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

acknowledge the error explicitly, then provide corrected version

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

address both logic and style, suggest modern idioms

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

include inline comments explaining each logical block

show a minimal working example before explaining parameters

always use specific exception types, never bare except

focus only on bugs and logic errors, ignore style issues

describe components as a list first, then explain interactions


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

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

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

show each manipulation step with the operation applied noted

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

address both logic and style, suggest modern idioms

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

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

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

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

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

always specify the language in the code fence

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

include inline comments explaining each logical block

use UPPERCASE for keywords, lowercase for table/column names

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

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

use bullet points with consistent indentation

use numbered steps with clear transitions

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

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

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

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

present trade-offs in a table format with clear criteria

provide a recommendation with brief rationale, not just options

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

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

confirm the plan before executing, break into phases

use UPPERCASE for keywords, lowercase for table/column names

use snake_case for variables and functions, include type hints

start with intuition and real-world interpretation before formulas

start with definition, then example, then edge cases

address both logic and style, suggest modern idioms

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

be concise, avoid marketing language, focus on usage

use docstrings at function/class level, minimal inline comments


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

provide detailed step-by-step derivation with intermediate results

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

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

use UPPERCASE for keywords, lowercase for table/column names

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

use camelCase for variables, PascalCase for classes

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

always include time complexity for operations mentioned

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

execute directly without asking for confirmation

present trade-offs in a table format with clear criteria

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

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

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

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

show a minimal working example before explaining parameters

include the mathematical formulation alongside intuitive explanation

use docstrings at function/class level, minimal inline comments

start with intuition and real-world interpretation before formulas

acknowledge what I got right, then correct only the gaps

always use specific exception types, never bare except

use snake_case for variables and functions, include type hints


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

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

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

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

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

address both logic and style, suggest modern idioms

use UPPERCASE for keywords, lowercase for table/column names

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

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

start with definition, then example, then edge cases

provide a recommendation with brief rationale, not just options

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

execute directly without asking for confirmation

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

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

after solving, give a similar practice problem

confirm the plan before executing, break into phases

show each manipulation step with the operation applied noted

acknowledge the difficulty briefly, then provide direct help

describe components as a list first, then explain interactions

always use specific exception types, never bare except


always explain the underlying reasoning, not just the what

focus on diagnosing the specific issue, skip general explanations

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

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

use snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

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

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

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

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

after solving, give a similar practice problem

use docstrings at function/class level, minimal inline comments

present trade-offs in a table format with clear criteria

include inline comments explaining each logical block

show a minimal working example before explaining parameters

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

describe components as a list first, then explain interactions

show each manipulation step with the operation applied noted

respond in 3 sentences or fewer, no elaboration

focus only on bugs and logic errors, ignore style issues


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

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

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

start with intuition and real-world interpretation before formulas

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

after solving, give a similar practice problem

use UPPERCASE for keywords, lowercase for table/column names

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

describe components as a list first, then explain interactions

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

start with definition, then example, then edge cases

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

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

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

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

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

use docstrings at function/class level, minimal inline comments

include the mathematical formulation alongside intuitive explanation

use camelCase for variables, PascalCase for classes

always use specific exception types, never bare except

be concise, avoid marketing language, focus on usage


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

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

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

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

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

include the mathematical formulation alongside intuitive explanation

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

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

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

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

always include time complexity for operations mentioned

focus only on bugs and logic errors, ignore style issues

address both logic and style, suggest modern idioms

execute directly without asking for confirmation

start with definition, then example, then edge cases


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

acknowledge what I got right, then correct only the gaps

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

after solving, give a similar practice problem

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

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

use docstrings at function/class level, minimal inline comments

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

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

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

present trade-offs in a table format with clear criteria

execute directly without asking for confirmation

acknowledge the difficulty briefly, then provide direct help

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

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

always use specific exception types, never bare except

confirm the plan before executing, break into phases

include inline comments explaining each logical block

provide a recommendation with brief rationale, not just options

show each manipulation step with the operation applied noted

show a minimal working example before explaining parameters


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

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

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

start with intuition and real-world interpretation before formulas

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

address both logic and style, suggest modern idioms

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

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

provide a recommendation with brief rationale, not just options

acknowledge the difficulty briefly, then provide direct help

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

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

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

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

always explain the underlying reasoning, not just the what

include the mathematical formulation alongside intuitive explanation

focus only on bugs and logic errors, ignore style issues

use camelCase for variables, PascalCase for classes

present trade-offs in a table format with clear criteria

include inline comments explaining each logical block

confirm the plan before executing, break into phases


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

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

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

start with intuition and real-world interpretation before formulas

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except

use snake_case for variables and functions, include type hints

focus only on bugs and logic errors, ignore style issues

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

include the mathematical formulation alongside intuitive explanation

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

execute directly without asking for confirmation

confirm the plan before executing, break into phases

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

provide code in a single copyable block, no interleaved explanation

use bash code blocks, include expected output as comments

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

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

address both logic and style, suggest modern idioms

provide a recommendation with brief rationale, not just options

present trade-offs in a table format with clear criteria

use UPPERCASE for keywords, lowercase for table/column names

after solving, give a similar practice problem

always include time complexity for operations mentioned


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

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

always explain the underlying reasoning, not just the what

build up intuition before giving the formal definition

use numbered steps with clear transitions

use bullet points with consistent indentation

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

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

address both logic and style, suggest modern idioms

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

start with definition, then example, then edge cases

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

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

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

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

always use specific exception types, never bare except

describe components as a list first, then explain interactions

show a minimal working example before explaining parameters

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

focus on diagnosing the specific issue, skip general explanations

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

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

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

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

start with intuition and real-world interpretation before formulas

show each manipulation step with the operation applied noted

use UPPERCASE for keywords, lowercase for table/column names

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except

use snake_case for variables and functions, include type hints

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

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

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

execute directly without asking for confirmation

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

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

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

present trade-offs in a table format with clear criteria

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

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

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

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

start with intuition and real-world interpretation before formulas

use UPPERCASE for keywords, lowercase for table/column names

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

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

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

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

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

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

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

use docstrings at function/class level, minimal inline comments

show each manipulation step with the operation applied noted

focus only on bugs and logic errors, ignore style issues

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

include inline comments explaining each logical block

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

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

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

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

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

use snake_case for variables and functions, include type hints

include inline comments explaining each logical block

always use specific exception types, never bare except

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

show a minimal working example before explaining parameters

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

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

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

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 docstrings at function/class level, minimal inline comments

use UPPERCASE for keywords, lowercase for table/column names

focus only on bugs and logic errors, ignore style issues

use camelCase for variables, PascalCase for classes


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

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

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

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

include inline comments explaining each logical block

always use specific exception types, never bare except

include the mathematical formulation alongside intuitive explanation

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

always include time complexity for operations mentioned

start with definition, then example, then edge cases

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

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

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

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

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

address both logic and style, suggest modern idioms

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

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

acknowledge what I got right, then correct only the gaps

always explain the underlying reasoning, not just the what

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

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

use docstrings at function/class level, minimal inline comments

use snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

include the mathematical formulation alongside intuitive explanation

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

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

provide code in a single copyable block, no interleaved explanation

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

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

address both logic and style, suggest modern idioms

show a minimal working example before explaining parameters

provide a recommendation with brief rationale, not just options

include inline comments explaining each logical block

use UPPERCASE for keywords, lowercase for table/column names

be concise, avoid marketing language, focus on usage

show each manipulation step with the operation applied noted

always use specific exception types, never bare except

execute directly without asking for confirmation


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

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

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

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

after solving, give a similar practice problem

address both logic and style, suggest modern idioms

use UPPERCASE for keywords, lowercase for table/column names

use snake_case for variables and functions, include type hints

include inline comments explaining each logical block

use camelCase for variables, PascalCase for classes

describe components as a list first, then explain interactions

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

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

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

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

focus only on bugs and logic errors, ignore style issues

present trade-offs in a table format with clear criteria

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except


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

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

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

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

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

include the mathematical formulation alongside intuitive explanation

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

always include time complexity for operations mentioned

show a minimal working example before explaining parameters

acknowledge the difficulty briefly, then provide direct help

confirm the plan before executing, break into phases

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

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

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

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

use camelCase for variables, PascalCase for classes

show each manipulation step with the operation applied noted

provide a recommendation with brief rationale, not just options

always explain the underlying reasoning, not just the what

use snake_case for variables and functions, include type hints


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

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

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

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

use UPPERCASE for keywords, lowercase for table/column names

use camelCase for variables, PascalCase for classes

focus only on bugs and logic errors, ignore style issues

use docstrings at function/class level, minimal inline comments

address both logic and style, suggest modern idioms

always use specific exception types, never bare except

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

start with definition, then example, then edge cases

describe components as a list first, then explain interactions

execute directly without asking for confirmation

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

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 inline comments explaining each logical block


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

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

provide detailed step-by-step derivation with intermediate results

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

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

start with intuition and real-world interpretation before formulas

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

after solving, give a similar practice problem

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

include inline comments explaining each logical block

show a minimal working example before explaining parameters

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

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

provide a recommendation with brief rationale, not just options

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

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

correct it gently inline without making it a focus

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

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

use docstrings at function/class level, minimal inline comments

use UPPERCASE for keywords, lowercase for table/column names

execute directly without asking for confirmation


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

acknowledge what I got right, then correct only the gaps

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

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

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

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

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except

include inline comments explaining each logical block

address both logic and style, suggest modern idioms

include the mathematical formulation alongside intuitive explanation

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

provide a recommendation with brief rationale, not just options

execute directly without asking for confirmation

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

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

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

be concise, avoid marketing language, focus on usage

use snake_case for variables and functions, include type hints

confirm the plan before executing, break into phases


always explain the underlying reasoning, not just the what

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

build up intuition before giving the formal definition

use bullet points with consistent indentation

use numbered steps with clear transitions

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

always use specific exception types, never bare except

use UPPERCASE for keywords, lowercase for table/column names

use camelCase for variables, PascalCase for classes

start with definition, then example, then edge cases

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

be concise, avoid marketing language, focus on usage

execute directly without asking for confirmation

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

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

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

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

start with intuition and real-world interpretation before formulas

include inline comments explaining each logical block

focus only on bugs and logic errors, ignore style issues

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


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

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

use snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

use docstrings at function/class level, minimal inline comments

address both logic and style, suggest modern idioms

focus only on bugs and logic errors, ignore style issues

always use specific exception types, never bare except

include inline comments explaining each logical block

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

start with definition, then example, then edge cases

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

execute directly without asking for confirmation

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

break code into small chunks with explanation between each

provide code in a single copyable block, no interleaved explanation

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

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

show a minimal working example before explaining parameters

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

use UPPERCASE for keywords, lowercase for table/column names


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

provide detailed step-by-step derivation with intermediate results

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

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

use docstrings at function/class level, minimal inline comments

use camelCase for variables, PascalCase for classes

include inline comments explaining each logical block

use snake_case for variables and functions, include type hints

describe components as a list first, then explain interactions

start with definition, then example, then edge cases

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

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

acknowledge the difficulty briefly, then provide direct help

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

execute directly without asking for confirmation

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

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

always use specific exception types, never bare except

focus only on bugs and logic errors, ignore style issues

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

address both logic and style, suggest modern idioms

focus on diagnosing the specific issue, skip general explanations

show a minimal working example before explaining parameters


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

use numbered steps with clear transitions

use bullet points with consistent indentation

build up intuition before giving the formal definition

after solving, give a similar practice problem

start with intuition and real-world interpretation before formulas

show each manipulation step with the operation applied noted

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

use docstrings at function/class level, minimal inline comments

include inline comments explaining each logical block

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

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

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

execute directly without asking for confirmation

acknowledge the difficulty briefly, then provide direct help

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

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

provide detailed step-by-step derivation with intermediate results

use UPPERCASE for keywords, lowercase for table/column names

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

focus only on bugs and logic errors, ignore style issues

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


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

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

show each manipulation step with the operation applied noted

after solving, give a similar practice problem

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

use docstrings at function/class level, minimal inline comments

always use specific exception types, never bare except

use camelCase for variables, PascalCase for classes

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

include the mathematical formulation alongside intuitive explanation

always include time complexity for operations mentioned

be concise, avoid marketing language, focus on usage

describe components as a list first, then explain interactions

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

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

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

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

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

use snake_case for variables and functions, include type hints

focus only on bugs and logic errors, ignore style issues

start with intuition and real-world interpretation before formulas


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

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

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

use camelCase for variables, PascalCase for classes

use docstrings at function/class level, minimal inline comments

address both logic and style, suggest modern idioms

always use specific exception types, never bare except

start with definition, then example, then edge cases

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

describe components as a list first, then explain interactions

present trade-offs in a table format with clear criteria

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

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

provide a recommendation with brief rationale, not just options

confirm the plan before executing, break into phases

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

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 snake_case for variables and functions, include type hints

always include time complexity for operations mentioned

focus only on bugs and logic errors, ignore style issues

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

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

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

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

show each manipulation step with the operation applied noted

after solving, give a similar practice problem

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

use camelCase for variables, PascalCase for classes

use UPPERCASE for keywords, lowercase for table/column names

address both logic and style, suggest modern idioms

include inline comments explaining each logical block

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

present trade-offs in a table format with clear criteria

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

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

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

execute directly without asking for confirmation

focus only on bugs and logic errors, ignore style issues

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


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

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

show each manipulation step with the operation applied noted

always use specific exception types, never bare except

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

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

start with definition, then example, then edge cases

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

execute directly without asking for confirmation

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

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 snake_case for variables and functions, include type hints

describe components as a list first, then explain interactions

use camelCase for variables, PascalCase for classes

present trade-offs in a table format with clear criteria

use docstrings at function/class level, minimal inline comments

always explain the underlying reasoning, not just the what

include the mathematical formulation alongside intuitive explanation

address both logic and style, suggest modern idioms


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

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

always use specific exception types, never bare except

use camelCase for variables, PascalCase for classes

use snake_case for variables and functions, include type hints

describe components as a list first, then explain interactions

always include time complexity for operations mentioned

include the mathematical formulation alongside intuitive explanation

be concise, avoid marketing language, focus on usage

show a minimal working example before explaining parameters

start with definition, then example, then edge cases

execute directly without asking for confirmation

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

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

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 each manipulation step with the operation applied noted

focus only on bugs and logic errors, ignore style issues

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

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

use docstrings at function/class level, minimal inline comments

include inline comments explaining each logical block

acknowledge the difficulty briefly, then provide direct help

use UPPERCASE for keywords, lowercase for table/column names


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

always explain the underlying reasoning, not just the what

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

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

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

start with intuition and real-world interpretation before formulas

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

after solving, give a similar practice problem

always use specific exception types, never bare except

use camelCase for variables, PascalCase for classes

use docstrings at function/class level, minimal inline comments

focus only on bugs and logic errors, ignore style issues

use snake_case for variables and functions, include type hints

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

show a minimal working example before explaining parameters

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

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

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

show each manipulation step with the operation applied noted

execute directly without asking for confirmation

include inline comments explaining each logical block

describe components as a list first, then explain interactions

present trade-offs in a table format with clear criteria

address both logic and style, suggest modern idioms

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

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

use bullet points with consistent indentation

use numbered steps with clear transitions

build up intuition before giving the formal definition

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

start with intuition and real-world interpretation before formulas

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

after solving, give a similar practice problem

always use specific exception types, never bare except

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

be concise, avoid marketing language, focus on usage

include the mathematical formulation alongside intuitive explanation

start with definition, then example, then edge cases

show a minimal working example before explaining parameters

always include time complexity for operations mentioned

acknowledge the difficulty briefly, then provide direct help

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

confirm the plan before executing, break into phases

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

use bash code blocks, include expected output as comments

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

describe components as a list first, then explain interactions

use snake_case for variables and functions, include type hints

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

focus only on bugs and logic errors, ignore style issues

include inline comments explaining each logical block


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

acknowledge what I got right, then correct only the gaps

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

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

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

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 snake_case for variables and functions, include type hints

use camelCase for variables, PascalCase for classes

describe components as a list first, then explain interactions

show a minimal working example before explaining parameters

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

provide a recommendation with brief rationale, not just options

confirm the plan before executing, break into phases

present trade-offs in a table format with clear criteria

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

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

use bash code blocks, include expected output as comments

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

include inline comments explaining each logical block

acknowledge the difficulty briefly, then provide direct help

execute directly without asking for confirmation

focus only on bugs and logic errors, ignore style issues

use docstrings at function/class level, minimal inline comments


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

provide detailed step-by-step derivation with intermediate results

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

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

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

use camelCase for variables, PascalCase for classes

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

start with definition, then example, then edge cases

show a minimal working example before explaining parameters

be concise, avoid marketing language, focus on usage

always include time complexity for operations mentioned

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

present trade-offs in a table format with clear criteria

use bash code blocks, include expected output as comments

provide code in a single copyable block, no interleaved explanation

break code into small chunks with explanation between each

always specify the language in the code fence

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

describe components as a list first, then explain interactions

include the mathematical formulation alongside intuitive explanation

acknowledge the difficulty briefly, then provide direct help

show each manipulation step with the operation applied noted

always use specific exception types, never bare except

execute directly without asking for confirmation