Chronicle

Analyze the user's Copilot session history using the copilot_sessionStoreSql tool. This skill handles standup reports, usage analysis, session search, and session store maintenance.

Sessions may be stored locally (SQLite) and optionally synced to the cloud for cross-device access. Cloud sync is controlled by the chat.sessionSync.enabled setting.

Prerequisite: Chronicle requires the github.copilot.chat.localIndex.enabled setting to be true. If the copilot_sessionStoreSql tool is not available, tell the user to enable this setting in VS Code Settings.

Available Tool Actions

The copilot_sessionStoreSql tool supports two actions:

Workflows

Standup

When the user asks for a standup, daily summary, or "what did I do" (e.g. /chronicle standup):

Step 1: Gather the last 24h of activity

Use copilot_sessionStoreSql with action: "query" and follow the SQL dialect shown in the tool description (SQLite locally, DuckDB on cloud — see the Database Schema and Query Guidelines sections below).

Query the sessions table for rows where updated_at falls within the last 24 hours, ordered by updated_at descending. Recent-window predicate by backend:

• Local SQLite: WHERE updated_at >= datetime('now', '-1 day')
• Cloud DuckDB: WHERE updated_at >= now() - INTERVAL '1 day'

Then, for those session ids, pull related references from session_refs (PRs, issues, commits). If you need more detail on a particular session, query turns (and session_files, or checkpoints on cloud) further — don't dump every turn for every session up front.

If no sessions are found in the last 24 hours, tell the user there's no recent activity to report, suggest a longer window or /chronicle reindex, and stop. Do not fabricate a standup.

Step 2: Include PR-less work

Treat every recent session as a candidate work item, even when it has no PR, issue, or commit reference. PRs are supporting evidence, not the source of truth. Do not omit a session or branch solely because it has no PR — use session summaries and turn content to decide what to include.

Step 3: Check PR status and format

For any PR references found, use the GitHub CLI or MCP tools to check current status (open, merged, draft, closed). For each work item, include either a PR status line or a "No PR found" line — never invent a PR.

Format the result grouped by work stream (branch/feature). Use exactly this structure:

Standup for <date>:

**✅ Done**

**Feature name** (`branch-name` branch, `repo-name`)
  - 3-7 words describing the status
  - Key files: 2-3 most important files changed
  - Merged: [#123](https://github.com/owner/repo/pull/123) or No PR found
  - Session: `full-session-id`

**🚧 In Progress**

**Feature name** (`branch-name` branch, `repo-name`)
  - 3-7 words describing the current state of work
  - Key files: 2-3 most important files being worked on
  - Draft: [#789](https://github.com/owner/repo/pull/789) or No PR found
  - Session: `full-session-id`

Rules:

• Keep it concise and succinct — the user can always ask follow-up questions
• Use turn data (user messages AND assistant responses) to understand WHAT was done
• Use file paths from session_files to identify which components/areas were affected
• Group related sessions on the same branch into one entry
• For sessions, only show the most recent session per feature/branch
• Link PRs and issues using markdown link syntax
• Classify as Done if work appears complete, In Progress otherwise
• If a session has no branch or repo, include it under an "Other" section

Tips

When the user asks for tips, workflow recommendations, or how to improve:

Step 1: Investigate how the user works

…