Reliable AI workflow with GitHub Copilot: a full guide with examples

TrustMe · February 3, 2026, 12:01pm

Привет! Сегодня я делюсь кратким руководством по тому, как настроить проект для работы с GitHub Copilot.

Надёжный AI воркфлоу с GitHub Copilot: полное руководство с примерами

Это руководство показывает, как создать предсказуемые и воспроизводимые AI-процессы (воркфлоу) в вашем репозитории и IDE/CLI с помощью агентных примитивов и инженерии контекста. Здесь вы найдёте структуру файлов, готовые шаблоны, правила безопасности и команды.

Примечание: функциональность файлов промптов и агентного режима в IDE/CLI может меняться — адаптируйте руководство к конкретным версиям Copilot и VS Code, которые вы используете.

1) Обзор: из чего состоит воркфлоу

Основная цель — разбить работу агента на прозрачные шаги и сделать их подконтрольными. Для этого существуют следующие инструменты:

Custom Instructions (.github/copilot-instructions.md) — глобальные правила проекта (как собрать, как тестировать, стиль кода, политики PR).
Path-specific Instructions (.github/instructions/*.instructions.md) — правила для конкретных областей, применяемые через applyTo (glob-паттерны).
Chat Modes (.github/chatmodes/*.chatmode.md) — специализированные режимы чата (например, Plan/Frontend/DBA) с фиксированными инструментами и моделью.
Prompt Files (.github/prompts/*.prompt.md) — многоразовые сценарии/“программы” для типичных задач (ревью, рефакторинг, генерация).
Context helpers (docs/*.spec.md, docs/*.context.md, docs/*.memory.md) — спецификации, справки и память проекта для точного контекста.
MCP servers (.vscode/mcp.json или через UI) — инструменты и внешние ресурсы, которые может использовать агент.

2) Структура файлов проекта

Следующая структура соответствует описанным выше инструментам и помогает составить полный воркфлоу для агентов.

.github/
  copilot-instructions.md
  instructions/
    backend.instructions.md
    frontend.instructions.md
    actions.instructions.md
  prompts/
    implement-from-spec.prompt.md
    security-review.prompt.md
    refactor-slice.prompt.md
    test-gen.prompt.md
  chatmodes/
    plan.chatmode.md
    frontend.chatmode.md
.vscode/
  mcp.json
docs/
  feature.spec.md
  project.context.md
  project.memory.md

3) Файлы и их назначение — техническое объяснение

Теперь рассмотрим каждый инструмент отдельно и его роль. Ниже объясняется, как всё это устроено под капотом: что собой представляют эти файлы, зачем они существуют, как влияют на понимание задачи агентом и в каком порядке они объединяются / переопределяются. Примеры кода ниже соответствуют спецификации.

Файл/папка	Что это	Зачем	Где применяется
`.github/copilot-instructions.md`	Глобальные правила проекта	Единые стандарты для всех ответов	Весь репозиторий
`.github/instructions/*.instructions.md`	Целевые инструкции для конкретных путей	Разные правила для frontend/backend/CI	Только для файлов, соответствующих `applyTo`
`.github/chatmodes/*.chatmode.md`	Набор правил + допустимых инструментов для режима чата	Разделение фаз работы (план/рефакторинг/DBA)	Когда выбран данный режим чата
`.github/prompts/*.prompt.md`	Сценарии задач (воркфлоу)	Повторный запуск типичных процессов	При вызове через `/name` или CLI
`docs/*.spec.md`	Спецификации	Точные постановки задач	При упоминании через `@` в диалоге
`docs/*.context.md`	Стабильные справки	Снижение «шума» в чатах	По ссылке / `@`-упоминанию
`docs/*.memory.md`	Память проекта	Запись решений для предотвращения повторов	По ссылке / `@`-упоминанию
`.vscode/mcp.json`	Конфигурация MCP-серверов	Доступ к GitHub и другим инструментам	Для данного воркспейса

Порядок объединения правил и настроек: Frontmatter промпта → Режим чата → Repo/Path инструкции → Значения по умолчанию.

И теперь рассмотрим каждый инструмент по отдельности.

3.1. Глобальные правила — `.github/copilot-instructions.md`

Что это: Markdown-файл с короткими, проверяемыми правилами: как собрать, как тестировать, стиль кода и политики PR.

Зачем: Чтобы все ответы опирались на единый набор стандартов (без дублирования в каждом промпте).

Как работает: Файл автоматически становится частью системного контекста для всех вопросов в рамках репозитория. Нет applyTo (об этом — ниже) — он применяется везде.

Минимальный пример:

# Repository coding standards
- Build: `npm ci && npm run build`
- Tests: `npm run test` (coverage ≥ 80%)
- Lint/Typecheck: `npm run lint && npm run typecheck`
- Commits: Conventional Commits; keep PRs small and focused
- Docs: update `CHANGELOG.md` in every release PR

Tips.

Держите пункты короткими.
Избегайте общих фраз.
Включайте только то, что может влиять на результат (build/test/lint/type/политика PR).

3.2. Инструкции для конкретных путей — `.github/instructions/*.instructions.md`

Что это: Модульные правила с YAML frontmatter applyTo — glob-паттерны файлов, для которых они подключаются.

Зачем: Для дифференциации стандартов в разных областях (frontend/backend/CI). Позволяет контролировать контекст в зависимости от типа задачи.

Как работает: При обработке задачи Copilot находит все *.instructions.md, у которых applyTo совпадает с текущим контекстом (файлы, которые вы обсуждаете/редактируете). Подходящие правила добавляются к глобальным.

Пример:

---
applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
---
- React: function components and hooks
- State: Zustand; data fetching with TanStack Query
- Styling: Tailwind CSS; avoid inline styles except dynamic cases
- Testing: Vitest + Testing Library; avoid unstable snapshots

Примечание.

Избегайте дублирования уже существующих глобальных правил.
Убедитесь, что glob действительно нацелен на нужные пути.

3.3. Режимы чата — `.github/chatmodes/*.chatmode.md`

Что это: Файлы конфигурации, задающие режим работы агента для диалога: короткое описание, модель (при необходимости) и список допустимых инструментов.

Зачем: Для разделения фаз работы (планирование/frontend/DBA/безопасность) и ограничения инструментов на каждом этапе. Это делает результаты более предсказуемыми.

Структура файла:

---
description: "Plan - analyze code/specs and propose a plan; read-only tools"
model: GPT-4o
tools:[ "search/codebase"]
---
In this mode:
- Produce a structured plan with risks and unknowns
- Do not edit files; output a concise task list instead

Как работает:

Режим чата применяется к текущему чату в IDE.
Если вы активируете файл промпта, его frontmatter имеет приоритет над режимом чата (может изменить модель и сузить tools).
Эффективный список допустимых инструментов: инструменты режима чата, ограниченные инструментами промпта и флагами CLI --allow/--deny.

Управление и переключение:

В IDE (VS Code):

Откройте панель Copilot Chat.
В верхней строке выберите нужный режим чата из выпадающего списка (список строится из .github/chatmodes/*.chatmode.md + встроенных режимов).
Режим применяется только к этой ветке диалога. Для смены — выберите другой или создайте новую ветку с нужным режимом.
Проверьте активный режим в заголовке/панели разговора; в References будет виден файл *.chatmode.md.

В CLI: (немного хакивщики, лучше через промпты)
- Специального флага CLI для переключения режимов обычно нет; закодируйте нужные ограничения в frontmatter файла промпта и/или через флаги --allow-tool/--deny-tool.
- Вы можете указать в первой строке: «Используйте режим чата i18n.» — если версия это поддерживает, агент может переключиться; если нет, frontmatter промпта всё равно применит ограничения инструментов.
Без переключения режима: запустите промпт с нужными tools: в frontmatter — это ограничит инструменты независимо от режима чата.

Диагностика: если агент использует «лишние» инструменты или не видит нужные — проверьте: (1) какой режим чата выбран; (2) tools в frontmatter промпта; (3) флаги CLI --allow/--deny; (4) References в ответе (видимые файлы *.chatmode.md/*.prompt.md).

3.4. Файлы промптов — `.github/prompts/*.prompt.md`

Что это: Файлы сценариев для многоразовых задач. Состоят из YAML frontmatter (конфигурация) и тела (инструкции/шаги/критерии приёмки). Вызываются в чате через /name или через CLI.

Когда использовать: Когда необходим предсказуемый, автоматизируемый процесс: ревью PR, генерация тестов, реализация функции по спецификации и т. д.

Структура frontmatter

description — краткая цель сценария.
mode — ask (Q&A, без редактирования файлов) · edit (локальное редактирование открытых файлов) · agent (многошаговый процесс с инструментами).
model — желаемый профиль модели.
tools — список допустимых инструментов для сценария (ограничивает даже то, что разрешил режим чата).

Алгоритм выполнения (последовательность)

Где запускать:

В чате: введите /prompt-name и аргументы в поле сообщения.
В CLI: вызовите copilot и передайте строку /prompt-name … (интерактивно или через heredoc / флаг -p).

Сбор контекста: Copilot строит контекст выполнения в следующем порядке:
repo-instructions → path-instructions (applyTo) → chat mode → frontmatter prompt (frontmatter промпта имеет наивысший приоритет и может сузить инструменты/сменить модель).
Парсинг параметров (где и как):
- В чате: параметры идут в том же сообщении после имени, например: /security-review prNumber=123 target=apps/web.
- В CLI: параметры идут в той же строке /… в stdin или после флага -p.
- Внутри файла промпта они доступны как ${input:name}. Если обязательный параметр отсутствует, промпт может попросить его текстом в диалоге.
Разрешение прав на инструменты:

Эффективный список допустимых инструментов: инструменты режима чата, ограниченные инструментами промпта и флагами CLI --allow/--deny.
Если инструмент запрещён, соответствующий шаг пропускается или требует подтверждения / изменения политики.

Выполнение шагов из тела промпта: агент строго следует порядку шагов, выполняя только то, что разрешено политиками/инструментами (поиск в кодовой базе, генерация diff, запуск тестов и т. д.). Для потенциально рискованных действий он запрашивает подтверждение.
Validation gates: в конце промпт запускает проверки (build/tests/lint/typecheck, проверки формата вывода). Если проверка не пройдена — агент возвращает список проблем и предлагает дальнейшие шаги (без автомерже/записи изменений).
Где появляется результат (что и где видно):

Основной ответ — в панели чата (IDE) или в stdout (CLI): таблицы, списки, текстовые отчёты, блоки кода с diff.
Изменения файлов — в вашем рабочем дереве: в IDE видны diff/предложенные патчи; в CLI файлы изменяются локально (если разрешено инструментами).
Дополнительные артефакты — например, комментарий к PR, если инструменты GitHub разрешены и промпт это указывает.

Формат вывода и проверки (рекомендации)

Всегда указывайте формат вывода (например, таблица «issue | file | line | severity | fix»).
Добавляйте validation gates: build/tests/lint/typecheck; требуйте unified-diff для предложенных изменений; список TODO для нерешённых вопросов.

Пример полного файла промпта

---
mode: 'agent'
model: GPT-4o
tools: ['search/codebase']
description: 'Implement a feature from a spec'
---
Goal: Implement the feature described in @docs/feature.spec.md.

Steps:
1) Read @docs/feature.spec.md and produce a short implementation plan (bullets)
2) List files to add/modify with paths
3) Propose code patches as unified diff; ask before installing new deps
4) Generate minimal tests and run them (report results)

Validation gates:
- Build, tests, lint/typecheck must pass
- Output includes the final diff and a TODO list for anything deferred
- If any gate fails, return a remediation plan instead of "done"

Антипаттерны

Размытые описания: держите description в 1–2 строках.
Отсутствующий формат вывода.
Слишком много инструментов: разрешайте только необходимые (tools).

Быстрый старт

Чат: /implement-from-spec
CLI: copilot <<<'/implement-from-spec' или copilot -p "Run /implement-from-spec"

3.5. Контекстные файлы — specs/context/memory

Что это: Вспомогательные Markdown-файлы (не специальные типы), которые вы упоминаете через @ в диалоге/промпте. Обычно хранятся как документация.

docs/*.spec.md — точные постановки задач (цель, критерии приёмки, крайние случаи, не-цели).
docs/*.context.md — короткие справки (политики API, безопасность, UI styleguide, SLA).
docs/*.memory.md — «журнал решений» с датами и обоснованиями, чтобы агент не возвращался к давным-давно решённым вопросам.

Пример:

# Feature: Export report to CSV
Goal: Users can export the filtered table to CSV.
Acceptance criteria:
- "Export CSV" button on /reports
- Server generates file ≤ 5s for 10k rows
- Column order/headers match UI; locale-independent values
Edge cases: empty values, large numbers, special characters
Non-goals: XLSX, multi-column simultaneous filters

3.6. MCP — `.vscode/mcp.json`

Что это: Конфигурация серверов Model Context Protocol (например, GitHub MCP), которые предоставляют инструменты агенту.

Зачем: Чтобы агент мог читать PR/issues, запускать тесты, взаимодействовать с БД/браузером — в рамках допустимых прав.

Пример:

{
  "servers": {
    "github-mcp": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    }
  }
}

Безопасность. Подключайте только доверенные серверы; используйте списки allow/deny инструментов в промптах/режимах чата/CLI.

3.7. Общий порядок объединения контекста и приоритеты (правила & инструменты)

Instructions: copilot-instructions + все *.instructions.md с applyTo, совпадающим с текущими путями. Конкретная инструкция добавляется к общему контексту.
Режим чата: ограничивает набор инструментов и (при необходимости) модель для сессии.
Frontmatter промпта: имеет наивысший приоритет; может ограничить инструменты и переопределить модель.
Контекст: всё, что упоминаете через @, гарантированно учитывается моделью.

Диагностика. Проверьте раздел References в выводах — в нём указаны, какие файлы инструкций были приняты во внимание и какой промпт был запущен.

3.8. Пример: полный цикл i18n с Goman MCP (создание/обновление/удаление)

Ниже — точный процесс и шаблоны для обеспечения следующего: (а) при создании UI-компонентов ключи локализации создаются/обновляются в Goman; (б) при удалении компонентов неиспользуемые записи обнаруживаются и (после подтверждения) удаляются.

Фрагменты кода и frontmatter — на английском языке.

3.8.1. Конфигурация MCP — подключение Goman

/.vscode/mcp.json

{
  "servers": {
    "goman-mcp": {
      "type": "http",
      "url": "https://mcp.goman.live/mcp",
      "headers": {
        "apiKey": "<YOUR_API_KEY>",
        "applicationid": "<YOUR_APPLICATION_ID>"
      }
    }
  }
}

3.8.2. Repo/Path правила — принуждение к i18n по умолчанию

/.github/instructions/frontend.instructions.md (дополнение)

---
applyTo: "apps/web/**/*.{ts,tsx}"
---
- All user-facing strings **must** use i18n keys (no hardcoded text in JSX/TSX)
- Key naming: `<ui_component_area>.<n>` (e.g., `ui_button_primary.label`)
- When creating components, run `/i18n-component-scaffold` and commit both code and created keys
- When deleting components, run `/i18n-prune` and confirm removal of unused keys

3.8.3. Режим чата — ограниченные i18n-инструменты

/.github/chatmodes/i18n.chatmode.md

---
description: "i18n - manage localization keys via Goman MCP; enforce no hardcoded strings"
model: GPT-4o
tools:
  - "files"
  - "goman-mcp:*"
---
In this mode, prefer:
- Creating/updating keys in Goman before writing code
- Checking for existing keys and reusing them
- Producing a table of changes (created/updated/skipped)

3.8.4. Промпт — scaffolding компонента + ключей в Goman

/.github/prompts/i18n-component-scaffold.prompt.md

---
mode: 'agent'
model: GPT-4o
tools: ['files','goman-mcp:*']
description: 'Scaffold a React component with i18n keys synced to Goman'
---
Inputs: componentName, namespace (e.g., `ui.button`), path (e.g., `apps/web/src/components`)

Goal: Create a React component and ensure all user-visible strings use i18n keys stored in Goman.

Steps:
1) Plan the component structure and list all user-visible strings
2) For each string, propose a key under `${namespace}`; reuse if it exists
3) Using Goman MCP, create/update translations for languages: en, be, ru (values may be placeholders)
4) Generate the component using `t('<key>')` and export it; add a basic test
5) Output a Markdown table: key | en | be | ru | action(created/updated/reused)

