Вітанкі! Сення невялікі гайд пра тое як наладзіць праект для працы з 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 для працы агентаў.
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 (пра яго далей) - дзейнічае ўсюды.
Мінімальны прыклад:
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 супадаюць з актуальным кантэкстам (файлы, якія вы абмяркоўваеце/рэдагуеце). Супадаючыя правілы дадаюцца да глабальных.
Прыклад:
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/бяспека) і абмежаваць інструменты у кожнай фазе. Так вынікі становяцца больш прадказальнымі.
Структура файла:
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):
- Адкрыйце панэль Copilot Chat.
- У верхняй панэлі абярыце патрэбны chat mode з выпадаючага спісу (спіс збіраецца з
.github/chatmodes/*.chatmode.md + убудаваныя рэжымы).
- Рэжым дзейнічае толькі для гэтага трэда. Каб змяніць - абярыце іншы або стварыце новы трэд з патрэбным рэжымам.
- Праверыць актыўны рэжым можна ў загалоўку/панэлі размовы і ў 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‑файла
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 не вяртаўся да старых спрэчак.
Прыклад:
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, запускаць тэсты, працаваць з БД/браузерам - у межах дазволаў.
Прыклад:
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
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 (дапаўненне)
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
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
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
Прыклад кода кампанента:
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
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
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‑файл у інтэрактыўнай сесіі
1copilot
2# унутры сесіі (радок уводзіцца як ёсць)
3/security-review prNumber=123
B. Запусціць prompt‑файл неінтэрактыўна (heredoc)
1copilot <<'EOF'
2/security-review prNumber=123
3EOF
C. Перадаць параметры prompt‑файлу
1copilot <<'EOF'
2/implement-from-spec path=@docs/feature.spec.md target=apps/web
3EOF
Унутры prompt можна чытаць значэнні праз ${input:target} і ${input:path}.
D. Запусціць prompt з бяспечнымі дазволамі інструментаў
1copilot --allow-tool "shell(npm run test:*)" \
2 --deny-tool "shell(rm*)" \
3 <<'EOF'
4/security-review prNumber=123
5EOF
E. Выкарыстаць chat mode (спецыялізаваны рэжым) у CLI
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. Адправіць спасылкі на файлы/дыфы як кантэкст
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‑файла. Калі падтрымліваецца флаг, можна вызначыць мадэль пры запуску:
1copilot --model GPT-4o <<'EOF'
2/implement-from-spec
3EOF
H. i18n‑цыкл з Goman MCP (CHAT)
У чат‑трэды запускайце паслядоўна:
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.
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
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
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
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
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
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
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
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
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
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
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
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)
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
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:
Дзякуй, што дачытаў(-ла) да канца! Калі матэрыял быў карысны - будзем вельмі рады, калі:
- 💬 Напішаш каментар ці пытанне,
- 📨 Падкінеш ідэю для наступнага артыкула,
- 🚀 Або проста падзелішся з сябрамі!
Тэхналогіі становяцца бліжэй, калі іх разумець. І ты ўжо зрабіў(ла) першы важны крок 💪
Да сустрэчы ў наступным артыкуле! Дзякуй вам за падтрымку!
(1).jpg?alt=media&token=2e8646ef-c28b-4864-9701-41b079c0cd1a)
Прывітанне, спадарства!
(Нашчасце не гэтыя)
.webp?alt=media&token=79231241-a498-47fb-8d49-8bedb8866f13)
.png?alt=media&token=f39e05d6-776b-4815-82b2-a9e4bfd7efe2)
