@smartsoft001-mobilems/claude-plugins 2.83.0 → 2.85.0

package/plugins/flow/skills/mobilems-docs-reader/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: mobilems-docs-reader
+description: Answer questions about the MuzaCMS / MobileMS indexer API by reading a freshly-fetched OpenAPI spec. Use whenever the user asks about endpoints, request/response shapes, status codes, auth, or behavior of the indexer API (host develop-indexer-api.mobilems.pl). Read-only — never fabricates endpoints.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+---
+
+You answer questions about the **MuzaCMS / MobileMS indexer API** strictly from the OpenAPI (Swagger 2.0) specification. You never invent endpoints, schemas, or status codes — if it is not in the spec, you say so plainly.
+
+The spec is **not bundled**. It is fetched from the live MuzaCMS instance by a refresh script that lives next to this skill, using credentials supplied via environment variables. The script caches the fetched spec per Claude Code session (with an 8-hour TTL safety net), so it may skip the actual network call and reuse a cached copy on follow-up invocations within the same session.
+
+## Step 1 — Run the refresh script (mandatory)
+
+On every invocation, run the refresh script via Bash. The script itself decides whether to actually fetch — it owns the cache. Your job is only to run it and react to the result. A successful run may be either:
+
+- A real fetch (`Refreshing MuzaCMS API spec from ... → GET /admin/login → POST /admin/login → GET /docs/api → ✓ Refreshed N bytes ...`), or
+- A cache hit (`✓ spec cached for this Claude Code session (refreshed N min ago at ...), skipping fetch`).
+
+Both are exit-code-0 successes. Treat them identically and proceed to Step 2. **Do not** attempt to bypass the cache, delete the cache file, or force a refetch — the cache is intentional and the script's decision is authoritative.
+
+### Invocation
+
+The refresh script is shipped per plugin variant under `plugins/<variant>/scripts/`. Invoke it through `bash` so the executable bit is irrelevant:
+
+```
+bash ./node_modules/@smartsoft001-mobilems/claude-plugins/plugins/flow/scripts/refresh-mobilems-api-spec.sh --quiet
+```
+
+Outcomes:
+
+- **Success (exit 0)** → jump to Step 2.
+- **Script-level error** (missing env vars, missing tooling, auth rejected, HTTP error, parse failure, etc.) → jump to the matching Fail mode below.
+- **Permission denied by Claude Code** → jump to "Fail mode — permission denied".
+
+The script reads two environment variables — `MOBILEMS_LOGIN` and `MOBILEMS_PASSWORD` — performs the Symfony CSRF + session login against `https://develop-indexer.mobilems.pl`, fetches `/docs/api`, and writes the spec to `shared-assets/mobilems-api.json` inside the installed package. It also auto-loads `.env` from the current working directory; no shell sourcing is needed.
+
+### Fail mode — permission denied by Claude Code
+
+If the Bash call is rejected by Claude Code's permission system, stop and tell the user verbatim:
+
+> The MuzaCMS spec could not be refreshed because Claude Code denied permission to run the refresh script. To allow it, add this entry to your project's `.claude/settings.json` (committed) or `.claude/settings.local.json` (per-dev, gitignored) under `permissions.allow`, then ask again:
+>
+> - `"Bash(bash ./node_modules/@smartsoft001-mobilems/claude-plugins/plugins/flow/scripts/refresh-mobilems-api-spec.sh:*)"`
+
+Do not attempt to answer the user's question from training knowledge. Do not invent alternative invocation patterns to try to bypass the denial.
+
+### Fail mode — missing env vars
+
+If the script exits non-zero with a message starting `✗ Brak wymaganych zmiennych środowiskowych` (or English equivalent listing `MOBILEMS_LOGIN` / `MOBILEMS_PASSWORD`), **stop immediately**. Relay the script's message verbatim to the user.
+
+Do not attempt to answer the user's question from training knowledge. Do not guess. Do not read any pre-existing `mobilems-api.json` that may be lying around in `node_modules/` — without a successful refresh you have no confirmation it is current.
+
+### Fail mode — missing tooling
+
+If the script exits with a message about missing `curl` or `jq`, relay it verbatim. The script tells the user exactly how to install the missing dependency (`brew install jq` / `apt install jq`).
+
+### Fail mode — other script failures
+
+If the script fails for any other reason (HTTP error, auth rejected, parse failure), report the exact error message from the script back to the user and stop. Do not answer the API question.
+
+## Step 2 — Locate the freshly-written spec
+
+Use `Glob` with this pattern:
+
+```
+**/claude-plugins/**/shared-assets/mobilems-api.json
+```
+
+The hit lives under `node_modules/@smartsoft001-mobilems/claude-plugins/shared-assets/` after a successful refresh. Exclude `dist/` and `tmp/` from the Glob, but **do** allow `node_modules/`.
+
+If the Glob returns nothing after the refresh script reported success, something is wrong with the install layout — tell the user and stop.
+
+## Step 3 — Answer from the spec
+
+The spec is **Swagger 2.0** with this wrapping shape:
+
+```
+{ "spec": { "swagger": "2.0", "paths": {...}, "definitions": {...} } }
+```
+
+Always traverse into `.spec` first.
+
+When the user asks about endpoints:
+
+1. **Locate the path** in `spec.paths`. Look for the exact path the user mentioned, including any path parameters (`{id}`).
+2. **Quote the HTTP method(s) and path verbatim.** Example: `GET /api/objects/{id}`.
+3. For request bodies and responses, cite the `$ref` target by name and (briefly) summarize its shape from `spec.definitions`.
+4. For status codes, list each documented response from `responses` with its `description`.
+5. For auth, check both the operation-level `security` and the global `spec.securityDefinitions`.
+
+If the user asks about a path that is **not in the spec**, say so explicitly:
+
+> The spec does not document a `DELETE /api/articles/{id}` endpoint. The articles paths in the spec are: `[list actual paths]`. If you've seen this endpoint elsewhere, it may exist in the running service without being documented — verify with a live request.
+
+## Known caveats — always surface when relevant
+
+- **Response schemas occasionally diverge from runtime.** Documented response shapes have, in practice, not always matched what the live API actually returns. When the user is about to implement against a response schema, add a brief reminder to verify with a real request before relying on the documented shape.
+- **Spec is regenerated server-side from PHP annotations.** Newly added endpoints in the live service may not appear until the next backend deployment, even with a fresh fetch.
+- **Auth flow nuance:** the spec describes the indexer API itself; the `/admin/login` flow used by the refresh script is separate and not documented in the spec.
+
+## Answering style
+
+- Be terse. The user wants a specific fact, not a tutorial on Swagger.
+- Always include exact path + method + relevant status codes when applicable.
+- When quoting definitions, use the schema name (e.g., `Object`, `Unauthorised`) as it appears in `spec.definitions`.
+- If multiple endpoints match a vague question, list them — don't pick one arbitrarily.
+
+## When NOT to use this skill
+
+- Non-MobileMS APIs (any other host).
+- Generic REST/OpenAPI guidance unrelated to the indexer.
+- Schema design decisions ("should I add X field?") — this skill only describes what exists.
+- Anything requiring a live network call to the API itself.

