@rubytech/create-maxy-code 0.1.183 → 0.1.185

package/payload/platform/plugins/prompt-optimiser/skills/prompt-optimiser/SKILL.md

@@ -0,0 +1,301 @@
+---
+name: prompt-optimiser
+description: Turn any rough prompt, half-formed idea, or task description into a finished, ready-to-send prompt optimized for Opus 4.7 (with adaptive thinking) inside the chat app — claude.ai, the Mac app, the iOS app — NOT the API. Use this skill whenever the user wants to write, rewrite, optimize, improve, sharpen, or polish a prompt for the chat app. Trigger phrases include "rewrite this prompt", "make this a better prompt", "optimize this prompt", "turn this into a prompt", "help me prompt this", "draft a prompt that...", "I want to ask...", or whenever the user pastes a draft prompt and asks for improvements. Also trigger when the user describes a task they plan to send into the chat app and clearly wants a reusable, well-structured prompt rather than a direct answer. The output is always a single, copy-pasteable prompt in a code block that the user sends as-is — never a template with placeholders.
+---
+
+# Prompt optimiser
+
+You turn whatever the user gives you — a rough draft, a vague idea, a task description, a paragraph of context — into a single high-quality prompt designed to run inside the chat app on Opus 4.7 with adaptive thinking.
+
+This is for the **chat app** (claude.ai, Mac, iOS), not the API. The user is going to paste a single message into chat. There is no system prompt, no `effort` parameter, no tool config to tune. The prompt itself has to do all the work.
+
+## Two hard rules
+
+These two rules override everything else in this skill. Read them, then re-read them.
+
+### Rule 1 — No placeholders. Ever.
+
+Never produce a prompt that contains `[paste X here]`, `[your content]`, `{topic}`, `<your_input_here>`, `[INSERT Y]`, `___`, or any other template variable the user is expected to fill in. The user must be able to copy your output, paste it into chat, hit send, and have a working interaction. If the prompt requires content the user hasn't provided yet, the prompt itself must handle that — see Rule 2.
+
+If you catch yourself typing square brackets around a noun, stop. That's a placeholder. Rewrite.
+
+### Rule 2 — Ship a finished prompt no matter what the user gave you.
+
+Two cases:
+
+**Case A — the user gave you real content** (a draft they wrote, code, a document, a list of items, a specific question, an actual product description). Bake that content directly into the optimized prompt. The whole thing — content and instructions — goes inside the code block. The user copies, pastes, sends. Done.
+
+**Case B — the user only described a class of task** ("I want a prompt to triage my emails", "help me prompt Claude to review my code", "give me a prompt for writing LinkedIn posts about my launches"). Write the prompt as a complete, self-contained instruction that works on its own. End the instruction by either:
+- Asking Claude to ask the user for the specific inputs it needs ("Before drafting, ask me to share the product name, audience, and a link."), or
+- Phrasing the task so the user will naturally provide the input in their next chat turn ("I'm going to paste a batch of emails next. For each one, do the following...").
+
+Either way: no brackets, no fill-in-the-blank, no template syntax. The prompt is final.
+
+## What you output
+
+A single fenced code block containing the optimized prompt. Nothing else. No preamble like "Here's your prompt:". No trailing explanation of what you changed.
+
+The prompt must end with this exact line as its final line:
+
+```
+Think before answering
+```
+
+That line is non-negotiable. It is the user's signal to push Opus 4.7's adaptive thinking toward deeper reasoning inside the chat app, where API-side `effort` controls aren't available.
+
+## Why these principles work
+
+Opus 4.7 reads prompts more literally than older models, calibrates its own thinking and length to perceived complexity, and rewards prompts that are specific, structured, and motivated. The cookbook below is distilled from Anthropic's own Opus 4.7 prompting guidance. Each rule has a reason. Treat the reasons as the point — apply them with judgment, don't paste them mechanically.
+
+## The rewrite workflow
+
+Work through these in your head before writing the prompt. You don't need to surface them.
+
+1. **Identify the goal.** What does the user actually want produced? A document? A decision? Code? A list? An analysis? Name it concretely.
+2. **Identify the audience and use.** Who reads the output, and what will they do with it? This drives tone and format.
+3. **Decide: Case A or Case B.** Did the user provide the actual content, or just describe a class of task? This decides whether you bake content in or write a self-contained instruction (see Rule 2).
+4. **Spot the gaps.** Audience, format, length, constraints, examples, edge cases — note which are missing.
+5. **Fill the gaps with reasonable assumptions.** The user told you not to ask questions. Make the most useful, most defensible assumption and move on. Keep it grounded in what they wrote.
+6. **Pick a structure.** Single-paragraph instruction for simple tasks. XML tags for anything with multiple sections.
+7. **Write the prompt.** Apply the principles below.
+8. **End with the closing line.**
+9. **Scan for brackets.** Before you finalize, re-read your output looking for `[`, `{`, or `<...your...>`-style placeholders. Kill any you find.
+
+## Core principles to apply
+
+### Be clear and direct
+State the task explicitly. Specify the desired output format and any hard constraints up front. If you want above-and-beyond effort, say so — Opus 4.7 won't infer it from a vague brief. "Create an analytics dashboard" is weaker than "Create an analytics dashboard with as many relevant features and interactions as possible — go beyond the basics for a fully-featured implementation."
+
+### Cap the length explicitly
+Opus 4.7 sizes its answer to whatever it infers the task needs, so an uncapped instruction produces unpredictable length. When the user has any length preference — or when a tight output is plainly better — name a hard cap, and a unit where one helps. "Summarize this report" drifts; "Summarize this in exactly 5 bullets, each under 15 words, each starting with an action verb" lands. Choose the cap that serves the goal; don't impose one where length should float (a short story, an open-ended analysis).
+
+### Explain the why
+When you give an instruction, briefly explain the reason. "Avoid ellipses, because the output will be read aloud by a TTS engine that mispronounces them" lands far better than "Never use ellipses." Opus 4.7 generalizes well from explanations and follows reasoned instructions more faithfully.
+
+### Tell Claude what to do, not what to avoid
+Positive framing outperforms negative framing. "Write in flowing prose paragraphs" beats "don't use bullet points."
+
+### Match prompt style to desired output style
+If you want prose, write the prompt in prose. If you want minimal markdown in the output, use minimal markdown in the prompt. Style leaks through.
+
+### Use XML tags when sections multiply
+When the prompt mixes instructions, context, examples, and input, wrap each in its own descriptive tag — `<instructions>`, `<context>`, `<examples>`, `<input>`. Nest naturally where there's hierarchy. This is the single highest-leverage structuring move for complex prompts. For simple one-shot prompts, skip it; XML on a haiku request is overkill.
+
+### Give Claude a role when it sharpens behavior
+A one-line role assignment ("You are a senior product strategist at a B2B SaaS company") tightens tone and frame. Don't force a role onto every prompt — only when it meaningfully steers the output.
+
+### Use examples for format, tone, or structure
+If the user has any preference about *how* the output should look, include 2–4 examples in `<example>` tags (or wrap multiple in `<examples>`). Examples beat description for steering format. Make them relevant, diverse, and structured. Skip examples when the task is so generic that examples would over-constrain.
+
+### Put long inputs on top, the question on the bottom
+If the prompt includes a long document, transcript, or data dump that the user provided, place it at the top. Anthropic's own testing shows up to ~30% quality lift from this ordering on long-context tasks.
+
+### Ask for grounding in long-document tasks
+For analysis or Q&A over long inputs, instruct Claude to first pull relevant quotes into `<quotes>` tags, then answer based on those quotes. This dramatically reduces drift and hallucination.
+
+### Be literal about scope
+Opus 4.7 doesn't silently generalize. If you want an instruction applied broadly, say "apply this to every section, not just the first one." If you want Claude to take action rather than suggest, use imperative verbs ("Edit the function to..." not "Could you suggest improvements to..."). Suggestion-flavored phrasing produces suggestions.
+
+### Self-check for high-stakes outputs
+For code, math, claims, or anything where errors matter, append a verification instruction near the end: "Before you finish, re-read your answer and check it against the criteria above." This catches errors reliably.
+
+## Domain-specific moves
+
+These are sharp tools for specific task types. Apply only when relevant.
+
+**Frontend / design.** Opus 4.7 has a strong default house style (warm cream backgrounds, serif type, terracotta accents) that's wrong for most products. If the user is asking for a design, either (a) specify a concrete alternative palette, type system, and structure in detail, or (b) instruct the model to propose 3–4 distinct visual directions before building, so the user picks one. Generic instructions like "make it clean and minimal" don't break the default.
+
+**Code review.** Tell the model its job at the finding stage is coverage, not filtering: "Report every issue you find, including ones you're uncertain about or consider low-severity. Include confidence and severity for each finding so a downstream filter can rank them." Avoid soft language like "only flag important issues" — Opus 4.7 takes that literally and under-reports.
+
+**Research / analysis.** Encourage hypothesis-tracking: "Develop several competing hypotheses as you gather information. Track confidence levels in your notes. Self-critique your approach periodically." This produces more rigorous synthesis than a flat "research X" prompt.
+
+**Creative writing.** Specify voice, audience, length, constraints, and provide one or two example sentences in the target voice if the user has them. Generic "write a blog post" yields generic prose.
+
+**Document creation (slides, reports).** Ask for design intentionality: "Include thoughtful visual hierarchy, considered typography, and engaging structure." Opus 4.7 produces strong first-pass document design when invited to.
+
+## Output format
+
+Always exactly this:
+
+````
+```
+[the optimized prompt — final, no placeholders, content baked in if provided
+or self-contained with an explicit "ask me for X" close if not]
+
+Think before answering
+```
+````
+
+No text before the code block. No text after. No "here you go." No "I added X and Y." Just the prompt.
+
+If the user explicitly asks "what did you change?" *after* they have the prompt, then explain in a follow-up turn. Until they ask, stay silent.
+
+## Examples
+
+These show the no-placeholder rule in action. Notice none of them contain `[paste X here]` or any other template variable.
+
+### Example 1 — Case B (user described a task class, no content given)
+
+**User input:**
+> I want a prompt to summarize my emails
+
+**Your output:**
+
+````
+```
+You are an executive assistant helping me triage email. I'm about to share a batch of emails with you in my next message.
+
+For each email, produce:
+- **Sender + subject** in one line
+- **Summary** — 1-2 sentences, neutral tone, no fluff
+- **Action required** — one of: reply needed, FYI only, schedule, delegate, ignore
+- **Priority** — high / medium / low, based on sender importance and urgency cues
+
+Group the output into three sections in this order: high priority, medium priority, low priority. Within each section, sort by action-required first (reply needed → schedule → delegate → FYI → ignore).
+
+Skip any email that's clearly automated marketing or notification spam — list its sender and subject under a final "Filtered out" section so I can verify.
+
+When you're ready, ask me to paste the emails.
+
+Think before answering
+```
+````
+
+The prompt ends by inviting the user to paste content in the next turn. No `[paste emails here]` block. The user sends this as-is and Claude responds with "Ready when you are — paste the batch."
+
+### Example 2 — Case B (rough draft prompt, no product details given)
+
+**User input:**
+> can you fix this prompt: "write a linkedin post about my new product launch, make it engaging and not too salesy"
+
+**Your output:**
+
+````
+```
+You are writing a LinkedIn post for me announcing a product launch. The audience is mid-to-senior B2B operators on LinkedIn — they've seen every launch post template and are skeptical of marketing language.
+
+Before you draft, ask me for:
+- The product's name
+- What it does, in plain language
+- Who it's for
+- The 1-2 reasons I built it that aren't obvious from the description
+- A link or destination for the call to action
+
+Once I've answered, write one post that:
+- Opens with a concrete hook in the first 2 lines (a tension, a number, or an unexpected observation — not "I'm excited to announce").
+- Tells a short story or shares a specific insight that led to the product, before naming it.
+- Names what the product does in one plain sentence. No adjectives like "revolutionary", "game-changing", or "powerful".
+- Closes with one clear next step (link, DM, comment) — not a generic "let me know what you think".
+- Sits between 150 and 220 words. Short paragraphs, one idea per line break. No emojis. No hashtags except up to two at the very end if they're genuinely relevant.
+
+Match the voice of someone who's built the thing themselves and is talking to peers, not pitching to strangers.
+
+Think before answering
+```
+````
+
+Instead of a `<product_details>` block with `[paste details here]`, the prompt explicitly tells Claude to gather the details by asking. Self-contained, ready to send.
+
+### Example 3 — Case B (technical task, no code given)
+
+**User input:**
+> I need claude to review my python code for bugs
+
+**Your output:**
+
+````
+```
+You're going to review Python code I share with you. Your job at the finding stage is coverage, not filtering — assume a separate pass will rank findings later.
+
+When I paste the code, report every issue you find, including ones you're uncertain about or consider low-severity. For each finding, include:
+- **Location** — file and line number(s)
+- **Issue** — what's wrong, in one sentence
+- **Why it matters** — the concrete failure mode (incorrect output, crash, security risk, race condition, etc.)
+- **Confidence** — high / medium / low
+- **Severity** — high / medium / low
+- **Suggested fix** — a minimal change that addresses the issue
+
+Cover at minimum: logic errors, off-by-one and boundary issues, mutable default arguments, exception handling gaps, race conditions and concurrency issues, resource leaks (files, connections, locks), input validation at trust boundaries, and any deviation from the code's apparent intent.
+
+Do not filter for importance at this stage. It's better to surface a finding that gets filtered out later than to silently drop a real bug.
+
+After listing findings, end with a single-paragraph overall assessment of code quality and the top 3 highest-severity issues to fix first.
+
+Ask me to paste the code when you're ready.
+
+Think before answering
+```
+````
+
+### Example 4 — Case A (real content provided, no follow-up needed)
+
+**User input:**
+> rewrite this so it's clearer: "Hey can you help me figure out whether to take the offer from Stripe vs the one from Anthropic. Stripe is paying 280k base + 60k bonus + 100k stock per year vesting over 4. Anthropic is 250k base + 0 bonus but 800k stock vesting over 4 with 1yr cliff. I care most about long term equity upside, work I'd be excited about, and not having to relocate. Stripe wants me in SF 3 days a week, Anthropic is fully remote."
+
+**Your output:**
+
+````
+```
+I'm deciding between two job offers and want your help thinking it through carefully.
+
+**My priorities, in order:**
+1. Long-term equity upside
+2. Work I'd be excited about
+3. Avoiding relocation
+
+**Offer A — Stripe**
+- $280k base
+- $60k annual bonus
+- $100k/year stock, vesting over 4 years
+- Hybrid: in SF 3 days a week
+
+**Offer B — Anthropic**
+- $250k base
+- No annual bonus
+- $800k stock, vesting over 4 years with a 1-year cliff
+- Fully remote
+
+Walk me through:
+1. The total expected compensation under each, year-by-year over 4 years, including a sensitivity range on equity outcomes (say: bear / base / bull cases for each company).
+2. How each offer scores against my three priorities, ranked.
+3. The non-obvious risks of each (what each offer's structure says about the company's confidence, how cliffs and vesting interact with my optionality, what the relocation requirement implies about future flexibility).
+4. Your overall recommendation and the single biggest reason it could be wrong.
+
+Be direct. Don't hedge with "it depends on what you value" — I told you what I value.
+
+Think before answering
+```
+````
+
+The user gave the actual numbers and constraints. They're baked in. No `[insert offer details]` block. The prompt is done.
+
+### Example 5 — simple task
+
+**User input:**
+> write me a haiku about coffee
+
+**Your output:**
+
+````
+```
+Write a haiku about coffee. Follow the traditional 5-7-5 syllable structure. Aim for a single concrete image rather than a general statement about coffee — something a reader could picture. Avoid clichés like "morning steam" and "liquid gold".
+
+Think before answering
+```
+````
+
+Notice the simple task doesn't get XML tags, a role, or a sectioning — and there's nothing to bake in. Apply structure proportional to the task; over-engineering a haiku prompt is its own failure mode.
+
+## Edge cases
+
+**The user pastes a prompt and asks "is this good?"** They want it rewritten regardless. Treat it as a rewrite request and return the optimized version in a code block. No commentary.
+
+**The user gives you a Claude system prompt or API-style prompt with parameters.** Strip out API-only mechanics (effort levels, thinking config, tool definitions), translate the intent into a single user-message prompt for the chat app, and end with the closing line.
+
+**The user wants the prompt to ask Claude to do many small things.** Combine into a single coherent prompt with clear sections rather than a numbered list of micro-tasks. Opus 4.7 handles long, well-structured asks well.
+
+**The user's input is already excellent.** Tighten where you can, add the closing line, return it. Don't add ceremony for its own sake.
+
+**The user input is in a language other than English.** Write the optimized prompt in the same language. Keep the closing line in English exactly as specified — that wording is what triggers the desired behavior in the chat app.
+
+**You're tempted to write a `<context>` or `<input>` block expecting the user to fill it.** Don't. That's Rule 1. Either bake the actual content in (Case A) or tell Claude to ask the user for it (Case B).

