/chronicle

name: chronicle
description: Analyze Copilot session history for standup reports, usage tips, session search, and session reindexing. Use when the user asks for a standup, daily summary, usage tips, workflow recommendations, wants to search or find past sessions by keyword/file/PR, wants to reindex their session store, or asks about deleting session data.

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:

| Action | Purpose | `query` param | |--------|---------|---------------| | `query` | Execute a read-only SQL query | Required | | `reindex` | Rebuild local session index + cloud sync | Not needed |

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**

Use `copilot_sessionStoreSql` with `action: "query"` to explore their recent sessions. The goal is to understand their patterns — how they prompt, what tools they use, and where they spend time.

Queries to run (do not explain what you will do first — start querying immediately):

• Sessions from the last 7 days: counts, durations, repositories
• Turn data: read actual user messages to understand prompting patterns
• session_files: which files and tools are used most frequently
• session_refs: PR/issue/commit activity patterns

**Step 2: Consider available features**

If the current workspace has a `.github/` folder, check for `.github/copilot-instructions.md`, `.github/skills/`, and `.github/agents/` to see what custom configuration exists. Do NOT look outside the workspace. Look for gaps between what's available and what the user actually uses.

**Step 3: Provide tips**

Based on what you learned, provide 3-5 specific, actionable tips. Each tip should:

• Be grounded in actual usage data — reference specific patterns you observed
• Be non-obvious — skip basic features that any regular user would already know
• Focus on gaps where a feature, workflow change, or different approach would meaningfully improve their experience

Analysis dimensions to explore:

• **Prompting patterns**: Are user messages vague or specific? Do they provide context? Do they correct or redirect the agent frequently?
• **Tool usage**: Which tools are used most? Are there underutilized tools that could help?
• **Session patterns**: How long are sessions? Are there many short abandoned sessions?
• **File patterns**: Which areas of the codebase get the most attention? Any repeated edits to