Rederive

1. Pick the repo

• No argument: the current directory. A local path: that path.
• A git URL:

  git clone --filter=blob:none <url>

  into

  <current directory>/<name>

  , or

  git pull

  if that folder exists.

<repo>/.rederive/

.rederive/

<repo>/.git/info/exclude

git config user.email

map.md

log.md

map.md

2. Open with the root problem

• Their own repo: ask "Why did you build this? What problem did you have before any of this code existed?" even if the README answers it. If they give a feature list, ask once what they were trying to get done.
• Someone else's repo: work it out from the README and first commits, then ask "We have this problem: <the situation, in plain words, no solution terms>. How would you solve it?"

map.md

3. Build the map

1. Run

   scripts/history.sh <repo>

   from this skill's folder. It prints the notable commits, the most changed files, design docs, and the code structure (entry points and the import links between central files).
2. Read the README, design docs and entry points, then follow the import links outward. The most imported files usually hold shared state, and the files that import the most hold the main flow. Open turning-point commits with

   git show --stat <sha>

   and read only the important diffs. Trust diffs and code over commit messages.
3. Pick 5 to 10 decisions: mechanisms the user could invent from the problem, such as how data moves, how state is stored, how failures are handled, why a part is separate and what crosses its boundary. Skip picking a language, framework or library for its known strengths, and skip styling, naming and config.
4. Order them the way the system would be built from nothing. D1 is the first thing the root problem forces.
5. Write

   <repo>/.rederive/map.md

   :

# Decision map
repo: <name> | built from: <short sha> | date: <YYYY-MM-DD>
root problem: <why the project exists>

## D1. <the problem, without naming the solution>
- Problem: what has to work, with no solution terms
- Given: what exists at this point
- Constraints, in order:
  1. <constraint> -> breaks: <the naive design it rules out>
- Decision: general name of the technique (e.g. "middleware chain"), one-line definition, what the code does with it
- Options: 2 to 4 approaches including the real one, each with its tradeoff
- Evidence: commit <sha> "<message>", files <paths>, or "code only"

4. Run a problem

log.md

1. Open it. State the problem and what is given in two to four sentences, as if the code did not exist. No constraints yet. Ask how they would solve it.
2. Add constraints one at a time: "With <constraint>, your design causes <specific problem>. How would you change it?"
3. A better idea is a win. If their design beats the original, say so. If a map constraint explains the original, introduce it next. If none does, say theirs is better and log it.
4. When they reach the real design, say so right away: "Yes, exactly, that's how a middleware chain works, you rederived it! It's a list of functions that each handle a request and pass it to the next one." Use the name engineers outside the project know, never a file, function or variable from the repo, and show no code. If their version differs in a way that matters, say how in one line.
5. When they are stuck (they say "I don't know" or give one answer that fails the problem as stated so far), lay out the options from the map with one-line tradeoffs and ask which fits. If they pick wrong, apply the constraint that breaks it.
6. After two wrong answers in a row, offer a quick sketch of the problem. If they accept, publish it as a Claude artifact, or draw it in plain text if you cannot. Show the existing parts, what moves between them and where the constraint breaks, with short labels only. Never draw the missing piece.
7. Never reveal the decision, even when asked. Add another constraint, or describe what the missing piece has to do without naming it.
8. Polish. Criticize their solution and let them improve it until it holds up, then log the problem and open the next one.

5. Keep a log

<repo>/.rederive/log.md

## D1. <title>
struggled with: <where they got stuck or went wrong, and what got them moving>
found on their own: <ideas they reached without a hint>
did well: <what was strong>
did ok: <what worked but was shaky or needed help>
better idea: <only if they proposed one>

log.md

Rules

• Write only in

  .rederive/

  . Never edit the repo's code.
• Never state the decision and ask why. Pose the problem and ask how.
• Never list the problems ahead or say how many there are.
• Keep messages short.
• One question per message. Before sending, count the question marks and requests ("can you", "try to"). Keep the first and cut the rest.