Validation gates:
- No hardcoded literals in the produced .tsx
- Confirm Goman actions succeeded (report tool responses)
- Tests and typecheck pass

Пример кода компонента:

import { t } from '@/i18n';
import React from 'react';

type Props = { onClick?: () => void };

export function PrimaryButton({ onClick }: Props) {
  return (
    <button aria-label={t('ui.button.primary.aria')} onClick={onClick}>
      {t('ui.button.primary.label')}
    </button>
  );
}

3.8.5. Промпт — удаление неиспользуемых ключей при удалении компонентов

/.github/prompts/i18n-prune.prompt.md

---
mode: 'agent'
model: GPT-4o
tools: ['files','goman-mcp:*']
description: 'Find and prune unused localization keys in Goman after code deletions'
---
Inputs: pathOrDiff (e.g., a deleted component path or a PR number)

Goal: Detect keys that are no longer referenced in the codebase and remove them from Goman after confirmation.

Steps:
1) Compute the set of removed/renamed UI elements (scan git diff or provided paths)
2) Infer candidate keys by namespace (e.g., `ui.<component>.*`) and check code references
3) For keys with **zero** references, ask for confirmation and delete them via Goman MCP
4) Produce a Markdown table: key | status(kept/deleted) | reason | notes

Validation gates:
- Never delete keys that still have references
- Require explicit confirmation before deletion
- Provide a rollback list of deleted keys