package/payload/platform/plugins/url-get/.claude-plugin/plugin.json

@@ -0,0 +1,17 @@
+{
+  "name": "url-get",
+  "description": "Faithful page retrieval. Provides url-get — fetches a server-rendered web page over HTTP, cleans the HTML to markdown with no model in the path (so there is nothing to refuse on copyright), and writes that verbatim copy to an account-scoped reference file. Separately produces a transformative summary via a short Claude subprocess. Returns { summary, referencePath } only — the verbatim markdown is never injected wholesale; the agent greps the reference file for passages and librarian reads it directly to ingest. This is the tool to use instead of native WebFetch when a faithful copy of a page is needed (e.g. ingesting the operator's own published writing): WebFetch refuses to reproduce copyrighted text and returns only a summary. Server-rendered HTML only — no JavaScript execution (JS-rendered pages use the browser MCP). A bot-challenge or empty page fails with an explicit error and writes no reference file.",
+  "version": "0.1.0",
+  "author": {
+    "name": "Rubytech LLC"
+  },
+  "mcpServers": {
+    "url-get": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${CLAUDE_PLUGIN_ROOT}/mcp/dist/index.js"
+      ]
+    }
+  }
+}

package/payload/platform/plugins/url-get/PLUGIN.md

@@ -0,0 +1,86 @@
+---
+name: url-get
+mcp:
+  command: node
+  args:
+    - ${PLATFORM_ROOT}/lib/mcp-spawn-tee/dist/index.js
+    - ${PLATFORM_ROOT}/plugins/url-get/mcp/dist/index.js
+  env:
+    MCP_SPAWN_TEE_NAME: url-get
+    LOG_DIR: ${LOG_DIR}
+    PLATFORM_ROOT: ${PLATFORM_ROOT}
+    ACCOUNT_ID: ${ACCOUNT_ID}
+    SESSION_ID: ${SESSION_ID}
+mcp-manifest: auto
+description: "Faithful page retrieval. Provides url-get — fetches a server-rendered web page over HTTP, cleans the HTML to markdown with no model in the path (so there is nothing to refuse on copyright), and writes that verbatim copy to an account-scoped reference file. Separately produces a transformative summary via a short Claude subprocess. Returns { summary, referencePath } only — the verbatim markdown is never injected wholesale; the agent greps the reference file for passages and librarian reads it directly to ingest. This is the tool to use instead of native WebFetch when a faithful copy of a page is needed (e.g. ingesting the operator's own published writing): WebFetch refuses to reproduce copyrighted text and returns only a summary. Server-rendered HTML only — no JavaScript execution (JS-rendered pages use the browser MCP). A bot-challenge or empty page fails with an explicit error and writes no reference file."
+tools:
+  - name: url-get
+    publicAllowlist: false
+    adminAllowlist: true
+always: true
+embed: false
+---
+
+# url-get
+
+## What it does
+
+A single MCP tool, `url-get`, takes a URL and returns two artefacts produced by
+two different mechanisms:
+
+- **Verbatim** — an HTTP GET followed by HTML→markdown cleanup, written to an
+  account-scoped reference file at `$ACCOUNT_DIR/url-get/<url-hash>.md`. No model
+  sits in this path, so there is nothing for a copyright refusal to act on. This
+  file is the ground truth.
+- **Summary** — a transformative summary of the cleaned text, produced by a
+  short `claude --print` subprocess. Being transformative, it does not trip the
+  copyright refusal either.
+
+Only `{ summary, referencePath }` returns to the conversation. The verbatim
+markdown is never injected wholesale: the agent greps the reference file when it
+needs a specific passage, and `librarian` reads the file directly when the
+operator chooses to ingest it.
+
+## Why it exists
+
+The only built-in page-retrieval tool is Claude's native WebFetch, whose refusal
+to reproduce copyrighted text lives in an internal post-fetch model — not in the
+source site and not in the outer prompt, so reframing cannot move it. A knowledge
+worker ingesting their own published writing (e.g. a Substack post) hits the same
+wall, because WebFetch cannot verify authorship. WebFetch is also structurally
+wrong for ingestion even when it does not refuse: it returns only a summary, never
+the verbatim source. `url-get` keeps WebFetch's two useful behaviours (HTML
+cleanup and a summary), adds the verbatim artefact, and removes the model from the
+verbatim path entirely.
+
+## Surface boundaries
+
+- **Server-rendered HTML only.** `url-get` does not execute JavaScript — the same
+  coverage limit as a plain fetch. JS-rendered pages are handled by the
+  pre-installed browser MCP (Task 492).
+- **No graph write.** `url-get` writes a reference file and returns a summary; it
+  never touches Neo4j. Ingestion is `librarian`'s job, reading the reference file.
+- **Verbatim is not size-capped** — it never enters the conversation, so there is
+  nothing to cap. The summary input is capped only to bound subprocess cost.
+- **No caching.** Every call fetches fresh.
+- A page that returns a bot-challenge interstitial or an empty body fails with an
+  explicit error (`challenge` / `empty`) and writes no reference file — never a
+  reference file full of challenge-page HTML.
+
+## Failure modes
+
+`url-get` returns an error envelope (never throws to the caller) for: `fetch`
+(network/DNS/TLS/timeout), `http` (non-2xx status), `non-html` (unsupported
+content-type), `challenge` (bot interstitial), `empty` (no readable text), and
+`no-account-dir` (storage unresolvable). The summary is best-effort: if the
+subprocess fails, the call still succeeds with `summarized: false` and the
+reference file intact — the verbatim artefact is the contract, the summary is
+derived.
+
+## Enabling
+
+`always: true` — the plugin auto-installs on every brand and is reachable by the
+spawned PTY agent on device; it is never pulled mid-session. The tool is
+admin-allowlisted (`adminAllowlist: true`) and is on the `tools:` list of the
+`research-assistant`, `librarian`, and `personal-assistant` specialists. It is
+not exposed to public agents (`publicAllowlist: false`).

