@mrrlin-dev/mcp 0.2.2 → 0.2.4

package/dist/prompts/report-issue.md

@@ -0,0 +1,155 @@
+---
+name: report-issue
+description: Use when a Mrrlin user hits a problem and wants it reported to support. Reads the local Director bridge log, asks the user a few clarifying questions in their own language, packages an English report, and sends it to the shared support Telegram channel via a single POST.
+---
+
+# Report a Mrrlin issue to support
+
+You are helping a Mrrlin **user/customer** report a problem. Do all the plumbing
+yourself and keep it invisible to them: read their local logs, ask only what you
+genuinely cannot infer, then send one packaged report to the support Telegram
+channel. The user should never see or touch the token, the log path, or the POST.
+
+## How this gets invoked
+
+This prompt ships inside `@mrrlin-dev/mcp`. `mrrlin-mcp report-issue` prints this
+file to stdout, so the same text drives all three surfaces:
+
+- **Terminal (feed it to Codex):** `codex "$(mrrlin-mcp report-issue)"`
+- **Codex slash command:** `mrrlin-mcp report-issue > ~/.codex/prompts/report-issue.md` once, then run `/report-issue`.
+- **Skill:** it has skill frontmatter (`name` + `description`), so a skill-aware agent can activate it directly.
+
+## Service bot it talks to
+
+The token below is **intentionally public** — `@mrrlinIssuesBot` is a throwaway
+service bot dedicated to the Mrrlin support group. Anyone reading this file may
+see it; that is by design. The bot can only post to the one chat hardcoded
+below, so leaking the token costs at most some spam in that chat — rotate via
+@BotFather if it ever happens.
+
+- Bot: `@mrrlinIssuesBot` (id `8506614214`)
+- Group: "Mrrlin", chat id `-5373779177`
+
+---
+
+## What to do
+
+### 1. Read the Director bridge log
+
+The bridge writes one JSON object per line to a daily file. Find the log dir, in
+this order, and use the first that exists:
+
+1. `$CODEX_HOME/mrrlin/director-bridge/logs/` (only if `CODEX_HOME` is set)
+2. `~/.mrrlin/director-bridge/logs/`
+
+Pick the **most recent** `bridge-YYYY-MM-DD.jsonl` file (filenames are UTC dates;
+sort descending). Read roughly the **last 200 lines**. Each line looks like:
+
+```json
+{"ts":"...","dir":"in|out","spanId":"...","sessionId":"...","type":"turn|event|error|...","ms":123,"payload":{...}}
+```
+
+Secrets are already redacted by the logger (tokens show as `[REDACTED]`), so the
+log lines are safe to forward as-is.
+
+From the tail, extract:
+
+- Every line with `type:"error"` (and any `dir:"out"` payload that looks like a failure — non-2xx HTTP, stack traces, "failed", "timeout").
+- The last few `type:"turn"` lines for context on what the user was doing.
+- The latest `sessionId` and the `spanId`s tied to the errors.
+- `ts` of the first and last relevant lines (the time window).
+
+If no log dir or file exists, or the tail has no errors, say so plainly and rely
+on what the user tells you in step 2 — still send the report.
+
+### 2. Ask the user — in THEIR language
+
+Detect the language the user is writing in and ask in that language. Keep it to a
+few short questions, ask them **once**, don't interrogate. Cover:
+
+- **What were you doing** when it broke?
+- **What actually happened** (the symptom they saw)?
+- **What did you expect to happen instead?** — ask this **only if the expected
+  result is not already obvious** from the log or from what they described. If
+  it's obvious, infer it and skip the question.
+
+If the user gives short or partial answers, accept them and move on. Never block
+the report on a perfect answer.
+
+### 3. Package the report (in ENGLISH)
+
+Translate the user's answers to English. Build a plain-text report. Keep the whole
+thing under **4096 characters** (Telegram's per-message limit) — trim the log
+excerpt first if needed, keeping the error lines over the context lines.
+
+```
+🛠️ Mrrlin issue report
+When (UTC): <iso timestamp of the report>
+Mrrlin MCP: v<version if known>  |  OS: <platform>  |  Node: <version>
+
+▶ What the user was doing:
+<their answer, in English>
+
+▶ Expected result:
+<their answer, or "(obvious from context: ...)", or "(not provided)">
+
+▶ Actual result / symptom:
+<their answer, in English>
+
+▶ Errors from bridge log (<filename>):
+<the extracted error lines, verbatim — already redacted>
+
+▶ Context:
+session=<sessionId>  spanIds=<...>  window=<first ts>..<last ts>
+```
+
+### 4. Send it — a single POST to Telegram
+
+This is **just one HTTP POST** to the Telegram Bot API `sendMessage` method.
+Endpoint and shape:
+
+```
+POST https://api.telegram.org/bot8506614214:AAGyhO1phWb7ah2aN6_gAX2Co7OXNN3zb0A/sendMessage
+Content-Type: application/json
+body: { "chat_id": "-5373779177", "text": "<the report>", "disable_web_page_preview": true }
+```
+
+Do **not** set `parse_mode` — send the report as plain text so nothing needs
+escaping. Because the report has newlines and quotes, build the JSON safely
+(serialize it; don't hand-concatenate a string), write it to a temp file, and POST
+the file so the shell can't mangle it:
+
+```bash
+# Write the JSON payload with a proper serializer, then:
+curl -sS -X POST \
+  "https://api.telegram.org/bot8506614214:AAGyhO1phWb7ah2aN6_gAX2Co7OXNN3zb0A/sendMessage" \
+  -H "Content-Type: application/json" \
+  --data-binary @/tmp/mrrlin-report.json
+```
+
+Check the response: Telegram returns `{"ok":true,...}` on success. If it returns
+`{"ok":false,"description":"..."}` or curl fails, show the user the error and offer
+to retry once.
+
+**Optional — full log as an attachment.** If the trimmed excerpt lost important
+lines, also send the full log file as a document (separate call):
+
+```bash
+curl -sS -X POST \
+  "https://api.telegram.org/bot8506614214:AAGyhO1phWb7ah2aN6_gAX2Co7OXNN3zb0A/sendDocument" \
+  -F "chat_id=-5373779177" \
+  -F "document=@<path-to-bridge-YYYY-MM-DD.jsonl>"
+```
+
+### 5. Confirm
+
+Tell the user, in their language, that the report was sent (or that it failed and
+why). Don't dump the raw report or the token back at them — just confirm.
+
+## Rules
+
+- Ask the user in their language; write the report in English.
+- Hide the mechanics: never surface the token, the log path, or the curl command to the user.
+- Forward log lines as-is — they're already secret-redacted. Do not paste anything that looks like a live token even if you see one.
+- One report = one `sendMessage` POST. Keep it under 4096 chars; use `sendDocument` only for the optional full log.
+- If anything is missing (no log, vague answers), still send the best report you can rather than giving up.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrrlin-dev/mcp",
-  "version": "0.2.2",
+  "version": "0.2.4",
   "type": "module",
   "bin": {
     "mrrlin-mcp": "dist/bin.cjs"
@@ -10,7 +10,8 @@
   },
   "files": [
     "dist/bin.cjs",
-    "dist/consensus/personas"
+    "dist/consensus/personas",
+    "dist/prompts"
   ],
   "devDependencies": {
     "@types/node": "^20.17.50",
@@ -19,12 +20,12 @@
     "@types/ws": "^8.18.1",
     "esbuild": "^0.24.0",
     "tsx": "^4.22.3",
+    "@mrrlin/client": "0.0.0",
     "@mrrlin/codex-client": "0.0.0",
     "@mrrlin/director-e2e": "0.0.0",
     "@mrrlin/schemas": "0.0.0",
     "@mrrlin/tsconfig": "0.0.0",
-    "@mrrlin/wiki": "0.0.0",
-    "@mrrlin/client": "0.0.0"
+    "@mrrlin/wiki": "0.0.0"
   },
   "dependencies": {
     "@iarna/toml": "^2.2.5",
@@ -36,7 +37,7 @@
   },
   "scripts": {
     "build": "tsc -p tsconfig.json && pnpm run bundle && chmod +x dist/bin.cjs",
-    "bundle": "esbuild src/bin.ts --bundle --platform=node --format=cjs --target=node20 --outfile=dist/bin.cjs --banner:js='#!/usr/bin/env node' && mkdir -p dist/consensus/personas && cp src/consensus/personas/*.md dist/consensus/personas/",
+    "bundle": "esbuild src/bin.ts --bundle --platform=node --format=cjs --target=node20 --outfile=dist/bin.cjs --banner:js='#!/usr/bin/env node' && mkdir -p dist/consensus/personas && cp src/consensus/personas/*.md dist/consensus/personas/ && mkdir -p dist/prompts && cp src/prompts/*.md dist/prompts/",
     "dev": "tsx watch src/bin.ts serve",
     "lint": "eslint .",
     "start": "node dist/bin.cjs serve",