mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-11 02:35:55 +00:00
docs: update Learning Hub with Copilot CLI v1.0.16–1.0.21 features
- automating-with-hooks.md: add notification and PermissionRequest hook events to the events table; document preToolUse permissionDecision response values (allow/ask); update PascalCase payload compatibility note to mention VS Code-compatible snake_case payloads - understanding-mcp-servers.md: add copilot mcp terminal command section for managing MCP servers outside interactive sessions - creating-effective-skills.md: document CLI built-in skills (v1.0.17+) - using-copilot-coding-agent.md: add Critic agent section (experimental, v1.0.18+) that auto-reviews plans using a complementary model Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
github-actions[bot]
committed by
GitHub
GitHub
parent
52e14abc86
commit
310ce82242
@@ -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-04-01
|
||||
lastUpdated: 2026-04-08
|
||||
estimatedReadingTime: '8 minutes'
|
||||
tags:
|
||||
- hooks
|
||||
@@ -97,10 +97,21 @@ Hooks can trigger on several lifecycle events:
|
||||
| `preCompact` | Before the agent compacts its context window | Save a snapshot, log compaction event, run summary scripts |
|
||||
| `subagentStart` | A subagent is spawned by the main agent | Inject additional context into the subagent's prompt, log subagent launches |
|
||||
| `subagentStop` | A subagent completes before returning results | Audit subagent outputs, log subagent activity |
|
||||
| `notification` | Fires **asynchronously** when a notable event occurs (shell completion, permission prompt, elicitation dialog, agent completion) | Send external notifications, update dashboards, trigger external systems without blocking the agent |
|
||||
| `PermissionRequest` | A tool permission request is raised (e.g., when `preToolUse` returns `permissionDecision: "ask"`) | Programmatically approve or deny tool permission requests from a script |
|
||||
| `errorOccurred` | An error occurs during agent execution | Log errors for debugging, send notifications, track error patterns |
|
||||
|
||||
> **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.
|
||||
|
||||
Your `preToolUse` hook script can control what happens next by writing JSON to stdout:
|
||||
|
||||
| Output | Effect |
|
||||
|--------|--------|
|
||||
| Exit code 0 (no output) | Tool is allowed to proceed |
|
||||
| Exit code non-zero | Tool execution is **blocked** |
|
||||
| `{"permissionDecision": "allow"}` | Tool is approved and the **tool approval prompt is suppressed** — the user is not asked |
|
||||
| `{"permissionDecision": "ask"}` | Raises a `PermissionRequest` event so another hook can handle the decision |
|
||||
|
||||
### 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.
|
||||
@@ -125,6 +136,8 @@ When multiple IDE extensions (or a mix of extensions and a `hooks.json` file) ea
|
||||
|
||||
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.
|
||||
|
||||
When a hook uses PascalCase event names, the payload delivered to your script uses **VS Code-compatible snake_case field names** (e.g., `hook_event_name`, `session_id`) with ISO 8601 timestamps — so you can use the same hook script across VS Code and the CLI.
|
||||
|
||||
### Plugin Hooks Environment Variables
|
||||
|
||||
When hooks are defined inside a **plugin**, the hook scripts receive two additional environment variables automatically:
|
||||
@@ -360,6 +373,28 @@ Send a Slack or Teams notification when an agent session completes:
|
||||
}
|
||||
```
|
||||
|
||||
### Asynchronous Notifications with the `notification` Hook
|
||||
|
||||
The `notification` hook fires **asynchronously** — it does not block the agent — making it ideal for sending external notifications, updating dashboards, or triggering CI systems when notable events occur (shell commands complete, permission prompts appear, elicitation dialogs open, agent finishes):
|
||||
|
||||
```json
|
||||
{
|
||||
"version": 1,
|
||||
"hooks": {
|
||||
"notification": [
|
||||
{
|
||||
"type": "command",
|
||||
"bash": "./scripts/notify-external.sh",
|
||||
"cwd": ".",
|
||||
"timeoutSec": 10
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Because it's asynchronous, the `notification` hook won't slow down the agent even if the external call takes time. Use `sessionEnd` (synchronous) when you need to guarantee the notification completes before the session closes, or `notification` when fire-and-forget is acceptable.
|
||||
|
||||
### Injecting Context into Subagents
|
||||
|
||||
The `subagentStart` hook fires when the main agent spawns a subagent (e.g., via the `task` tool). Use it to inject additional context—such as project conventions or security guidelines—directly into the subagent's prompt:
|
||||
|
||||
@@ -3,7 +3,7 @@ title: 'Creating Effective Skills'
|
||||
description: 'Master the art of writing reusable, shareable skill folders that deliver consistent results across your team.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: 2026-02-26
|
||||
lastUpdated: 2026-04-08
|
||||
estimatedReadingTime: '9 minutes'
|
||||
tags:
|
||||
- skills
|
||||
@@ -361,6 +361,10 @@ A: Yes! Skills are folders, not single files. You can bundle reference documents
|
||||
|
||||
A: Store skill folders in your repository's `.github/skills/` directory. They're automatically available to all team members with Copilot access when working in that repository.
|
||||
|
||||
**Q: Does the CLI include any built-in skills?**
|
||||
|
||||
A: Yes. Starting with v1.0.17, GitHub Copilot CLI ships with a set of **built-in skills** that are available in every session without any configuration. The first built-in skill is a guide for customizing the Copilot coding agent's cloud environment (`copilot-setup-steps.yml`). You can see the built-in skills in action by asking Copilot about setting up your coding agent environment. These built-in skills complement (and do not replace) your own project-level or personal skills.
|
||||
|
||||
**Q: Can agents chain multiple skills?**
|
||||
|
||||
A: Agents can discover and invoke multiple skills during a conversation based on user intent. Each skill invocation is independent, but agents maintain conversation context across invocations.
|
||||
|
||||
@@ -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-04-01
|
||||
lastUpdated: 2026-04-08
|
||||
estimatedReadingTime: '8 minutes'
|
||||
tags:
|
||||
- mcp
|
||||
@@ -114,6 +114,18 @@ The available RPCs are:
|
||||
|
||||
These are especially useful for plugins and installer scripts that need to self-register or de-register their MCP server as part of install/uninstall flows, without requiring the user to manually edit config files.
|
||||
|
||||
### Managing MCP Servers from the Terminal
|
||||
|
||||
The `copilot mcp` command lets you manage MCP servers directly from the terminal, without opening an interactive session:
|
||||
|
||||
```bash
|
||||
gh copilot mcp list # list all configured MCP servers
|
||||
gh copilot mcp add <name> # add a new MCP server to persistent configuration
|
||||
gh copilot mcp remove <name> # remove an MCP server from persistent configuration
|
||||
```
|
||||
|
||||
This complements the in-session `/mcp` slash commands (`/mcp show`, `/mcp enable`, `/mcp disable`, `/mcp reload`, `/mcp auth`) for cases where you want to manage your MCP server configuration from scripts or CI workflows, or before starting a session.
|
||||
|
||||
### Common MCP Server Configurations
|
||||
|
||||
**PostgreSQL** — Query databases and inspect schemas:
|
||||
|
||||
@@ -3,7 +3,7 @@ title: 'Using the Copilot Coding Agent'
|
||||
description: 'Learn how to use GitHub Copilot coding agent to autonomously work on issues, generate pull requests, and automate development tasks.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: 2026-03-25
|
||||
lastUpdated: 2026-04-08
|
||||
estimatedReadingTime: '12 minutes'
|
||||
tags:
|
||||
- coding-agent
|
||||
@@ -379,6 +379,21 @@ It's less suited for:
|
||||
- Use hooks to enforce security scanning on every commit
|
||||
- Scope repository permissions appropriately
|
||||
|
||||
## Critic Agent (Experimental)
|
||||
|
||||
The Critic agent is an automatic review step that runs **after** the coding agent completes a plan or complex implementation. It uses a complementary AI model to independently evaluate the agent's reasoning and catch errors that the primary model may miss.
|
||||
|
||||
**How it works**:
|
||||
1. The coding agent completes a plan or implementation
|
||||
2. The Critic agent (powered by a different model) reviews the work
|
||||
3. If the Critic finds issues, the primary agent can revise before opening the PR
|
||||
|
||||
This "second opinion" approach catches logical errors, missed edge cases, and inconsistencies that are easy to overlook in complex multi-step tasks — similar to having a second developer review a plan before writing any code.
|
||||
|
||||
**When it runs**: The Critic agent is available for **Claude models in experimental mode**. Enable experimental features in your CLI settings to try it. No additional configuration is required; the Critic activates automatically on plans and complex implementations.
|
||||
|
||||
> **Note**: This is an experimental feature and behavior may change in future releases. See [Copilot Configuration Basics](../copilot-configuration-basics/) for how to enable experimental features.
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: How long does the coding agent take?**
|
||||
|
||||
Reference in New Issue
Block a user