# Prompt Library Template: Role → Context → Task → Constraints → Format

> 5-компонентный шаблон промптов для переиспользуемой библиотеки. Структура, примеры для разных задач, организация и версионирование prompt library.
> Author: Roman Belov · Published: 2026-06-10 · Source: https://futurecraft.pro/ru/blog/prompt-library-template/

Каждый раз инженер тратит 15–30 минут, формулируя промпт, который уже писал неделю назад. Без структуры, без версионирования, без переиспользования. Проблема не в сложности задач, а в отсутствии системы.

Prompt library решает эту проблему. Не коллекция «лучших промптов из Twitter», а инженерный инструмент с единой структурой, версионированием и каталогом. В основе лежит 5-компонентный шаблон: Role → Context → Task → Constraints → Format. Каждый компонент отвечает за конкретный аспект поведения модели.

## Почему структурированные промпты работают лучше

LLM обрабатывает промпт как единый текстовый блок. Модель не различает «инструкцию» и «контекст» на архитектурном уровне. Но структура помогает модели правильно распределить attention между частями входа.

Практика и гайды по prompt engineering от Anthropic и OpenAI говорят об одном: промпты с явным разделением на секции дают более релевантные и точные ответы, чем монолитный текст той же длины. Причина в том, что модель получает явные сигналы о приоритетах.

Пять компонентов шаблона решают пять разных задач:

```
┌──────────────────────────────────────────────┐
│              Prompt Template                  │
├──────────┬───────────────────────────────────┤
│  Role    │ Кто отвечает (экспертиза, тон)    │
├──────────┼───────────────────────────────────┤
│  Context │ Что известно (данные, ситуация)   │
├──────────┼───────────────────────────────────┤
│  Task    │ Что сделать (конкретное действие)  │
├──────────┼───────────────────────────────────┤
│ Constr.  │ Чего избегать (границы, запреты)  │
├──────────┼───────────────────────────────────┤
│  Format  │ Как оформить (структура вывода)   │
└──────────┴───────────────────────────────────┘
```

Каждый компонент можно менять независимо. Один и тот же Task с разным Role даёт принципиально разные результаты. Один и тот же Role + Task с разным Format подходит для разных потребителей вывода. Модульность шаблона превращает промпт из одноразового текста в переиспользуемый инструмент.

## Компонент 1: Role — кто отвечает

Role задаёт экспертизу, перспективу и тон ответа. Модель активирует разные «области знаний» в зависимости от заданной роли.

**Плохо:** «Ты полезный ассистент»
**Хорошо:** «Ты senior backend-инженер с 10-летним опытом в распределённых системах. Специализация: PostgreSQL, event-driven architecture, Go»

Эффективная роль содержит три элемента:

1. **Уровень экспертизы.** «Junior», «senior», «principal» — модель калибрует глубину и детализацию ответа.
2. **Область специализации.** Конкретные технологии, домены, методологии. Чем уже, тем точнее.
3. **Поведенческие рамки.** «Ты предпочитаешь простые решения сложным», «Ты всегда указываешь на потенциальные проблемы с масштабированием».

```markdown
## Role
Senior DevOps engineer. 8 years of experience with Kubernetes,
Terraform, AWS. You prioritize reliability over cost optimization.
You always mention monitoring implications of proposed changes.
```

Role работает как фильтр. Один и тот же вопрос о выборе базы данных от «senior backend-инженера» и «CTO стартапа на 5 человек» даст разные ответы: первый получит технический анализ, второй — стратегический.

## Компонент 2: Context — что известно

Context предоставляет модели информацию, которой у неё нет в обучающих данных. Это факты о проекте, текущее состояние системы, бизнес-ограничения, предыдущие решения.

Три типа контекста:

**Статический контекст** не меняется между вызовами. Описание проекта, стек технологий, архитектурные принципы. Его имеет смысл выносить в [системные промпты или CLAUDE.md-файлы](/ru/blog/context-engineering-guide/).

**Динамический контекст** меняется при каждом вызове. Текущий код, ошибка из логов, результат предыдущего шага. Подставляется через переменные шаблона.

**Имплицитный контекст** модель извлекает из самого промпта. Язык запроса, стиль формулировок, технический уровень терминов. Управлять им сложнее, но он влияет на ответ.

```markdown
## Context
Project: e-commerce platform, 50k DAU, Python/FastAPI backend.
Database: PostgreSQL 15, ~200GB, hosted on AWS RDS.
Current problem: order creation endpoint p99 latency increased
from 120ms to 800ms after last deployment (commit abc123).
Related: we added a new inventory check that joins 3 tables.
No changes to infrastructure or database configuration.
```

Правило: контекст должен содержать только релевантную информацию. Модель с контекстным окном на 200 000 токенов обработает и 50 000 токенов контекста, но качество ответа деградирует. [Управление контекстом](/ru/blog/context-engineering-guide/) — отдельная дисциплина, и минимально необходимый контекст всегда лучше максимально возможного.