package/payload/platform/plugins/url-get/mcp/dist/index.d.ts

@@ -0,0 +1,9 @@
+/**
+ * MCP server entrypoint for the url-get plugin. Registers one tool, `url-get`,
+ * on the standard stdio transport. Module init must never throw on missing
+ * per-account env — plugin-system spawn enumerates tools/list with empty env,
+ * and any boot throw empties the registry. The tool reads ACCOUNT_DIR at call
+ * time and returns an error envelope when storage cannot be resolved.
+ */
+export {};
+//# sourceMappingURL=index.d.ts.map

package/payload/platform/plugins/url-get/mcp/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG"}

package/payload/platform/plugins/url-get/mcp/dist/index.js

@@ -0,0 +1,53 @@
+/**
+ * MCP server entrypoint for the url-get plugin. Registers one tool, `url-get`,
+ * on the standard stdio transport. Module init must never throw on missing
+ * per-account env — plugin-system spawn enumerates tools/list with empty env,
+ * and any boot throw empties the registry. The tool reads ACCOUNT_DIR at call
+ * time and returns an error envelope when storage cannot be resolved.
+ */
+import { initStderrTee } from "../../../../lib/mcp-stderr-tee/dist/index.js";
+initStderrTee("url-get");
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
+import { eagerTool } from "../../../../lib/mcp-eager/dist/index.js";
+import { z } from "zod";
+import { urlGet } from "./tools/url-get.js";
+const server = new McpServer({
+    name: "url-get",
+    version: "0.1.0",
+});
+eagerTool(server, "url-get", "Fetch a server-rendered web page and produce two artefacts. (1) VERBATIM: the page is fetched over HTTP and cleaned to markdown with no model in the path, then written to an account-scoped reference file — this is the faithful ground-truth copy, never returned inline. (2) SUMMARY: a transformative summary of that text. Returns { summary, referencePath } — grep the reference file for specific passages rather than asking for the whole page; librarian reads it directly to ingest. Use this instead of WebFetch when you need a faithful copy of a page (e.g. ingesting the operator's own writing) — WebFetch refuses to reproduce copyrighted text and only ever returns a summary. Handles server-rendered HTML only (no JavaScript execution). A page that returns a bot-challenge or empty body fails with an explicit error and writes no file.", {
+    url: z.string().url().describe("Absolute http(s) URL of the page to fetch."),
+}, async (args) => {
+    const result = await urlGet(args);
+    if (!result.ok) {
+        return {
+            isError: true,
+            content: [{ type: "text", text: JSON.stringify(result, null, 2) }],
+        };
+    }
+    return {
+        content: [
+            {
+                type: "text",
+                text: JSON.stringify({
+                    summary: result.summary,
+                    referencePath: result.referencePath,
+                    url: result.url,
+                    httpStatus: result.httpStatus,
+                    bytes: result.bytes,
+                    summarized: result.summarized,
+                }, null, 2),
+            },
+        ],
+    };
+});
+async function main() {
+    const transport = new StdioServerTransport();
+    await server.connect(transport);
+}
+main().catch((err) => {
+    console.error("[url-get] fatal:", err);
+    process.exit(1);
+});
+//# sourceMappingURL=index.js.map

