math_problem_solving v1.0.0

name: "math_problem_solving" description: "Solve math problems systematically with Polya's four steps, write complete solutions, and improve through an error log and targeted drills. Triggers when someone asks how to solve a math problem, how to get better at math, how to study math, or how to fix recurring mistakes." metadata: { "includeInPrompt": true }

Math Problem Solving

Purpose

Turn math from guesswork into a repeatable method. This skill guides an agent (and the person it helps) through a problem using Polya's four steps, produces a full written solution rather than just an answer, and builds a lasting error log that drives targeted practice. Use it whenever a math problem needs solving, a solution needs checking, or someone wants to get better at math.

Workflow

1. Understand the problem

Before touching a pencil, answer these on paper or aloud:

• What is the unknown? What exactly are we finding?
• What is given? List the data, and list the conditions each piece must satisfy.
• Restate the problem in your own words. If you cannot, you do not understand it yet.
• Can you draw a figure, table, or small example? A concrete picture beats abstract staring.
• Is it the kind of problem you have seen before? If not, what is the closest one?

Rule: no plan, no equations, until the restatement exists.

2. Devise a plan

Find the connection between the data and the unknown. Pick from these moves, in this order of cheapness:

1. Look for a directly relevant theorem, formula, or worked example you already know.
2. Try an auxiliary problem: a simpler version, a special case (small numbers, extreme values), or the problem solved backwards (assume the answer, see what follows).
3. Introduce notation. Name the unknown x (or whatever fits) and translate each condition into an equation or inequality.
4. If the problem has symmetry, use it. If it has parts, split it.

Write the plan down as 2-5 bullet steps before executing. A plan that fits in your head is fine to state once, then write.

3. Carry out the plan

Execute the written plan step by step, checking each step as you go:

• Verify each line: does this follow from the previous line and a justified rule?
• Check the conditions of any theorem you invoke.
• Watch units and signs at every line. They are the two most common killers.
• If a step stalls for more than a few honest minutes, stop: return to step 2 and pick a different move. Do not patch a dead plan blindly.

4. Look back

A solved problem is not a finished problem until you look back:

• Check the answer against the original conditions. Plug it in. Does it satisfy every condition?
• Can you derive the result a second, different way? A cheap sanity check (estimate, special case) is enough.
• What did the problem teach? Name the trick, the theorem, or the move that cracked it.
• Can you state a generalization, or a problem this method would now solve?

Writing the full solution

An answer is a number; a solution is a record of reasoning someone else can follow. Write every solution with:

1. A restatement line ("Find ... given ...").
2. The plan in words, briefly ("Let x be ...; we use ...").
3. The working, one justified line per step.
4. A boxed or stated final answer.
5. A one-line check ("Plugging back: ...").

A worked example of the full template in action is in references/worked_example.md.

The error log

Every mistake becomes a row in the log, not a shrug. Template: assets/error_log_template.md.

For each miss, record:

• Date, problem reference, topic.
• Type (pick one): mechanical (slipped arithmetic, transposed digit, sign flip), reading (answered the wrong question, missed a condition), method (wrong approach chosen), concept (missing or wrong knowledge), time (ran out or rushed).
• What actually went wrong, in one honest sentence. Never write "careless": name the mechanism.
• The correct move, in one sentence. This is the line you will re-read.

Review the log weekly. Errors that cluster on one type or topic are your drill list. Rework each logged problem from scratch, without looking at the solution, before it counts as fixed.

Targeted drilling

1. Rank the log: (a) missed more than once in the last two weeks, (b) missed once and never re-tested, (c) covered in notes but never tested, (d) longest since last review.
2. Take the top one or two themes only. One drill batch, one theme.
3. Write or pick 5-10 problems in the real shape of the exam or homework: same format, same qualifiers, plausible distractors if multiple choice.
4. Work them under real conditions (timed if the real test is timed).
5. Log every miss back into the error log. If accuracy is under half, the topic needs study before it needs drills.

Output Contract

When helping with a problem, produce:

• The four steps, visible, in order (understand, plan, carry out, look back), each written down, not implied.
• A full solution in the format above, never just the answer.
• For misses: an error-log row filled in with an honest type classification.
• For study help: a ranked drill list derived from the log, plus a drill batch for the top theme.

Operating Rules

1. Never skip to the plan before the restatement is written.
2. Never present an answer without the solution that produced it.
3. Never label an error "careless". Classify it.
4. Never drill five topics in one batch. One batch, one theme.
5. Every factual claim (theorem statement, formula, historical note) gets verified or cut. No confident guessing on math.
6. If a plan stalls, name the new move explicitly before switching.