## Компонент 3: Task — что сделать

Task — ядро промпта. Одно конкретное действие, сформулированное императивом. Не «расскажи про оптимизацию запросов», а «найди причину деградации p99 latency и предложи fix».

Признаки хорошего Task:

- **Атомарность.** Одна задача, один результат. Если задача требует «проанализируй И напиши И протестируй», её нужно разбить.
- **Верифицируемость.** Можно однозначно определить, выполнена задача или нет.
- **Конкретность.** «Улучши код» — плохо. «Замени N+1 запрос в OrderService.get_orders() на JOIN с предзагрузкой» — хорошо.

```markdown
## Task
Analyze the slow query log below and identify the root cause
of the p99 latency increase. Propose a specific fix:
either an index, a query rewrite, or an application-level change.
Include the exact SQL for any database changes.
```

Для сложных задач Task может содержать пронумерованные шаги. Модель следует им последовательно, что снижает вероятность пропуска этапов:

```markdown
## Task
1. Identify which of the 3 JOINs in the query is the bottleneck
2. Check if an index on inventory.product_id would help
3. If yes — provide CREATE INDEX statement
4. If no — propose an alternative (query rewrite or caching)
5. Estimate the expected latency improvement
```

## Компонент 4: Constraints — чего избегать

Constraints определяют границы допустимого. Без них модель выбирает «наиболее вероятный» ответ, который может не соответствовать реальным ограничениям проекта.

Четыре категории ограничений:

**Технические.** «Не используй ORM, только raw SQL», «Совместимость с Python 3.9+», «Решение должно работать без даунтайма».

**Бизнесовые.** «Бюджет на инфраструктуру — $500/мес», «Не трогай legacy-модуль billing — он на аудите», «Решение нужно за 2 часа, не за 2 недели».

**Стилевые.** «Не используй аббревиатуры без расшифровки», «Код на Go — без generics (поддержка 1.17)», «Комментарии на английском».

**Запреты.** Явные «не делай X». Работают надёжнее, чем надежда на здравый смысл модели. «Не предлагай переезд на другую СУБД», «Не меняй API-контракт».

```markdown
## Constraints
- Solution must be backward-compatible (no API changes)
- No additional infrastructure (no Redis, no Elasticsearch)
- Must work with current PostgreSQL 15, no extensions
- Migration must be online (zero downtime)
- Do not suggest application-level caching as primary solution
```

Constraints — самый недооценённый компонент. Большинство «плохих» ответов модели вызваны не плохим промптом, а отсутствием ограничений. Модель предлагает идеальное решение в вакууме, игнорируя реальность.

## Компонент 5: Format — как оформить

Format определяет структуру вывода. Без него модель сама выбирает формат, и это почти всегда «стена текста с markdown-заголовками».

Format решает две задачи:

1. **Для человека.** Структурированный вывод легче читать и проверять.
2. **Для кода.** Если вывод парсится программно, формат должен быть строгим (JSON, YAML, конкретная markdown-структура).

```markdown
## Format
Respond with:
1. **Root cause** (1-2 sentences)
2. **Fix** — exact SQL or code change, ready to copy-paste
3. **Risk assessment** — what could go wrong, how to rollback
4. **Expected improvement** — estimated latency after fix
5. **Verification query** — SQL to confirm the fix worked

Do not include explanations of basic concepts.
Use code blocks for all SQL and code.
```

Для программного парсинга Format задаёт JSON-схему:

```markdown
## Format
Respond with valid JSON matching this schema:
{
  "root_cause": "string",
  "fix_type": "index" | "query_rewrite" | "app_change",
  "sql": "string | null",
  "code_change": "string | null",
  "risk": "low" | "medium" | "high",
  "estimated_improvement_ms": "number"
}
```

## Полный шаблон в действии

Собранный промпт выглядит так:

```markdown
## Role
Senior backend engineer specializing in PostgreSQL performance
optimization. 10 years of experience. You prefer minimal,
targeted fixes over large refactors.

## Context
E-commerce platform, 50k DAU. Python/FastAPI, PostgreSQL 15
on AWS RDS (db.r6g.xlarge). Order creation p99 jumped from
120ms to 800ms after deploy on 2026-03-25.

New code adds inventory check:
SELECT o.*, p.name, i.quantity
FROM orders o
JOIN products p ON o.product_id = p.id
JOIN inventory i ON i.product_id = p.id
JOIN warehouses w ON i.warehouse_id = w.id
WHERE o.user_id = $1 AND w.region = $2;

Tables: orders (12M rows), products (500k), inventory (2M),
warehouses (50).

## Task
1. Identify the bottleneck in this query
2. Propose the minimal fix (index, rewrite, or both)
3. Provide exact migration SQL
4. Estimate improvement

## Constraints
- No downtime — online migration only
- No new infrastructure
- PostgreSQL 15, no extensions
- Keep the same API response format

## Format
1. **Diagnosis** (2-3 sentences)
2. **Fix** (SQL, copy-paste ready)
3. **Migration plan** (step-by-step, with rollback)
4. **Expected result** (estimated p99 after fix)
```