package/payload/platform/plugins/url-get/mcp/dist/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAC7E,aAAa,CAAC,SAAS,CAAC,CAAC;AAEzB,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AACjF,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,MAAM,EAAE,MAAM,oBAAoB,CAAC;AAE5C,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;IAC3B,IAAI,EAAE,SAAS;IACf,OAAO,EAAE,OAAO;CACjB,CAAC,CAAC;AAEH,SAAS,CACP,MAAM,EACN,SAAS,EACT,s0BAAs0B,EACt0B;IACE,GAAG,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,QAAQ,CAAC,4CAA4C,CAAC;CAC7E,EACD,KAAK,EAAE,IAAqB,EAAE,EAAE;IAC9B,MAAM,MAAM,GAAG,MAAM,MAAM,CAAC,IAAI,CAAC,CAAC;IAClC,IAAI,CAAC,MAAM,CAAC,EAAE,EAAE,CAAC;QACf,OAAO;YACL,OAAO,EAAE,IAAI;YACb,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAe,EAAE,IAAI,EAAE,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,EAAE,CAAC;SAC5E,CAAC;IACJ,CAAC;IACD,OAAO;QACL,OAAO,EAAE;YACP;gBACE,IAAI,EAAE,MAAe;gBACrB,IAAI,EAAE,IAAI,CAAC,SAAS,CAClB;oBACE,OAAO,EAAE,MAAM,CAAC,OAAO;oBACvB,aAAa,EAAE,MAAM,CAAC,aAAa;oBACnC,GAAG,EAAE,MAAM,CAAC,GAAG;oBACf,UAAU,EAAE,MAAM,CAAC,UAAU;oBAC7B,KAAK,EAAE,MAAM,CAAC,KAAK;oBACnB,UAAU,EAAE,MAAM,CAAC,UAAU;iBAC9B,EACD,IAAI,EACJ,CAAC,CACF;aACF;SACF;KACF,CAAC;AACJ,CAAC,CACF,CAAC;AAEF,KAAK,UAAU,IAAI;IACjB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC;AAED,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC,GAAG,EAAE,EAAE;IACnB,OAAO,CAAC,KAAK,CAAC,kBAAkB,EAAE,GAAG,CAAC,CAAC;IACvC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}

