---
name: unrolled
description: Rewrites AI-generated code, in any popular language (Python, JS/TS, Java, C/C++, C#, Go, Rust, MATLAB, R, SQL, Bash, etc.), into a verbose, linear, engineering-student style — top-down procedural scripts, no functions/abstraction unless asked, unrolled loops, an inline comment on nearly every line, dashed section dividers with bracketed task labels, task-prefixed variable names, and boxed ASCII console output. Use whenever the user wants code to look "hand-written," "less AI-generated," "like a student wrote it," "homework style," or "verbose," or references their own/a professor's required commenting convention with dashes, bracketed labels, or heavy inline comments — even if they never say "skill." Also trigger when the user hands Claude code and asks to add exhaustive step-by-step comments, remove abstraction, unroll loops, or make logic maximally explicit.
license: MIT
---

# Unrolled

Turns clean, abstracted, AI-shaped code into code that looks like it was typed out by hand, one explicit step at a time, by someone who is showing every ounce of their work. No hidden cleverness, no silent helper functions, no one-liners that quietly do five things at once.

This is a **style skill**, not a correctness skill. Apply it *after* you know the logic is right — it changes how the solution is written, not what it computes.

## Core philosophy

1. **Show every step.** If a human would have to do it manually to understand it, write it out manually — even if the language has a built-in for it.
2. **Linear beats abstract.** A script that reads top-to-bottom like a lab notebook beats one that jumps between five functions.
3. **Comments describe the mechanical action, not the theory.** "increase index by one," not "iterate through the collection."
4. **Repetition is fine — encouraged, even.** Near-duplicate blocks (e.g., the same operation applied to 3 different variables) should have near-duplicate, sometimes word-for-word-identical comments. Don't DRY it up into a loop or function unless the user asked for that.
5. **It should look hand-typed, not formatter-generated.** Slightly inconsistent spacing, a naming convention that no linter would suggest, the occasional very human quirk — these are features here, not bugs.

Only apply this transformation to code you were actually asked to write or restyle — don't retroactively rewrite unrelated files in the same repo just because this skill is loaded.

---

## Structural rules

- **No functions/methods/classes unless explicitly requested.** Default to one continuous top-down script. If the user's course/professor/employer requires a function signature, honor that requirement but keep everything *inside* that function just as linear and unrolled as it would be at top level.
- **Unroll loops and hardcode where it's reasonable to.** If there are 3 fixed cases, write 3 explicit blocks rather than one loop with an abstraction over them — especially for anything with a small, known, fixed iteration count (e.g., "solve for p = 1, 2, 3" becomes three copy-pasted blocks, not a `for p in [1, 2, 3]`).
- **Avoid standard-library shortcuts that hide steps.** Prefer manually computing a sum over `sum()`, manually finding a max over `max()`, manually building a string over a one-line join/format — *when the point of the code is to show the computation*. (Exception: don't reinvent things like file I/O, HTTP requests, or plotting — those aren't "the logic," they're plumbing, and hand-rolling them adds risk with no teaching value.)
- **Explicit is better than clever, always.** If there are two ways to write a line and one is more obvious about what it's doing step-by-step, use that one even if it's longer.

---

## Section & header conventions

Every major task or phase gets a full-width dashed divider using the target language's native single-line comment token, followed by a bracketed capital letter and a short descriptive goal:

```
<token> ------------------------------------------------------------------
<token> {A} Solve the system of equations exactly using Gaussian elimination
```

Internal variations within a task (different parameters, different methods, different iteration counts) get a clean, **unbracketed** one-line sub-header instead of a full divider:

```
<token> Jacobi method, 5 iterations
```

```
<token> SOR method, omega = 1.2
```

Use consecutive capital letters ({A}, {B}, {C}, ...) for each new major task in a script, in order.

---

## Comment placement rules

This is the part that most reliably makes code look hand-typed rather than AI-generated, so follow it precisely:

| Type of line | Comment placement |
|---|---|
| **Static/initial value declarations** (constants, starting parameters, bounds, matrix setup) | Code line first. Comment goes on the line **immediately below it**. |
| **Operational lines** (loop updates, indexing, formula evaluation, printing, assignments that compute something) | Comment goes **inline, same line**, trailing after the statement, separated by a space or tab. |

Example (Python):
```python
Task1_MaxIterations = 25
# Set intial values for maximum iteration count

Task1_CurrentGuess = Task1_CurrentGuess + Task1_StepSize  # Use formula to find next guess
```

Example (C-family):
```c
int Loop2_Counter = 0;
// Reset index to one

Loop2_Counter = Loop2_Counter + 1; // Increment iteration counter
```

---

## Variable naming convention

Prefix every variable with the task, method, or loop it belongs to, so the data's timeline is visible just from the name. This intentionally ignores normal per-language naming conventions (no strict camelCase-only or snake_case-only rule) — that's part of what makes it read as hand-typed rather than linted.

- `Task1_VarA`, `Task1_ResultMatrix`
- `MethodB_Result`, `JacobiMethod_Error`
- `Loop2_Counter`, `Loop2_Error`

Don't reuse a temporary variable across steps if doing so would hide the order things happened in — a new, clearly-prefixed variable per step is preferred over overwriting one generic `temp`.

---

## Phrase bank

Use short, literal, mechanical phrasing. These exact patterns (or close variants) should show up often — they're the signature of the style:

- "Set intial values for [X]" *(the misspelling of "initial" as "intial" is intentional — see Grammar quirks)*
- "Increase [matrix/array/loop] index"
- "Reset index to one"
- "Increment iteration counter"
- "Extract [data type/values]"
- "print [matrix/array/result]"
- "Calculating [error/result]"
- "Use formula to find [X]"

Avoid high-level, AI-sounding summaries like "This function optimizes the matrix via an iterative convergence loop." Say what the line does mechanically instead: "subtract row 1 from row 2 to eliminate x1."

---

## Grammar quirks

- **No periods** at the end of short inline or trailing comments.
- Trailing inline comments often **start lowercase** (e.g., `; % find RE for x`, `// print matrix`).
- Occasionally (not every time — once or twice per script is plenty) misspell "initial" as "**intial**" in a comment. It's a real, consistent human typo, not a random one — keep it consistent within a single script rather than sprinkling in different misspellings.
- Never use structured docstring blocks (`@param`, `@return`, `"""Args:...Returns:..."""`, JSDoc, etc.) — these read as generated, not hand-typed.

---

## Console/terminal output formatting

Wrap headers, intermediate steps, and final results in strict ASCII borders using the language's normal print/output statement, clearly labeled:

```
=========================
   RESULTS FOR TASK A
=========================
```

Each distinct task or method variant gets its own labeled, bordered block — don't let output from two different tasks run together unlabeled.

---

## Do / Don't summary

**DO**
- Keep comments completely literal and mechanical.
- Put comments for static declarations on the line below; put comments for operational lines trailing on the same line.
- Copy-paste near-identical comments across near-identical code blocks, word for word.
- Use dashed dividers + bracketed capital-letter labels for every major phase.

**DON'T**
- Write high-level "AI-style" summaries of what a block accomplishes.
- Use structured docstrings or tag-based documentation blocks.
- Put periods on short/trailing comments.
- Capitalize every single comment — trailing ones often start lowercase.
- "Clean up" repeated blocks into a shared function/loop just to be tidy, unless asked.

---

## Language quick reference

Use each language's own native single-line comment token for dividers and trailing comments; everything else in this file applies unchanged.

| Language | Comment token | Typical output statement |
|---|---|---|
| Python | `#` | `print(...)` |
| JavaScript / TypeScript | `//` | `console.log(...)` |
| Java | `//` | `System.out.println(...)` |
| C / C++ | `//` | `printf(...)` / `std::cout <<` |
| C# | `//` | `Console.WriteLine(...)` |
| Go | `//` | `fmt.Println(...)` |
| Rust | `//` | `println!(...)` |
| MATLAB / Octave | `%` | `disp(...)` / `fprintf(...)` |
| R | `#` | `print(...)` / `cat(...)` |
| SQL | `--` | `SELECT` / `PRINT` (dialect-dependent) |
| Bash | `#` | `echo ...` |

If the target language isn't listed, use its standard single-line comment marker and its standard console-print call — the conventions above transfer directly.

---

## Worked mini-example (Python)

**Before (typical AI-generated style):**
```python
def average(numbers):
    """Return the arithmetic mean of a list of numbers."""
    return sum(numbers) / len(numbers)

print(average([4, 8, 15, 16, 23, 42]))
```

**After (Unrolled style):**
```python
# ------------------------------------------------------------------
# {A} Find the average of a list of numbers by hand
Task1_Numbers = [4, 8, 15, 16, 23, 42]
# Set intial values for the list of numbers

Task1_Total = 0
# Set intial values for running total

Task1_Count = 0
# Set intial values for item counter

for Task1_Value in Task1_Numbers:
    Task1_Total = Task1_Total + Task1_Value  # Add current value to running total
    Task1_Count = Task1_Count + 1            # Increment iteration counter

Task1_Average = Task1_Total / Task1_Count  # Use formula to find average

print("=========================")
print("   RESULT FOR TASK A")
print("=========================")
print(Task1_Average)  # print result
```

See `references/examples.md` for the same transformation in JavaScript, Java, C, and MATLAB, plus a slightly larger numerical-methods example (Jacobi iteration) that shows the bracketed task/sub-header convention in full.