Каждый компонент можно заменить. Если завтра p99 прыгнет в другом эндпоинте, меняется только Context. Если нужен ответ для CTO, меняется Role и Format. Если переезд на MySQL, меняются Constraints. Шаблон работает как конструктор.

## Примеры для разных задач

### Код-ревью

```markdown
## Role
Principal engineer, code reviewer. Focus: correctness,
maintainability, security. You catch subtle bugs.

## Context
TypeScript/React project. PR #247: new payment form component.
Team convention: Zod for validation, React Hook Form, no any types.
{{code_diff}}

## Task
Review this PR. Flag bugs, security issues, and deviations
from team conventions. Approve or request changes.

## Constraints
- Don't comment on style (Prettier handles it)
- Don't suggest rewrites of working code
- Focus on logic errors and security only

## Format
For each issue:
- **File:line** — severity (critical/warning/nit)
- Description (1 sentence)
- Suggested fix (code block)

End with: APPROVE / REQUEST CHANGES / BLOCK
```

### Написание документации

```markdown
## Role
Technical writer. You write for developers who have 5 minutes
to understand a new API. No marketing language.

## Context
Internal REST API for user management. FastAPI, OpenAPI spec
attached. Audience: frontend developers on the same team.
{{openapi_spec}}

## Task
Write API documentation for the /users endpoints.
Include request/response examples for each endpoint.

## Constraints
- No introductory paragraphs ("Welcome to our API...")
- No explanation of REST concepts
- Every example must be a valid curl command
- Use realistic data, not "John Doe"

## Format
For each endpoint:
## METHOD /path
Brief description (1 sentence)
**Request:** curl example
**Response:** JSON example
**Errors:** table of error codes
```

### Анализ данных

```markdown
## Role
Data analyst. SQL expert. You explain findings in terms
that product managers understand.

## Context
SaaS product, B2B. PostgreSQL analytics DB.
Tables: users, subscriptions, events, invoices.
Current MRR: $180k. Churn last month: 4.2%.
{{schema_ddl}}

## Task
Write SQL queries to identify the top 3 predictors of churn.
Analyze the last 6 months of data.

## Constraints
- Queries must run under 30 seconds on 10M events table
- Use only standard PostgreSQL (no extensions)
- No ML models — pure SQL analysis

## Format
For each predictor:
1. **Finding** (1 sentence, plain language)
2. **Evidence** (SQL query + expected output description)
3. **Recommendation** (what product team should do)
```

### Генерация тестов

```markdown
## Role
QA engineer specializing in unit and integration testing.
You write tests that catch real bugs, not tests for coverage.

## Context
Go service, payment processing. Function: ProcessRefund().
Handles partial refunds, full refunds, idempotency.
{{function_code}}

## Task
Write test cases for ProcessRefund(). Cover happy path,
edge cases, and error scenarios. Use table-driven tests.

## Constraints
- Standard library + testify only
- No mocks of external HTTP calls — use interfaces
- Each test must be independent (no shared state)
- Test names must describe the scenario, not the method

## Format
Go test file, ready to compile. Each test case
in a table-driven format with: name, input, expected output,
expected error.
```

## Организация prompt library

Библиотека промптов требует структуры, как и кодовая база. Без неё коллекция превращается в свалку.

### Файловая структура

```
prompts/
├── engineering/
│   ├── code-review.md
│   ├── debug-performance.md
│   ├── write-tests.md
│   └── migration-plan.md
├── product/
│   ├── spec-review.md
│   ├── user-story.md
│   └── competitive-analysis.md
├── data/
│   ├── sql-analysis.md
│   ├── dashboard-design.md
│   └── anomaly-investigation.md
├── writing/
│   ├── api-docs.md
│   ├── adr.md
│   └── incident-report.md
└── _components/
    ├── roles/
    │   ├── senior-backend.md
    │   ├── principal-engineer.md
    │   └── data-analyst.md
    ├── constraints/
    │   ├── postgresql-only.md
    │   ├── zero-downtime.md
    │   └── no-new-deps.md
    └── formats/
        ├── json-response.md
        ├── pr-review.md
        └── step-by-step.md
```

Ключевой элемент — папка `_components`. В ней хранятся переиспользуемые блоки: роли, ограничения, форматы. Промпт собирается из компонентов, а не пишется с нуля каждый раз.

### Метаданные промпта

Каждый промпт в библиотеке содержит заголовок с метаданными:

