# replace-with-pseudocode.md

> Source: <https://gist.github.com/tom-rigelblu/135dbba2b5700cb9b38b954767792d2c>
> Published: 2026-05-23 15:52:52+00:00

Claude Code reads the context: fork
frontmatter and isolates this task automatically; other agents do not. If you are not Claude, do this manually:
- Delegate the rewrite to a subagent — pass it everything below this section (after the
---
) as the prompt, plus$1
as the code reference - The subagent must run the Verify step below and report explicit confirmation that every original line in the selection is gone — without that confirmation, treat the edit as incomplete and request a re-check
- After the subagent confirms, do NOT pull the loaded code back into your main context — the practice depends on the original being gone; the subagent's confirmation is your verification
Replace $1
(inclusive of starting/ending line numbers) with English pseudocode comments. Delete the original — only the pseudocode remains. I'll rewrite the code from the pseudocode as active-recall practice to build a core memory of the pattern, so the pseudocode must give me enough to rebuild the original — and no more. Leave room to think.
Only the lines in $1
get rewritten as pseudocode. Code outside the selection (other functions, imports, surrounding structure) stays untouched. If the selection includes a signature, declaration, or class header, those get rewritten too — writing them from pseudocode is part of the core-memory practice.
- Too literal — reads like a sentence-by-sentence translation of the syntax
- Too abstract — I couldn't reconstruct the original from it
- Right level — describes operations and their order in domain terms; leaves API, idiom, and syntax choices to me
- Declaration shape — visibility (exported, public), kind (function, class, const), parameter roles and types with defaults, return type
- Operations and their order — filter, then map, then sum
- Control flow shape — loop, early return, branching condition
- Data being transformed and where it comes from
- Side effects — I/O, mutation, network calls
- Names — use the role for variables, parameters, functions, and classes ("a function that joins category hierarchies" not
joinCategoryHierarchy
; "the user list" notusers
) - Syntax markers — no
.filter(...)
, nofor x in y
, no=>
- Use the language's native comment syntax (
//
,#
,--
,/* */
) - One comment per logical step — group related lines under a single comment that describes their joint intent
- Preserve the original indentation so the block's shape is recognizable
- "Keep the original code commented out so it's not lost." → Defeats active recall; git history has the original
- "More detail makes the pseudocode easier to rewrite from." → Defeats active recall; if I don't have to think, I don't learn
Before reporting the edit complete, confirm every original line in the selection is gone:
- Inclusive endpoints — both the start and end lines of the range must be replaced
- Check by content, not by post-edit position — line numbers shift after the edit; the original end line might no longer exist or land elsewhere
- Do not treat surrounding block structure as permission to preserve a line inside the selection — closing braces, dedent lines, the closing tag of a multi-line element inside the range still get replaced
- Required state: every original source line from the requested range is absent from the modified file