3.8.6. Промпт — синхронизация и проверка отсутствующих переводов (опционально)

/.github/prompts/i18n-sync.prompt.md

---
mode: 'agent'
model: GPT-4o
tools: ['files','goman-mcp:*']
description: 'Sync new/changed i18n keys and check for missing translations'
---
Goal: Compare code references vs Goman and fill gaps.

Steps:
1) Scan code for `t('...')` keys under provided namespaces
2) For missing keys in Goman - create them (placeholder text ok)
3) For missing languages - create placeholders and report coverage
4) Output coverage table: key | en | be | de | missing

4) Как использовать (IDE и CLI)

4.1. В VS Code / другом IDE

Откройте Copilot Chat — выберите Agent/Edit/Ask в выпадающем списке.
Для файлов промптов просто введите /file-name без расширения (например, /security-review).
Добавляйте контекст через @-упоминания файлов и директорий.
Переключайте режим чата (Plan/Frontend/DBA) при смене типа задачи.

4.2. В Copilot CLI (терминал)

Пример установки: npm install -g @github/copilot → запустить copilot.
Интерактивно: «Run /implement-from-spec on @docs/feature.spec.md».
Программно / в CI: copilot -p "Implement feature from @docs/feature.spec.md" --deny-tool shell("rm*").
Добавляйте / ограничивайте инструменты через флаги: --allow-all-tools, --allow-tool, --deny-tool (глобально или по паттерну, например shell(npm run test:*)).

