Як заставіць Github Copilot працаваць або "Надзейны AI‑workflow з GitHub Copilot: поўны гайд з прыкладамі"

Copilot

Вітанкі! Сення невялікі гайд пра тое як наладзіць праект для працы з Github Copilot. Таксама не забудзьце азнаеміцца з папярэднімі артыкуламі:

Надзейны AI‑workflow з GitHub Copilot: поўны гайд з прыкладамі (2025)

Гэты гайд паказвае, як збудаваць прадказальныя і паўтаральныя AI‑працэсы (workflow) у вашым рэпазіторыі і IDE/CLI праз агентныя прымітывы (agentic primitives) і інжынерыю кантэксту (context engineering). Тут вы знойдзеце структуру файлаў, гатовыя шаблоны, правілы бяспекі і таксама каманды.

⚠️ Заўвага: функцыянал prompt‑файлаў і агентны рэжым у IDE/CLI можа змяняцца - прыстасоўвайце гайд да канкрэтнай версіі вашага Copilot і VS Code.

1) Абагульненне: з чаго складаецца workflow

Асноўная мэта - гэта раскласці працу агента на празрыстыя крокі і зрабіць іх кіраванымі. Для гэтага існуюць наступныя інструменты:

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.j son або праз UI) - інструменты і знешнія рэсурсы, якімі можа карыстацца агент.

2) Файлавая структура праекту

Наступная структура адпавядае разгледжаным вышэй інструментам і дапамагае скласці паўнавартасны workflow для працы агентаў.

text
1.github/
2  copilot-instructions.md
3  instructions/
4    backend.instructions.md
5    frontend.instructions.md
6    actions.instructions.md
7  prompts/
8    implement-from-spec.prompt.md
9    security-review.prompt.md
10    refactor-slice.prompt.md
11    test-gen.prompt.md
12  chatmodes/
13    plan.chatmode.md
14    frontend.chatmode.md
15.vscode/
16  mcp.json
17docs/
18  feature.spec.md
19  project.context.md
20  project.memory.md

3) Файлы і іх прызначэнні - тэхнічнае тлумачэнне

А зараз разгледзім асобна кожны з інтсрументаў і іх ролю. Ніжэй - «як гэта ўладкавана пад капотам»: што за файлы, навошта яны, як яны ўплываюць на разуменне задачы агентам, і ў якім парадку аб’ядноўваюцца (merge/override). Код‑прыклады прадстаўленыя далей адпавядаюць спецыфікацыі.

Файл/папка	Што гэта	Навошта	Дзе дзейнічае
`.github/copilot-instructions.md`	Глабальныя правілы праекта	Аднолькавыя стандарты для ўсіх адказаў	Увесь рэпазіторый
`.github/instructions/*.instructions.md`	Таргетаваныя інструкцыі для пэўных шляхоў	Розныя правілы для фронту/беку/CI	Толькі для файлаў, што трапляюць пад `applyTo`
`.github/chatmodes/*.chatmode.md`	Набор правіл + дазволеных інструментаў для рэжыму чату	Падзяляць фазы працы (план/рэфактар/DBA)	Калі выбраны гэты chat mode
`.github/prompts/*.prompt.md`	«Сцэнар» задач (workflow)	Паўторна запускаць тыпавыя працэсы	Калі запускаецца праз `/name` або CLI
`docs/*.spec.md`	Спецыфікацыі	Дакладная пастаноўка задачы	Калі вы іх @‑згадваеце ў дыялогу
`docs/*.context.md`	Сталыя даведкі	Скарочваць «шум» у чатах	Па спасылцы/@‑згадцы
`docs/*.memory.md`	Памяць праекта	Фіксаваць рашэнні, каб не паўтараць	Па спасылцы/@‑згадцы
`.vscode/mcp.json`	Канфіг MCP сервераў	Доступ да GitHub/інш. інструментаў	Для гэтага workspace

Парадак аб’яднання правіл і настроек: Prompt frontmatter → Chat mode → Repo/Path instructions → Defaults.