package/plugins/flow/skills/plan/SKILL.md

@@ -31,7 +31,7 @@ Create an implementation plan for a Linear task and save it as a `plan.md` attac
 
 These rules override ANY other instruction, ANY surrounding example, and ANY default habit. Violating them is a skill failure.
 
-1. **The plan MUST be saved via `mcp__linear__create_attachment` — NEVER as a Linear comment.** `mcp__linear__save_comment` MUST NOT be called with plan content as the body. Comments are reserved for status notifications (e.g., "no plan attachment found, run /plan again"), never for the plan itself. If you find yourself about to call `save_comment` with `## Implementation Plan` in the body — STOP. That's a bug.
+1. **The plan body MUST be saved via `mcp__linear__create_attachment` — NEVER as a Linear comment.** `mcp__linear__save_comment` MUST NOT be called with plan content as the body. Comments are reserved for: (a) status notifications (e.g., "no plan attachment found, run /plan again"), and (b) the single token-usage comment posted in Step 9c. No other comment may carry plan content. If you find yourself about to call `save_comment` with `## Implementation Plan` in the body — STOP. That's a bug.
 
 2. **One call, no fallback.** The first Linear write for the plan is `mcp__linear__create_attachment`. If it fails, surface the error to the user — do NOT silently fall back to `save_comment`.
 
