Ask Knox

The track has taught each capability as a standalone topic. What it has not shown is how those capabilities work together on one real task. That is the purpose of this capstone.

You will scope a task, generate and review a plan, delegate an isolated sub-task with scoped tools, read the resulting diffs, and ship a pull request — from start to finish, using each tool from the track in the order it belongs.

The task

The scenario is realistic and bounded: you are adding structured request logging to an Express TypeScript API. The middleware does not exist yet. Tests do not exist yet. The team uses this repo for production traffic.

Here is what needs to happen:

Write the custom instructions so Copilot CLI starts calibrated to this codebase
Use plan mode so you can review what will change before it changes
Delegate test authoring to a background agent with scoped tools
Read the diffs before merging anything
Ship the PR

That is the full workflow. Let's walk it.

Step 1 — Scope the task (custom instructions)

Before you touch a single file, write .github/copilot-instructions.md. This is the team's contract with every Copilot CLI session on this repo. It runs before any task.

The minimum for this task:

# Context
Node.js 20 · TypeScript 5 strict · Express 4.

# Conventions
- Test command: vitest --run
- New middleware goes in src/middleware/
- Named exports only — no default exports in src/

# Tools
Deny: git push, git push --force, npm publish

Three sections. Twelve lines. That is enough to prevent the most common problems: wrong test command, wrong file location, and accidental git push from a plan that ran further than you expected.

Step 2 — Generate and review the plan

Open a session and request plan mode for the main task:

copilot

Inside the session:

/plan "Add structured request logging middleware to this Express API.
The middleware should log method, path, status code, and duration in JSON.
It will live in src/middleware/logging.ts and be registered in src/app.ts
before the route handlers."

Copilot CLI reads the codebase, reasons about the change, and writes plan.md to your session state. Read it before you type anything else.

What you are looking for in plan.md:

Files to change. Does the list match what you expect? If Copilot CLI planned to touch src/lib/currency.ts — a shared helper — that is a scope creep signal. Edit the plan to remove it before approving.

Step ordering. Express middleware order matters. Logging should come before auth, not after. If the plan registers the middleware in the wrong position in src/app.ts, fix the step.

Risks section. A plan that catches risks before execution is the whole point. If this section is empty on a task touching src/app.ts, that is a yellow flag — not a blocker, but worth a careful read.

Approve the plan when you are satisfied with it. Or edit it first — plan editing is undersued. If the plan is 80% right, modify the 20% before executing. You do not need to reject and re-prompt.

Step 3 — Delegate the test sub-task

The main task is in flight. While it runs (or after it completes), delegate test authoring to a background agent. Tests for a new middleware module are the canonical delegate candidate: they are isolated, the scope is clear, the output is a reviewable PR.

/delegate "Write unit and integration tests for src/middleware/logging.ts.
Match the test structure and assertion style in src/middleware/auth.test.ts.
Cover: (1) logs correct method + path, (2) logs response status, (3) logs
duration as a positive number, (4) calls next() so subsequent handlers run.
No new dependencies. PR title: 'test: add request logging middleware tests'."

/delegate hands this brief to the Copilot coding agent on GitHub. It works in its own isolated cloud environment — your local session's tool flags do not carry over — and its only write path back to you is a draft pull request on a new branch. That isolation is the blast-radius boundary for delegated work: nothing it does lands in your codebase without your review.

The delegate brief quality determines the PR quality. Three things make a brief strong:

Reference an existing file as a style guide. Match the style in src/middleware/auth.test.ts is more actionable than "write good tests."
List explicit coverage targets. Four numbered items in the brief above translate directly to four test cases.
Name the PR title. It makes the resulting PR easier to triage.

Step 4 — Read the diffs

Two PRs will arrive. One from the main session (the middleware implementation). One from the delegate agent (the tests). Read both.

Do not skim. The session ran under your supervision but autonomously. The delegate agent ran without supervision on a task brief. Both can make reasonable but wrong assumptions.

Specifically check:

File scope. Does the implementation PR touch any files that were not in the plan? If src/lib/logger.ts was edited when only src/middleware/logging.ts and src/app.ts were in scope, that is unexpected work you need to evaluate.
Test coverage. Does the test PR cover the four cases from the brief? Missing test coverage is a gap you catch here, not in production.
Middleware registration order. Is logging registered before the auth middleware in src/app.ts? This is the kind of ordering bug that passes tests but fails in production.

Running tests locally is part of this step, not optional. The delegate agent ran tests in its own context. Run them in yours.

Step 5 — Ship

After review, create the PR from the session:

gh pr create \
  --title "feat(middleware): add structured request logging" \
  --body "Adds JSON-structured request logging middleware (src/middleware/logging.ts).
Registered in src/app.ts before route handlers.
Plan approved via Copilot CLI plan mode — see plan.md in session state.
Test PR: [link to /delegate test PR]."

The commit history from the session is already clean — Copilot CLI tracks what changed and why. The PR description links the plan to the implementation.

Putting it together

This is what the full workflow looks like as a sequence:

1. Write .github/copilot-instructions.md        ← scope + guardrails
2. copilot (with --allow-tool/--deny-tool)      ← narrow blast radius
3. /plan "add structured logging..."            ← plan generated
4. Read + approve the plan                      ← the human control point
5. [Copilot CLI executes]
6. /delegate "write tests..."                   ← cloud agent → draft PR
7. Review both PRs (read diffs, run tests)      ← never skip
8. gh pr create                                 ← ship

Notice what the instructions file enables: Copilot CLI knew the test command (vitest --run), the file location (src/middleware/), and the deny list (git push) before any prompt was written. That context carried through plan mode, through execution, and into the delegate brief. The instructions file is not overhead — it is what makes every downstream step faster.

Lesson Drill

Pick a real task in an existing project — adding a feature, refactoring a module, adding a new endpoint. Write the .github/copilot-instructions.md for that repo from scratch. Include the test command, at least two denied tools, and a file-location convention.
Use plan mode on that task. Before approving, identify one thing in plan.md you want to change — a file you want excluded, a step you want reordered, or a risk the plan missed. Edit the plan and approve the revised version.
Identify the most isolated sub-task from the plan. Write the /delegate brief for it. Make it specific enough that a competent junior engineer with only the brief and the codebase could produce a reviewable PR on the first attempt. Run it.
Read the resulting PR diffs before merging. Write down one thing the plan mode step helped you catch that you might have missed in a direct prompt-to-execution approach.

Bottom Line

The track introduced each capability as a standalone lesson. Plan mode teaches you to review before executing. Tool control teaches you to bound the blast radius. Delegation teaches you to parallelize isolated work. Team setup teaches you to version-control the conventions.

This capstone is the evidence that they work together. Scope the task with instructions, generate and review a plan, delegate with narrow tools, read the diffs, ship the PR. The sequence is repeatable on any task. The discipline is in not skipping steps.

The next track covers multi-agent orchestration — coordinating fleets of agents across larger systems. The patterns you practiced here (scoping, planning, delegating, reviewing) are the foundations you will apply at that scale.

The Full Workflow — A Copilot CLI Completion Project