mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-11 02:35:55 +00:00
docs: update Learning Hub for CLI v1.0.10/v1.0.11 features (#1150)
- Add monorepo support section to copilot-configuration-basics: customizations discovered at every directory level up to git root - Add personal skills directory (~/.agents/skills/) documentation - Add /clear vs /new session command distinction + /undo command - Add MCP organization policy enforcement to understanding-mcp-servers - Add sessionStart additionalContext injection to automating-with-hooks - Add extension hooks merging behaviour to automating-with-hooks Source: https://github.com/github/copilot-cli/releases/tag/v1.0.11 Source: https://github.com/github/copilot-cli/releases/tag/v1.0.10 Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
github-actions[bot]
committed by
GitHub
GitHub
parent
7471eb5492
commit
f1004d04c0
@@ -3,7 +3,7 @@ title: 'Automating with Hooks'
|
||||
description: 'Learn how to use hooks to automate lifecycle events like formatting, linting, and governance checks during Copilot agent sessions.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: 2026-03-22
|
||||
lastUpdated: 2026-03-24
|
||||
estimatedReadingTime: '8 minutes'
|
||||
tags:
|
||||
- hooks
|
||||
@@ -99,6 +99,26 @@ Hooks can trigger on several lifecycle events:
|
||||
|
||||
> **Key insight**: The `preToolUse` hook is the most powerful — it can **approve or deny** individual tool executions. This enables fine-grained security policies like blocking specific shell commands or requiring approval for sensitive file operations.
|
||||
|
||||
### sessionStart additionalContext
|
||||
|
||||
The `sessionStart` hook supports an `additionalContext` field in its output. When your hook script writes JSON to stdout containing an `additionalContext` key, that text is **injected directly into the conversation** at the start of the session. This lets hooks dynamically provide environment-specific context—such as the current git branch, deployment environment, or team onboarding notes—without requiring the user to paste it manually.
|
||||
|
||||
Example hook script that surfaces context:
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# Output JSON with additionalContext to inject into the session
|
||||
cat <<EOF
|
||||
{
|
||||
"additionalContext": "Current branch: $(git rev-parse --abbrev-ref HEAD). Open tickets: $(gh issue list --limit 3 --json number,title | jq -r '.[] | \"#\(.number) \(.title)\"' | tr '\n' '; ')"
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
### Extension Hooks Merging
|
||||
|
||||
When multiple IDE extensions (or a mix of extensions and a `hooks.json` file) each define hooks, all hook definitions are **merged** rather than the last one overwriting the others. This means you can layer hooks from different sources—a project's `.github/hooks/` file, an extension you have installed, and a personal settings file—and all of them will fire for the relevant events.
|
||||
|
||||
### Cross-Platform Event Name Compatibility
|
||||
|
||||
Hook event names can be written in **camelCase** (e.g., `preToolUse`) or **PascalCase** (e.g., `PreToolUse`). Both are accepted, making hook configuration files compatible across GitHub Copilot CLI, VS Code, and Claude Code without modification. Hooks also support Claude Code's nested `matcher`/`hooks` structure alongside the standard flat format.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: 'Copilot Configuration Basics'
|
||||
description: 'Learn how to configure GitHub Copilot at user, workspace, and repository levels to optimize your AI-assisted development experience.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: 2026-03-23
|
||||
lastUpdated: 2026-03-24
|
||||
estimatedReadingTime: '10 minutes'
|
||||
tags:
|
||||
- configuration
|
||||
@@ -170,6 +170,43 @@ A well-organized Copilot configuration directory looks like this:
|
||||
└── api-design.instructions.md
|
||||
```
|
||||
|
||||
### Monorepo Support
|
||||
|
||||
In monorepos with multiple packages or services, GitHub Copilot CLI discovers customizations at **every directory level** from your working directory up to the git repository root. This means each package or service can have its own `.github/` folder with specialized agents, instructions, skills, and MCP servers, while still inheriting configuration from parent directories.
|
||||
|
||||
```
|
||||
my-monorepo/
|
||||
├── .github/
|
||||
│ └── instructions/
|
||||
│ └── shared-conventions.instructions.md ← applies everywhere
|
||||
├── packages/
|
||||
│ ├── api/
|
||||
│ │ └── .github/
|
||||
│ │ └── agents/
|
||||
│ │ └── api-expert.agent.md ← applies in packages/api/
|
||||
│ └── web/
|
||||
│ └── .github/
|
||||
│ └── instructions/
|
||||
│ └── react-conventions.instructions.md ← applies in packages/web/
|
||||
```
|
||||
|
||||
When you work inside `packages/api/`, Copilot loads configuration from `packages/api/.github/`, then `packages/.github/` (if it exists), then the root `.github/`. This layered discovery ensures the right context is active no matter where in the repository you're working.
|
||||
|
||||
### Personal Skills Directory
|
||||
|
||||
In addition to repository-level skills, GitHub Copilot CLI supports a **personal skills directory** at `~/.agents/skills/`. Skills you place here are discovered automatically across all your projects, making them ideal for personal workflows and reusable utilities that are not project-specific.
|
||||
|
||||
```
|
||||
~/.agents/
|
||||
└── skills/
|
||||
├── my-review-style/
|
||||
│ └── SKILL.md ← available in all sessions
|
||||
└── cleanup-todos/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
This personal directory aligns with the VS Code GitHub Copilot for Azure extension's default skill discovery path, so skills defined here work consistently across tools.
|
||||
|
||||
### Custom Agents
|
||||
|
||||
Agents are specialized assistants for specific workflows. Place agent definition files in `.github/agents/`.
|
||||
@@ -357,6 +394,25 @@ CLI settings use **camelCase** naming. Key settings added in recent releases:
|
||||
|
||||
> **Note**: Older snake_case names (e.g., `include_gitignored`, `auto_updates_channel`) are still accepted for backward compatibility, but camelCase is now the preferred format.
|
||||
|
||||
### CLI Session Commands
|
||||
|
||||
GitHub Copilot CLI has two commands for managing session state, with distinct behaviours:
|
||||
|
||||
| Command | Behaviour |
|
||||
|---------|-----------|
|
||||
| `/new [prompt]` | Starts a fresh conversation while keeping the current session backgrounded. You can switch back to backgrounded sessions. |
|
||||
| `/clear [prompt]` | Abandons the current session entirely and starts a new one. Backgrounded sessions are not affected. |
|
||||
|
||||
Both commands accept an optional prompt argument to seed the new session with an opening message, for example `/new Add error handling to the login flow`.
|
||||
|
||||
The `/undo` command reverts the last turn—including any file changes the agent made—letting you course-correct without manually undoing edits:
|
||||
|
||||
```
|
||||
/undo
|
||||
```
|
||||
|
||||
Use `/undo` when the agent's last response went in an unwanted direction and you want to try a different approach from that point.
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: How do I disable Copilot for specific files?**
|
||||
|
||||
@@ -3,7 +3,7 @@ title: 'Understanding MCP Servers'
|
||||
description: 'Learn how Model Context Protocol servers extend GitHub Copilot with access to external tools, databases, and APIs.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: 2026-03-23
|
||||
lastUpdated: 2026-03-24
|
||||
estimatedReadingTime: '8 minutes'
|
||||
tags:
|
||||
- mcp
|
||||
@@ -207,6 +207,15 @@ MCP server SDKs are available in [Python](https://github.com/modelcontextprotoco
|
||||
- **Test server connectivity**: Verify MCP servers start correctly before relying on them in agent workflows.
|
||||
- **Use the MCP allowlist (experimental)**: In high-security environments, the `MCP_ALLOWLIST` feature flag lets you validate MCP servers against a configured registry, blocking unrecognized servers from loading. This is an experimental feature for enterprise environments requiring strict control over which MCP servers are permitted.
|
||||
|
||||
### Organization Policy for Third-Party MCP Servers
|
||||
|
||||
GitHub organizations can enforce a policy that restricts which third-party MCP servers members are permitted to use. When this policy is active:
|
||||
|
||||
- Copilot CLI **enforces** the policy for all users in the organization.
|
||||
- A **warning is shown** if a configured MCP server is blocked by the policy, so you know which servers are restricted before expecting them to work.
|
||||
|
||||
If you see a warning that an MCP server is blocked, contact your organization administrator to find out which servers are on the allowlist, or switch to an approved alternative.
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: Do MCP servers run in the cloud?**
|
||||
|
||||
Reference in New Issue
Block a user