Skip to content
GitHub Copilot Train-the-Trainer
Slides

Canvas extensions

Define the contract, state, and allowed actions

Today's outcome

Build one delivery-readiness canvas in the Copilot app.

Record:

  • the approved contract;
  • one direct update;
  • one agent-requested update;
  • one rejected update and recovery;
  • one human review decision.

Access policy

The lab requires:

  • GitHub Copilot app access;
  • the built-in /create-canvas skill;
  • approval for the chosen extension scope.

If app access or the skill is missing, stop the lab. If project scope is unavailable, use user scope. Do not install a replacement or move data to an unapproved surface.

Choose the right customization

Need Use
Repository convention Instructions
Repeatable procedure Skill
Specialist behavior Custom agent
External tool or data MCP server
Shared interactive artifact Canvas
Packaged customizations Plugin

A canvas is useful when people and an agent need to inspect or change the same visible state.

Canvas anatomy

shared state
  ├─ human actions in the interface
  ├─ agent-callable capabilities
  └─ validation before every change

The contract names all four parts before implementation starts.

Worked contract

Part Delivery-readiness rule
State item, status, review flag, evidence
Status planned, in-progress, review, ready
Human actions set status, flag review, add evidence
Agent capabilities read board, update one named item, list flagged items
Validation known item, accepted status, evidence before ready

Authority stays narrow

Safe:

  • read the current board;
  • update one named item;
  • list items flagged for review.

Out of scope:

  • deployment;
  • external writes;
  • credentials;
  • hidden data imports;
  • broad actions such as "manage the project."

Prepared demo inputs

ID Item Start state Evidence
DOC-101 Draft operator guide planned none
API-204 Add retry metric in-progress test log
WEB-318 Check empty state review preview

All names and evidence are synthetic.

Prepared demo sequence

  1. Run the local contract tests.
  2. Create the canvas from the worked prompt.
  3. Move WEB-318 to ready with a visible control.
  4. Ask the agent to move API-204 to review.
  5. Ask for DOC-101 to move to ready.
  6. Show the rejection, add evidence, and retry.

Creation prompt

/create-canvas

Create a delivery-readiness canvas from @prepared-items.json.
Use the contract in @canvas-contract.md.
People can add evidence and update one item.
Copilot can read the board, update one named item, and list review flags.
Reject unknown items or statuses. Require evidence before ready.
Do not connect external systems.

Choose project scope only when .github/extensions is allowed. Otherwise use user scope.

Visible and agent-requested changes

The same state must change through both paths:

Path Evidence
Human control The item visibly changes in the canvas
Agent capability The named item changes and the response matches the canvas

If the response and visible state disagree, stop and inspect the artifact.

Rejection is part of the design

Request:

Move DOC-101 to ready.

Expected:

Rejected: evidence is required before ready.

A safe canvas keeps the state unchanged and explains the rule.

Recovery keeps the rule

  1. Add synthetic evidence to DOC-101.
  2. Retry the same transition.
  3. Check that ready is now accepted.
  4. Record before, rejection, correction, and after state.

Keep validation in place when you fix the demo.

Review the generated extension

Check:

  • state fields and defaults;
  • visible actions;
  • agent-callable capabilities;
  • dependencies and persisted data;
  • owner and reviewer;
  • retirement trigger.

Remove anything the contract did not request.

Source of truth

The canvas is a working artifact, not an automatic system of record.

If another system owns the data:

  • label the canvas as a projection;
  • record refresh or reconciliation rules;
  • keep external writes outside this lab.

Peer decision

The reviewer chooses:

  • approve when the recorded results match the contract;
  • revise when the correction fits the contract;
  • pause when access, ownership, data, or behavior is unresolved.

Lab handoff

Use one contract and one prepared data set for the full two hours.