docs: update Learning Hub for CLI v1.0.6–v1.0.10 changes (#1119)

- automating-with-hooks: add subagentStart event to hook events table,
  add cross-platform PascalCase event name compatibility note, add
  subagentStart example, expand hook config file location FAQ to include
  settings.json and config.json locations
- defining-custom-instructions: document that applyTo accepts both
  string and array formats (added in v1.0.6)
- installing-and-using-plugins: document --plugin-dir flag and the
  External Plugins section in /plugin list (added in v1.0.10)

Source: github/copilot-cli releases v1.0.6 through v1.0.10
(March 16–20, 2026)

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]
2026-03-23 11:36:23 +11:00
committed by GitHub
parent 80b2129888
commit f1e39bb2a5
3 changed files with 58 additions and 5 deletions

View File

@@ -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.' description: 'Learn how to use hooks to automate lifecycle events like formatting, linting, and governance checks during Copilot agent sessions.'
authors: authors:
- GitHub Copilot Learning Hub Team - GitHub Copilot Learning Hub Team
lastUpdated: 2026-02-26 lastUpdated: 2026-03-22
estimatedReadingTime: '8 minutes' estimatedReadingTime: '8 minutes'
tags: tags:
- hooks - hooks
@@ -93,11 +93,16 @@ Hooks can trigger on several lifecycle events:
| `preToolUse` | Before the agent uses any tool (e.g., `bash`, `edit`) | **Approve or deny** tool executions, block dangerous commands, enforce security policies | | `preToolUse` | Before the agent uses any tool (e.g., `bash`, `edit`) | **Approve or deny** tool executions, block dangerous commands, enforce security policies |
| `postToolUse` | After a tool completes execution | Log results, track usage, format code after edits, send failure alerts | | `postToolUse` | After a tool completes execution | Log results, track usage, format code after edits, send failure alerts |
| `agentStop` | Main agent finishes responding to a prompt | Run final linters/formatters, validate complete changes | | `agentStop` | Main agent finishes responding to a prompt | Run final linters/formatters, validate complete changes |
| `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 | | `subagentStop` | A subagent completes before returning results | Audit subagent outputs, log subagent activity |
| `errorOccurred` | An error occurs during agent execution | Log errors for debugging, send notifications, track error patterns | | `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. > **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.
### 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.
### Event Configuration ### Event Configuration
Each hook entry supports these fields: Each hook entry supports these fields:
@@ -281,6 +286,28 @@ Send a Slack or Teams notification when an agent session completes:
} }
``` ```
### 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:
```json
{
"version": 1,
"hooks": {
"subagentStart": [
{
"type": "command",
"bash": "echo 'Follow the team coding standards in .github/instructions/ for all code changes.'",
"cwd": ".",
"timeoutSec": 5
}
]
}
}
```
This is especially useful in multi-agent workflows where subagents may not automatically inherit context from the parent session.
## Writing Hook Scripts ## Writing Hook Scripts
For complex logic, use bundled scripts instead of inline bash commands: For complex logic, use bundled scripts instead of inline bash commands:
@@ -327,7 +354,13 @@ echo "Pre-commit checks passed ✅"
**Q: Where do I put hooks configuration files?** **Q: Where do I put hooks configuration files?**
A: Place them in the `.github/hooks/` directory in your repository (e.g., `.github/hooks/my-hook.json`). You can have multiple hook files — all are loaded automatically. This makes hooks available to all team members. A: There are several supported locations, loaded in order of precedence:
- **Repository-level** (shared with team): `.github/hooks/*.json` in your repository — all JSON files in this folder are loaded automatically
- **Global settings**: `settings.json` or `settings.local.json` (user-level CLI config)
- **Legacy config**: `config.json` (also supported)
For team-wide hooks that everyone should use, `.github/hooks/` is the recommended location as it is version-controlled and shared automatically.
**Q: Can hooks access the user's prompt text?** **Q: Can hooks access the user's prompt text?**

View File

@@ -3,7 +3,7 @@ title: 'Defining Custom Instructions'
description: 'Learn how to create persistent, context-aware instructions that guide GitHub Copilot automatically across your codebase.' description: 'Learn how to create persistent, context-aware instructions that guide GitHub Copilot automatically across your codebase.'
authors: authors:
- GitHub Copilot Learning Hub Team - GitHub Copilot Learning Hub Team
lastUpdated: 2025-12-02 lastUpdated: 2026-03-22
estimatedReadingTime: '8 minutes' estimatedReadingTime: '8 minutes'
tags: tags:
- instructions - instructions
@@ -100,7 +100,17 @@ export function UserProfile({ userId, onUpdate }: UserProfileProps) {
## Scoping Instructions Effectively ## Scoping Instructions Effectively
The `applyTo` field determines which files receive the instruction's guidance. The `applyTo` field determines which files receive the instruction's guidance. It accepts either a **comma-separated string** or an **array of glob patterns** — both formats work:
```yaml
# String format (comma-separated)
applyTo: '**/*.ts, **/*.tsx'
# Array format
applyTo:
- '**/*.ts'
- '**/*.tsx'
```
### Common Scoping Patterns ### Common Scoping Patterns

View File

@@ -3,7 +3,7 @@ title: 'Installing and Using Plugins'
description: 'Learn how to find, install, and manage plugins that extend GitHub Copilot CLI with reusable agents, skills, hooks, and integrations.' description: 'Learn how to find, install, and manage plugins that extend GitHub Copilot CLI with reusable agents, skills, hooks, and integrations.'
authors: authors:
- GitHub Copilot Learning Hub Team - GitHub Copilot Learning Hub Team
lastUpdated: 2026-02-26 lastUpdated: 2026-03-22
estimatedReadingTime: '8 minutes' estimatedReadingTime: '8 minutes'
tags: tags:
- plugins - plugins
@@ -177,6 +177,16 @@ copilot plugin update my-plugin
copilot plugin uninstall my-plugin copilot plugin uninstall my-plugin
``` ```
### Loading Plugins from a Local Directory
You can load plugins directly from a local directory without installing them from a marketplace, using the `--plugin-dir` flag when starting Copilot:
```bash
copilot --plugin-dir /path/to/my-plugin
```
Plugins loaded this way appear in `/plugin list` under a separate **External Plugins** section, clearly distinguished from marketplace-installed plugins. This is useful for testing local plugins in development or loading private plugins that aren't published to any marketplace.
### Where Plugins Are Stored ### Where Plugins Are Stored
- **Marketplace plugins**: `~/.copilot/installed-plugins/MARKETPLACE/PLUGIN-NAME/` - **Marketplace plugins**: `~/.copilot/installed-plugins/MARKETPLACE/PLUGIN-NAME/`