Generated banner for Session Log Canvas Update
Generated logo for Session Log Canvas Update

Session Log Canvas Update

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Workflow
  • Software development
  • MIT
  • Low risk
  • Has scripts

From the author

Update the Session Log canvas after a Copilot release changes session events, session storage, system prompt structure, or the canvas SDK. Diffs the installed session-events schema against the canvas baseline, then guides the fixes, fixtures, docs, and baseline refresh. Use after updating Copilot or when the canvas shows unknown events or missing data.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured workflow for maintaining the Session Log canvas when updates to Copilot releases introduce changes to session events, storage, or system prompt structures. It automates the process of diffing schemas, identifying necessary code adjustments, updating test fixtures, and refreshing the baseline to ensure that both new and historical session data remain accurately readable within the canvas.

What it does

  • Diffs installed Copilot session-events schemas against the current canvas baseline.
  • Identifies and classifies changes to event types, fields, and storage structures.
  • Guides the implementation of necessary code fixes and updates to the canvas indexer.
  • Updates synthetic test fixtures to ensure backward and forward compatibility.
  • Refreshes the event-shapes baseline after verification.
  • Validates changes through automated test suites and linting.

When to use it

  • After updating the Copilot CLI or SDK version.
  • When the Session Log canvas displays unknown events or missing data.
  • When preparing to release changes that affect session logging or storage.
  • During routine maintenance to ensure the canvas remains aligned with the latest Copilot schema.

Advantages

  • Ensures consistent rendering of session logs across different Copilot versions.
  • Prevents regressions by requiring synthetic fixture updates for all schema changes.
  • Provides a clear audit trail of changes via the style guide and baseline updates.
  • Maintains data privacy by strictly prohibiting the use of real session content in tests or docs.

Usage examples

“Update the session log canvas for the latest Copilot release.”
The agent runs the update workflow, diffs the latest schema, identifies required changes, and prompts for confirmation before applying updates and refreshing the baseline.
“Check if the current canvas is compatible with Copilot version 1.2.3.”
The agent performs a check-mode analysis, reporting any discrepancies between the current canvas baseline and the specified Copilot version without modifying any files.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/session-log-canvas-update/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip session-log-canvas-update.zip -d .agents/skills

Documentation by Microsoft

Session Log Canvas Update

Goal

Keep the Session Log canvas accurate when a new Copilot version changes what a session records. Find what changed between the schema the canvas was built against and the current one, then update the canvas so new and changed data renders correctly while sessions recorded by earlier versions stay readable.

This skill belongs to the HVE Core repository. Keep it directly under .github/skills/session-log-canvas-update/, outside package directories and plugin or VSIX membership. The canvas it maintains lives at .github/extensions/hve-core/session-log/.

Inputs

  • mode (optional): check reports what changed and the work it implies without editing. update (default) also applies the changes and refreshes the baseline.

  • schema (optional): which schema to compare. Accepts a path to a session-events.schema.json, an installed Copilot version, or latest (default, the newest installed Copilot CLI package).

Success Criteria

  • Every change to an event type the canvas handles is classified (needs code, already tolerated, or not used by the canvas) with the diff line that supports it.

  • New persisted event types either render through a deliberate log kind or are recorded as intentionally generic; none is silently dropped.

  • Sessions recorded by both the baseline version and the new version render without regressions: the canvas tests cover the old and new shapes with synthetic fixtures.

  • Storage, workspace.yaml, system prompt structure, and canvas SDK changes are checked even when the event schema diff is empty.

  • The baseline (assets/event-shapes.json) describes the schema the updated canvas was verified against, and the style guide revision log names the change.

  • No session content appears in fixtures, tests, docs, reports, or responses.