4.3. Рецептуры команд для CLI (режимы чата и промпты)

Ниже готовые рецепты. Все команды должны запускаться из корня репозитория и уважать ваши deny/allow-списки.

A. Запуск файла промпта в интерактивной сессии

copilot
# внутри сессии (введите строку как есть)
/security-review prNumber=123

B. Запуск файла промпта в неинтерактивном режиме (heredoc)

copilot <<'EOF'
/security-review prNumber=123
EOF

C. Передача параметров в файл промпта

copilot <<'EOF'
/implement-from-spec path=@docs/feature.spec.md target=apps/web
EOF

Внутри промпта значения можно читать как ${input:target} и ${input:path}.

D. Запуск промпта с безопасными правами на инструменты

copilot --allow-tool "shell(npm run test:*)" \
        --deny-tool  "shell(rm*)" \
        <<'EOF'
/security-review prNumber=123
EOF

E. Использование режима чата (специализированный режим) в CLI

copilot
# внутри сессии — просите переключиться на нужный режим и запустить промпт
Use the i18n chat mode.
/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components

Если ваш клиент поддерживает выбор режима через меню — выберите i18n перед запуском промпта. Если нет — укажите ограничения в frontmatter промпта (tools и правила в теле промпта).

F. Передача ссылок на файлы/diff в качестве контекста

copilot <<'EOF'
Please review these changes:
@apps/web/src/components/PrimaryButton.tsx
@docs/feature.spec.md
/security-review prNumber=123
EOF

G. Смена модели для конкретного запуска

Мы рекомендуем указывать модель в frontmatter промпта. Если поддержано, вы также можете передать флаг модели во время выполнения:

copilot --model GPT-4o <<'EOF'
/implement-from-spec
EOF