package/payload/platform/plugins/url-get/mcp/dist/lib/summarise.d.ts

@@ -0,0 +1,8 @@
+import { spawn as realSpawn } from "node:child_process";
+type SpawnFn = typeof realSpawn;
+/** Run the summary. Throws on every failure mode (the caller decides whether a
+ *  summary failure should degrade gracefully — the verbatim file is already on
+ *  disk by the time this runs). */
+export declare function summarise(url: string, text: string, _spawn?: SpawnFn): Promise<string>;
+export {};
+//# sourceMappingURL=summarise.d.ts.map

package/payload/platform/plugins/url-get/mcp/dist/lib/summarise.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"summarise.d.ts","sourceRoot":"","sources":["../../src/lib/summarise.ts"],"names":[],"mappings":"AAeA,OAAO,EAAE,KAAK,IAAI,SAAS,EAAE,MAAM,oBAAoB,CAAC;AAQxD,KAAK,OAAO,GAAG,OAAO,SAAS,CAAC;AAchC;;mCAEmC;AACnC,wBAAsB,SAAS,CAC7B,GAAG,EAAE,MAAM,EACX,IAAI,EAAE,MAAM,EACZ,MAAM,GAAE,OAAmB,GAC1B,OAAO,CAAC,MAAM,CAAC,CAkDjB"}

