Meticulous Use Session Data

by alwaysmeticulousdeb5e45e6e56No license10 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated today

Download and use structured Meticulous session data (user flows + network mocks) for testing code changes locally. Use when you need to understand what user interactions and API calls a test covers, or when you want network mocks for writing tests.

Instructions onlySoftware Development
AI-generated overview

Downloads recorded Meticulous session data — user flows and network mocks — so agents can inspect and reuse it for local testing.

What it does
Guides an agent through running the Meticulous CLI to find recorded sessions that exercise code changed on the current branch, then download their data as a structured directory tree under .meticulous/sessions/. It explains the output layout (manifest, per-session summaries, user events, network requests, storage state, URL history, context and WebSocket data) and how to navigate it. It also covers downloading specific sessions by ID and submitting a short feedback note to Meticulous afterwards.
When to use it
Use it when you need to understand which user interactions and API calls a recorded test covers, or when you want real request/response pairs to build network mocks for tests. It fits local verification of code changes against recorded session data.
Requirements
The Meticulous CLI (and optionally the Meticulous MCP tools) plus access to the Meticulous service; commands run from the root of a git repository. No scripts ship with the skill — it is instructions only.

Use this workflow to get structured session data from Meticulous — the recorded user flows and network mocks that cover your code changes.

Before starting, run the meticulous-cli-update skill to ensure the Meticulous CLI and skills are up to date — unless it has already run earlier in this conversation, in which case skip it.

Step 1 — Find relevant sessions and download their data

Run the following command from the root of the git repository:

bash
meticulous local relevant-sessions --format=multi-file --minimum-times-to-cover-each-line=1

This will:

  1. Identify which recorded sessions exercise the code paths changed on your current branch.
  2. Download each session's data as a structured directory tree to .meticulous/sessions/.

Options:

OptionTypeDefaultDescription
--formatmulti-file—Set to multi-file to download each relevant session's data as a structured directory tree
--minimum-times-to-cover-each-linenumber—Select at least this many sessions to cover each edited line, choosing the most diverse subset when more candidates are available
--include-superfluous-sessionsbooleanfalseAlso include sessions that do test some changes but were superfluous given --minimum-times-to-cover-each-line
--outputDirstring.meticulous/sessionsOutput directory for multi-file format
--showMaybeRelevantbooleanfalseAlso show sessions that may be affected
--startingPointShastring—Only consider changes since this commit SHA

Step 2 — Understand the output structure

The downloaded data is organized as follows:

.meticulous/sessions/  manifest.json                       # List of all sessions with summary metadata  sessions/    <sanitized-session-id>/           # Special characters in session IDs are replaced for filesystem safety      summary.json                    # Session overview: URL, viewport, duration, event count      user-events.json                # Sequence of user interactions (clicks, typing, navigation)      network-requests/        summary.json                  # All network requests: method, URL, status (no bodies)        <order>.json                  # Individual request/response pairs (with bodies)      storage/        cookies.json                  # Initial cookie state        local-storage.json            # Initial localStorage state        session-storage.json          # Initial sessionStorage (if present)        indexed-db.json               # Initial IndexedDB (if present)      url-history.json                # Page navigation history with timestamps      context.json                    # Feature flags, user ID, custom context (if present)      websockets/                     # WebSocket data (if present)        summary.json                  # WebSocket connections overview        <connection-id>.json          # Events for each connection

Step 3 — Navigate the data

  1. Start with manifest.json to see all available sessions. Each entry includes the session ID, start URL, event count, duration, and network request count. Pick the session(s) relevant to your task.

  2. Read summary.json inside a session directory for a quick overview of that session — the starting URL, viewport size, total duration, and number of events.

  3. Read user-events.json to understand the user flow. Each event has:

    • type: the interaction type (e.g., click, input, scroll)
    • selector: the CSS selector of the target element
    • timestampMs: when the event occurred
    • coordinates: click position (if applicable)
  4. Browse network-requests/summary.json to see all API calls made during the session. Each entry shows the HTTP method, URL, status code, content type, and response time — without response bodies, so it's quick to scan.

  5. Read individual network-requests/<order>.json files for the full request/response data of specific API calls. Use these as mock data when writing tests. The order field in the summary corresponds to the filename.

  6. Check storage/ files if you need to understand the initial application state (cookies, localStorage, etc.).

Step 4 — Use the data for testing

Common use cases:

Understanding user flows

Read user-events.json to see the exact sequence of user interactions. This tells you what the user clicked, typed, and navigated, which helps you understand what your code change needs to support.

Creating network mocks

Use the network request files to create mock responses for your tests:

  1. Read network-requests/summary.json to find the relevant API endpoints.
  2. Read the individual network-requests/<order>.json files for the full request/response pairs.
  3. Use the response.content.text field as mock response data in your tests.

Verifying coverage

Cross-reference the user events and network requests with your code changes to verify that the session covers the code paths you've modified.

Alternative: Download specific sessions

If you already know which session IDs you need, you can download them directly:

bash
# CLImeticulous download session --sessionId=<id> --format=multi-file
# MCP (returns the same structured data inline instead of writing it to disk)get_session_data(sessionId="<id>")

The CLI writes to .meticulous/sessions/ by default; use --outputDir to change the output location.

Final step — Report feedback to Meticulous

Once you've finished using the session data, submit one brief feedback note to the Meticulous team: did the session data cover the flows you needed, and what information was missing or would have made the task easier?

bash
# CLImeticulous agent submit-feedback --message="<one or two sentences>" --outcome=<helped|neutral|hindered> --skill=meticulous-use-session-data
# MCPsubmit_feedback(message="<one or two sentences>", outcome="<helped|neutral|hindered>", skill="meticulous-use-session-data")

Source and attribution

Source:alwaysmeticulous/skillsinskills/meticulous-use-session-dataat commitdeb5e45

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal