The skill's task is interface texts. Text in the interface answers two user questions: what is happening and what should I do. Good microcopy is written from the scenario: what matters is what came before the screen, what will happen after the action, and what the user is feeling right now.
The method is based on the practices of Lyudmila Sarycheva (gladlax.ru) and was put together jointly with Nikita Arkhipov (niar42.com).
Step 0. Context
If the project has a file .agents/redpolitika.md — read it first: it contains the product glossary, how the user is addressed, and the tone of voice. If there is no file, and there are many interface texts, suggest creating one with the skill redpolitika.
Before writing the text, find out:
- What screen or message it is.
- What the user did before this.
- What should happen afterward.
- What the user may be feeling: in a hurry, angry, afraid of losing data, just choosing.
- What constraints there are: length, platform, buttons, legal text.
Modes
- Options — give 2–3 phrasings and explain the difference.
- Rewrite — before/after/rule for existing texts.
- Audit — find problems with the scenario and the text without a full rewrite.
If no mode is named, give options: for an interface it is useful to choose from several precise solutions.
Depth of analysis
Adapt the answer to the person you are talking to. To an editor, you can answer using the method's terminology. If the user is not from the editing world — explain in plain terms: not "an unfounded statement", but "here it says 'many people believe', but it is unclear who and where this is known from". Either avoid terminology or explain it in parentheses, and keep the analysis shorter: three main edits are more useful than fifteen.
Process
1. Scenario
Describe the scenario in the user's words: “I want…”, “I did…”, “I don't understand…”. Details are in references/printsipy.md.
Rule scenario ahead of the screen: first the user's path, then the element text.
2. Element
Identify the element type: button, heading, field, placeholder, checkbox, tooltip. Details are in references/elementy.md.
Rule each element does its own job: the button names the action, the heading explains the state, the text next to it gives details.
3. Errors and states
If this is an error, empty state, loading, or dangerous action, check that the text explains what happened and the next step. Details are in references/oshibki-i-sostoyaniya.md.
Rule what happened and what to do: the user should understand the situation without the system's internal code.
4. Notifications
For pushes, emails, toasts, and snackbars, check whether writing is needed at all. If the message does not change the user's action, it is often better to stay silent. Details are in references/uvedomleniya.md.
Rule benefit of the message: a notification intrudes on the user's attention and must repay that intrusion.
5. Tone
Check against ../redaktura/references/tonalnost.md: without blame, pressure, false urgency, or “oops”. The user's words matter more than the system's words.
Response format
In the “Why” and “Rule” columns, name the method's rules by name (“event and step”, “action on the button”, “user's words”, “consequence is visible”) — this way the user learns rather than just receiving strings.
Options
| Элемент | Вариант 1 | Вариант 2 | Почему |
|---|---|---|---|
Edit
| Было | Стало | Правило |
|---|---|---|
Audit
## Диагноз
[2–4 предложения о сценарии и главной проблеме]
## Главные правки
| Элемент | Проблема | Как исправить |
|---|---|---|
## Что ещё нужно узнать
[сценарные дыры, ограничения, системные причины]
What not to do
- Do not write from the screen. First the scenario, then the element text.
- Do not invent system facts. Deadlines (“a few minutes”), response channels (“we'll email you”), and system behavior are easy to insert out of habit — but if they were not specified by the user, that is invention. Write the placeholder “[deadline: to be clarified]” or ask a question.
- Don't blame the user. The text helps them get out of the situation and stay in control.
- Don't put "OK" where there's an action. The button should say what will happen.
- Don't be noisy with notifications. If the user shouldn't have to do anything, it's often better to stay silent.
Related skills
- redaktura — do a final check of the tone, wording, and rhythm of interface texts
- redpolitika — product glossary and tone of voice
- statya — articles, posts, and long explanatory materials