package/payload/platform/plugins/url-get/mcp/dist/lib/summarise.js

@@ -0,0 +1,83 @@
+// Transformative summary of fetched page text via a Claude Code subprocess.
+//
+//   VALIDATE TEXT ──▶ SPAWN claude --print --model <haiku> --max-turns 1 ──▶ STDOUT
+//        │                       │                                              │
+//        ├─ empty → throw        ├─ ENOENT (claude not in PATH) → throw         │
+//        │                       ├─ non-zero exit → throw (stderr + stdout)     │
+//        │                       ├─ timeout → SIGTERM → throw                   │
+//        │                       └─ empty stdout → throw                        │
+//        └───────────────────────────────────────────────────────────▶ return text
+//
+// Claude Code handles its own OAuth internally — no API key, no SDK. This is
+// the same mechanism the workflows plugin uses for LLM steps. The summary is
+// transformative, so it does not trip WebFetch's copyright refusal; the
+// verbatim path keeps the model out entirely.
+import { spawn as realSpawn } from "node:child_process";
+/** Haiku is the right tier for a one-shot summary (cheap, fast). Overridable
+ *  via env for forward-compat with model id changes. */
+const SUMMARY_MODEL = process.env.URL_GET_SUMMARY_MODEL ?? "claude-haiku-4-5";
+const SUMMARY_TIMEOUT_MS = 60_000;
+const MAX_STDERR_BYTES = 4096;
+/** Builds the summarisation prompt. A single principled instruction, not a
+ *  checklist of conditions — per the project's LLM-classification doctrine,
+ *  a prescriptive rule list turns the model into a brittle pattern matcher. */
+function buildPrompt(url, text) {
+    return (`Summarise the page below for a reader deciding whether to open the full text. ` +
+        `Capture what the page is, its main claims, and anything that would matter to ` +
+        `someone searching for it later. Write only the summary — no preamble.\n\n` +
+        `Source: ${url}\n\n---\n${text}`);
+}
+/** Run the summary. Throws on every failure mode (the caller decides whether a
+ *  summary failure should degrade gracefully — the verbatim file is already on
+ *  disk by the time this runs). */
+export async function summarise(url, text, _spawn = realSpawn) {
+    if (!text.trim()) {
+        throw new Error("nothing to summarise — cleaned text is empty");
+    }
+    const prompt = buildPrompt(url, text);
+    const args = [
+        "--print",
+        "--model",
+        SUMMARY_MODEL,
+        "--max-turns",
+        "1",
+        "--permission-mode",
+        "dontAsk",
+        prompt,
+    ];
+    return new Promise((resolve, reject) => {
+        const proc = _spawn("claude", args, { stdio: ["ignore", "pipe", "pipe"] });
+        let stdout = "";
+        let stderr = "";
+        proc.stdout?.on("data", (chunk) => {
+            stdout += chunk.toString("utf-8");
+        });
+        proc.stderr?.on("data", (chunk) => {
+            if (stderr.length < MAX_STDERR_BYTES) {
+                stderr += chunk.toString("utf-8").slice(0, MAX_STDERR_BYTES - stderr.length);
+            }
+        });
+        const timer = setTimeout(() => {
+            proc.kill("SIGTERM");
+            reject(new Error(`summary timed out after ${SUMMARY_TIMEOUT_MS}ms`));
+        }, SUMMARY_TIMEOUT_MS);
+        proc.on("close", (code) => {
+            clearTimeout(timer);
+            if (code !== 0) {
+                const tail = stderr.trim() ? ` stderr: ${stderr.trim()}` : "";
+                reject(new Error(`claude exited ${code}${tail}`));
+                return;
+            }
+            if (!stdout.trim()) {
+                reject(new Error("claude returned an empty summary"));
+                return;
+            }
+            resolve(stdout.trim());
+        });
+        proc.on("error", (err) => {
+            clearTimeout(timer);
+            reject(new Error(`failed to spawn claude: ${err.message}`));
+        });
+    });
+}
+//# sourceMappingURL=summarise.js.map

