mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-11 02:35:55 +00:00
docs: update Learning Hub for Copilot CLI v1.0.15–v1.0.18 features
- Add notification and PermissionRequest hook events to automating-with-hooks.md - Document permissionDecision: 'allow' behavior for preToolUse hooks - Add Critic agent (experimental) section to using-copilot-coding-agent.md - Document built-in skills bundled with CLI (v1.0.17) in creating-effective-skills.md Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
github-actions[bot]
committed by
GitHub
GitHub
parent
5f3d66c380
commit
8dd7712d32
@@ -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-05
|
||||
estimatedReadingTime: '8 minutes'
|
||||
tags:
|
||||
- hooks
|
||||
@@ -97,9 +97,13 @@ 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` | **Asynchronously** on shell completion, permission prompts, elicitation dialogs, and agent completion | Send async alerts, log events without blocking the agent |
|
||||
| `PermissionRequest` | Before the agent presents a tool permission prompt to the user | **Programmatically approve or deny** individual permission requests, auto-approve trusted tools |
|
||||
| `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.
|
||||
>
|
||||
> As of v1.0.18, a `preToolUse` hook can also return `permissionDecision: 'allow'` in its JSON output to **suppress the tool approval prompt entirely** for that tool call. This is useful in automated workflows where your script validates the tool call and wants to silently approve it without interrupting the user.
|
||||
|
||||
### sessionStart additionalContext
|
||||
|
||||
@@ -207,6 +211,92 @@ automatically before the agent commits changes.
|
||||
|
||||
## Practical Examples
|
||||
|
||||
### Async Notifications with the notification Hook
|
||||
|
||||
The `notification` hook fires **asynchronously** — it does not block the agent — on events such as shell completion, permission prompts, elicitation dialogs, and agent completion. Use it for lightweight side-effects like sending a Slack alert or writing a log entry without slowing down the agent:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": 1,
|
||||
"hooks": {
|
||||
"notification": [
|
||||
{
|
||||
"type": "command",
|
||||
"bash": "./scripts/notify-async.sh",
|
||||
"cwd": ".",
|
||||
"timeoutSec": 5
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Because the hook runs asynchronously, timeouts are still enforced but a slow script will not delay the next agent action.
|
||||
|
||||
> **Tip**: Prefer `notification` over `sessionEnd` for lightweight alerts. Save `sessionEnd` for cleanup work that must complete before the session closes.
|
||||
|
||||
### Programmatic Permission Decisions with PermissionRequest
|
||||
|
||||
The `PermissionRequest` hook fires **before** the agent displays a tool permission prompt to the user. Your script receives the permission request details as JSON input and can return a decision to approve or deny it without user interaction:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": 1,
|
||||
"hooks": {
|
||||
"PermissionRequest": [
|
||||
{
|
||||
"type": "command",
|
||||
"bash": "./scripts/auto-approve.sh",
|
||||
"cwd": ".",
|
||||
"timeoutSec": 5
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Example `auto-approve.sh` that approves read-only tools and denies everything else:
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
INPUT=$(cat)
|
||||
TOOL=$(echo "$INPUT" | jq -r '.tool // ""')
|
||||
|
||||
case "$TOOL" in
|
||||
read|codebase|search|grep|glob)
|
||||
echo '{"decision": "allow"}'
|
||||
;;
|
||||
*)
|
||||
# Fall through to the normal permission prompt
|
||||
echo '{"decision": "ask"}'
|
||||
;;
|
||||
esac
|
||||
```
|
||||
|
||||
This is especially powerful in CI/CD pipelines or automated environments where you want a known set of tools to run without interruption.
|
||||
|
||||
### Suppressing the Approval Prompt from preToolUse
|
||||
|
||||
In addition to the `PermissionRequest` hook, a `preToolUse` hook can return `permissionDecision: 'allow'` in its JSON output to silently approve a specific tool call and suppress the approval prompt:
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# pre-tool-use.sh — silently approve safe formatting tools
|
||||
INPUT=$(cat)
|
||||
TOOL=$(echo "$INPUT" | jq -r '.tool // ""')
|
||||
|
||||
if [[ "$TOOL" == "edit" || "$TOOL" == "bash" ]]; then
|
||||
# Perform your validation here, then approve silently
|
||||
echo '{"permissionDecision": "allow"}'
|
||||
else
|
||||
exit 0 # No decision — normal approval flow
|
||||
fi
|
||||
```
|
||||
|
||||
Use this pattern when your `preToolUse` hook already validates the tool call and you want to combine validation and approval in a single step.
|
||||
|
||||
### Handling Tool Failures with postToolUseFailure
|
||||
|
||||
The `postToolUseFailure` hook fires when a tool call fails with an error — distinct from `postToolUse`, which only fires on success. Use it to log errors, send failure alerts, or implement retry logic:
|
||||
|
||||
@@ -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-05
|
||||
estimatedReadingTime: '9 minutes'
|
||||
tags:
|
||||
- skills
|
||||
@@ -35,6 +35,14 @@ Skills are folders containing a `SKILL.md` file and optional bundled assets. The
|
||||
- Skills are **more normalised across coding agent systems** via the open [Agent Skills specification](https://agentskills.io/home)
|
||||
- Skills still support **slash-command invocation** just like prompts did
|
||||
|
||||
### Built-in Skills
|
||||
|
||||
Starting with **v1.0.17**, GitHub Copilot CLI ships with **built-in skills** that are available in every session without any configuration. The first built-in skill is a guide for customizing the Copilot cloud agent's environment — helping you create and tune `.github/copilot-setup-steps.yml` for your project.
|
||||
|
||||
Built-in skills are automatically available alongside your custom skills and behave identically — agents discover and invoke them based on context. You can list available skills (including built-ins) using `/skills` in a session.
|
||||
|
||||
> **Tip**: Built-in skills set a useful reference for structure and style. If you want to override or extend a built-in skill's behavior, create a custom skill with the same name in your `.github/skills/` directory — your version will take precedence.
|
||||
|
||||
### How Skills Differ from Other Customizations
|
||||
|
||||
**Skills vs Instructions**:
|
||||
|
||||
@@ -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-05
|
||||
estimatedReadingTime: '12 minutes'
|
||||
tags:
|
||||
- coding-agent
|
||||
@@ -348,6 +348,29 @@ See [Automating with Hooks](../automating-with-hooks/) for configuration details
|
||||
|
||||
## Best Practices
|
||||
|
||||
### The Critic Agent (Experimental)
|
||||
|
||||
GitHub Copilot CLI v1.0.18 introduced the **Critic agent** — an experimental feature that automatically reviews the agent's plans and complex implementations using a **complementary model** before execution begins.
|
||||
|
||||
When enabled, the Critic acts as a second set of eyes:
|
||||
- It reads the agent's proposed plan and checks for logic errors, missing edge cases, or risky steps
|
||||
- It can flag issues early, **before** the agent writes any code
|
||||
- It operates silently in the background — you see a Critic review step in the session timeline when it runs
|
||||
|
||||
**How to enable**: The Critic is currently available in **experimental mode** for Claude models. Enable it by setting:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": {
|
||||
"critic": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
in your `config.json` (or `.claude/settings.json` for per-project configuration).
|
||||
|
||||
> **When it helps most**: Long, multi-step plans and complex refactors benefit most from Critic review. For simple, well-scoped tasks the overhead may not be worth it — you can enable or disable it per project via `.claude/settings.json`.
|
||||
|
||||
### Setting Up for Success
|
||||
|
||||
- **Invest in `copilot-setup-steps.yml`**: A reliable setup means the agent can build and test confidently. If tests are flaky, the agent will struggle.
|
||||
|
||||
Reference in New Issue
Block a user