chronicle

What this skill does

# 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 the same files?
- **Workflow**: Is the user leveraging agent mode, custom instructions, prompt files, skills?

If the session store has little data, acknowledge that and suggest features to try based on what configuration you found in the workspace.

When recommending custom skills, agents, or instructions as a tip, consult the **agent-customization** skill for proper file creation patterns — don't give vague "create a custom skill" advice without actionable file structure guidance.

### Cost Tips

When the user asks for cost tips, ways to reduce token usage, or how to lower Copilot spend (e.g. `/chronicle cost-tips`):

The goal is **personalized, data-grounded recommendations** for reducing token usage — not a generic checklist. Every tip must point to a specific pattern you observed in their data.

**Scope: focus on VS Code chat sessions**

Other agent surfaces (Copilot CLI, Copilot Coding Agent, Copilot Code Review, custom agents/subagents) have very different cost profiles and would skew the analysis. By default, **filter every query to the interactive VS Code chat surface** so findings reflect that usage only. Only widen the scope if the user explicitly asks about CLI, Coding Agent, or custom agents — and when you do, run separate queries per agent type rather than mixing them.

The stored `agent_name` differs by backend — match the active backend's value **exactly** (case and spacing matter):

- **Cloud (DuckDB)**: `sessions.agent_name = 'VS Code Chat'`
- **Local (SQLite)**: `sessions.agent_name = 'GitHub Copilot Chat'`. Local also records subagent invocations (e.g. `Explore`, `summarizeConversationHistory`) as their own session rows; the default filter correctly excludes them.

Briefly check the agent mix once so you know what's being excluded (e.g. `SELECT agent_name, COUNT(*) AS n FROM sessions WHERE updated_at > <30-day cutoff> GROUP BY 1 ORDER BY n DESC`). If the interactive chat value is a small minority of the user's sessions, mention that in the summary so they know the tips are scoped to a slice of their activity, and **offer to run a separate pass on another agent type** — name the candidates you saw in the mix check (e.g. "want a separate pass on `Copilot CLI` or `Copilot Coding Agent`?") so the user knows widening is possible.

If the user asks to widen scope to a specific surface (e.g. "now do CLI", "cost