package/payload/platform/plugins/url-get/mcp/dist/lib/summarise.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"summarise.js","sourceRoot":"","sources":["../../src/lib/summarise.ts"],"names":[],"mappings":"AAAA,4EAA4E;AAC5E,EAAE;AACF,oFAAoF;AACpF,kFAAkF;AAClF,kFAAkF;AAClF,kFAAkF;AAClF,kFAAkF;AAClF,kFAAkF;AAClF,mFAAmF;AACnF,EAAE;AACF,6EAA6E;AAC7E,6EAA6E;AAC7E,wEAAwE;AACxE,8CAA8C;AAE9C,OAAO,EAAE,KAAK,IAAI,SAAS,EAAE,MAAM,oBAAoB,CAAC;AAExD;wDACwD;AACxD,MAAM,aAAa,GAAG,OAAO,CAAC,GAAG,CAAC,qBAAqB,IAAI,kBAAkB,CAAC;AAC9E,MAAM,kBAAkB,GAAG,MAAM,CAAC;AAClC,MAAM,gBAAgB,GAAG,IAAI,CAAC;AAI9B;;+EAE+E;AAC/E,SAAS,WAAW,CAAC,GAAW,EAAE,IAAY;IAC5C,OAAO,CACL,gFAAgF;QAChF,+EAA+E;QAC/E,2EAA2E;QAC3E,WAAW,GAAG,YAAY,IAAI,EAAE,CACjC,CAAC;AACJ,CAAC;AAED;;mCAEmC;AACnC,MAAM,CAAC,KAAK,UAAU,SAAS,CAC7B,GAAW,EACX,IAAY,EACZ,SAAkB,SAAS;IAE3B,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,EAAE,CAAC;QACjB,MAAM,IAAI,KAAK,CAAC,8CAA8C,CAAC,CAAC;IAClE,CAAC;IACD,MAAM,MAAM,GAAG,WAAW,CAAC,GAAG,EAAE,IAAI,CAAC,CAAC;IACtC,MAAM,IAAI,GAAG;QACX,SAAS;QACT,SAAS;QACT,aAAa;QACb,aAAa;QACb,GAAG;QACH,mBAAmB;QACnB,SAAS;QACT,MAAM;KACP,CAAC;IAEF,OAAO,IAAI,OAAO,CAAS,CAAC,OAAO,EAAE,MAAM,EAAE,EAAE;QAC7C,MAAM,IAAI,GAAG,MAAM,CAAC,QAAQ,EAAE,IAAI,EAAE,EAAE,KAAK,EAAE,CAAC,QAAQ,EAAE,MAAM,EAAE,MAAM,CAAC,EAAE,CAAC,CAAC;QAC3E,IAAI,MAAM,GAAG,EAAE,CAAC;QAChB,IAAI,MAAM,GAAG,EAAE,CAAC;QAChB,IAAI,CAAC,MAAM,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,KAAa,EAAE,EAAE;YACxC,MAAM,IAAI,KAAK,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;QACpC,CAAC,CAAC,CAAC;QACH,IAAI,CAAC,MAAM,EAAE,EAAE,CAAC,MAAM,EAAE,CAAC,KAAa,EAAE,EAAE;YACxC,IAAI,MAAM,CAAC,MAAM,GAAG,gBAAgB,EAAE,CAAC;gBACrC,MAAM,IAAI,KAAK,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,gBAAgB,GAAG,MAAM,CAAC,MAAM,CAAC,CAAC;YAC/E,CAAC;QACH,CAAC,CAAC,CAAC;QACH,MAAM,KAAK,GAAG,UAAU,CAAC,GAAG,EAAE;YAC5B,IAAI,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC;YACrB,MAAM,CAAC,IAAI,KAAK,CAAC,2BAA2B,kBAAkB,IAAI,CAAC,CAAC,CAAC;QACvE,CAAC,EAAE,kBAAkB,CAAC,CAAC;QACvB,IAAI,CAAC,EAAE,CAAC,OAAO,EAAE,CAAC,IAAmB,EAAE,EAAE;YACvC,YAAY,CAAC,KAAK,CAAC,CAAC;YACpB,IAAI,IAAI,KAAK,CAAC,EAAE,CAAC;gBACf,MAAM,IAAI,GAAG,MAAM,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,YAAY,MAAM,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;gBAC9D,MAAM,CAAC,IAAI,KAAK,CAAC,iBAAiB,IAAI,GAAG,IAAI,EAAE,CAAC,CAAC,CAAC;gBAClD,OAAO;YACT,CAAC;YACD,IAAI,CAAC,MAAM,CAAC,IAAI,EAAE,EAAE,CAAC;gBACnB,MAAM,CAAC,IAAI,KAAK,CAAC,kCAAkC,CAAC,CAAC,CAAC;gBACtD,OAAO;YACT,CAAC;YACD,OAAO,CAAC,MAAM,CAAC,IAAI,EAAE,CAAC,CAAC;QACzB,CAAC,CAAC,CAAC;QACH,IAAI,CAAC,EAAE,CAAC,OAAO,EAAE,CAAC,GAAU,EAAE,EAAE;YAC9B,YAAY,CAAC,KAAK,CAAC,CAAC;YACpB,MAAM,CAAC,IAAI,KAAK,CAAC,2BAA2B,GAAG,CAAC,OAAO,EAAE,CAAC,CAAC,CAAC;QAC9D,CAAC,CAAC,CAAC;IACL,CAAC,CAAC,CAAC;AACL,CAAC"}