І так разгледзім зараз кожны інструмент паасобку.

3.1. Глабальныя правілы - `.github/copilot-instructions.md`

Што гэта: Markdown‑файл з кароткімі, правяраемымі правіламі: як збіраць, як тэставаць, стыль кода, палітыкі PR.

Навошта: Каб усе адказы апіраліся на адзіныя стандарты (без дублявання ў кожным prompt).

Як працуе: Файл аўтаматычна трапляе ў сістэмны кантэкст для ўсіх пытанняў у межах рэпазіторыя. Ніякіх applyTo (пра яго далей) - дзейнічае ўсюды.

Мінімальны прыклад:

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

Парады.

Кароткія пункты;
без агульных фраз;
толькі тое, што можа паўплываць на вынік (build/test/lint/type/PR policy).

3.2. Таргетаваныя інструкцыі - `.github/instructions/*.instructions.md`

Што гэта: Модульныя правілы з YAML‑frontmatter applyTo - glob‑шаблоны файлаў, для якіх яны ўключаюцца.

Навошта: Адрозніваць стандарты для розных зон (frontend/backend/CI). Дазваляе кіраваць кантэкстам у залежнасці ад тыпу задачы.

Як працуе: Пры апрацоўцы задачы Copilot шукае ўсе *.instructions.md, чые applyTo супадаюць з актуальным кантэкстам (файлы, якія вы абмяркоўваеце/рэдагуеце). Супадаючыя правілы дадаюцца да глабальных.

Прыклад:

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

Увага.

Не дубліруйце тое, што ўжо ёсць у глабальных правілах;
правярайце, што glob сапраўды трапляе ў патрэбныя шляхі.

3.3. Chat modes - `.github/chatmodes/*.chatmode.md`

Што гэта: файлы‑канфігі, што задаюць аперацыйны рэжым агента для дыялогу: кароткае апісанне, мадэль (пры патрэбе) і спіс дазволеных інструментаў.

Навошта: каб аддзяліць фазы працы (планаванне/фронтэнд/DBA/бяспека) і абмежаваць інструменты у кожнай фазе. Так вынікі становяцца больш прадказальнымі.

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

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

Як працуе:

Дзеянне chat mode распаўсюджваецца на бягучы чат у IDE.
Калі актывуеце prompt‑файл, яго frontmatter мае прыярытэт над chat mode (можа змяніць мадэль і звузіць tools).
Фактычна дазволеныя інструменты : (tools chat mode) / (tools prompt) / (CLI‑флагі --allow/--deny).

Кіраванне і пераключэнне:

