claude-sql

Query the user's own Claude Code transcript history with SQL, semantic search, and LLM-driven analytics. Use this skill whenever the user asks about their past Claude sessions, their coding history with Claude, what they worked on last week/month/quarter, how much they spent on Opus or Sonnet, which sessions succeeded or failed, their autonomy patterns, the themes across their work, recurring topics, todos they never closed, or any analytical question about their own ~/.claude/ transcripts. Also triggers for "my claude history", "my claude sessions", "my transcripts", "analyze my sessions", "what did I do in claude", "search my conversations", "my opus cost", "my claude spend", "autonomy tier", "work categories", "group my sessions", "cluster my work", "find sessions about X", "sessions where I disagreed with myself", or any phrasing that implies analyzing the user's own Claude Code corpus.

Use when the user asks for a deterministic code pack of a repo or group — a 9-item BOM (manifest, skeleton, file-tree, deps, ast-chunks, xrefs, optional embeddings sidecar, findings, licenses + readme) that is byte-identical given the same (commit, tokenizer, budget). Examples: "pack this repo for an LLM", "deterministic code pack", "build a reproducible context pack", "pack the platform group". DO NOT use for one-off repo packing without determinism — `pack_codebase --engine repomix` is the bandwidth-saving fallback for that case (no packHash, no 9-item BOM, no reproducibility contract).

Use when the user asks for a cross-repo contract map, an API-consumer matrix, or a service-interaction diagram across a repo group. Examples: "map the HTTP contracts between services", "which services call the billing API", "show the contract matrix for the platform group". GROUP MODE ONLY — requires a named group. DO NOT use on a single repo (use `codehub-document` with `reference/public-api.md`). DO NOT use if `mcp__codehub__group_list` does not include the group.

Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug", "This endpoint returns 500".

Use when the user asks to generate, regenerate, or refresh long-form codebase documentation, an architecture book, a module map, or a per-repo reference — especially after `codehub analyze` finishes or after a large merge. Examples: "document this repo", "regenerate the architecture docs", "write a module map for the monorepo", "produce a group-wide portfolio doc". DO NOT use if the repo is not indexed — run `codehub analyze` first and confirm `mcp__codehub__list_repos` returns the repo. DO NOT use for PR descriptions (use `codehub-pr-description`), onboarding docs (use `codehub-onboarding`), or cross-repo contract maps alone (use `codehub-contract-map`).

Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of a codebase. Examples: "How does X work?", "What calls this function?", "Show me the auth flow", "Where does the request enter the system?".

Use when the user asks about OpenCodeHub itself — available MCP tools, resources, graph schema, or workflow reference. Examples: "What OpenCodeHub tools are available?", "How do I query the code graph?", "Show me the schema".

Use when the user wants to know what will break if they change something, or needs safety analysis before editing or merging code. Examples: "Is it safe to change X?", "What depends on this?", "What will break?", "Blast radius for this change".

Use when the user asks for an ONBOARDING, getting-started, or new-engineer guide for the current repo or group. Examples: "write ONBOARDING.md", "generate an onboarding doc for new hires", "what should a new engineer read first". Produces a ranked reading order from `project_profile` + top processes + entry points + owners + centrality. DO NOT use for full architecture books (use `codehub-document`) or PR summaries (use `codehub-pr-description`).

Use when the user asks for a PR description, a pull request summary, a merge write-up, or a release note for a branch or diff. Examples: "write the PR description", "summarize this branch for review", "draft release notes for HEAD". Calls `detect_changes` + `verdict` + `owners` + `list_findings_delta` and writes Markdown. DO NOT use for open-ended architecture docs (use `codehub-document`) or onboarding guides (use `codehub-onboarding`). DO NOT use when no diff exists — the skill refuses on a clean tree.

Use when the user wants to review a pull request, understand what a PR changes, assess risk of merging, or check missing test coverage. Examples: "Review this PR", "What does PR #42 change?", "Is this PR safe to merge?", "Audit the dependencies in this PR".

Use when the user is planning a rename, extraction, split, move, or restructure and wants to know the blast radius and verify the result. Examples: "What breaks if I rename this function?", "Map every caller before I extract this module.", "Did my refactor touch anything I didn't expect?". OpenCodeHub does NOT edit source — it plans and verifies; you (or your editor) apply the edits.