sessionview: Skill for Claude Code

Add a SessionView Provider

Treat a provider as a normalization and indexing boundary, not just a parser. A complete integration discovers current source artifacts, maps them into SessionView's model without invented values, connects every backend/frontend boundary, and proves the result against synthetic and real sessions.

The AI performs the investigation directly with ordinary read-only tools. Do not create persistent discovery, parsing, or validation scripts as a substitute for reading actual sessions and source. Add a helper script only when the user explicitly asks for one or a repeated deterministic transformation genuinely requires it; scripts are never the default provider workflow.

Read AGENTS.md, style/rust.md, and style/ts.md first. Then read:

• Source research before designing or changing a parser.
• Evidence and work modes to establish authority, output, and proof status.
• Provider contract for every provider.
• Discovery and freshness when locating files, databases, sidecars, assets, or incremental state.
• Subagents when the tool delegates work, stores child logs, or exposes agent/task calls.
• Messages, tools, and images when mapping content blocks, tool calls/results, reasoning, attachments, or generated media.
• Usage and cost whenever the source records tokens, cache traffic, model calls, or provider cost.
• Controlled live-session generation when the existing local corpus does not exercise a source capability that must be verified.
• Cross-layer checklist before declaring implementation complete.
• Real-data validation before final handoff.

Workflow

1. Select add, extend, audit, or repair mode and write the evidence/acceptance matrix from Evidence and work modes. Audit is read-only unless the user also requests fixes.
2. Establish the current product identity, CLI executable, installed version, source roots, resume syntax, wire/schema version, and mutable sidecars. Read representative real local sessions directly. Do not infer a product from a misspelling when local evidence can resolve it.
3. Classify the official repository correctly. An issue tracker, binary distribution repository, documentation repository, or package shell is not an open-source implementation. When implementation source exists, read the writer and reader code, types, migrations, subagents, tools, images/assets, usage/cost, branching/compaction, and CLI resume, reconciling installed and repository versions. Otherwise use the closed-source fallback and inspect installed bundles/types/schema; documentation alone is insufficient.
4. Choose the closest existing SessionView providers by storage and behavior; complex integrations usually need more than one reference provider. Record which target-source fields authoritatively supply identity, ordering, title, project, model, parent/child links, tools, images, and usage.
5. Build read-only discovery and parsing around provider-specific typed signals. Preserve valid partial sessions, count malformed or unknown visible records, and log exact context. Never scan message text to invent structural relationships.
6. Normalize into ParsedSession and Message, then implement load_messages against the same identity rules. Add incremental freshness only after the complete source graph is mapped and every mutable input has its own mutation regression.
7. Connect all backend, frontend, security, documentation, and resume surfaces. Use exhaustive Rust matches and Record<Provider, ...> maps to expose missing work; do not weaken them with wildcard/default branches. Follow the substantial-provider directory layout and file-size limit in Provider contract.
8. Verify synthetic edge cases, multiple representative real sessions, sanitized parse coverage, isolated index/command round trips, GUI/headless gates, and the running UI where visible behavior changed. When the existing real corpus lacks a required capability, report it as unobserved or generate the smallest controlled persistent session when authorized; never treat absence as proof of unsupported behavior.