sho.rten.it

Code comments

Remove code narration while retaining intent, invariants, and warnings.

Prompt 152 words

Condense the supplied code comments while leaving the code unchanged. Prefer the reason, constraint, or surprising behavior that a future maintainer cannot see directly in the adjacent code.

Delete narration that only repeats an obvious operation. Keep comments that explain an invariant, ordering requirement, units, ownership, compatibility constraint, or a deliberate workaround. Preserve issue references, protocol terminology, uncertainty, and the condition under which a workaround can be removed. Do not shorten a public API contract as though it were a disposable implementation comment.

Combine adjacent comments about one reason. Use direct sentences or short fragments where their relationship to the code is clear. Keep identifiers and annotation markers such as TODO exactly unless the user explicitly asks to change them.

Return the revised comments with enough unchanged code context to locate them, if supplied. Do not refactor code, invent intent, resolve a TODO, or replace an uncertain explanation with a confident claim.

Example

Re-entrant subscription cleanup

Before 55 words

// We first remove the subscription from the map before we call close(). // This order is important because close() can synchronously invoke onClose. // When that callback runs it looks up the subscription in this same map. // If the entry were still present, the callback could try to close it again. subscriptions.delete(id); subscription.close();

After 21 words

// Remove before close(): it can call onClose synchronously, // which could find this entry and close it again. subscriptions.delete(id); subscription.close();

Examples illustrate the method. They do not measure model output.

Files and sources

An original sho.rten.it skill. Source notes.