H. Цикл i18n с Goman MCP (ЧАТ)

Запускайте последовательно в одной ветке чата:

/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components
/i18n-prune pathOrDiff=@last-diff
/i18n-sync namespace=ui.button

Что вы получаете:

итоговые таблицы/отчёты в панели чата;
изменения кода в вашем рабочем дереве (IDE показывает diff);
запускать команды CLI для Goman MCP здесь не требуется.

5) Инженерия контекста: как не «забить» лишним контекстом

Разделяйте сессии по фазам: План → Реализация → Ревью/Тесты. У каждой фазы свой Chat Mode.
Присоединяйте только необходимые инструкции: используйте path-specific *.instructions.md вместо того, чтобы загружать всё.
Память проекта: записывайте короткие ADR в project.memory.md — это снижает «забывание» агентом между задачами.
Контекстные помощники: частые справки (API/безопасность/UI) храните в *.context.md и ссылайтесь на них из файлов промптов.
Фокус на задаче: в файлах промптов всегда указывайте цель, шаги и формат вывода (таблица, diff, checklist).

6) Безопасность и управление инструментами

Требуйте явного подтверждения перед запуском команд/инструментов. В CI используйте --deny-tool по умолчанию и добавляйте локальные allow-списки.
Паттерны прав: разрешайте только необходимое (shell(npm run test:*), playwright:*), запрещайте опасные паттерны (shell(rm*)).
Секреты: не кладите ключи в промпты и инструкции; используйте GitHub Environments или локальные менеджеры секретов и .env с .gitignore.
Любой MCP — только из доверенных источников; проверяйте код/конфигурацию перед подключением.
Проверки патчей: требуйте unified-diff и объяснения в файлах промптов — это упрощает ревью.

7) Рецепт CI/CD (необязательный пример)

Убедитесь, что «всё собирается»: запустите Copilot CLI в безопасном режиме для генерации комментария к PR.

# .github/workflows/ai-review.yml
name: AI Review (Copilot CLI)
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  ai_review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Install Copilot CLI
        run: npm install -g @github/copilot
      - name: Run security review prompt (no dangerous tools)
        env:
          PR: ${{ github.event.pull_request.number }}
        run: |
          copilot -p "Run /security-review with prNumber=${PR}" \
            --deny-tool shell("rm*") --deny-tool shell("curl*") \
            --allow-tool shell("npm run test:*") \
            --allow-tool "github:*" \
            > ai-review.txt || true
      - name: Comment PR with results
        if: always()
        run: |
          gh pr comment ${{ github.event.pull_request.number }} --body-file ai-review.txt

Совет: держите плотные deny/allow-списки; не давайте агенту «полную свободу» в CI.

8) Маленькие сценарии и полезные tips

От идеи до PR: /plan — обсудить план — /implement-from-spec → локальные тесты — PR — /security-review.
Техническое обслуживание: /refactor-slice для локальных улучшений без изменения поведения.
Тесты: /test-gen для новых модулей + ручные добавления для крайних случаев.
Постепенный ввод: начинайте с 1–2 файлов промптов и одного режима чата; расширяйте позже.

9) Проверки качества (validation gates)

В каждом файле промпта фиксируйте «что считается готовым»:

Формат вывода: таблица рисков, unified-diff, checklist.
Автоматические проверки: build, unit/integration тесты, lint/typecheck.
Ручная проверка: «OK to merge?» с обоснованием и остаточными рисками.

10) Антипаттерны и хаки

Антипаттерн: один огромный instructions.md. Предпочитайте несколько *.instructions.md с applyTo.
Антипаттерн: общие слова вместо правил. Предпочитайте конкретные команды/шаги.
Антипаттерн: запуск опасных shell-команд без проверки. Используйте deny/allow и ручное подтверждение.
Антипаттерн: забытые спецификации/память. Поддерживайте feature.spec.md и project.memory.md.
Антипаттерн: смешивание задач в одной сессии. Создавайте Chat Mode для каждой фазы.

11) Чек-лист реализации

Добавьте .github/copilot-instructions.md (как минимум 5–8 пунктов о build/tests/style).
Создайте 1–2 *.instructions.md с applyTo (frontend/backend или workflows).
Добавьте plan.chatmode.md и один промпт (например, implement-from-spec.prompt.md).
Создайте docs/feature.spec.md и docs/project.memory.md.
Подключите MCP (как минимум GitHub MCP) через .vscode/mcp.json.
Запустите воркфлоу в VS Code: /implement-from-spec — проверьте — PR.
(Опционально) Добавьте простое AI-ревью в CI через Copilot CLI с жёсткими deny/allow-списками.

12) Вопросы и ответы (FAQ)

Q: Как убедиться, что Copilot «видит» мои инструкции?
A: Проверьте summary/References в ответе; также держите правила короткими и конкретными.

Q: Можно ли передавать параметры динамически в файлы промптов?
A: Да, как правило через переменные-заполнители (вроде ${prNumber}) или просто через текстовый запрос при запуске /prompt в чате.

Q: Куда хранить секреты для MCP?
A: В GitHub Environments или локальных менеджерах секретов; не в .prompt.md/.instructions.md.

Q: Что выбрать: Chat Mode или Prompt File?
A: Chat Mode задаёт «рамку» (модель/инструменты/роль). Prompt File — «сценарий» внутри этой рамки.

13) Дальнейшие шаги

