@smartsoft001-mobilems/claude-plugins 2.84.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`.
 
@@ -745,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
@@ -815,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.84.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 '"'