@@ -55,7 +55,7 @@ Execute each step in order. Do not skip any step marked as MANDATORY.
 - [ ] **8. Analyze external library deps** — check if `@smartsoft001` or `@smartsoft001-mobilems` changes are needed (mark as separate process)
 - [ ] **9. Create implementation plans** — generate structured plans per task/subtask with all required sections
 - [ ] **10. MANDATORY: Write plans in Polish** — all plan content must be in Polish language
-- [ ] **11. Show plans to user** — present plans for review and approval before saving (skipped in `--auto`; proceed directly to save)
+- [ ] **11. MANDATORY: Get user approval of generated plan** — present the full plan content in the chat, then call `AskUserQuestion` with three options: save / regenerate / cancel. Save and label steps below MUST NOT run without approval. Skipped only in `--auto` (auto-approved; logged in audit comment).
 - [ ] **12. MANDATORY: Confirm old plan deletion** — if replacing existing `plan.md`, ask user to confirm deletion of old attachment before proceeding (skipped in `--auto`; delete old attachment automatically)
 - [ ] **13. MANDATORY: Save plan as native Linear attachment** — base64-encode `plan.md` content and upload via `mcp__linear__create_attachment`. **Calling `mcp__linear__save_comment` for the plan body is FORBIDDEN.** Linear hosts the file natively; no external storage.
 - [ ] **14. MANDATORY: Add "AI Plan" label** — ensure `AI Plan` label exists on the team and apply it to the invoked issue (the `linearTaskId` passed to `/plan` — parent task or subtask, whichever was called)
@@ -132,13 +132,13 @@ You create plans that are:
 
 | Default behavior                                                  | `--auto` override                                                                                |
 | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
-| Show plans to user for review/approval before saving              | Skip the review step; proceed directly to attachment save                                        |
+| Final approval of generated plan content before saving            | Skip the approval gate; proceed directly to attachment save (auto-approve)                       |
 | Ask user to confirm deletion of old `plan.md` attachments         | Delete old attachments automatically before saving new ones                                      |
 | Ask "regenerate anyway?" when all plans are up-to-date            | Exit cleanly with a Linear comment noting all plans are current; no regeneration                 |
 | Secondary signal prompt (keyword-triggered confirmation to regen) | Ignore the secondary signal; only the mtime rule decides regeneration                            |
 | `AskUserQuestion` for any decision                                | Use the option marked **(Recommended)**; if none, fail fast with a Linear comment explaining why |
 
-**Hard requirement in `--auto`**: every decision (save, replace, skip) MUST be logged as a Linear comment in Polish so the run remains auditable after the fact. The mtime rule remains authoritative — `--auto` does not change *what* gets regenerated, only that no human is asked.
+**Hard requirement in `--auto`**: every decision (save, replace, skip) MUST be logged as a Linear comment in Polish so the run remains auditable after the fact. The mtime rule remains authoritative — `--auto` does not change _what_ gets regenerated, only that no human is asked.
 
 **Detection**: The flag `--auto` is provided as a positional/named arg. Treat any of `--auto`, `--ci`, `--non-interactive` as equivalent. Combinable with `--deep` (deep team mode runs without the final approval prompt).
 
@@ -675,13 +675,47 @@ When using `--deep` flag and the Planning Team has completed its analysis, appen
 - 2: Significant disagreements on approach
 - 1: Fundamental disagreements — plan needs revision
 