Добавьте второй промпт для вашего самого частого ручного процесса.
Сделайте project.memory.md обязательным после всех архитектурных решений.
Постепенно перемещайте коллективные знания в *.context.md и ссылайтесь на них из файлов промптов.

Приложение A — Шаблоны быстрого старта

Все ключи, пути и флаги соответствуют документации (28 октября 2025 г.).

/.github/copilot-instructions.md — правила для всего репозитория

# Repository coding standards
- Build: `npm ci && npm run build`
- Tests: `npm run test` (coverage ≥ 80%)
- Lint/Typecheck: `npm run lint && npm run typecheck`
- Commits: Conventional Commits; keep PRs small and focused
- Docs: update `CHANGELOG.md` in every release PR

/.github/instructions/frontend.instructions.md — инструкции для конкретных путей

---
applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
---
- React: function components and hooks
- State: Zustand; data fetching with TanStack Query
- Styling: Tailwind CSS; avoid inline styles except dynamic cases
- Testing: Vitest + Testing Library; avoid unstable snapshots

/.github/instructions/backend.instructions.md — инструкции для конкретных путей

---
applyTo: "services/api/**/*.{ts,js},packages/server/**/*.{ts,js}"
---
- HTTP: Fastify; version APIs under `/v{N}`
- DB access: Prisma; migrations via `prisma migrate`
- Security: schema validation (Zod), rate limits, audit logs
- Testing: integration tests via `vitest --config vitest.integration.ts`

/.github/instructions/actions.instructions.md — GitHub Actions

---
applyTo: ".github/workflows/**/*.yml"
---
- Keep jobs small; reuse via composite actions
- Cache: `actions/setup-node` + built-in cache for npm/pnpm
- Secrets: only through GitHub Environments; never hardcode

/.github/chatmodes/plan.chatmode.md — пользовательский режим чата

---
description: "Plan - analyze code/specs and propose a plan; read-only tools"
model: GPT-4o
tools:
  - "search/codebase"
---
In this mode:
- Produce a structured plan with risks and unknowns
- Do not edit files; output a concise task list instead

/.github/prompts/security-review.prompt.md — файл промпта

---
mode: 'agent'
model: GPT-4o
tools: ['search/codebase']
description: 'Perform a security review of a pull request'
---
Goal: Review PR ${input:prNumber} for common security issues.

Checklist:
- Authentication/authorization coverage
- Input validation and output encoding (XSS/SQLi)
- Secret management and configuration
- Dependency versions and known CVEs

Output:
- A Markdown table: issue | file | line | severity | fix
- If trivial, include a unified diff suggestion

/.github/prompts/implement-from-spec.prompt.md — файл промпта

---
mode: 'agent'
model: GPT-4o
tools: ['search/codebase']
description: 'Implement a feature from a spec'
---
Your task is to implement the feature described in @docs/feature.spec.md.

Steps:
1) Read @docs/feature.spec.md and summarize the plan
2) List files to add or modify
3) Propose code changes; ask before installing new dependencies
4) Generate minimal tests and run them

Validation gates:
- Build, tests, lint/typecheck must pass
- Provide a TODO list for anything deferred

/.github/prompts/refactor-slice.prompt.md — файл промпта