Flow

  1. Find the versions in play. Run node scripts/event-schema.mjs list from the skill root (or node .github/skills/session-log-canvas-update/scripts/event-schema.mjs list from the repository root) to see installed Copilot CLI schemas. Read the baseline's source in assets/event-shapes.json. For a VS Code session, also locate the schema bundled with VS Code at <VS Code app resources>/app/node_modules.asar.unpacked/@github/copilot-sdk-<platform>/schemas/session-events.schema.json, because the VS Code harness can run a newer runtime than the installed CLI. The copilotVersion a session recorded comes from its session.start event; the canvas get_session_summary action returns it.

  2. Diff the schema. Run node scripts/event-schema.mjs diff --schema <path|version|latest> for each relevant schema. The report lists handled types that changed (field by field), new event types with whether they persist, removed types, other changed types, and handled types the schema no longer defines. A field that union alternatives share lists every signature it can take, and a signature cut short by the script's size limits ends in …. Use --json when you need to process the result.

  3. Check real sessions without reading content. Open the canvas on a session from the new version and call its get_session_summary action: eventHealth.unknownTypes lists persisted types the canvas does not handle, and unreadableLines counts lines it could not parse. The Details tab shows the same counts. Compare a few entries of each changed kind in the log against the expected rendering.

  4. Read the release notes. The CLI package's changelog.json (beside its schemas/ folder) lists changes per version; scan the versions between the baseline and the new version for session events, compaction, hooks, subagents, system prompt, storage, and extension or canvas changes.

  5. Map each change to canvas code with references/coupling-map.md, and classify it:

    • Changed field that the indexer reads: read the new location first and fall back to the old one so earlier sessions still render.

    • New persisted type: decide whether it becomes a log entry, enriches an existing entry, updates counts or metadata, or stays generic. Add it to the indexer switch and HANDLED_EVENT_TYPES together; a test enforces that they match.

    • Removed type or field: keep reading it while sessions recorded by earlier versions can still contain it.

    • Ephemeral type: ignore unless it becomes persisted. In check mode, stop here and report.

  6. Apply the changes. Add synthetic events for each new or changed shape to the canvas test fixtures (never copy real session text), extend the indexer, server, and UI as needed, and keep the log grammar consistent with the style guide. Update the style guide's Log Grammar table and revision log, and the README when user-visible behavior or actions change.

  7. Validate:

    • npm run test:extensions and node --test ".github/skills/session-log-canvas-update/tests/*.test.mjs". PR validation runs both suites in its Node test lane.

    • node --check on changed modules, and npm run plugin:validate.

    • Markdown lint, spelling, table format, and frontmatter checks on changed Markdown.

    • A browser check on synthetic fixtures only: confirm the page URL before each screenshot, and never capture the live canvas because it shows real session content.

    • A host reload (extensions_reload, then reopen the canvas) with the served ui/ files matching disk.

  8. Refresh the baseline. Run node scripts/event-schema.mjs snapshot --schema <the schema you verified against> --write, rerun diff against it to confirm a clean report, and commit the baseline with the canvas changes. Both commands exit non-zero without writing anything when the file defines no session event types.

Constraints

  • Read session logs only through the canvas or for event type names, field names, counts, and sizes. Do not print, paste, or persist message, prompt, tool, or summary text from real sessions.

  • The script reads schema files, their package.json, and the baseline, and imports the canvas indexer, or the module passed with --indexer, to read its exported type lists. That module runs in the script's process, so pass --indexer only a module you trust. The script writes only to stdout or, with snapshot --write, to assets/event-shapes.json. SECURITY.md records its threat model.

  • The baseline keeps event and field identifiers and type signatures only, never schema descriptions.

  • Prefer a schema from a package whose license permits redistribution of derived identifiers for the committed baseline, such as the MIT-licensed @github/copilot-sdk-<platform> package bundled with VS Code.

  • Keep changes inside the canvas, its tests and docs, and this skill. Do not commit, push, or publish without the user's request.

Stop Rules

  • Stop and ask for a schema path when no installed schema is found and none was given.

  • Stop in check mode after the classified report.

  • Stop as Blocked when a change cannot be mapped to canvas behavior from the diff, release notes, and synthetic reproduction; report the type and fields and what evidence would settle it.

  • Stop as Revise when validation fails; report the failing check and do not refresh the baseline.

Final Response Contract

Report the versions compared, a classified table of changes (type or surface, change, canvas impact, action taken or proposed), files changed, validation results with exact commands, whether the baseline was refreshed and from which schema, and any blocked items with the evidence needed.

Files

references/coupling-map.md


description: 'Map of Copilot session data surfaces to the Session Log canvas code, tests, and docs that depend on them'

Session Log Canvas Coupling Map

Read this map when a schema diff, release note, or session check shows a change. Paths are relative to this file. The canvas root is extensions/hve-core/session-log.

Where Copilot Describes Its Session Data

Each installed Copilot package (<COPILOT_HOME or ~/.copilot>/pkg/<platform>/<version>/) and the package VS Code bundles (@github/copilot-sdk-<platform>) carry:

FileWhat it tells you
schemas/session-events.schema.jsonEvery event type, its data fields, and whether it is ephemeral
changelog.json (CLI package)Release notes per version
copilot-sdk/generated/session-events.d.tsThe same event types as TypeScript
copilot-sdk/generated/rpc.d.tsSession RPC methods, including the canvas open and action requests
copilot-sdk/canvas.d.tscreateCanvas, canvas actions, CanvasError, and the open result
copilot-sdk/extension.d.tsjoinSession and the extension entry contract
copilot-sdk/docs/extensions.mdExtension and canvas authoring guidance

Surfaces and Dependents