У IDE (VS Code):
1. Адкрыйце панэль Copilot Chat.
2. У верхняй панэлі абярыце патрэбны chat mode з выпадаючага спісу (спіс збіраецца з .github/chatmodes/*.chatmode.md + убудаваныя рэжымы).
3. Рэжым дзейнічае толькі для гэтага трэда. Каб змяніць - абярыце іншы або стварыце новы трэд з патрэбным рэжымам.
4. Праверыць актыўны рэжым можна ў загалоўку/панэлі размовы і ў References (файл *.chatmode.md будзе пазначаны).
У CLI: *(неяк кастыльна, лепш праз промпты) *
- Пераключальніка рэжыму як флага звычайна няма; энкодзьце патрэбныя абмежаванні ў frontmatter prompt‑файла і/або праз флагі --allow-tool/--deny-tool.
- Можна даць інструкцыю ў першым радку: “Use the i18n chat mode.” - калі версія падтрымлівае, агент пераключыцца; калі не, frontmatter prompt усё роўна зафіксуе інструменты.
Без пераключэння рэжыму: запускайце prompt з патрэбным tools: у frontmatter - ён абмяжуе інструменты незалежна ад рэжыму чату.

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

3.4. Prompt files - `.github/prompts/*.prompt.md`

Што гэта: Файлы‑сцэнары для паўторных задач. Складаюцца з YAML‑frontmatter (канфіг) і цела (інструкцыі/крокі/критэрыі прыёмкі). Запускаюцца ў чаце як /name або праз CLI.

Калі выкарыстоўваць. Калі трэба зрабіць працэс прадказальным і аўтаматызаваным: агляд PR, генерацыя тэстаў, рэалізацыя фіч па спецыфікацыі і г.д.

Структура frontmatter

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

Алгарытм выканання (паслядоўнасць)

Дзе запускаем:
- У чаце: у полі паведамлення ўводзіце /імя‑prompt і аргументы.
- У CLI: выклікаеце copilot і перадаеце радок з /імя‑prompt … (інтэрактыўна або праз heredoc / флаг -p).
Збор кантэксту: Copilot будуе схему выканання ў такім парадку: repo‑instructions → path‑instructions (applyTo) → chat mode → frontmatter prompt (мае найвышэйшы прыярытэт і можа звузіць інструменты/змяніць мадэль).
Парсінг параметраў (дзе і як):
- У чаце: параметры ідуць у тым жа паведамленні пасля назвы, напрыклад: /security-review prNumber=123 target=apps/web.
- У CLI: параметры ідуць у тым жа радку /… у stdin або пасля флага -p.
- Унутры prompt‑файла яны даступныя як ${input:імя}. Калі патрэбнага параметра няма - prompt можа запытаць яго тэкстава ў дыялогу.
Вырашэнне дазволаў інструментаў:
- Фактычна дазволеныя інструменты : (chat mode tools) / (prompt tools) /(CLI‑флагі --allow/--deny).
- Калі інструмент забаронены, адпаведны крок пропускаецца або патрабуе пацвярджэння/змены палітык.
Выканаўчыя крокі з цела prompt: агент ідзе строга па парадку Steps, робячы толькі тое, што дазволена палітыкамі/інструментамі (пошук у кодзе, генерацыя diff, запуск тэстаў і г.д.). Для патэнцыйна рызыковых дзеянняў просіцца пацвярджэнне.
Validation gates: у канцы prompt запускае праверкі (build/tests/lint/typecheck, праверка фармату выхаду). Калі gate не пройдзены - вяртаецца спіс праблем і прапанова наступных крокаў (без аўта‑мерджа/запісаў).
Дзе з'яўляецца вынік (што і дзе бачым):
- Асноўны адказ - у панэлі чату (IDE) або ў stdout (CLI): табліцы, спісы, тэкставыя справаздачы, code blocks з diff.
- Змены ў файлах - у вашым working tree: у IDE бачыце diff/тыповыя прапанаваныя патчы; у CLI - файлы змяняюцца лакальна (калі гэта дазволена інструментамі).
- Дадатковыя артыфакты - напрыклад, каментар у PR, калі дазволены інструменты GitHub і так прапісана ў prompt.

Выніковы фармат і праверкі (рэкамендавана)

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

Прыклад поўнага prompt‑файла

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implement a feature from a spec'
6---
7Goal: Implement the feature described in @docs/feature.spec.md.
8
9Steps:
101) Read @docs/feature.spec.md and produce a short implementation plan (bullets)
112) List files to add/modify with paths
123) Propose code patches as unified diff; ask before installing new deps
134) Generate minimal tests and run them (report results)
14
15Validation gates:
16- Build, tests, lint/typecheck must pass
17- Output includes the final diff and a TODO list for anything deferred
18- 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 "Запусці /implement-from-spec"

3.5. Кантэкст‑файлы - specs/context/memory

Што гэта: Дапаможныя Markdown‑файлы (не спецыяльныя тыпы), якія вы @‑згадваеце ў дыялогу/прампце. Звычайна размешчаны як дакументацыя.

docs/*.spec.md - дакладная пастаноўка (goal, acceptance, edge cases, non‑goals).
docs/*.context.md - кароткія даведкі (API policies, security, UI styleguide, SLA).
docs/*.memory.md - «журнал рашэнняў» з датамі і прычынамі, каб agent не вяртаўся да старых спрэчак.

Прыклад:

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

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

Што гэта: Канфігурацыя Model Context Protocol сервераў (напрыклад, GitHub MCP), якія адкрываюць інструменты для агента. Мы разглядалі гэта раней у артыкуле Ствараем свой першы MCP-сервер

Навошта: Каб агент мог чытаць PR/issues, запускаць тэсты, працаваць з БД/браузерам - у межах дазволаў.

Прыклад:

json
1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Бяспека. Падлучайце толькі давераныя серверы; выкарыстоўвайце allow/deny‑спісы інструментаў у prompt/chat mode/CLI.

3.7. Агульны парадак аб’яднання кантэксту і прыярытэтаў (rules & tools)

Instructions: copilot-instructions + усе *.instructions.md з applyTo, якія супалі з актуальнымі шляхамі. Канкрэтная інструкцыя дадаецца да агульнага кантэксту.
Chat mode: абмяжоўвае набор інструментаў і (пры патрэбе) мадэль для сесіі.
Prompt frontmatter: мае найвышэйшы прыярытэт; можа абмежаваць інструменты і перазапісаць мадэль.
Кантэкст: тое, што вы @‑згадаеце, гарантавана трапіць ва ўвагу мадэлі.

Дыягностыка. Правярайце ў выдачы раздзел References - там бачна, якія файлы інструкцый былі ўлічаныя і які prompt быў запушчаны.

3.8. Прыклад - поўны i18n‑цыкл з Goman MCP (стварэнне/абнаўленне/ачыстка)

Ніжэй - дакладны працэс і шаблоны, як гарантаваць: (а) пры стварэнні UI‑кампанентаў ключы лакалізацыі ствараюцца/абнаўляюцца ў Goman; (б) пры выдаленні кампанентаў - выяўляюцца і (пасля пацвярджэння) выдаляюцца непатрэбныя запісы.

Код‑фрагменты і frontmatter - англійскай, па дыяпазоне дакументацыі.

3.8.1. MCP канфіг - падключаем Goman

/.vscode/mcp.json

json
1{
2  "servers": {
3    "goman-mcp": {
4      "type": "http",
5      "url": "https://mcp.goman.live/mcp",
6      "headers": {
7        "apiKey": "<YOUR_API_KEY>",
8        "applicationid": "<YOUR_APPLICATION_ID>"
9      }
10    }
11  }
12}

3.8.2. Repo/Path‑правілы - прымушаем i18n па змаўчанні

/.github/instructions/frontend.instructions.md (дапаўненне)

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

3.8.3. Chat mode - абмежаваны набор інструментаў i18n

/.github/chatmodes/i18n.chatmode.md

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

3.8.4. Prompt - стварэнне кампанента + ключы ў Goman

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

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Scaffold a React component with i18n keys synced to Goman'
6---
7Inputs: componentName, namespace (e.g., `ui.button`), path (e.g., `apps/web/src/components`)
8
9Goal: Create a React component and ensure all user‑visible strings use i18n keys stored in Goman.
10
11Steps:
121) Plan the component structure and list all user‑visible strings
132) For each string, propose a key under `${namespace}`; reuse if it exists
143) Using Goman MCP, create/update translations for languages: en, be, ru (values may be placeholders)
154) Generate the component using `t('<key>')` and export it; add a basic test
165) Output a Markdown table: key | en | be | ru | action(created/updated/reused)
17
18Validation gates:
19- No hardcoded literals in the produced .tsx
20- Confirm Goman actions succeeded (report tool responses)
21- Tests and typecheck pass

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

tsx
1import { t } from '@/i18n';
2import React from 'react';
3
4type Props = { onClick?: () => void };
5
6export function PrimaryButton({ onClick }: Props) {
7  return (
8    <button aria-label={t('ui.button.primary.aria')} onClick={onClick}>
9      {t('ui.button.primary.label')}
10    </button>
11  );
12}

3.8.5. Prompt - ачысціць непатрэбныя ключы пры выдаленні

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

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Find and prune unused localization keys in Goman after code deletions'
6---
7Inputs: pathOrDiff (e.g., a deleted component path or a PR number)
8
9Goal: Detect keys that are no longer referenced in the codebase and remove them from Goman after confirmation.
10
11Steps:
121) Compute the set of removed/renamed UI elements (scan git diff or provided paths)
132) Infer candidate keys by namespace (e.g., `ui.<component>.*`) and check code references
143) For keys with **zero** references, ask for confirmation and delete them via Goman MCP
154) Produce a Markdown table: key | status(kept/deleted) | reason | notes
16
17Validation gates:
18- Never delete keys that still have references
19- Require explicit confirmation before deletion
20- Provide a rollback list of deleted keys

3.8.6. Prompt - сінхранізацыя і праверка прапушчаных лакалізацый (апцыянальна)

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

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Sync new/changed i18n keys and check for missing translations'
6---
7Goal: Compare code references vs Goman and fill gaps.
8
9Steps:
101) Scan code for `t('...')` keys under provided namespaces
112) For missing keys in Goman - create them (placeholder text ok)
123) For missing languages - create placeholders and report coverage
134) Output coverage table: key | en | be | de | missing

4) Як гэтым карыстацца (IDE і CLI)

4.1. У VS Code / іншай IDE

Адкрыйце Copilot Chat - выберыце Agent/Edit/Ask у выпадаючым меню.
Для prompt‑файлаў проста набярыце /назва‑файла без пашырэння (напр. /security-review).
Дадавайце кантэкст з дапамогай @‑згадвання файлаў і каталогаў.
Пераключайце chat mode (Plan/Frontend/DBA), калі задача змянілася.

4.2. У Copilot CLI (тэрмінал)

Усталёўка (прыклад): npm install -g @github/copilot → запусціце copilot.
Інтэрактыўна: «Запусці /implement-from-spec па @docs/feature.spec.md».
Праграмна/у CI: copilot -p "Рэалізуй фічу з @docs/feature.spec.md" --deny-tool shell("rm *").
Дадайце/абмяжуйце інструменты флагамі: --allow-all-tools, --allow-tool, --deny-tool (глабальныя або па шаблонах, напр. shell(npm run test:*)).

4.3. Cookbook каманд для CLI (chat modes і prompts)

Ніжэй - гатовыя рэцэпты. Усе каманды выконваюцца ў карані праекта і падтрымліваюць вашыя deny/allow‑спісы.

A. Запусціць prompt‑файл у інтэрактыўнай сесіі

bash
1copilot
2# унутры сесіі (радок уводзіцца як ёсць)
3/security-review prNumber=123

B. Запусціць prompt‑файл неінтэрактыўна (heredoc)

bash
1copilot <<'EOF'
2/security-review prNumber=123
3EOF

C. Перадаць параметры prompt‑файлу

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

Унутры prompt можна чытаць значэнні праз ${input:target} і ${input:path}.

D. Запусціць prompt з бяспечнымі дазволамі інструментаў

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

E. Выкарыстаць chat mode (спецыялізаваны рэжым) у CLI

bash
1copilot
2# унутры сесіі - папрасіце перайсці ў патрэбны рэжым і запусціце prompt
3Use the i18n chat mode.
4/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components

Калі ваш кліент падтрымлівае выбар рэжыму праз меню - абярыце i18n перад запускам prompt. Калі не - пазначайце абмежаванні ў самым prompt (frontmatter tools і правілы ў целе файла).

F. Адправіць спасылкі на файлы/дыфы як кантэкст

bash
1copilot <<'EOF'
2Please review these changes:
3@apps/web/src/components/PrimaryButton.tsx
4@docs/feature.spec.md
5/security-review prNumber=123
6EOF

G. Змяніць мадэль для канкрэтнага запуску

Рэкамендуем указваць мадэль у frontmatter prompt‑файла. Калі падтрымліваецца флаг, можна вызначыць мадэль пры запуску:

bash
1copilot --model GPT-4o <<'EOF'
2/implement-from-spec
3EOF

H. i18n‑цыкл з Goman MCP (CHAT)

У чат‑трэды запускайце паслядоўна:

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

Што атрымаеце:

выніковыя табліцы/справаздачы - у панэлі чату;
змяненні кода - у вашым working tree (IDE пакажа diff);
ніякіх CLI‑камандаў для Goman MCP тут не патрабуецца.

5) Інжынерыя кантэксту: як не «заліваць» лішняе

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

6) Бяспека і кіраванне інструментамі

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

7) CI/CD рэцэпт (апцыянальны прыклад)

Пацвярджанне, што «ўсё збіраецца»: запускаем Copilot CLI ў «сухім» рэжыме, каб атрымаць каментар да PR.

yaml
1# .github/workflows/ai-review.yml
2name: AI Review (Copilot CLI)
3on:
4  pull_request:
5    types: [opened, synchronize, reopened]
6
7jobs:
8  ai_review:
9    runs-on: ubuntu-latest
10    permissions:
11      contents: read
12      pull-requests: write
13    steps:
14      - uses: actions/checkout@v4
15      - uses: actions/setup-node@v4
16        with:
17          node-version: 22
18      - name: Install Copilot CLI
19        run: npm install -g @github/copilot
20      - name: Run security review prompt (no dangerous tools)
21        env:
22          PR: ${{ github.event.pull_request.number }}
23        run: |
24          copilot -p "Запусці /security-review з prNumber=${PR}" \
25            --deny-tool shell("rm*") --deny-tool shell("curl*") \
26            --allow-tool shell("npm run test:*") \
27            --allow-tool "github:*" \
28            > ai-review.txt || true
29      - name: Comment PR with results
30        if: always()
31        run: |
32          gh pr comment ${{ github.event.pull_request.number }} --body-file ai-review.txt

Парада: захоўвайце строгія deny/allow‑спісы; не давайце агенту «поўнай свабоды» ў CI.

8) невялікія сцэнары і парады якія могуць спатрэбіцца

З ідэі да PR: /plan - абмеркаванне плана - /implement-from-spec → лакальныя тэсты - PR - /security-review.
Падтрымка: /refactor-slice для лакальных паляпшэнняў без змен паводзінаў.
Тэсты: /test-gen на новыя модулі + ручное дапаўненне гранічных сцэнарыяў.
Паступовае ўвядзенне: пачынайце з 1–2 prompt‑файлаў і аднаго chat‑mode; далей пашырайце.

9) Праверкі якасці (validation gates)

У кожным prompt‑файле зафіксуйце «што лічыцца гатовым»:

Фармат выхаду: табліца рызыкаў, unified‑diff, чэк‑ліст.
Аўтаматычныя праверкі: build, unit/integration‑тэсты, lint/typecheck.
Мануальная праверка: «OK to merge?» з аргументацыяй і residual‑рызыкамі.

10) Анты‑патэрны і лайфхакі

Анты‑патэрн: адзін велізарны instructions.md. Лепш замяніце на некалькі *.instructions.md з applyTo.
Анты‑патэрн: агульныя словы замест правілаў. Лепш пішыце канкрэтныя каманды/крокі.
Анты‑патэрн: запуск небяспечных shell‑каманд без gate. Карыстайцеся deny/allow і ручным пацвярджэннем.
Анты‑патэрн: «забыліся» пра specs/memory. Вядзіце feature.spec.md і project.memory.md.
Анты‑патэрн: змешванне задач у адной сесіі. Пад кожную фазу стварайце свой Chat Mode.

11) Чэк‑ліст імплементацыі

Дадайце .github/copilot-instructions.md (мінімум 5–8 булшытаў пра зборку/тэсты/стыль).
Стварыце 1–2 *.instructions.md з applyTo (frontend/backend або workflows).
Дадайце plan.chatmode.md і адзін prompt (напрыклад, implement-from-spec.prompt.md).
Стварыце docs/feature.spec.md і docs/project.memory.md.
Уключыце MCP (GitHub MCP як мінімум) праз .vscode/mcp.json.
Запусціце workflow у VS Code: /implement-from-spec - праверка - PR.
(Апцыянальна) Дадайце просты AI‑агляд у CI праз Copilot CLI з жорсткім deny/allow‑спісам.

12) Пытанні і адказы (FAQ)

Q: Як пераканацца, што Copilot «бачыць» мае інструкцыі? A: У адказах глядзіце рэзюмэ/References; акрамя таго, трымайце правілы кароткімі і канкрэтнымі.

Q: Ці можна дынамічна перадаваць параметры ў prompt‑файл? A: Так, звычайна праз падстаўныя зменныя (кшталту ${prNumber}) або проста праз тэкст запыту пры запуску /prompt у чаце.

Q: Дзе лепш захоўваць сакрэты для MCP? A: У Environments GitHub або ў лакальных сакрэт‑менеджарах; не ў .prompt.md/.instructions.md.

Q: Што выбраць: Chat Mode vs Prompt File? A: Chat Mode задае «раму» (мадэль/інструменты/роля). Prompt File - «сцэнар» у гэтай раме.

13) Далейшыя крокі

Дадайце другі prompt для вашага найбольш частага «ручнога» працэсу.
Увядзіце project.memory.md як абавязковы пункт пасля ўсіх архітэктурных рашэнняў.
Паступова пераносьце калектыўныя веды ў *.context.md і спасылайцеся на іх з prompt‑файлаў.

Appendix A - Quickstart templates

All keys, paths, and flags match the docs (Oct 28, 2025).

/.github/copilot-instructions.md - repository-wide rules

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

/.github/instructions/frontend.instructions.md - path‑specific rules

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

/.github/instructions/backend.instructions.md - path‑specific rules

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

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

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

/.github/chatmodes/plan.chatmode.md - custom chat mode

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

/.github/prompts/security-review.prompt.md - prompt file

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Perform a security review of a pull request'
6---
7Goal: Review PR ${input:prNumber} for common security issues.
8
9Checklist:
10- Authentication/authorization coverage
11- Input validation and output encoding (XSS/SQLi)
12- Secret management and configuration
13- Dependency versions and known CVEs
14
15Output:
16- A Markdown table: issue | file | line | severity | fix
17- If trivial, include a unified diff suggestion

/.github/prompts/implement-from-spec.prompt.md - prompt file

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implement a feature from a spec'
6---
7Your task is to implement the feature described in @docs/feature.spec.md.
8
9Steps:
101) Read @docs/feature.spec.md and summarize the plan
112) List files to add or modify
123) Propose code changes; ask before installing new dependencies
134) Generate minimal tests and run them
14
15Validation gates:
16- Build, tests, lint/typecheck must pass
17- Provide a TODO list for anything deferred

/.github/prompts/refactor-slice.prompt.md - prompt file

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

/.github/prompts/test-gen.prompt.md - prompt file

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

/docs/feature.spec.md - spec skeleton

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

/.vscode/mcp.json - minimal MCP config

json
1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Appendix B - Operational extras (CLI & CI examples)

These examples complement Appendix A; they cover runtime/automation usage and do not duplicate templates above.

Copilot CLI - safe tool permissions (interactive/CI)

bash
1# Start an interactive session in your repo
2copilot
3
4# Allow/deny specific tools (exact flags per GitHub docs)
5copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)"
6
7# Run a prompt file non-interactively (example)
8copilot <<'EOF'
9/security-review prNumber=123
10EOF

GitHub Actions - comment review results on a PR

yaml
1name: AI Security Review (Copilot CLI)
2on:
3  pull_request:
4    types: [opened, synchronize, reopened]
5
6jobs:
7  review:
8    runs-on: ubuntu-latest
9    permissions:
10      contents: read
11      pull-requests: write
12    steps:
13      - uses: actions/checkout@v4
14      - uses: actions/setup-node@v4
15        with:
16          node-version: 22
17      - name: Install Copilot CLI
18        run: npm install -g @github/copilot
19      - name: Run security review prompt
20        env:
21          PR: ${{ github.event.pull_request.number }}
22        run: |
23          copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)" <<'EOF'
24          /security-review prNumber=${PR}
25          EOF
26      - name: Post results
27        run: |
28          gh pr comment ${{ github.event.pull_request.number }} --body "Copilot review completed. See artifacts/logs for details."

Крыніцы

Custom chat modes in VS Code

Use MCP servers in VS Code

Adding repository custom instructions for GitHub Copilot

How to build reliable AI workflows with agentic primitives and context engineering

🙌 PS:

Дзякуй, што дачытаў(-ла) да канца! Калі матэрыял быў карысны - будзем вельмі рады, калі:

💬 Напішаш каментар ці пытанне,
📨 Падкінеш ідэю для наступнага артыкула,
🚀 Або проста падзелішся з сябрамі!

Тэхналогіі становяцца бліжэй, калі іх разумець. І ты ўжо зрабіў(ла) першы важны крок 💪

Да сустрэчы ў наступным артыкуле! Дзякуй вам за падтрымку!

Admin, 2025-10-28

Каментары

Ваша імя

Ваш каментар

(Каб даслаць каментар залагуйцеся ў свой уліковы запіс)

Як заставіць Github Copilot працаваць або "Надзейны AI‑workflow з GitHub Copilot: поўны гайд з прыкладамі"

Надзейны AI‑workflow з GitHub Copilot: поўны гайд з прыкладамі (2025)

1) Абагульненне: з чаго складаецца workflow

2) Файлавая структура праекту

3) Файлы і іх прызначэнні - тэхнічнае тлумачэнне

3.1. Глабальныя правілы - .github/copilot-instructions.md

3.2. Таргетаваныя інструкцыі - .github/instructions/*.instructions.md

3.3. Chat modes - .github/chatmodes/*.chatmode.md

3.4. Prompt files - .github/prompts/*.prompt.md

Структура frontmatter

Алгарытм выканання (паслядоўнасць)

Выніковы фармат і праверкі (рэкамендавана)

Прыклад поўнага prompt‑файла

Анты‑патэрны

Хуткі запуск

3.5. Кантэкст‑файлы - specs/context/memory

3.6. MCP - .vscode/mcp.json

3.7. Агульны парадак аб’яднання кантэксту і прыярытэтаў (rules & tools)

3.8. Прыклад - поўны i18n‑цыкл з Goman MCP (стварэнне/абнаўленне/ачыстка)

3.8.1. MCP канфіг - падключаем Goman

3.8.2. Repo/Path‑правілы - прымушаем i18n па змаўчанні

3.8.3. Chat mode - абмежаваны набор інструментаў i18n

3.8.4. Prompt - стварэнне кампанента + ключы ў Goman

3.8.5. Prompt - ачысціць непатрэбныя ключы пры выдаленні

3.8.6. Prompt - сінхранізацыя і праверка прапушчаных лакалізацый (апцыянальна)

4) Як гэтым карыстацца (IDE і CLI)

4.1. У VS Code / іншай IDE

4.2. У Copilot CLI (тэрмінал)

4.3. Cookbook каманд для CLI (chat modes і prompts)

5) Інжынерыя кантэксту: як не «заліваць» лішняе

6) Бяспека і кіраванне інструментамі

7) CI/CD рэцэпт (апцыянальны прыклад)

8) невялікія сцэнары і парады якія могуць спатрэбіцца

9) Праверкі якасці (validation gates)

10) Анты‑патэрны і лайфхакі

11) Чэк‑ліст імплементацыі

12) Пытанні і адказы (FAQ)

13) Далейшыя крокі

Appendix A - Quickstart templates

Appendix B - Operational extras (CLI & CI examples)

Copilot CLI - safe tool permissions (interactive/CI)

GitHub Actions - comment review results on a PR

Крыніцы

🙌 PS:

Каментары

3.1. Глабальныя правілы - `.github/copilot-instructions.md`

3.2. Таргетаваныя інструкцыі - `.github/instructions/*.instructions.md`

3.3. Chat modes - `.github/chatmodes/*.chatmode.md`

3.4. Prompt files - `.github/prompts/*.prompt.md`

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