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

Каждый раз инженер тратит 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. Поведенческие рамки. «Ты предпочитаешь простые решения сложным», «Ты всегда указываешь на потенциальные проблемы с масштабированием».

## 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-файлы.

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

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

## 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 токенов контекста, но качество ответа деградирует. Управление контекстом — отдельная дисциплина, и минимально необходимый контекст всегда лучше максимально возможного.

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

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

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

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

## 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 может содержать пронумерованные шаги. Модель следует им последовательно, что снижает вероятность пропуска этапов:

## 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-контракт».

## 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-структура).

## 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-схему:

## 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"
}

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

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

## 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. Шаблон работает как конструктор.

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

Код-ревью

## 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

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

## 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

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

## 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)

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

## 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. В ней хранятся переиспользуемые блоки: роли, ограничения, форматы. Промпт собирается из компонентов, а не пишется с нуля каждый раз.

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

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

---
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 → 2.1): исправление формулировок, уточнение constraints
• Minor (2.1 → 2.2): новые секции, изменение task, добавление шагов
• Major (2.0 → 3.0): смена модели, полная переработка подхода

Git хранит историю изменений. Если Langfuse или аналогичная платформа используется для prompt management, промпты версионируются и там. Когда библиотека вырастает за пределы нескольких файлов, её стоит дополнить полноценной системой управления промптами для деплоя и мониторинга.

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

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

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

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

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.