Спецификация функции (PRD)
Превращает идею или запрос в структурированный PRD: проблема, цели, не-цели, истории, требования, метрики и критерии приёмки.
СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется
- Что делает
- Превращает идею или запрос в структурированный PRD: проблема, цели, не-цели, истории, требования, метрики и критерии приёмки.
- Когда брать
- Когда нужно оформить расплывчатую идею в документ, определить рамки функции, метрики успеха и критерии приёмки или разбить большую задачу на фазы.
- Пример запроса
- Напиши спецификацию для функции выгрузки данных клиентов в CSV, у нас жалуются, что нельзя перенести данные.
- Работает лучше с
- трекер задач, база знаний, дизайн
Входит в плагин product-management. В Cowork и Claude Code можно поставить плагин целиком.
Как включить
- Нажмите «Скачать на русском» и сохраните архив.
- В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
- Включите скилл переключателем.
Для терминала
Распакуйте архив и положите папку write-spec в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.
Текст
---
name: write-spec
description: Пишет спецификацию функции или PRD по формулировке проблемы либо идее функции. Используй, когда нужно превратить расплывчатую идею или запрос пользователя в структурированный документ, определить рамки функции с целями и не-целями, задать метрики успеха и критерии приёмки или разбить крупную задачу на фазы в спецификации.
argument-hint: "<feature or problem statement>"
---Написание спецификации
Если встретишь незнакомые подстановки или понадобится узнать, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).
Напиши спецификацию функции или документ с продуктовыми требованиями (PRD).
Использование
/write-spec $ARGUMENTSРабочий процесс
1. Пойми функцию
Спроси пользователя, что он хочет описать. Принимай любое из:
- Название функции («поддержка SSO»)
- Формулировку проблемы («Корпоративные клиенты постоянно просят централизованную авторизацию»)
- Запрос пользователя («Пользователи хотят выгружать свои данные в CSV»)
- Расплывчатую идею («Надо что-то сделать с тем, что люди бросают адаптацию»)
2. Собери контекст
Спроси пользователя о следующем. Говори по-человечески — не вываливай все вопросы сразу. Сначала задай самые важные, а пробелы заполняй по ходу:
- Проблема пользователя: какую проблему это решает? Кто с ней сталкивается?
- Целевые пользователи: каким сегментам пользователей это служит?
- Метрики успеха: как мы поймём, что получилось?
- Ограничения: технические ограничения, сроки, регуляторные требования, зависимости
- Предыдущий опыт: пробовали ли это раньше? Есть ли готовые решения?
3. Подтяни контекст из подключённых инструментов
Если подключён ~~project tracker:
- Найди связанные тикеты, эпики или функции
- Подтяни существующие требования и критерии приёмки
- Определи зависимости от других рабочих задач
Если подключена ~~knowledge base:
- Найди связанные документы исследований, прежние спецификации или дизайн-документы
- Подтяни значимые находки пользовательских исследований
- Найди связанные заметки встреч или записи решений
Если подключён ~~design:
- Подтяни связанные макеты, каркасы (wireframes) или дизайнерские наработки
- Найди компоненты дизайн-системы, относящиеся к функции
Если этих инструментов нет, работай целиком с тем, что даёт пользователь. Не проси пользователя подключать инструменты — просто продолжай с доступной информацией.
4. Составь PRD
Подготовь структурированный PRD со следующими разделами. Подробные указания, что должно быть в каждом разделе, смотри ниже в Структуре PRD.
- Формулировка проблемы: проблема пользователя, кого она затрагивает и чем грозит её нерешённость (2–3 предложения)
- Цели: 3–5 конкретных измеримых результатов, привязанных к метрикам пользователей или бизнеса
- Не-цели: 3–5 вещей, явно выведенных за рамки, с кратким обоснованием для каждой
- Пользовательские истории: стандартный формат («Как [тип пользователя], я хочу [возможность], чтобы [польза]»), сгруппированные по персонам
- Требования: разделены на обязательные (P0), желательные (P1) и задел на будущее (P2), к каждому — критерии приёмки
- Метрики успеха: опережающие показатели (меняются быстро) и запаздывающие (меняются со временем), с конкретными целевыми значениями
- Открытые вопросы: нерешённые вопросы с пометкой, кто должен на них ответить (разработка, дизайн, юристы, данные)
- Соображения по срокам: жёсткие дедлайны, зависимости и разбивка на фазы
5. Проверь и доработай
После составления PRD:
- Спроси пользователя, нужно ли поправить какие-то разделы
- Предложи расширить отдельные разделы
- Предложи подготовить сопутствующие материалы (бриф для дизайна, разбивку на тикеты для разработки, питч для заинтересованных лиц)
Структура PRD
Формулировка проблемы
- Опиши проблему пользователя в 2–3 предложениях
- Кто с ней сталкивается и как часто
- Чем грозит её нерешённость (боль пользователей, влияние на бизнес, конкурентный риск)
- Опирайся на факты: пользовательские исследования, данные поддержки, метрики или обратную связь клиентов
Цели
- 3–5 конкретных измеримых результатов, которых должна достичь функция
- Каждая цель должна отвечать на вопрос: «Как мы поймём, что получилось?»
- Различай цели пользователей (что получают пользователи) и цели бизнеса (что получает компания)
- Цели должны быть результатами, а не выпускаемыми вещами («сократить время до первой пользы на 50 %», а не «сделать мастер адаптации»)
Не-цели
- 3–5 вещей, которые функция явно НЕ будет делать
- Смежные возможности, которые не входят в эту версию
- Для каждой не-цели кратко объясни, почему она за рамками (мало влияния, слишком сложно, отдельная инициатива, рано)
- Не-цели не дают рамкам расползаться во время реализации и задают ожидания заинтересованным лицам
Пользовательские истории
Пиши пользовательские истории в стандартном формате: «Как [тип пользователя], я хочу [возможность], чтобы [польза]»
Рекомендации:
- Тип пользователя должен быть достаточно конкретным, чтобы иметь смысл («администратор корпоративного клиента», а не просто «пользователь»)
- Возможность должна описывать, чего он хочет добиться, а не как
- Польза должна объяснять «зачем» — какую ценность это даёт
- Включай граничные случаи: состояния ошибок, пустые состояния, предельные условия
- Включай разные типы пользователей, если функция служит нескольким персонам
- Расставляй по приоритету — самые важные истории первыми
Пример:
- «Как администратор команды, я хочу настроить SSO для своей организации, чтобы сотрудники могли входить с корпоративными учётными данными»
- «Как участник команды, я хочу автоматически попадать на страницу входа SSO моей компании, чтобы не запоминать отдельный пароль»
- «Как администратор команды, я хочу видеть, какие сотрудники вошли через SSO, чтобы убедиться, что внедрение работает»
Требования
Обязательные (P0): без них функцию выпускать нельзя. Они образуют минимально жизнеспособную версию функции. Спроси: «Если мы это уберём, решит ли функция основную проблему?» Если нет — это P0.
Желательные (P1): заметно улучшают опыт, но основной сценарий работает и без них. Часто становятся быстрыми доработками после запуска.
Задел на будущее (P2): явно за рамками первой версии, но проектировать нужно так, чтобы позже их можно было поддержать. Если их записать, случайные архитектурные решения не затруднят их позднее.
Для каждого требования:
- Напиши чёткое, однозначное описание ожидаемого поведения
- Добавь критерии приёмки (см. ниже)
- Отметь технические соображения и ограничения
- Пометь зависимости от других команд и систем
Открытые вопросы
- Вопросы, на которые нужны ответы до или во время реализации
- Пометь каждый, кто должен ответить (разработка, дизайн, юристы, данные, заинтересованное лицо)
- Различай блокирующие вопросы (нужно ответить до начала работы) и неблокирующие (можно решить в ходе реализации)
Соображения по срокам
- Жёсткие дедлайны (договорные обязательства, мероприятия, даты соответствия требованиям)
- Зависимости от работы или релизов других команд
- Предлагаемая разбивка на фазы, если функция слишком велика для одного релиза
Написание пользовательских историй
Хорошие пользовательские истории:
- Независимы: их можно разработать и выпустить отдельно
- Обсуждаемы: детали можно обсуждать, история — не контракт
- Ценны: приносят ценность пользователю (а не только команде)
- Оцениваемы: команда может примерно оценить трудозатраты
- Малы: их можно завершить за один спринт или итерацию
- Проверяемы: есть чёткий способ убедиться, что это работает
Типичные ошибки в пользовательских историях
- Слишком расплывчато: «Как пользователь, я хочу, чтобы продукт работал быстрее» — что именно должно ускориться?
- Предписание решения: «Как пользователь, я хочу выпадающее меню» — описывай потребность, а не элемент интерфейса
- Нет пользы: «Как пользователь, я хочу нажать кнопку» — зачем? Чего это достигает?
- Слишком крупно: «Как пользователь, я хочу управлять своей командой» — разбей на конкретные возможности
- Внутренний фокус: «Как команда разработки, мы хотим переработать базу данных» — это задача, а не пользовательская история
Категоризация требований
Метод MoSCoW
- Must have (обязательно): без этого функция нежизнеспособна. Не обсуждается.
- Should have (желательно): важно, но не критично для запуска. Быстрые доработки высокого приоритета.
- Could have (возможно): хорошо бы, если хватит времени. Если убрать, поставку это не задержит.
- Won't have (на этот раз не будет): явно за рамками. К этому можно вернуться в будущих версиях.
Советы по категоризации
- Будь беспощаден с P0. Чем короче список обязательного, тем быстрее вы выпускаете и учитесь.
- Если всё — P0, то ничто не P0. Оспорь каждое обязательное требование: «Неужели мы правда не выпустили бы без этого?»
- P1 — это то, что вы уверенно собираетесь делать в ближайшее время, а не список пожеланий.
- P2 — это архитектурная страховка: они направляют проектные решения, хотя вы пока их не делаете.
Определение метрик успеха
Опережающие показатели
Метрики, которые меняются быстро после запуска (дни или недели):
- Доля принятия: % подходящих пользователей, которые попробовали функцию
- Доля активации: % пользователей, выполнивших основное действие
- Доля выполненных задач: % пользователей, успешно достигших цели
- Время выполнения: сколько занимает основной рабочий процесс
- Доля ошибок: как часто пользователи сталкиваются с ошибками или тупиками
- Частота использования функции: как часто пользователи возвращаются к функции
Запаздывающие показатели
Метрики, которым нужно время (недели или месяцы):
- Влияние на удержание: улучшает ли функция удержание пользователей?
- Влияние на выручку: ведёт ли она к переходам на платные тарифы, расширению или новой выручке?
- Изменение NPS / удовлетворённости: улучшает ли она отношение пользователей к продукту?
- Снижение числа обращений в поддержку: уменьшает ли она нагрузку на поддержку?
- Доля выигранных у конкурентов сделок: помогает ли она выигрывать больше сделок?
Постановка целевых значений
- Целевые значения должны быть конкретными: «50 % принятия за 30 дней», а не «высокое принятие»
- Опирайся на сопоставимые функции, отраслевые ориентиры или явные гипотезы
- Задай порог «успеха» и «амбициозное» значение
- Определи способ измерения: какой инструмент, какой запрос, какое окно времени
- Укажи, когда будешь оценивать: через неделю, месяц, квартал после запуска
Критерии приёмки
Пиши критерии приёмки в формате «Дано / Когда / Тогда» или в виде чек-листа:
Дано / Когда / Тогда (Given/When/Then):
- Дано [предусловие или контекст]
- Когда [действие пользователя]
- Тогда [ожидаемый результат]
Пример:
- Дано, что администратор настроил SSO для своей организации
- Когда участник команды заходит на страницу входа
- Тогда он автоматически перенаправляется к SSO-провайдеру организации
Формат чек-листа:
- [ ] Администратор может ввести адрес SSO-провайдера в настройках организации
- [ ] Участники команды видят на странице входа кнопку «Войти через SSO»
- [ ] Вход через SSO создаёт новую учётную запись, если её ещё нет
- [ ] Вход через SSO привязывается к существующей учётной записи, если совпадает адрес почты
- [ ] Неудачные попытки входа через SSO показывают понятное сообщение об ошибке
Советы по критериям приёмки
- Охватывай основной сценарий, случаи ошибок и граничные случаи
- Будь конкретен в ожидаемом поведении, а не в реализации
- Включай то, чего НЕ должно происходить (негативные тест-кейсы)
- Каждый критерий должен проверяться независимо
- Избегай расплывчатых слов: «быстро», «удобно», «интуитивно» — определи, что они значат конкретно
Управление рамками
Как распознать расползание рамок (scope creep)
Рамки расползаются, когда:
- Требования продолжают добавляться после утверждения спецификации
- «Небольшие» добавления накапливаются в заметно больший проект
- Команда делает функции, о которых никто из пользователей не просил («раз уж мы тут…»)
- Дата запуска постоянно сдвигается без явного пересмотра рамок
- Заинтересованные лица добавляют требования, ничего не убирая
Как предотвратить расползание рамок
- Пиши явные не-цели в каждой спецификации
- Требуй, чтобы любое расширение рамок сопровождалось сокращением рамок или продлением сроков
- Чётко разделяй в спецификации «v1» и «v2»
- Сверяй спецификацию с исходной формулировкой проблемы — всё ли ей служит?
- Ограничивай исследования по времени: «Если мы не разберёмся с X за 2 дня, мы это убираем»
- Заведи «парковку» для хороших идей, которые не входят в рамки
Формат результата
Используй markdown с понятными заголовками. Документ должен легко просматриваться глазами — занятые заинтересованные лица должны уловить суть, прочитав лишь заголовки и выделенный жирным текст.
Советы
- Занимай твёрдую позицию по рамкам. Лучше сжатая, чётко определённая спецификация, чем обширная и расплывчатая.
- Если идея пользователя слишком велика для одной спецификации, предложи разбить её на фазы и опиши первую.
- Метрики успеха должны быть конкретными и измеримыми, а не расплывчатыми («улучшить пользовательский опыт»).
- Не-цели так же важны, как цели. Они не дают рамкам расползаться во время реализации.
- Открытые вопросы должны быть по-настоящему открытыми — не включай вопросы, на которые можешь ответить из контекста.
Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills/write-spec, лицензия Apache-2.0. Изменения: перевод на русский язык.
Оригинал на английском
---
name: write-spec
description: Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.
argument-hint: "<feature or problem statement>"
---
# Write Spec
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
Write a feature specification or product requirements document (PRD).
## Usage
```
/write-spec $ARGUMENTS
```
## Workflow
### 1. Understand the Feature
Ask the user what they want to spec. Accept any of:
- A feature name ("SSO support")
- A problem statement ("Enterprise customers keep asking for centralized auth")
- A user request ("Users want to export their data as CSV")
- A vague idea ("We should do something about onboarding drop-off")
### 2. Gather Context
Ask the user for the following. Be conversational — do not dump all questions at once. Ask the most important ones first and fill in gaps as you go:
- **User problem**: What problem does this solve? Who experiences it?
- **Target users**: Which user segment(s) does this serve?
- **Success metrics**: How will we know this worked?
- **Constraints**: Technical constraints, timeline, regulatory requirements, dependencies
- **Prior art**: Has this been attempted before? Are there existing solutions?
### 3. Pull Context from Connected Tools
If **~~project tracker** is connected:
- Search for related tickets, epics, or features
- Pull in any existing requirements or acceptance criteria
- Identify dependencies on other work items
If **~~knowledge base** is connected:
- Search for related research documents, prior specs, or design docs
- Pull in relevant user research findings
- Find related meeting notes or decision records
If **~~design** is connected:
- Pull related mockups, wireframes, or design explorations
- Search for design system components relevant to the feature
If these tools are not connected, work entirely from what the user provides. Do not ask the user to connect tools — just proceed with available information.
### 4. Generate the PRD
Produce a structured PRD with these sections. See **PRD Structure** below for detailed guidance on what each section should contain.
- **Problem Statement**: The user problem, who is affected, and impact of not solving it (2-3 sentences)
- **Goals**: 3-5 specific, measurable outcomes tied to user or business metrics
- **Non-Goals**: 3-5 things explicitly out of scope, with brief rationale for each
- **User Stories**: Standard format ("As a [user type], I want [capability] so that [benefit]"), grouped by persona
- **Requirements**: Categorized as Must-Have (P0), Nice-to-Have (P1), and Future Considerations (P2), each with acceptance criteria
- **Success Metrics**: Leading indicators (change quickly) and lagging indicators (change over time), with specific targets
- **Open Questions**: Unresolved questions tagged with who needs to answer (engineering, design, legal, data)
- **Timeline Considerations**: Hard deadlines, dependencies, and phasing
### 5. Review and Iterate
After generating the PRD:
- Ask the user if any sections need adjustment
- Offer to expand on specific sections
- Offer to create follow-up artifacts (design brief, engineering ticket breakdown, stakeholder pitch)
## PRD Structure
### Problem Statement
- Describe the user problem in 2-3 sentences
- Who experiences this problem and how often
- What is the cost of not solving it (user pain, business impact, competitive risk)
- Ground this in evidence: user research, support data, metrics, or customer feedback
### Goals
- 3-5 specific, measurable outcomes this feature should achieve
- Each goal should answer: "How will we know this succeeded?"
- Distinguish between user goals (what users get) and business goals (what the company gets)
- Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")
### Non-Goals
- 3-5 things this feature explicitly will NOT do
- Adjacent capabilities that are out of scope for this version
- For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
- Non-goals prevent scope creep during implementation and set expectations with stakeholders
### User Stories
Write user stories in standard format: "As a [user type], I want [capability] so that [benefit]"
Guidelines:
- The user type should be specific enough to be meaningful ("enterprise admin" not just "user")
- The capability should describe what they want to accomplish, not how
- The benefit should explain the "why" — what value does this deliver
- Include edge cases: error states, empty states, boundary conditions
- Include different user types if the feature serves multiple personas
- Order by priority — most important stories first
Example:
- "As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
- "As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"
- "As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working"
### Requirements
**Must-Have (P0)**: The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0.
**Nice-to-Have (P1)**: Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.
**Future Considerations (P2)**: Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.
For each requirement:
- Write a clear, unambiguous description of the expected behavior
- Include acceptance criteria (see below)
- Note any technical considerations or constraints
- Flag dependencies on other teams or systems
### Open Questions
- Questions that need answers before or during implementation
- Tag each with who should answer (engineering, design, legal, data, stakeholder)
- Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)
### Timeline Considerations
- Hard deadlines (contractual commitments, events, compliance dates)
- Dependencies on other teams' work or releases
- Suggested phasing if the feature is too large for one release
## User Story Writing
Good user stories are:
- **Independent**: Can be developed and delivered on their own
- **Negotiable**: Details can be discussed, the story is not a contract
- **Valuable**: Delivers value to the user (not just the team)
- **Estimable**: The team can roughly estimate the effort
- **Small**: Can be completed in one sprint/iteration
- **Testable**: There is a clear way to verify it works
### Common Mistakes in User Stories
- Too vague: "As a user, I want the product to be faster" — what specifically should be faster?
- Solution-prescriptive: "As a user, I want a dropdown menu" — describe the need, not the UI widget
- No benefit: "As a user, I want to click a button" — why? What does it accomplish?
- Too large: "As a user, I want to manage my team" — break this into specific capabilities
- Internal focus: "As the engineering team, we want to refactor the database" — this is a task, not a user story
## Requirements Categorization
### MoSCoW Framework
- **Must have**: Without these, the feature is not viable. Non-negotiable.
- **Should have**: Important but not critical for launch. High-priority fast follows.
- **Could have**: Desirable if time permits. Will not delay delivery if cut.
- **Won't have (this time)**: Explicitly out of scope. May revisit in future versions.
### Tips for Categorization
- Be ruthless about P0s. The tighter the must-have list, the faster you ship and learn.
- If everything is P0, nothing is P0. Challenge every must-have: "Would we really not ship without this?"
- P1s should be things you are confident you will build soon, not a wish list.
- P2s are architectural insurance — they guide design decisions even though you are not building them now.
## Success Metrics Definition
### Leading Indicators
Metrics that change quickly after launch (days to weeks):
- **Adoption rate**: % of eligible users who try the feature
- **Activation rate**: % of users who complete the core action
- **Task completion rate**: % of users who successfully accomplish their goal
- **Time to complete**: How long the core workflow takes
- **Error rate**: How often users encounter errors or dead ends
- **Feature usage frequency**: How often users return to use the feature
### Lagging Indicators
Metrics that take time to develop (weeks to months):
- **Retention impact**: Does this feature improve user retention?
- **Revenue impact**: Does this drive upgrades, expansion, or new revenue?
- **NPS / satisfaction change**: Does this improve how users feel about the product?
- **Support ticket reduction**: Does this reduce support load?
- **Competitive win rate**: Does this help win more deals?
### Setting Targets
- Targets should be specific: "50% adoption within 30 days" not "high adoption"
- Base targets on comparable features, industry benchmarks, or explicit hypotheses
- Set a "success" threshold and a "stretch" target
- Define the measurement method: what tool, what query, what time window
- Specify when you will evaluate: 1 week, 1 month, 1 quarter post-launch
## Acceptance Criteria
Write acceptance criteria in Given/When/Then format or as a checklist:
**Given/When/Then**:
- Given [precondition or context]
- When [action the user takes]
- Then [expected outcome]
Example:
- Given the admin has configured SSO for their organization
- When a team member visits the login page
- Then they are automatically redirected to the organization's SSO provider
**Checklist format**:
- [ ] Admin can enter SSO provider URL in organization settings
- [ ] Team members see "Log in with SSO" button on login page
- [ ] SSO login creates a new account if one does not exist
- [ ] SSO login links to existing account if email matches
- [ ] Failed SSO attempts show a clear error message
### Tips for Acceptance Criteria
- Cover the happy path, error cases, and edge cases
- Be specific about the expected behavior, not the implementation
- Include what should NOT happen (negative test cases)
- Each criterion should be independently testable
- Avoid ambiguous words: "fast", "user-friendly", "intuitive" — define what these mean concretely
## Scope Management
### Recognizing Scope Creep
Scope creep happens when:
- Requirements keep getting added after the spec is approved
- "Small" additions accumulate into a significantly larger project
- The team is building features no user asked for ("while we're at it...")
- The launch date keeps moving without explicit re-scoping
- Stakeholders add requirements without removing anything
### Preventing Scope Creep
- Write explicit non-goals in every spec
- Require that any scope addition comes with a scope removal or timeline extension
- Separate "v1" from "v2" clearly in the spec
- Review the spec against the original problem statement — does everything serve it?
- Time-box investigations: "If we cannot figure out X in 2 days, we cut it"
- Create a "parking lot" for good ideas that are not in scope
## Output Format
Use markdown with clear headers. Keep the document scannable — busy stakeholders should be able to read just the headers and bold text to get the gist.
## Tips
- Be opinionated about scope. It is better to have a tight, well-defined spec than an expansive vague one.
- If the user's idea is too big for one spec, suggest breaking it into phases and spec the first phase.
- Success metrics should be specific and measurable, not vague ("improve user experience").
- Non-goals are as important as goals. They prevent scope creep during implementation.
- Open questions should be genuinely open — do not include questions you can answer from context.
Источник: anthropics/knowledge-work-plugins / product-management / write-spec ↗. Ссылка проверена 2026-10-10.