The art of simplicity

So far in this series we've covered modes, session management, and parallelization with /fleet . This post is about hooks — one of the more powerful features of Copilot CLI. Hooks let you inject your own shell scripts at key moments during a session, enabling everything from audit logging to blocking dangerous commands before they execute. What are hooks? Hooks are custom scripts that run at specific points during a Copilot CLI session. They receive structured JSON input describing what's happening at that moment — which tool is being called, what arguments it received, what the session context looks like — and can optionally respond with a JSON output that influences what Copilot does next. The key thing that makes hooks different from just writing good prompts or instructions: hooks are deterministic. They execute your code at specific lifecycle points with guaranteed outcomes. Unlike instructions that guide agent behavior, a hook can guarantee that a dangerous comman...

In the previous posts we covered the different CLI modes and session management. This time we're looking at one of Copilot CLI's most powerful features: the /fleet command. If you've ever wished you could clone yourself to tackle several parts of a codebase at once, this is the closest thing to it. What is /fleet ? When you send a prompt to Copilot CLI, by default a single agent works through the task sequentially. /fleet changes that model entirely. The /fleet slash command lets Copilot CLI break down a complex request into smaller tasks and run them in parallel, maximizing efficiency and throughput. The main Copilot agent analyzes the prompt and determines whether it can be divided into smaller subtasks. It then acts as an orchestrator, managing the workflow and dependencies between those subtasks, each handled by a separate subagent. In practice, this means a task that might take 20 minutes sequentially can complete in a fraction of the time — because independ...

In the first post we covered the different modes in Copilot CLI. This time we're looking at something that becomes essential once you're doing serious work in the CLI: session management. Sessions let you pause, resume, and organize your work — across terminal restarts, across machines, and across multiple concurrent workstreams. What is a session? Every time you launch Copilot CLI, you're working inside a session. A session captures your full conversation history, the tool calls Copilot made, the files it touched, and the permissions you granted — all stored locally under ~/.copilot/session-state/ . Sessions are identified by a UUID and automatically receive an AI-generated name based on your first message, making them easy to identify later. Most important is that sessions persist after you close the CLI. That means nothing is lost when you shut down your terminal — you can always pick up right where you left off. Resuming a session Pick up where you left off ...

Welcome to the first post in my series on getting the most out of GitHub Copilot in the terminal. We'll kick things off with one of the most important things to understand: the different modes Copilot CLI operates in, and when to reach for each one. A quick intro to GitHub Copilot CLI GitHub Copilot CLI is a terminal-native coding agent — not just a chat wrapper. It can plan complex tasks, edit files, run tests, and iterate autonomously, all without leaving your terminal. But to get the most out of it, you need to understand how to control how much autonomy you give it at any point in time. That's exactly what the different modes are for. You cycle through the main modes using Shift+Tab . A mode indicator in the CLI's footer tells you which one you're currently in. The three main modes 1. Standard Mode — The default When you launch copilot , you start in standard (interactive) mode. This is the classic back-and-forth: you submit a prompt, Copilot responds o...

Between all this AI craziness, we often forget to appreciate the small tools and features that make our lives easier. Such  a feature is Central Management Servers (CMS) , a built-in SQL Server feature that lets you manage a whole fleet of instances from one place. Let's walk through what it is, how to set it up, and when it'll actually make your life easier. So, what is a Central Management server? At its core, CMS is a SQL Server instance that acts as your hub for organizing and talking to other SQL Server instances. You register your other servers under it, group them however makes sense (by environment, team, region — you name it), and then query all of them at once. The metadata about your registered servers gets stored in the msdb database on the CMS host. Nothing fancy — it's just a central directory that SSMS knows how to use. Setting it up in SSMS Here's how to get going in SQL Server Management Studio: Step 1: Open the Registered Servers panel ...

The timeout appeared without warning. A migration pipeline that had run fine in staging suddenly ground to a halt in production, throwing lock wait timeouts across multiple worker threads. The application was querying and writing to the same table, and somewhere in that dance of reads and writes, things had seized up entirely. Here is a walk through the investigation, from the first diagnostic query all the way to the fix — along with an explanation of why it worked. Find the blocker The first tool in any SQL Server lock investigation is sys.dm_exec_requests joined against sys.dm_exec_sessions . This query shows you every session that is currently blocked, who is blocking it, and what SQL both parties are running: A second query dug into the exact lock modes held on the specific table in question: The output told the story The results were unambiguous. Three sessions. One blocker. Two victims. Blocking Blocked Wait type ...