| name | proofread-personal-engineering-writing |
| description | Proofread and lightly edit Swashata Ghosh's personal engineering writing while preserving his practical, reflective voice. Use for blog posts, MDX drafts, changelog updates, social posts, rough notes, and essays about engineering, product, SaaS, WordPress, Freemius, AI systems, developer experience, or leadership. |
Proofread Personal Engineering Writing
Purpose
Polish the writing without making it sound generic, salesy, or over-produced.
Preserve the author's practical, reflective voice. The goal is clarity, not performance.
Core Principles
Treat the writing as lived engineering and product reflection.
Focus on:
- What problem was noticed.
- Why it mattered.
- What changed in the author's thinking.
- What outcome the author was trying to create.
- What trade-offs or constraints shaped the decision.
Prefer writing that invites discussion. Do not turn context-dependent experience into
universal advice.
Voice
Keep the tone:
- Practical.
- Experienced.
- Thoughtful.
- Direct.
- Calm.
- Personal, but not overly emotional.
Allow light informality when it fits. Keep phrases like "I think", "in my experience",
"often", "probably", and "usually" when they preserve honest nuance.
The final text should feel like a senior engineering leader reflecting from real work, not
someone trying to impress an audience.
Editing Rules
Do:
- Fix grammar, spelling, punctuation, and awkward phrasing.
- Improve flow and readability.
- Remove repetition and filler.
- Clarify vague sentences without changing meaning.
- Preserve first-person perspective.
- Preserve technical and product nuance.
- Keep Markdown structure unless it hurts readability.
- Use the smallest edit that makes the sentence better.
Do not:
- Over-edit.
- Add generic motivational language.
- Add buzzwords.
- Make claims stronger than the draft supports.
- Add frameworks, lists, or lessons not implied by the draft.
- Turn the article into a tutorial unless it is already written that way.
- Make the tone preachy, salesy, or corporate.
- Add emojis unless already present and appropriate.
- Check Astro/build errors; stay focused on the writing.
Markdown Handling
When editing Markdown:
- Preserve headings, links, lists, inline code, and code blocks.
- Do not alter code unless explicitly asked.
- Keep technical identifiers exactly as written unless there is an obvious typo.
- Keep valid MDX.
Final Check
Before returning, verify that:
- The meaning did not drift.
- The tone still sounds like the author.
- The text is clearer and tighter.
- The writing does not sound like generic LinkedIn advice.
- Product and engineering claims remain precise.
