​
Галоўная > Reliable AI workflow with GitHub Copilot: complete guide with examples

Reliable AI workflow with GitHub Copilot: complete guide with examples

AI
Copilot

Greetings! Today, I’m sharing a short guide on how to set up a project to work with GitHub Copilot.

Reliable AI workflow with GitHub Copilot: complete guide with examples (2025)

This guide shows how to build predictable and repeatable AI processes (workflows) in your repository and IDE/CLI using agentic primitives and context engineering. Here you will find the file structure, ready-made templates, security rules, and commands.

⚠️ Note: the functionality of prompt files and agent mode in IDE/CLI may change - adapt the guide to the specific versions of Copilot and VS Code you use.

1) Overview: what the workflow consists of

The main goal is to break the agent's work into transparent steps and make them controllable. For this there are the following tools:

  • Custom Instructions (.github/copilot-instructions.md) - global project rules (how to build, how to test, code style, PR policies).
  • Path-specific Instructions (.github/instructions/*.instructions.md) - domain rules targeted via applyTo (glob patterns).
  • Chat Modes (.github/chatmodes/*.chatmode.md) - specialized chat modes (for example, Plan/Frontend/DBA) with fixed tools and model.
  • Prompt Files (.github/prompts/*.prompt.md) - reusable scenarios/"programs" for typical tasks (reviews, refactoring, generation).
  • Context helpers (docs/*.spec.md, docs/*.context.md, docs/*.memory.md) - specifications, references, and project memory for precise context.
  • MCP servers (.vscode/mcp.json or via UI) - tools and external resources the agent can use.

2) Project file structure

The following structure corresponds to the tools described above and helps to compose a full workflow for agents.

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) Files and their purpose - technical explanation

Now let's review each tool separately and its role. Below is how it’s arranged under the hood: what these files are, why they exist, how they affect the agent's understanding of the task, and in what order they are merged/overridden. The code examples below match the specification.

File/folderWhat it isWhyWhere it applies
.github/copilot-instructions.mdGlobal project rulesConsistent standards for all responsesEntire repository
.github/instructions/*.instructions.mdTargeted instructions for specific pathsDifferent rules for frontend/backend/CIOnly for files matching the applyTo
.github/chatmodes/*.chatmode.mdA set of rules + allowed tools for a chat modeSeparate work phases (plan/refactor/DBA)When that chat mode is selected
.github/prompts/*.prompt.mdTask "scenarios" (workflow)Re-run typical processesWhen invoked via /name or CLI
docs/*.spec.mdSpecificationsPrecise problem statementsWhen you @-mention them in dialogue
docs/*.context.mdStable referencesReduce "noise" in chatsBy link/@-mention
docs/*.memory.mdProject memoryRecord decisions to avoid repeatsBy link/@-mention
.vscode/mcp.jsonMCP servers configurationAccess to GitHub/other toolsFor this workspace

Merge order of rules and settings: Prompt frontmatter → Chat mode → Repo/Path instructions → Defaults.

And now let's review each tool separately.

3.1. Global rules - .github/copilot-instructions.md

What it is: A Markdown file with short, verifiable rules: how to build, how to test, code style, and PR policies.

Why: So that all responses rely on a single set of standards (no duplication in each prompt).

How it works: The file automatically becomes part of the system context for all questions within the repository. No applyTo (more on that later) - it applies everywhere.

Minimal example:

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

Tips.

  1. Keep points short.
  2. Avoid generic phrases.
  3. Include only what can affect the outcome (build/test/lint/type/PR policy).

3.2. Path-specific instructions - .github/instructions/*.instructions.md

What it is: Modular rules with YAML frontmatter applyTo - glob patterns of files for which they are included.

Why: To differentiate standards for different areas (frontend/backend/CI). Allows controlling context based on the type of task.

How it works: When processing a task, Copilot finds all *.instructions.md whose applyTo matches the current context (files you are discussing/editing). Matching rules are added to the global ones.

Example:

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

Note.

  1. Avoid duplicating existing global rules.
  2. Ensure the glob actually targets the intended paths.

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

What it is: Config files that set the agent’s operational mode for a dialogue: a short description, the model (if needed) and a list of allowed tools.

Why: To separate work phases (planning/frontend/DBA/security) and restrict tools in each phase. This makes outcomes more predictable.

File structure:

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

How it works:

  • The chat mode applies to the current chat in the IDE.
  • If you activate a prompt file, its frontmatter takes precedence over the chat mode (it can change the model and narrow tools).
  • Effective allowed tools: chat mode tools, limited by prompt tools and CLI --allow/--deny flags.

Management and switching:

  • In the IDE (VS Code):

    1. Open the Copilot Chat panel.
    2. In the top bar, choose the desired chat mode from the dropdown (the list is built from .github/chatmodes/*.chatmode.md + built-in modes).
    3. The mode applies only to this thread. To change - select another or create a new thread with the desired mode.
    4. Check the active mode in the header/panel of the conversation; the References will show the *.chatmode.md file.

  • In the CLI: (a bit hacky, better via prompts)

    • There is usually no dedicated CLI flag to switch modes; encode desired constraints in the prompt file frontmatter and/or via --allow-tool/--deny-tool flags.
    • You can instruct in the first line: “Use the i18n chat mode.” - if the version supports it, the agent may switch; if not, the prompt frontmatter will still enforce tools.

  • Without switching the mode: run a prompt with the required tools: in frontmatter - it will limit tools regardless of chat mode.

Diagnostics: if the agent uses "extra" tools or does not see needed ones - check: (1) which chat mode is selected; (2) tools in the prompt frontmatter; (3) CLI --allow/--deny flags; (4) References in the response (visible *.chatmode.md/*.prompt.md files).

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

What it is: Scenario files for repeatable tasks. They consist of YAML frontmatter (config) and a body (instructions/steps/acceptance criteria). They are invoked in chat via /name or via CLI.

When to use: When you need a predictable, automatable process: PR review, test generation, implementing a feature from a spec, etc.

Frontmatter structure

  • description - short goal of the scenario.
  • mode - ask (Q&A, no file edits) · edit (local edits in open files) · agent (multistep process with tools).
  • model - desired model profile.
  • tools - list of allowed tools for the scenario (limits even what the chat mode allowed).

Execution algorithm (sequence)

  1. Where to run:

    • In chat: type /prompt-name and arguments in the message field.
    • In CLI: call copilot and pass the /prompt-name … line (interactive or via heredoc / -p flag).

  2. Context collection: Copilot builds the execution context in the following order: repo-instructions → path-instructions (applyTo) → chat mode → frontmatter prompt (the prompt frontmatter has the highest priority and can narrow tools/change the model).

  3. Parameter parsing (where and how):

    • In chat: parameters go in the same message after the name, for example: /security-review prNumber=123 target=apps/web.
    • In CLI: parameters go in the same /… line in stdin or after the -p flag.
    • Inside the prompt file they are available as ${input:name}. If a required parameter is missing, the prompt can ask for it textually in the dialog.

  4. Resolving tool permissions:

    • Effective allowed tools: chat mode tools, limited by prompt tools and CLI --allow/--deny flags.
    • If a tool is denied, the corresponding step is skipped or requires confirmation/change of policy.

  5. Executing steps from the prompt body: the agent strictly follows the Steps order, doing only what is permitted by policies/tools (searching the codebase, generating diffs, running tests, etc.). For potentially risky actions, it requests confirmation.

  6. Validation gates: at the end, the prompt runs checks (build/tests/lint/typecheck, output format checks). If a gate fails - the agent returns a list of issues and proposes next steps (without auto-merging/writing changes).

  7. Where the result appears (what and where you see it):

    • Main response - in the chat panel (IDE) or in stdout (CLI): tables, lists, textual reports, code blocks with diff.
    • File changes - in your working tree: in IDE you see a diff/suggested patches; in CLI files change locally (if allowed by tools).
    • Additional artifacts - e.g., a PR comment if GitHub tools are allowed and the prompt specifies it.

Output format and checks (recommended)

  • Always specify the output format (for example, table "issue | file | line | severity | fix").
  • Add validation gates: build/tests/lint/typecheck; require unified-diff for proposed changes; a TODO list for unresolved issues.

Example of a complete prompt file

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"

Anti-patterns

  • Watered-down descriptions: keep description 1–2 lines.
  • Missing output format.
  • Too many tools: allow only what is needed (tools).

Quick start

  • Chat: /implement-from-spec
  • CLI: copilot <<<'/implement-from-spec' or copilot -p "Run /implement-from-spec"

3.5. Context files - specs/context/memory

What it is: Helper Markdown files (not special types) that you @-mention in dialogue/prompt. Typically stored as documentation.

  • docs/*.spec.md - precise problem statements (goal, acceptance, edge cases, non-goals).
  • docs/*.context.md - short references (API policies, security, UI styleguide, SLA).
  • docs/*.memory.md - "decision log" with dates and reasons so the agent does not return to old disputes.

Example:

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

What it is: Configuration for Model Context Protocol servers (for example, GitHub MCP) which enable tools for the agent.

Why: So the agent can read PRs/issues, run tests, interact with DB/browser - within allowed permissions.

Example:

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

Security. Connect only trusted servers; use allow/deny tool lists in prompts/chat modes/CLI.

3.7. General context merge order and priorities (rules & tools)

  1. Instructions: copilot-instructions + all *.instructions.md with applyTo that match current paths. A specific instruction is added to the common context.
  2. Chat mode: restricts the toolset and (if needed) the model for the session.
  3. Prompt frontmatter: has the highest priority; can limit tools and override the model.
  4. Context: anything you @-mention is guaranteed to be considered by the model.

Diagnostics. Check the References section in outputs - it shows which instruction files were considered and which prompt was run.

3.8. Example: full i18n cycle with Goman MCP (create/update/prune)

Below is the exact process and templates on how to ensure: (a) when creating UI components localization keys are created/updated in Goman; (b) when removing components - unused entries are detected and (after confirmation) deleted.

Code snippets and frontmatter are in English.

3.8.1. MCP config - connect 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 rules - enforce i18n by default

/.github/instructions/frontend.instructions.md (addition)

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 - limited i18n tools

/.github/chatmodes/i18n.chatmode.md

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

3.8.4. Prompt - scaffold component + keys in 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

Example component code:

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 - prune unused keys when removing components

/.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 - sync and check missing translations (optional)

/.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) How to use this (IDE and CLI)

4.1. In VS Code / other IDE

  • Open Copilot Chat - choose Agent/Edit/Ask in the dropdown.
  • For prompt files just type /file-name without extension (e.g. /security-review).
  • Add context using @-mentions of files and directories.
  • Switch chat mode (Plan/Frontend/DBA) when the task changes.

4.2. In Copilot CLI (terminal)

  • Example install: npm install -g @github/copilot → run copilot.
  • Interactively: “Run /implement-from-spec on @docs/feature.spec.md”.
  • Programmatically/in CI: copilot -p "Implement feature from @docs/feature.spec.md" --deny-tool shell("rm*").
  • Add/restrict tools with flags: --allow-all-tools, --allow-tool, --deny-tool (global or by pattern, e.g. shell(npm run test:*)).

4.3. Cookbook commands for CLI (chat modes and prompts)

Below are ready recipes. All commands should run from the repository root and respect your deny/allow lists.

A. Run a prompt file in an interactive session

bash
1copilot
2# inside the session (enter the line as-is)
3/security-review prNumber=123

B. Run a prompt file non-interactively (heredoc)

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

C. Pass prompt file parameters

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

Inside the prompt you can read values as ${input:target} and ${input:path}.

D. Run a prompt with safe tool permissions

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

E. Use a chat mode (specialized mode) in the CLI

bash
1copilot
2# inside the session - ask to switch to the required mode and run the prompt
3Use the i18n chat mode.
4/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components

If your client supports selecting the mode via a menu - choose i18n before running the prompt. If not - specify constraints in the prompt frontmatter (tools and rules in the prompt body).

F. Send file links/diffs as context

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. Change the model for a specific run

We recommend specifying the model in the prompt frontmatter. If supported, you can also pass a model flag at runtime:

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

H. i18n cycle with Goman MCP (CHAT)

Run sequentially in a chat thread:

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

What you get:

  • resulting tables/reports in the chat panel;
  • code changes in your working tree (IDE shows diffs);
  • no CLI commands for Goman MCP are required here.

5) Context engineering: how not to "dump" excess context

  1. Split sessions by phases: Plan → Implementation → Review/Tests. Each phase has its own Chat Mode.
  2. Attach only necessary instructions: use path-specific *.instructions.md instead of dumping everything.
  3. Project memory: record short ADRs in project.memory.md - this reduces agent "forgetting" between tasks.
  4. Context helpers: keep frequent references (API/security/UI) in *.context.md and link to them from prompt files.
  5. Focus on the task: in prompt files always state the goal, steps and output format (table, diff, checklist).

6) Security and tool management

  • Require explicit confirmation before running commands/tools. In CI use --deny-tool by default and add local allow lists.
  • Permission patterns: allow only what is necessary (shell(npm run test:*), playwright:*), deny dangerous patterns (shell(rm*)).
  • Secrets: never put keys in prompts or instructions; use GitHub Environments or local secret managers and .env with .gitignore.
  • Any MCP - only from trusted origins; review the code/config before enabling.
  • Patch checks: require unified-diff and explanations in prompt files - this makes review easier.

7) CI/CD recipe (optional example)

Ensure "everything builds": run Copilot CLI in a dry/safe mode to produce a comment for the 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 "Run /security-review with 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

Tip: keep tight deny/allow lists; do not give the agent "full freedom" in CI.

8) Small scenarios and tips that might be useful

  • From idea to PR: /plan - discuss the plan - /implement-from-spec → local tests - PR - /security-review.
  • Maintenance: /refactor-slice for local improvements without behavior changes.
  • Tests: /test-gen for new modules + manual additions for edge cases.
  • Gradual rollout: start with 1–2 prompt files and one chat mode; expand later.

9) Quality checks (validation gates)

In each prompt file, fix "what counts as done":

  • Output format: risk table, unified-diff, checklist.
  • Automated checks: build, unit/integration tests, lint/typecheck.
  • Manual check: "OK to merge?" with rationale and residual risks.

10) Anti-patterns and hacks

  • Anti-pattern: one huge instructions.md. Prefer multiple *.instructions.md with applyTo.
  • Anti-pattern: generic words instead of rules. Prefer concrete commands/steps.
  • Anti-pattern: running dangerous shell commands without a gate. Use deny/allow and manual confirmation.
  • Anti-pattern: forgetting specs/memory. Maintain feature.spec.md and project.memory.md.
  • Anti-pattern: mixing tasks in one session. Create a Chat Mode per phase.

11) Implementation checklist

  1. Add .github/copilot-instructions.md (at least 5–8 bullets about build/tests/style).
  2. Create 1–2 *.instructions.md with applyTo (frontend/backend or workflows).
  3. Add plan.chatmode.md and one prompt (for example, implement-from-spec.prompt.md).
  4. Create docs/feature.spec.md and docs/project.memory.md.
  5. Include MCP (GitHub MCP at minimum) via .vscode/mcp.json.
  6. Run the workflow in VS Code: /implement-from-spec - verify - PR.
  7. (Optional) Add a simple AI review in CI via Copilot CLI with strict deny/allow lists.

12) Questions and answers (FAQ)

Q: How to ensure Copilot "sees" my instructions? A: Check the response's summary/References; also keep rules short and concrete.

Q: Can I pass parameters dynamically into prompt files? A: Yes, typically via placeholder variables (like ${prNumber}) or simply via the text query when running /prompt in chat.

Q: Where to store secrets for MCP? A: In GitHub Environments or local secret managers; not in .prompt.md/.instructions.md.

Q: Which to choose: Chat Mode vs Prompt File? A: Chat Mode defines the "frame" (model/tools/role). Prompt File is a "scenario" within that frame.

13) Next steps

  • Add a second prompt for your most frequent manual process.
  • Make project.memory.md mandatory after all architecture decisions.
  • Gradually move collective knowledge into *.context.md and reference it from prompt files.

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."

Sources

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:

Thank you for reading to the end! If the material was useful, we would be very glad if you:

  • 💬 Leave a comment or question,
  • 📨 Suggest an idea for the next article,
  • 🚀 Or simply share it with friends!

Technology becomes more accessible when it is understood. And you have already made the first important step 💪

See you in the next article! Thank you for your support!

Admin, 2025-10-29
Каментары

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