+### Step 8a: User Approval of Generated Plan
+
+**MANDATORY.** Before any Linear write (deletion of old `plan.md`, creation of new `plan.md`, label apply), the user MUST approve the generated plan content. This is the gate FRA-126 added.
+
+**`--auto` mode**: Skip this entire step. The plan is auto-approved. Record the auto-approval in the final Linear audit comment (e.g. `Plan zaakceptowany automatycznie (--auto)`). Proceed to Step 9.
+
+**Default mode** (interactive):
+
+1. **Render the full plan(s) in chat.** Print the markdown produced in Step 8 for every task/subtask that needs planning. The `AskUserQuestion` option labels alone do not give the user enough context — the full text must be visible above the prompt.
+
+2. **Ask for approval** via `AskUserQuestion`:
+
+   ```markdown
+   ## Akceptacja planu
+
+   Powyżej znajduje się wygenerowany plan dla zadania <linearTaskId> (oraz <N> podzadań, jeśli dotyczy).
+   Czy akceptujesz plan i mogę zapisać go jako załącznik `plan.md` w Linear?
+   ```
+
+   Options (use exactly these labels for consistency with Step 9):
+
+   - **"Tak, zapisz plan do Linear"** _(Recommended)_ — user accepts. Proceed to Step 9 (delete old attachment if replacing, then save). Existing flow continues unchanged from here.
+   - **"Wygeneruj plan ponownie"** — user wants a different plan. Go to step 3 (regeneration loop) below.
+   - **"Anuluj"** — user rejects. Stop the whole skill. Do NOT delete the existing `plan.md` attachment. Do NOT save a new one. Do NOT apply the `AI Plan` label. Print a short status in Polish (`Plan nie został zapisany. Anulowano na żądanie użytkownika.`) and exit.
+
+3. **Regeneration branch**: if the user chose "Wygeneruj plan ponownie":
+
+   - Ask a follow-up `AskUserQuestion` (or accept the free-text the user typed alongside the rejection) to capture what should change: scope, structure, missed files, wrong approach, etc.
+   - Loop back to **Step 7 (Create implementation plans)** with the user's feedback in mind. Do NOT re-run Steps 1–6 — the Linear task, comments, commits, and codebase analysis have not changed.
+   - On the regenerated plan, return to **Step 8a step 1** (render + ask again).
+   - **Cap the loop at 3 regenerations.** On the 3rd rejection, surface the situation to the user (`Plan został odrzucony 3 razy. Przerywam, abyś mógł doprecyzować wymagania.`) and exit without saving.
+
+4. **State invariants on entry to Step 9**: the only path that reaches Step 9 is the explicit "Tak, zapisz plan do Linear" choice (or `--auto`). Treat plan content as final.
+
 ### Step 9: Confirm and Delete Old Plan Attachments
 
 **This step applies only when replacing existing plans** (i.e., `oldPlanAttachments` from Step 3a is not empty).
 
 **`--auto` mode**: Skip the confirmation prompt. For each task in `oldPlanAttachments`, delete the Linear attachment via `mcp__linear__delete_attachment({ id: attachmentId })` and proceed directly to Step 9a. Log the deletions in the final summary comment.
 
-**Default mode** (interactive): Before saving new plans, ask the user to confirm deletion of old `plan.md` attachments:
+**Default mode** (interactive): The plan content was already approved in Step 8a; this prompt is strictly about confirming deletion of the **existing** Linear attachment that will be overwritten. Ask the user:
 
 ```markdown
 ## Zastąpienie istniejących planów
@@ -711,15 +745,13 @@ Use `AskUserQuestion` tool with options:
 
 ### Step 9a: Save Plan as Linear Attachment
 
-**⛔ DO NOT call `mcp__linear__save_comment` with plan content here. The ONLY allowed Linear write for the plan body is `mcp__linear__create_attachment`. Re-read Hard Rule #1 if tempted.**
+**⛔ DO NOT call `mcp__linear__save_comment` with plan content here. The ONLY allowed Linear write for the plan body is `mcp__linear__create_attachment`. Re-read Hard Rule #1 if tempted.** (Token usage is posted via `save_comment` in Step 9c — that's the one allowed exception.)
 
 For each task that needs planning, upload the plan content directly to Linear via `mcp__linear__create_attachment` — Linear hosts the file itself, no intermediate storage.
 
 #### 9a.1 — Prepare plan content
 
-The plan content is exactly the markdown produced in Step 8 (the same block that would previously have been posted as a comment).
-
-Write it to a temp file so it can be base64-encoded:
+The plan content is exactly the markdown produced in Step 8 (the same block that would previously have been posted as a comment). Write it to the temp file:
 
 ```bash
 mkdir -p /tmp/claude-plans
@@ -781,6 +813,38 @@ Steps:
 
 3. **Failure handling**: if label lookup/apply fails, surface the error but do not roll back the plan attachment. The plan is the primary deliverable; the label is a marker.
 
