pattern-breakdown

---
name: pattern-breakdown
description: Use when asked to find, count or explain patterns in a large set of data (sequences, logs, time series, tables, event lists). Breaks the work into small verified steps, counts in code, and reports in plain words so the numbers can be trusted.
---

# Pattern breakdown

AI gets less reliable as data gets bigger. It miscounts, swaps one measure for another, drops records without saying so, and writes numbers that no code produced. This skill keeps the work small, checked and readable.

## 1. Pin down the pattern first
- Write the pattern in the user's own words as a rule a script could follow: what counts, what does not, the minimum length, whether order matters.
- If the user gave an example, test your rule on it. It must find exactly the cases they point to and nothing else. If it does not, your rule is wrong, not their example.
- Never swap their rule for your own definition. If a term is unclear, ask once, in one short question.
- Use the bands, categories and units the user gave. Do not invent new ones.

## 2. Break it into steps
- One step at a time. Each step works only on the records that passed the step before it.
- Start every finding with the base: how many records were examined and how many passed each step.
- Records that do not fit a step are not thrown away. They form their own branch and are listed as such.
- Move on to the next step only when the user is happy with the current one.

## 3. Count in code, not in your head
- Every number you give must come out of code you ran on the real data, in its real order. No estimates and no numbers from memory.
- Check that the measure matches the question word for word: what is being counted, and over which records.
- Say how many records each number covers. If the data has gaps, say where.
- Do not shuffle or randomise the data to compare against unless asked.
- Reading over your own answer is not a check. Re-run the code, or recount a sample by hand against the source.

## 4. Look at small sections as well as the whole
- A big pooled total can hide a pattern that shows up in smaller sections. When asked, split the data into consecutive chunks of one fixed size and show each chunk on its own line. Use one chunk size at a time.
- Report a result that does not find the pattern as plainly as one that does. Not finding it in one cut of the data does not mean it is not there.

## 5. Present it for a person
- Short, plain words. Answer only what was asked.
- Give single percentages and simple counts, each named in words. Explain any technical term before using it, or leave it out.
- List cases one per line. Never merge different cases into one total.
- No extra tables, side numbers or new terms the user did not ask for.
- Do not make suggestions or run extra analyses unprompted.

## 6. Analyse on top, only after the counts are verified
- Compare cases using the verified counts: how often, how far apart, in what order.
- Give a range only when asked, or when reporting the smallest and largest seen.
- Give predictions only when asked, and call them predictions.

## 7. When the user says you are wrong
- Believe it, find the error yourself, say what it was in one sentence, and correct it. Do not defend the mistake, and do not agree and argue in the same reply.
- If earlier context has been lost, say so straight away.
- Confirm with the user before changing anything of theirs (scripts, data, definitions).

## Failure modes this skill is built to stop
- Answering a different measure from the one asked.
- Writing numbers that no code produced.
- Silently leaving out records, then reporting the total as if it covered everything.
- Reading a trend from data that is incomplete at one end.
- Reviewing your own answer and approving it.
- Padding an answer with extra numbers until the real one is buried.