Редактура технического текста

Этот навык позволяет проверять и редактировать технические документы на английском языке, обеспечивая их соответствие стандартам публикации. Он помогает выявлять и исправлять ошибки, сохраняя при этом оригинальный стиль автора.

Экосистема: Универсальный

Инструкция

---
name: tech-writing-proofread
description: "Proofreads English technical writing for typos, grammar, punctuation, terminology consistency, jargon, and structure; returns an itemized Original → Suggestion → Reason list without rewriting the document. Use when asked to proofread or polish a technical doc, README, or blog draft."
category: writing
risk: safe
source: https://github.com/alapha888/agent-skills-en
source_repo: alapha888/agent-skills-en
source_type: community
date_added: "2026-10-01"
author: alapha888
tags: [proofreading, technical-writing, editing]
tools: [claude, cursor, gemini, codex]
license: MIT
license_source: https://github.com/alapha888/agent-skills-en/blob/main/LICENSE
---

# Редактура технического текста

Переведите английский технический документ из состояния "понятный" в состояние "готовый к публикации". Проверяйте только — никогда не переписывайте содержание. Отмечайте предполагаемые фактические ошибки; не исправляйте их молча.

## Когда использовать

- Используйте, когда пользователь просит проверить, отредактировать или просмотреть английский технический документ, README или черновик блога.
- Используйте, когда необходимо проверить согласованность терминологии или жаргона в документе.

## Рабочий процесс

1. **Сначала читайте для определения тона**: Прочитайте весь документ и определите его тип (учебник / справочник API / пост в блоге / README). Учебники допускают разговорный стиль; справочники API должны быть точными.
2. **Составьте список терминов**: Просканируйте на наличие ключевых терминов (например, "callback" против "callback function", "sign in" против "log in") и проверьте, не называется ли одно и то же понятие несколькими способами. Стандартизируйте на наиболее частой форме и отметьте это в контрольном списке.
3. **Проверяйте параграф за параграфом**, но только по этим шести категориям — не отклоняйтесь к "хорошо ли написан этот параграф":
   - Опечатки и орфография: перепутанные буквы, дублирующиеся слова ("the the"), часто путаемые пары ("affect/effect", "its/it's", "complement/compliment").
   - Грамматика: согласование подлежащего и сказуемого, согласованность времени глагола в процессе, висячие модификаторы, отсутствие артиклей перед существительными в единственном числе.
   - Пунктуация: согласованное использование серийной (Оксфордской) запятой; дефисы в составных прилагательных ("command-line tool"); отсутствие двойных пробелов после точек; согласованное использование длинных тире против скобок.
   - Встроенный код и собственные имена: встроенный код, команды, имена файлов и пути в обратных кавычках; собственные имена в их официальном написании (`GitHub`, а не `github`; `JavaScript`, а не `Javascript`).
   - Стиль предложений: предпочитайте активный залог ("Система вызывает функцию" вместо "Функция вызывается системой"); убирайте лишние слова ("в основном", "просто", "только", "очень"); одна идея на предложение.
   - Структура: заголовки в параллельной форме; списки используют параллельные элементы; шаги в процессе должны быть императивными и пронумерованными; аббревиатуры расшифровываются при первом использовании.
4. **Выводите контрольный список**: перечислите элементы как "Оригинал → Предложение → Причина", с номерами строк или короткими цитатами. Отмечайте неуверенные элементы `[verify]` вместо того, чтобы принуждать к изменению.
5. **Заканчивайте статистикой**: Всего N элементов, из которых опечатки x, грамматика y, терминология z, стиль w — чтобы автор мог быстро увидеть распределение.

## Правила

- Исправляйте язык, а не факты. Подозреваемая фактическая ошибка становится `[verify] Это противоречит обычному определению — пожалуйста, подтвердите`, никогда не молчаливое "исправление".
- Не переписывайте целые параграфы. Даже многословный параграф получает только конкретные, исправимые предложения с пометкой; сохраняйте голос автора.
- Один проход. Не продолжайте "полировать еще раз" — конечный продукт — это контрольный список "без дефектов", а не идеальный текст.

## Минимальный пример

Входной фрагмент:

```text
This function will be called by the system after the data is ready, you can use it to basically handle the registration of the callback, the timeout is 5 s, examples on github can be referenced.
```

Выходной контрольный список:

```text
1. [Style] "will be called by the system" → "the system calls" (passive → active)
2. [Style] "basically handle" → "handle" (cut filler word)
3. [Terminology] "callback" — if written elsewhere as "callback function", unify on one form (most frequent wins)
4. [Grammar] run-on sentence: split after "ready." into two sentences
5. [Proper noun] "github" → "GitHub" (official casing)

Statistics: 5 items — style 2, terminology 1, grammar 1, proper noun 1.
```

## Ограничения

- Проверяет; не переписывает. Голос, структура и аргумент сохраняются, поэтому документ, который плохо аргументирован, останется плохо аргументированным после проверки.
- Технические утверждения сами по себе выходят за рамки: неуверенное утверждение остается нетронутым, а не молчаливо "исправляется" в другой факт.
- Согласованность терминологии оценивается по доминирующему использованию в документе, а не по внешнему глоссарию, если пользователь не предоставляет его.
- Заявляется только проверка на английском языке. Другие языки, качество перевода и проверка локализации находятся вне рамок этого навыка.

## Антипаттерны

- ❌ Превращение проверки в переписывание: разбор параграфа так, что голос и структура автора теряются.
- ❌ Галлюцинированные "исправления": изменение неуверенного технического утверждения так, как будто это была опечатка, что приводит к фактической ошибке.
- ❌ Проверки только на опечатки: несогласованная терминология и небрежная структура — это настоящие дефекты в технических документах.
- ❌ Бесконечная итерация: пользователь говорит "отполируйте еще раз", и это никогда не заканчивается — конечный продукт — это контрольный список, а не идеальный текст.