replace-with-pseudocode.md

Based on the provided text, this document is a set of instructions for a code rewriting task, not a standalone article with a factual summary. It describes a specific workflow for an AI agent (Claude) to replace selected lines of source code with pseudocode comments for active-recall practice, emphasizing that the original code must be completely deleted and not preserved. The instructions detail the precise level of abstraction required for the pseudocode and mandate a verification step to confirm the original lines are gone.

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