Meaning-Preserving Editor

Edits technical documentation, emails, or specifications to eliminate grammatical errors, passive voice, and wordiness. Strictly preserves technical terminology, code names, and semantics.

1. Purpose

Polish writing without changing what it says. "Meaning-preserving" means every factual premise, command line argument, code symbol, and technical claim remains untouched.

2. When to Use

Use this skill when:

• Polishing technical documentation, comments, or pull request descriptions.
• Refining non-native English drafts into idiomatic technical writing.
• User requests: "Edit this text for grammar and clarity without changing meaning."

3. When Not to Use

• Do not use to compress or summarize text into fewer bullet points; use factual-summarizer.
• Do not use to invent new documentation sections; use readme-writer.

4. Required Inputs

• draft_text: The text to edit (string).
• style_preference: Optional tone guidelines (e.g., concise, formal, friendly). Default: concise technical.

5. Missing-Input Behavior

1. If draft_text is empty: stop and ask: "Please provide the text you would like edited."
2. Never rename technical identifiers (function names, variables, CLI flags, URLs).
3. Do not add unsubstantiated claims or marketing fluff.

6. Procedure

Follow these numbered actions:

1. Action 1: Identify Invariable Elements
   • Mark all code blocks, backtick symbols, URLs, and numbers as invariant.
2. Action 2: Fix Grammar, Punctuation & Typos
   • Correct subject-verb agreement, misspellings, and comma splices.
3. Action 3: Simplify Sentence Structure
   • Replace passive constructions with active voice where appropriate.
   • Remove filler words ("in order to" -> "to", "at this point in time" -> "now").
4. Action 4: Audit Meaning Preservation
   • Read original and edited versions side by side to ensure no semantic shift.
5. Action 5: Emit Edited Output with Change Log
   • Format per Section 8.

7. Decision Rules

• If an ambiguous sentence in original could mean two different things: preserve both meanings or flag the ambiguity in the change log.
• Never convert a cautious statement ("may cause latency") into an absolute ("causes latency").

8. Output Format

Emit the edited text using this template:

### Edited Text

[Full edited text here]

---

#### Change Log & Rationale
- **[Edit 1]**: [What was changed and why, e.g. Replaced passive voice]
- **[Edit 2]**: [Corrected typo or punctuation]

9. Verification Checklist

• 100% of technical identifiers and code symbols remain identical.
• No factual claims were added, altered, or deleted.
• Grammar and spelling errors are resolved.
• Change log documents all significant edits.

10. Common Failures and Recovery

11. Stop or Escalation Conditions

Stop and ask the user when:

• The draft text is unintelligible to the extent that intended meaning cannot be inferred.

12. Examples

Example 1: Successful Execution

Input:

Draft: In order to successfully run the unit test suite, it is required that the user executes the npm test command at this point in time.

Output:

### Edited Text

To run the unit test suite, execute `npm test`.

---

#### Change Log & Rationale
- **Wordiness**: Replaced "In order to successfully run" with "To run".
- **Passive Voice**: Converted "it is required that the user executes" to active imperative "execute".
- **Redundant Phrasing**: Removed filler "at this point in time".
- **Formatting**: Wrapped `npm test` in code backticks for readability.

Example 2: Ambiguous or Missing Input

Input:

Edit this:

Output:

### Edited Text: Halted - No Text Provided

- **Status**: Halted

Please provide the draft text you would like edited.

Example 3: Expected Final Output

Output:

### Edited Text

The database client caches query results for five minutes to reduce round-trip latency.

---

#### Change Log & Rationale
- **Conciseness**: Condensed "is functioning by caching query results for a duration of five minutes" into "caches query results for five minutes".