```yaml
---
id: eng-debug-perf-001
name: Debug Performance Regression
version: 2.1
category: engineering
models: [claude-sonnet-4-6, gpt-5.4]
variables: [error_log, query, table_schema]
author: team-backend
last_tested: 2026-03-15
success_rate: 87%  # примерная оценка: доля тестовых прогонов, прошедших проверки
---
```

Метаданные позволяют фильтровать, версионировать и отслеживать эффективность промптов. Поле `variables` указывает, какие данные нужно подставить при использовании. Поле `models` фиксирует, на каких моделях промпт тестировался.

### Версионирование

Промпты эволюционируют. Версионирование по тем же принципам, что и код:

- **Patch** (2.0.0 → 2.0.1): исправление формулировок, уточнение constraints
- **Minor** (2.0 → 2.1): новые секции, изменение task, добавление шагов
- **Major** (2.0 → 3.0): смена модели, полная переработка подхода

Git хранит историю изменений. Если Langfuse или аналогичная платформа используется для [prompt management](/ru/blog/llm-observability-langfuse/), промпты версионируются и там. Когда библиотека вырастает за пределы нескольких файлов, её стоит дополнить полноценной [системой управления промптами](/ru/blog/prompt-engineering-system/) для деплоя и мониторинга.

### Тестирование промптов

Промпт без тестов — как функция без тестов. Работает до первого изменения.

Минимальный набор для каждого промпта:

1. **Golden test.** Фиксированный ввод → ожидаемый вывод. Проверяет, что промпт выполняет основную задачу.
2. **Edge case test.** Пустой ввод, слишком длинный ввод, невалидные данные. Проверяет устойчивость.
3. **Format test.** Парсинг вывода. Если Format задаёт JSON-схему, вывод должен быть валидным JSON.
4. **Regression test.** При обновлении промпта прогоняются все предыдущие тесты.

```python
def test_debug_prompt():
    response = call_llm(
        prompt=load_prompt("eng-debug-perf-001"),
        variables={
            "error_log": SAMPLE_ERROR_LOG,
            "query": SAMPLE_SLOW_QUERY,
            "table_schema": SAMPLE_SCHEMA,
        }
    )
    result = json.loads(response)
    assert "root_cause" in result
    assert result["fix_type"] in ["index", "query_rewrite", "app_change"]
    assert result["risk"] in ["low", "medium", "high"]
```

## Антипаттерны промпт-библиотек

**Промпт-роман.** Промпт на 2000 слов, который пытается покрыть все возможные сценарии. Модель теряет фокус, качество падает. Решение: разбить на атомарные промпты, каждый для одной задачи.

**Copy-paste наследование.** Десять промптов с одинаковым Role, скопированным вручную. При изменении роли нужно обновлять все десять. Решение: компонентная архитектура с `_components/`.

**Отсутствие Constraints.** «Напиши код» без ограничений. Модель выберет свой «дефолт», который может не совпадать с нужным. Решение: всегда задавать хотя бы 3-5 ограничений.

**Жёсткий Format без причины.** JSON-схема для ответа, который читает только человек. Лишнее ограничение снижает качество содержания. Решение: JSON и строгие форматы только для программного парсинга.

**Prompt rot.** Промпты, написанные для GPT-4o, используются с Claude Opus 4.6 без обновления. Разные модели по-разному реагируют на структуру, длину, стиль инструкций. Решение: поле `models` в метаданных и регулярное тестирование.

## Внедрение в команде

Prompt library становится ценной, когда ей пользуется вся команда, а не один человек.

**Шаг 1: аудит.** Собрать все промпты, которые команда использует регулярно. Обычно их 10-15 на команду из 5 человек.

**Шаг 2: стандартизация.** Переписать каждый по 5-компонентному шаблону. Это занимает 15-20 минут на промпт.

**Шаг 3: каталогизация.** Организовать в файловую структуру, добавить метаданные. Вынести общие компоненты в `_components/`.

**Шаг 4: интеграция.** Подключить к рабочему процессу. Промпты из библиотеки доступны в IDE (через CLAUDE.md или .cursorrules), в CI/CD (через API-вызовы), в Langfuse (через prompt management).

**Шаг 5: ревью.** Новые промпты проходят ревью, как код. Проверяются: структура по шаблону, наличие тестов, метаданные.

Библиотека промптов — это не PDF с «топ-50 промптов». Это инженерный артефакт с версионированием, тестами и CI. Role → Context → Task → Constraints → Format — пять компонентов, каждый управляет конкретным аспектом поведения модели, каждый можно менять независимо. Пяти шаблонов под самые частые задачи команды достаточно для измеримого улучшения качества и скорости работы с LLM.

---

*Нужна помощь с prompt engineering? Я помогаю стартапам внедрять AI-решения и строить продукты — [belov.works](https://belov.works).*