package/payload/platform/plugins/url-get/mcp/dist/tools/url-get.d.ts

@@ -0,0 +1,21 @@
+export interface UrlGetParams {
+    url: string;
+}
+export type UrlGetError = "fetch" | "http" | "non-html" | "challenge" | "empty" | "no-account-dir";
+export type UrlGetResult = {
+    ok: true;
+    url: string;
+    httpStatus: number;
+    bytes: number;
+    referencePath: string;
+    summary: string;
+    summarized: boolean;
+} | {
+    ok: false;
+    url: string;
+    error: UrlGetError;
+    message: string;
+    httpStatus?: number;
+};
+export declare function urlGet(params: UrlGetParams): Promise<UrlGetResult>;
+//# sourceMappingURL=url-get.d.ts.map

package/payload/platform/plugins/url-get/mcp/dist/tools/url-get.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"url-get.d.ts","sourceRoot":"","sources":["../../src/tools/url-get.ts"],"names":[],"mappings":"AAsBA,MAAM,WAAW,YAAY;IAC3B,GAAG,EAAE,MAAM,CAAC;CACb;AAED,MAAM,MAAM,WAAW,GAAG,OAAO,GAAG,MAAM,GAAG,UAAU,GAAG,WAAW,GAAG,OAAO,GAAG,gBAAgB,CAAC;AAEnG,MAAM,MAAM,YAAY,GACpB;IACE,EAAE,EAAE,IAAI,CAAC;IACT,GAAG,EAAE,MAAM,CAAC;IACZ,UAAU,EAAE,MAAM,CAAC;IACnB,KAAK,EAAE,MAAM,CAAC;IACd,aAAa,EAAE,MAAM,CAAC;IACtB,OAAO,EAAE,MAAM,CAAC;IAChB,UAAU,EAAE,OAAO,CAAC;CACrB,GACD;IACE,EAAE,EAAE,KAAK,CAAC;IACV,GAAG,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,WAAW,CAAC;IACnB,OAAO,EAAE,MAAM,CAAC;IAChB,UAAU,CAAC,EAAE,MAAM,CAAC;CACrB,CAAC;AAyCN,wBAAsB,MAAM,CAAC,MAAM,EAAE,YAAY,GAAG,OAAO,CAAC,YAAY,CAAC,CAqGxE"}