Technical Communication

Technical Communication

Purpose

Create useful technical communication that is clear on the first read. The writing should sound like a capable person who understands the situation, states what is known, and gives the reader a practical next step.

Requests mentioning Quark, Kwork, Кворк, an отклик, or freelance proposals use this same skill. Treat each new brief as its own context. For a requested отклик, deliver ready-to-send buyer-facing text unless the user also asks for analysis or advice.

Use this skill for:

• client, partner, vendor, and freelance correspondence;
• proposals, scopes, estimates, and follow-ups;
• project, delivery, incident, and handover updates;
• technical explanations, recommendations, and short decision records;
• drafting or editing technical documentation;
• revising text that is vague, inflated, repetitive, or AI-sounding.

Do not use it as a replacement for legal, security, or domain review. Do not invent expertise, work completed, timelines, pricing, guarantees, access, links, or technical facts.

Language

1. Write in the language the user requested or used most recently.
2. Do not translate or produce a bilingual result unless the user asks.
3. For Russian output, read references/rules.ru.md. For English output, read references/rules.en.md.
4. For reusable structures and examples, read the matching formats reference only when it helps the requested deliverable:
   • references/formats.ru.md
   • references/formats.en.md

Shared operating principles

• Start from the reader's decision: what they need to understand, approve, provide, or do next.
• Lead with the outcome, current state, or recommendation. Put tools and implementation detail behind the result they enable.
• Use concrete verbs and observable deliverables: configure, send, verify, deploy, document, review.
• Preserve uncertainty. Clearly distinguish confirmed facts, assumptions, options, and requests for input.
• Match depth to the audience. Explain an implementation detail only when it changes a decision, risk, cost, timeline, or next action.
• Ask only for information that is actually missing. Do not request materials already supplied in the conversation.
• Keep lists meaningful. A copied inventory of technologies is not evidence of understanding.
• Prefer a short, complete message over an exhaustive one. Expand only when the audience needs the detail.
• Preserve the user's chosen facts, commitments, terminology, and level of formality when editing an existing draft.

Workflow

Before writing, identify the audience, objective, known facts, missing facts, real constraints, and the smallest useful next action. Then choose the right format: short message, structured update, proposal, note, or documentation section.

Draft around the reader's outcome. For client-facing work, state what will be delivered and how progress will be checked. For internal technical work, state status, impact, owner, risk, and next action where relevant. For documentation, describe behavior and constraints rather than narrating the drafting process.

Quality gate

Before returning the text, check that it:

• answers the actual request rather than a generic version of it;
• contains no invented evidence or blanket promises;
• has no duplicate meaning, filler, or defensive comparisons with poor work;
• makes required work assertive and optional work clearly optional;
• ends with a practical next step when one is needed;
• uses the requested language consistently.

Boundary with specialised skills

Use a specialised technical-documentation skill when a repository requires its documentation conventions, API contract rules, or operational runbooks. This skill supplies the communication voice and concise framing; the specialised skill owns format-specific technical standards.