+### Step 9c: Post Token-Usage Comment
+
+After the plan attachment(s) and `AI Plan` label have been applied, post a single Linear comment on the **invoked issue** (the same `linearTaskId` passed to `/plan`, identical to the labelling target) reporting the session's token usage.
+
+1. Run the per-plugin token-summing script:
+
+   ```bash
+   bash "$CLAUDE_PLUGIN_ROOT/scripts/compute-session-tokens.sh"
+   ```
+
+   The script prints four whitespace-separated integers on one line: `<input> <output> <cache_creation> <cache_read>`. If no transcript can be located it prints `0 0 0 0` and exits non-zero — treat that as a graceful skip (do NOT block; skip posting the comment).
+
+2. Compute `<TOTAL> = <input> + <output> + <cache_creation> + <cache_read>`.
+
+3. Call `mcp__linear__save_comment` with `issueId: invokedTaskId` and `body` equal to:
+
+   ```markdown
+   ## Zużycie tokenów — etap /plan
+
+   | Metryka        | Wartość        |
+   | -------------- | -------------- |
+   | Input          | <INPUT>        |
+   | Output         | <OUTPUT>       |
+   | Cache creation | <CACHE_CREATE> |
+   | Cache read     | <CACHE_READ>   |
+   | **Łącznie**    | **<TOTAL>**    |
+   ```
+
+4. **Subtask rule**: post ONLY to the invoked issue. Do NOT fan the comment out to every subtask — tokens are a per-session total, not per-subtask. Same scoping rule as Step 9b.
+
+5. **Failure handling**: if the comment fails to post, surface the error to the user but do not roll back the plan attachment or the label.
+
 ### Step 10: Confirm to User
 
 After successfully saving the plans, confirm to the user:

package/plugins/flow/skills/push/SKILL.md

@@ -194,6 +194,28 @@ Use `AskUserQuestion` tool with options:
 1. **For tasks with subtasks**: Update all completed subtasks to "In Review"
 2. **For tasks without subtasks**: Update the task itself to "In Review"
 