SurfaceRecorded asCanvas codeTests
Storage location<COPILOT_HOME or ~/.copilot>/session-state/<session id>/lib/paths.mjstests/paths.test.mjs
Session list metadataworkspace.yaml (name, summary, cwd, repository, branch, client_name, updated_at) and inuse.<pid>.locklib/sessions.mjs (CLIENT_LABELS; activity from live inuse.<pid>.lock files, also returned by each GET /api/poll answer as active), lib/yaml.mjstests/sessions.test.mjs and server tests (poll activity)
Event envelopeevents.jsonl lines with type, data, id, timestamp, parentId, and agentId for subagents. The log only grows by appending: a replaced, shortened, or same-size-changed file is indexed again under a new epochlib/indexer.mjs (SessionIndex, HANDLED_EVENT_TYPES); GET /api/poll epoch, next, and moretests/indexer.test.mjs, tests/fixtures.mjs, and server tests (eviction and paging)
Prompts, responses, and turnsuser.message, assistant.message, assistant.turn_start, assistant.turn_end, session.usage_recordIndexer #apply and withBodies; ui/render.mjs entry kindsIndexer and server tests
Tool callstool.execution_start, tool.execution_complete (result.content, result.detailedContent, error), external_tool.*Indexer tool cases and #toolPreviewIndexer tests (previews)
Subagentssubagent.* events with agentId; subagent.started.data.toolCallId links the spawning callIndexer subagent cases and #linkSubagent; agent tree in ui/app.mjsIndexer tests (nesting)
Hookshook.start and hook.end (hookInvocationId, hookType, input, output, error)Indexer hook pairing and PRE_TURN_HOOKSIndexer tests (hook runs)
Session lifecyclesession.start, session.resume (a root resume clears the earlier shutdown totals and end time; the shutdown entry stays in the log), session.shutdown (shutdownType, request and duration totals)Indexer session cases and getSummary sessionIndexer tests (shutdown and resume)
Compactionsession.compaction_start, session.compaction_complete, and the compaction call's model.messages_snapshot; the optional compactionAttemptId pairs a start with its completion, and a completion without a matching ID pairs with the agent's running compactionIndexer compaction cases, pickCompactionRequest, readCompactionText; GET /api/compaction in lib/server.mjsIndexer and server compaction tests
System promptsystem.message content and contentBlocks: tagged sections, <available_skills>, the instruction file table, <agent_instructions>Indexer analyzeSystemPrompt, diffSections, and prompt versions (the newest 500 kept, numbered from a running total, older ones re-read from their entries); GET /api/system-promptIndexer tests (prompt analysis and versions)
Model and contextsession.start, session.model_change, session.usage_record, session.usage_checkpoint (promptCacheBreakState)Indexer model, usage, and context tracking; getRecordedInventoryIndexer and inventory tests
Live inventoriessession.rpc: agent.list, agent.getCurrent, skills.list, skills.getInvoked, instructions.getSources, mcp.list, plugins.list, extensions.list, model.getCurrentlib/inventory.mjs (createLiveInventoryProvider)tests/inventory.test.mjs
Live definitionssession.rpc: tools.getCurrentMetadata (name, description, input_schema, mcpServerName, mcpToolName, deferLoading), agent.list with includePrompt, skills.list, instructions.getSources (content), canvas.list (canvasId, displayName, description, inputSchema, actions, extensionId), mcp.list (status, url, error, serverMetadata.instructions), plugins.list, extensions.list; the task tool's agent_type enum and its "Available agent types" and "User-provided custom agents" lines (- **name**:)lib/definitions.mjs (createLiveDefinitionProvider lookup and catalog, projectDefinition, agentListing, subagentCatalog); GET /api/definitiontests/definitions.test.mjs and server tests
Recorded definitionsskill.invoked (content, path, allowedTools, trigger, invokedAtTurn) and skill.invoked_ref (contentId), skill.context_delivered (content, the complete delivered text) and skill.context_delivered_ref (contentId, prefix, suffix) matched to the receiving agent by agentId and to the load by content ID, <skill> entries and the instruction table in system.message, session.usage_checkpoint tool schema_hash, tool call parts (latest call arguments and result), the opening text of a subagent's system.message and the root <agent_instructions> block (delivered agent prompts)Indexer getDefinition, skillPromptEntry, instructionPromptEntry, leadingPromptText, agentInstructionsBlock, agentNameKeyIndexer tests (recorded definitions)
Recorded inventories<canvas> entries (<id>, <name>, <description>) in system.message; open_canvas, invoke_canvas_action, and list_canvas_capabilities arguments (canvasId, instanceId, actionName) and the capabilities JSON in result.content; session.canvas.recorded and session.canvas.removed; tool.execution_start mcpServerName; view path arguments; system.notification instruction_discovered; tool_search.activated toolNames; root subagent.selected; hook.end error.source and output.additionalContextIndexer analyzeSystemPrompt, canvasPromptEntry, getRecordedInventory, getReadCounts, and the canvas, hook, MCP, and read records; lib/context.mjs (buildContextSections); GET /api/inventory sections and part=countsIndexer, tests/context.test.mjs, and server tests
Canvas SDK@github/copilot-sdk/extension: joinSession, createCanvas, CanvasError, the open request sessionIdextension.mjs, lib/lifecycle.mjs, lib/actions.mjsLifecycle, actions, and static tests

Documentation to Keep in Step

  • STYLE-GUIDE.md: the Log Grammar table names the source events behind each log kind, and the revision log records each update.

  • README.md: data locations, agent actions, and user-visible behavior.

Requirements and compatibility

Written for: GitHub Copilot, Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter, Needs Node.js

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/hve-core · .github/skills/session-log-canvas-update · commit f425e94
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download session-log-canvas-update.zip