Skip to content
cccskills
Official · MicrosoftFreePublished on GitHub

session-log-canvas-update

Compare installed Copilot session event schemas with the Session Log canvas baseline, classify changes, and guide code, fixture, documentation, and baseline updates. It helps keep new session data visible while preserving readability for sessions recorded by earlier versions.

OriginalShow the original description

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.

microsoft/hve-core1,580 stars(GitHub 1,580 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Check schema changes after updating Copilot
  • Investigate unknown events or missing canvas data
  • Update rendering and synthetic fixtures for changed events
  • Refresh the verified event schema baseline

Files included (6)

  • SKILL.md7.9 KB
  • assets/event-shapes.json128.4 KB
  • references/coupling-map.md22.3 KB
  • scripts/event-schema.mjs29.2 KB
  • SECURITY.md29.8 KB
  • tests/event-schema.test.mjs18.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

accessibility

Official · MicrosoftFreeSummary

Support accessibility planning and checks using references such as WCAG 2.2, ARIA Authoring Practices, and cognitive accessibility guidance. Its tools can scan pages and organize runtime evidence, while distinguishing automated findings from checks that require interaction or assistive technology.

  • Plan accessibility standards and evidence for a project
  • Scan a page for automated accessibility findings
  • Review whether keyboard behavior needs manual checks
microsoft/hve-core1.6KUpdated Oct 28, 2026

accessibility-coverage-matrix

Official · MicrosoftFreeSummary

Builds an accessibility coverage matrix across standards, interface surfaces, and evidence methods. It calculates coverage only from methods considered adequate for each criterion and produces a report plus a bundle of supporting evidence, including items that still need human testing.

  • Compare accessibility coverage across pages and components
  • Refresh a matrix with new test findings
  • Report coverage gaps and pending human checks
microsoft/hve-core1.6KUpdated Oct 28, 2026

adr-author

Official · MicrosoftFreeSummary

Create Architecture Decision Records that capture scope, decision makers, drivers, options, rationale, and consequences. Choose a concise Y-Statement or MADR v4 format, start from a planner handoff, or adopt an existing project template while preserving supersession history.

  • Record the reasoning behind an architecture choice
  • Compare options and document tradeoffs
  • Create an ADR from a planner handoff
microsoft/hve-core1.6KUpdated Oct 28, 2026

analysis-authoring

Official · MicrosoftFreeSummary

Plan and review exploratory data analysis notebooks and analytical dashboards. Choose sections and charts based on the question and available data, handle dense scales deliberately, document interpretations and limits, and check dashboard behavior against performance budgets.

  • Plan the structure of an exploratory analysis notebook
  • Choose charts for an analytical question
  • Review dashboard responsiveness and completeness
microsoft/hve-core1.6KUpdated Oct 28, 2026

architecture-diagrams

Official · MicrosoftFreeSummary

Turns supported infrastructure files or a declared data catalog into an architecture diagram in the requested ASCII or Mermaid format. It shows confirmed components and relationships while keeping inferred catalog links visibly distinct and avoiding unsupported assumptions.

  • Visualizing cloud infrastructure from configuration files
  • Preparing a diagram for an architecture review
  • Rendering declared data catalog relationships
microsoft/hve-core1.6KUpdated Oct 28, 2026

architecture-review

Official · MicrosoftFreeSummary

Create a lasting architecture review record that captures confirmed scope, evidence, assumptions, pillar findings, trade-offs, recommendations, and reviewer decisions. It keeps analysis traceable and links significant accepted decisions to ADRs while leaving decision authority with the user.

  • Recording findings from a system architecture review
  • Tracking evidence and assumptions across review areas
  • Documenting why recommendations were accepted or deferred
microsoft/hve-core1.6KUpdated Oct 28, 2026

See all skills by microsoft

Report a problem with this skill