+**Before posting**, run the token-summing script and capture its output:
+
+```bash
+bash "$CLAUDE_PLUGIN_ROOT/scripts/compute-session-tokens.sh"
+```
+
+It prints four whitespace-separated integers on one line: `<INPUT> <OUTPUT> <CACHE_CREATE> <CACHE_READ>`. If no transcript can be located it prints `0 0 0 0` and exits non-zero — treat that as a graceful skip (still post the comment, with zeros in the table).
+
+Compute `<TOTAL> = <INPUT> + <OUTPUT> + <CACHE_CREATE> + <CACHE_READ>`. Append exactly one copy of the following Polish block to the bottom of the comment body, after the existing `_Raport wygenerowany przez Claude Code_` footer. Do not create a second Linear comment — the block belongs in **this** comment.
+
+```markdown
+## Zużycie tokenów — etap /push
+
+| Metryka        | Wartość        |
+| -------------- | -------------- |
+| Input          | <INPUT>        |
+| Output         | <OUTPUT>       |
+| Cache creation | <CACHE_CREATE> |
+| Cache read     | <CACHE_READ>   |
+| **Łącznie**    | **<TOTAL>**    |
+```
+
 Create a comment on the **parent task** summarizing:
 
 ```markdown

package/plugins/flow-external/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "flow-external",
   "description": "Development flow skills for standalone Angular 6-11 museum projects without framework (Angular CLI, Karma/Jasmine, Bootstrap 4)",
-  "version": "2.83.0"
+  "version": "2.85.0"
 }

package/plugins/flow-external/agents/shared-impl-reporter.md

@@ -1,9 +1,9 @@
 ---
 name: shared-impl-reporter
 description: Generate implementation reports for Linear comments. Creates Polish-language summaries of completed work.
-tools: Read, Glob, Grep
+tools: Read, Glob, Grep, Bash
 model: sonnet
-color: "#5E6AD2"
+color: '#5E6AD2'
 ---
 
 You are an implementation reporter that generates Polish-language summaries for Linear comments.
@@ -12,6 +12,34 @@ You are an implementation reporter that generates Polish-language summaries for
 
 Create structured implementation reports in Polish for Linear task comments.
 
+## Token Usage Step (MANDATORY)
+
+Every report you emit MUST end with exactly one Polish token-usage block — the one defined below. Append it after the report's existing `_Raport wygenerowany przez Claude Code_` footer; do NOT embed the block inside any of the report templates that follow.
+
+1. Run the token-summing script once:
+
+   ```bash
+   bash "$CLAUDE_PLUGIN_ROOT/scripts/compute-session-tokens.sh"
+   ```
+
+   It prints four whitespace-separated integers on one line: `<INPUT> <OUTPUT> <CACHE_CREATE> <CACHE_READ>`. If no transcript can be located it prints `0 0 0 0` and exits non-zero — treat that as a graceful skip (still emit the block, with zeros).
+
+2. Compute `<TOTAL> = <INPUT> + <OUTPUT> + <CACHE_CREATE> + <CACHE_READ>`.
+
+3. Append this block to the end of the report:
+
+   ```markdown
+   ## Zużycie tokenów — etap /impl
+
+   | Metryka        | Wartość        |
+   | -------------- | -------------- |
+   | Input          | <INPUT>        |
+   | Output         | <OUTPUT>       |
+   | Cache creation | <CACHE_CREATE> |
+   | Cache read     | <CACHE_READ>   |
+   | **Łącznie**    | **<TOTAL>**    |
+   ```
+
 ## Report Templates
 
 ### Completed Implementation
@@ -25,12 +53,12 @@ Create structured implementation reports in Polish for Linear task comments.
 
 ### Zmiany
 
-| Plik | Typ zmiany | Opis |
-|------|-----------|------|
-| `src/app/components/feature.component.ts` | Nowy | Komponent widoku |
-| `src/app/components/feature.component.html` | Nowy | Szablon z Bootstrap 4 |
-| `src/app/components/feature.component.scss` | Nowy | Style SCSS |
-| `src/app/components/feature.component.spec.ts` | Nowy | Testy Karma/Jasmine |
+| Plik                                           | Typ zmiany | Opis                  |
+| ---------------------------------------------- | ---------- | --------------------- |
+| `src/app/components/feature.component.ts`      | Nowy       | Komponent widoku      |
+| `src/app/components/feature.component.html`    | Nowy       | Szablon z Bootstrap 4 |
+| `src/app/components/feature.component.scss`    | Nowy       | Style SCSS            |
+| `src/app/components/feature.component.spec.ts` | Nowy       | Testy Karma/Jasmine   |
 
 ### Testy
 
@@ -63,9 +91,9 @@ _Raport wygenerowany przez Claude Code_
 
 ### Niezrealizowane
 
-| Element | Powod |
-|---------|-------|
-| [item] | [reason] |
+| Element | Powod    |
+| ------- | -------- |
+| [item]  | [reason] |
 
 ### Nastepne kroki
 

package/plugins/flow-external/scripts/compute-session-tokens.sh

@@ -0,0 +1,39 @@
+#!/usr/bin/env bash
+# Sum token usage from the current Claude Code session's JSONL transcript.
+# Prints four whitespace-separated integers on one line:
+#   <input> <output> <cache_creation> <cache_read>
+# Prints "0 0 0 0" and exits non-zero if no transcript can be found.
+#
+# Resolution order:
+#   1. $CLAUDE_CONFIG_DIR (set by Claude Code) or ~/.claude as fallback.
+#   2. Inside <config>/projects/<encoded-cwd>/, pick the file matching
+#      $CLAUDE_CODE_SESSION_ID.jsonl when that env var is set.
+#   3. Otherwise pick the most-recently-modified *.jsonl (current session).
+
+set -u
+
+CONFIG_DIR="${CLAUDE_CONFIG_DIR:-$HOME/.claude}"
+ENCODED_CWD="$(pwd | sed 's|/|-|g')"
+TRANSCRIPT_DIR="$CONFIG_DIR/projects/$ENCODED_CWD"
+
+if [[ -n "${CLAUDE_CODE_SESSION_ID:-}" && -f "$TRANSCRIPT_DIR/$CLAUDE_CODE_SESSION_ID.jsonl" ]]; then
+  TRANSCRIPT_FILE="$TRANSCRIPT_DIR/$CLAUDE_CODE_SESSION_ID.jsonl"
+else
+  TRANSCRIPT_FILE="$(ls -t "$TRANSCRIPT_DIR"/*.jsonl 2>/dev/null | head -1)"
+fi
+
+if [[ -z "${TRANSCRIPT_FILE:-}" || ! -f "$TRANSCRIPT_FILE" ]]; then
+  echo "0 0 0 0"
+  exit 1
+fi
+
+jq -s '
+  reduce .[] as $m (
+    {i:0, o:0, cc:0, cr:0};
+    .i  += ($m.message.usage.input_tokens                // 0)
+  | .o  += ($m.message.usage.output_tokens               // 0)
+  | .cc += ($m.message.usage.cache_creation_input_tokens // 0)
+  | .cr += ($m.message.usage.cache_read_input_tokens     // 0)
+  )
+  | "\(.i) \(.o) \(.cc) \(.cr)"
+' "$TRANSCRIPT_FILE" | tr -d '"'