---
mode: 'agent'
model: GPT-4o
description: 'Refactor a specific code slice without changing behavior'
---
Goal: Improve readability and reduce side effects in @src/feature/* while keeping behavior unchanged.
Criteria: fewer side effects, clearer structure, all tests pass.

/.github/prompts/test-gen.prompt.md — файл промпта

---
mode: 'agent'
model: GPT-4o-mini
description: 'Generate tests for a given file/module'
---
Ask the user to @-mention the target file; generate unit/integration tests and edge cases.

/docs/feature.spec.md — шаблон спецификации

# Feature: Export report to CSV
Goal: Users can export the filtered table to CSV.
Acceptance criteria:
- "Export CSV" button on /reports
- Server generates file ≤ 5s for 10k rows
- Column order/headers match UI; locale-independent values
Edge cases: empty values, large numbers, special characters
Non-goals: XLSX, multi-column simultaneous filters

/.vscode/mcp.json — минимальная конфигурация MCP

{
  "servers": {
    "github-mcp": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    }
  }
}

Приложение B — Операционные дополнения (примеры CLI & CI)

Эти примеры дополняют Приложение A; они описывают использование в рамках выполнения / автоматизации и не дублируют шаблоны выше.

Copilot CLI — безопасные права на инструменты (интерактивный / CI)

# Запуск интерактивной сессии в вашем репозитории
copilot

# Разрешить/запретить конкретные инструменты (точные флаги согласно документации GitHub)
copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)"

# Запуск файла промпта в неинтерактивном режиме (пример)
copilot <<'EOF'
/security-review prNumber=123
EOF

GitHub Actions — комментирование результатов ревью в PR

name: AI Security Review (Copilot CLI)
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Install Copilot CLI
        run: npm install -g @github/copilot
      - name: Run security review prompt
        env:
          PR: ${{ github.event.pull_request.number }}
        run: |
          copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)" <<'EOF'
          /security-review prNumber=${PR}
          EOF
      - name: Post results
        run: |
          gh pr comment ${{ github.event.pull_request.number }} --body "Copilot review completed. See artifacts/logs for details."

14) Настройка контекста на существующем проекте

Этот раздел решает конкретную задачу: вы берёте уже живой проект и за один подход создаёте полноценный контекст и инструкции для GitHub Copilot. Ничего не выдумываем — всё берётся из того, что уже есть в коде.

Каждый шаг — это промпт, который запускается в VS Code в режиме Agent. Каждый следующий шаг зависит от результата предыдущего, поэтому порядок важен.

14.1. Шаг 1 — Аудит проекта

Цель: получить объективную карту проекта. Без неё всё дальнейшее — угадайка.

Что делаем: открываем Copilot Chat, выбираем режим Agent, подкепляем корневую папку через @, и запускаем:

@/

Проанализируй структуру этого проекта. Определи:

- стек: язык, фреймворки, менеджер пакетов
- команды сборки, тестирования, линтинга (точные, из package.json / pom.xml / Makefile и т.д.)
- существующие CI-воркфлоу (.github/workflows) — что там запускается
- основные папки и их назначение
- существующие конфигурации: lint, prettier, typescript, и подобные

Верни результат в виде структурированного списка.
Не домысливай — только то, что реально видно в файлах.

Результат: сохраняем ответ — он понадобится на шаге 2. Это «исходная карта», от неё зависит качество всего, что будет дальше.

14.2. Шаг 2 — Генерация глобальных инструкций

Цель: создать .github/copilot-instructions.md — единый источник правил для всего репозитория.

Что делаем: берём результат шага 1 и запускаем:

На основе этого аудита проекта:

[вставляем результат шага 1]

Создай файл .github/copilot-instructions.md

Требования:
- только факты из аудита, ничего выдуманного
- команды сборки, тестирования, линтинга — точные, скопированные из конфигов
- стиль кода — только если есть prettier/eslint конфиг, и только то что там зафиксировано
- commit-policy — только если есть commitlint или аналог
- 8–12 пунктов максимум
- каждый пункт — одна конкретная строка

Результат: файл .github/copilot-instructions.md создан и зафиксирован в рабочем дереве.

14.3. Шаг 3 — Генерация path-specific инструкций

Цель: создать отдельные правила для разных областей кода, которые подключаются автоматически по паттерну пути.

Когда нужно: если в проекте есть хотя бы две логически отдельные области — frontend и backend, apps и packages, несколько сервисов. Если проект однородный — этот шаг пропускаем.

Что делаем: для каждой области подкепляем соответствующую папку и запускаем отдельный промпт. Пример для frontend:

@src/components/
@src/pages/

Проанализируй эту часть проекта и определи:

- какой фреймворк и как пишутся компоненты
- паттерны управления состоянием (если видны)
- как устроены тесты (если есть)
- стиль импортов и именования файлов

Создай файл .github/instructions/frontend.instructions.md

Требования:
- applyTo — точный glob, покрывающий именно эти папки
- правила — только из того, что видишь в коде
- не дублирует то, что уже есть в copilot-instructions.md
- не больше 6–8 пунктов

Аналогичный промпт для backend, если он есть, с соответствующими папками в @.

Результат: файлы в .github/instructions/ для каждой области.

14.4. Шаг 4 — Генерация справочника проекта

Цель: создать docs/project.context.md — стабильный справочник, который снижает «шум» в чатах и не требует обновления при каждом изменении.

Что делаем:

@/
@README.md
@package.json

Создай файл docs/project.context.md —
это справочник проекта для AI-ассистента.

Включай:
- краткое описание: что делает проект, для кого
- ключевые паттерны архитектуры, если они видны в структуре папок и импортах
- внешние зависимости и их роли (почему именно эти, если понятно из контекста)
- то, что НЕ нужно делать: deprecated папки, забитые паттерны, известные ограничения

Ограничения:
- максимум 30–40 строк
- только то, что объективно видно в проекте
- без предположений и рекомендаций

Результат: файл docs/project.context.md.

14.5. Шаг 5 — Генерация памяти проекта

Цель: зафиксировать решения, которые уже приняты, чтобы агент не возвращался к ним снова.

Что делаем:

@/

Посмотри на проект и найди решения, которые уже зафиксированы в коде:

- выбор библиотек — если видны obvious альтернативы в lock-файлах или комментариях
- структура папок — если она нестандартная для этого стека
- любые TODO или FIXME, у которых есть контекст почему
- конфигурации, у которых есть комментарии с обоснованием

Создай файл docs/project.memory.md в формате:

## [дата или «unknown»] | Решение | Почему

Каждая запись — максимум 2 строки.
Не больше 10–12 записей.
Только то, что реально видно.

Результат: файл docs/project.memory.md.

14.6. Шаг 6 — Первый промпт-файл

Цель: создать один рабочий промпт для самой частой задачи. Не нужно сразу все пять из шаблонов — начинаем с одного и добавляем по необходимости.

Когда какой промпт: если команда чаще реализует новые фичи — берём implement-from-spec. Если чаще ревьит PR — берём security-review. Выбираем то, что используется ежедневно.

Что делаем (пример для implement-from-spec):

@.github/copilot-instructions.md

Создай файл .github/prompts/implement-from-spec.prompt.md
для этого проекта.

Требования:
- mode: agent
- tools: только search/codebase
- шаги должны использовать команды сборки и тестирования
  из copilot-instructions.md
- validation gates: сборка, тесты, линт должны проходить
- description — одна строка

Результат: файл .github/prompts/implement-from-spec.prompt.md, адаптированный под конкретный стек проекта.

14.7. Итог и что делать дальше

После этих шести шагов в репозитории будет:

.github/
  copilot-instructions.md          ← глобальные правила (шаг 2)
  instructions/
    frontend.instructions.md       ← правила для frontend (шаг 3)
    backend.instructions.md        ← правила для backend (шаг 3)
  prompts/
    implement-from-spec.prompt.md  ← первый промпт (шаг 6)
docs/
  project.context.md               ← справочник проекта (шаг 4)
  project.memory.md                ← память решений (шаг 5)

Это минимально работающий набор. Дальше — итеративно:

добавляете промпт-файлы по мере того, как появляются новые типовые задачи
обновляете project.memory.md после каждого архитектурного решения
добавляете chat modes, когда начинаете замечать, что разные фазы работы мешают друг другу
подключаете MCP только после того, как базовый контекст работает

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

Источники

Пользовательские режимы чата в VS Code

Использование MCP-серверов в VS Code

Добавление пользовательских инструкций репозитория для GitHub Copilot

Как создать надёжные AI воркфлоу с агентными примитивами и инженерией контекста

PS:

Спасибо, что дочитали до конца! Если материал показался полезным, мы будем рады, если вы:

Технологии становятся доступнее, когда они понимаются. И вы уже сделали первый важный шаг

H1GH · February 4, 2026, 1:59am

A Powerful Article

Topic		Replies	Views
Как создать портал авторизации для своих доменов с помощью Caddy WEB технологии и их применение caddy , безопасность , auth-portal , security	0	143	August 11, 2025
Повышение безопасности VPS на Ubuntu и Debian: практическая памятка WEB технологии и их применение fail2ban , ufw , безопасность , ssh	0	681	August 11, 2025
Remnawave Managment Scripts by DigneZzZ GIG-скрипты remnanode , remnawave , caddy , selfsteal	55	4000	February 4, 2026
Страница подписки Remnawave Статьи RemnaWave	0	1286	July 8, 2025
Настройка безопасного Cloudflare Tunnel для Remnawave VPN через Docker Compose (без проброса портов) Статьи RemnaWave remnawave , cloudflare , docker , reverse-proxy , tunnel	0	648	June 8, 2025

Reliable AI workflow with GitHub Copilot: a full guide with examples

Надёжный AI воркфлоу с GitHub Copilot: полное руководство с примерами

1) Обзор: из чего состоит воркфлоу

2) Структура файлов проекта

3) Файлы и их назначение — техническое объяснение

3.1. Глобальные правила — .github/copilot-instructions.md

3.2. Инструкции для конкретных путей — .github/instructions/*.instructions.md

3.3. Режимы чата — .github/chatmodes/*.chatmode.md

3.4. Файлы промптов — .github/prompts/*.prompt.md

Структура frontmatter

Алгоритм выполнения (последовательность)

Формат вывода и проверки (рекомендации)

Пример полного файла промпта

Антипаттерны

Быстрый старт

3.5. Контекстные файлы — specs/context/memory

3.6. MCP — .vscode/mcp.json

3.7. Общий порядок объединения контекста и приоритеты (правила & инструменты)

3.8. Пример: полный цикл i18n с Goman MCP (создание/обновление/удаление)

3.8.1. Конфигурация MCP — подключение Goman

3.8.2. Repo/Path правила — принуждение к i18n по умолчанию

3.8.3. Режим чата — ограниченные i18n-инструменты

3.8.4. Промпт — scaffolding компонента + ключей в Goman

3.8.5. Промпт — удаление неиспользуемых ключей при удалении компонентов

3.8.6. Промпт — синхронизация и проверка отсутствующих переводов (опционально)

4) Как использовать (IDE и CLI)

4.1. В VS Code / другом IDE

4.2. В Copilot CLI (терминал)

4.3. Рецептуры команд для CLI (режимы чата и промпты)

5) Инженерия контекста: как не «забить» лишним контекстом

6) Безопасность и управление инструментами

7) Рецепт CI/CD (необязательный пример)

8) Маленькие сценарии и полезные tips

9) Проверки качества (validation gates)

10) Антипаттерны и хаки

11) Чек-лист реализации

12) Вопросы и ответы (FAQ)

13) Дальнейшие шаги

Приложение A — Шаблоны быстрого старта

Приложение B — Операционные дополнения (примеры CLI & CI)

Copilot CLI — безопасные права на инструменты (интерактивный / CI)

GitHub Actions — комментирование результатов ревью в PR

14) Настройка контекста на существующем проекте

14.1. Шаг 1 — Аудит проекта

14.2. Шаг 2 — Генерация глобальных инструкций

14.3. Шаг 3 — Генерация path-specific инструкций

14.4. Шаг 4 — Генерация справочника проекта

14.5. Шаг 5 — Генерация памяти проекта

14.6. Шаг 6 — Первый промпт-файл

14.7. Итог и что делать дальше

Источники

PS:

Related topics

3.1. Глобальные правила — `.github/copilot-instructions.md`

3.2. Инструкции для конкретных путей — `.github/instructions/*.instructions.md`

3.3. Режимы чата — `.github/chatmodes/*.chatmode.md`

3.4. Файлы промптов — `.github/prompts/*.prompt.md`

3.6. MCP — `.vscode/mcp.json`