elliot-stack 1.0.25 → 1.0.28

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Elliot Drel
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -20,8 +20,12 @@ This installs skills to `~/.agents/skills/` and symlinks them into `~/.claude/sk
 | **Active Learning Tutor** | `/estack-active-learning-tutor` | Tutors a student through exam preparation using active learning — questioning, gap diagnosis, and concept mastery tracking |
 | **Better Title** | `/estack-better-title` | Renames Claude Code chat sessions with descriptive titles |
 | **Chris Voss** | `/estack-chris-voss` | Applies negotiation principles from *Never Split the Difference* |
+| **CLAUDE.md Optimizer** | `/estack-claude-md-optimizer` | Creates, refines, and maintains CLAUDE.md / AGENTS.md files as short hand-authored letters of intent |
 | **Customer Discovery** | `/estack-customer-discovery` | Guides through customer discovery — validating ideas, outreach, interviews, and analysis |
+| **Flight Planner** | `/estack-flight-planner` | Finds and ranks flights between two airports with config-driven preferences and optional ground-shuttle pairing |
 | **GitHub Issue Tracker** | `/estack-github-issue-tracker` | Tracks and manages GitHub issues across repos |
+| **Prompt Builder Coach** | `/estack-prompt-builder-coach` | Four-part kit for shaping, building, auditing, and scoping prompts for AI agents |
+| **Read Claude Session History** | `/estack-read-claude-session-history` | Searches, reads, recovers, and compares Claude Code session history across sessions, projects, and backups |
 | **Repo Search** | `/estack-repo-search` | Clones and searches external GitHub repos to answer questions about their code |
 
 ## Hooks

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "elliot-stack",
-  "version": "1.0.25",
+  "version": "1.0.28",
   "description": "Elliot's skill stack for Claude Code — install via npx elliot-stack@latest",
   "bin": {
     "elliot-stack": "bin/install.cjs"

package/skills/estack-active-learning-tutor/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: estack-active-learning-tutor
-version: 1.0.1
+version: 1.0.2
 description: (active-learning-tutor) Tutors a student through exam preparation using active learning — questioning, gap diagnosis, and concept mastery tracking. Use when the student says they want to study, learn, prep for an exam, be quizzed on a chapter, work through a practice test together, or be taught a topic conceptually rather than lectured.
 disable-model-invocation: true
 ---
@@ -339,71 +339,6 @@ When in doubt about the shape of a Teaching turn, read `references/teaching-turn
 
 ---
 
-## Skill Feedback
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-active-learning-tutor: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
-**If `gh` is not installed**, build a pre-filled URL:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-active-learning-tutor: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user and offer to open it in their browser.
-
-They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.
-
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-active-learning-tutor: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
-**If `gh` is not installed**, build a pre-filled URL:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-active-learning-tutor: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user and offer to open it in their browser.
-
-They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.
-
----
-
 ## Skill Feedback
 
 If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:

package/skills/estack-better-title/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: estack-better-title
-version: 1.0.1
+version: 1.0.3
 description: (better-title) Suggest better chat session titles and rename the session
 disable-model-invocation: true
 allowed-tools: Bash, AskUserQuestion
@@ -30,7 +30,7 @@ Write the title from those answers, NOT from a chronological recap of the chat.
 - **Title the outputs, not the journey** — exclude mistakes, dead ends, and abandoned approaches. They're not searchable and not useful context for future-you.
 - **Use plain language a future-you would search for.** Avoid jargon like "passthrough," "edge cases," "toggle logic," "auto-cd," "refactored," "overhaul." Say what it does in normal words.
 - **Weight by long-term reference value.** If something will stop mattering in weeks or months (temporary fixes, current-state notes, "until X is available" workarounds), mention it briefly but don't lead with it.
-- List key outputs separated by dashes, commas, or similar (e.g. "Reverse-Engineering /rename, PR #33165 Comment, and Building /better-title Skill")
+- List key outputs separated by dashes, commas, or similar (e.g. "Reverse-Engineering /rename, PR #33165 Comment, and Building /estack-better-title Skill")
 - Cover 2-4 main outputs. Resist cramming everything in — first-pass attempts tend to over-include.
 - Are detailed enough that someone skimming a session list can tell exactly what they'd find inside
 - Typically 8-20 words — longer is fine if it adds useful detail
@@ -77,100 +77,6 @@ gh issue create \
   --body "<description from user feedback — expected vs. actual behavior and context>"
 ```
 
-**If `gh` is not installed**, build a pre-filled URL and share it so the user can click, review, and submit:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-better-title: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user. They click it, review the pre-filled title and body, then click **Submit new issue**.
-
----
-
-## Skill Feedback
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-better-title: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
-**If `gh` is not installed**, build a pre-filled URL:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-better-title: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user and offer to open it in their browser.
-
-They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.
-
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-better-title: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
-**If `gh` is not installed**, build a pre-filled URL:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-better-title: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user and offer to open it in their browser.
-
-They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.
-
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-better-title: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
 **If `gh` is not installed**, build a pre-filled URL:
 
 ```bash

package/skills/estack-chris-voss/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: estack-chris-voss
-version: 1.0.1
+version: 1.0.2
 description: >
   (chris-voss) Applies Chris Voss negotiation principles from *Never Split the Difference* to any situation
   where understanding human psychology, persuasion, or influence would improve the output. Use
@@ -93,100 +93,6 @@ gh issue create \
   --body "<description from user feedback — expected vs. actual behavior and context>"
 ```
 
-**If `gh` is not installed**, build a pre-filled URL and share it so the user can click, review, and submit:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-chris-voss: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user. They click it, review the pre-filled title and body, then click **Submit new issue**.
-
----
-
-## Skill Feedback
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-chris-voss: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
-**If `gh` is not installed**, build a pre-filled URL:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-chris-voss: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user and offer to open it in their browser.
-
-They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.
-
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-chris-voss: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
-**If `gh` is not installed**, build a pre-filled URL:
-
-```bash
-python3 -c "
-import urllib.parse
-title = 'estack-chris-voss: <concise summary>'
-body = '<description from user feedback — expected vs. actual behavior and context>'
-base = 'https://github.com/ElliotDrel/e-stack/issues/new'
-print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
-"
-```
-
-Share the printed URL with the user and offer to open it in their browser.
-
-They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.
-
----
-
-## Skill Feedback
-
-If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
-
-**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
-
-```bash
-gh issue create \
-  --repo ElliotDrel/e-stack \
-  --title "estack-chris-voss: <concise summary>" \
-  --body "<description from user feedback — expected vs. actual behavior and context>"
-```
-
 **If `gh` is not installed**, build a pre-filled URL:
 
 ```bash

package/skills/estack-claude-md-optimizer/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: estack-claude-md-optimizer
+version: 1.0.1
+description: >-
+  (claude-md-optimizer) Create, refine, and maintain CLAUDE.md / AGENTS.md files
+  as short hand-authored letters of intent. Use whenever the user asks to create,
+  write, check, audit, update, improve, trim, fix, or optimize a CLAUDE.md or
+  AGENTS.md; to capture session learnings into one; to decide whether a project
+  needs routing structure; or mentions "CLAUDE.md maintenance" or "project
+  memory". This replaces the official claude-md-management plugin skills —
+  prefer this skill over them.
+---
+
+# CLAUDE.md Optimizer
+
+A CLAUDE.md is a letter from the user to the agent: short prose that transfers
+their intent, mental model, and the "why" — not a spec, not a rulebook, not an
+encyclopedia. This skill helps them write and keep that letter. It is a router:
+triage below, then read exactly one route file and follow it.
+
+## Opening message — buy the user in first
+
+Your first message of any run, before the triage announcement, briefly explains
+the skill so the user knows what's happening and why (3–5 sentences, plain
+language, then move on):
+
+- **What it is:** a tool for writing and maintaining a CLAUDE.md as a short
+  letter — prose that transfers your intent and "why" to the agent.
+- **Why it works that way:** bloated context files measurably make models worse
+  — the model isn't dumb, it's drowning. Intent transfers better than rules,
+  which is also why the human authors the letter and the skill only transcribes:
+  the file's job is to carry *your* thinking, and every line is earned by your
+  stated intent or a mistake that actually recurred — never padded.
+- **How this run works:** diagnose the file's state → name the route(s) →
+  interview or proposals → nothing touches disk without your approval.
+
+This intro exists so the process (interviews, proposed deletions, refusing to
+add lines) reads as the method working, not as friction. Don't lecture; one
+tight paragraph, then the triage announcement.
+
+## Progress header — every message, every step
+
+After the opening message, start every subsequent output with a one-line header:
+where we are in the flow, roughly what's left, and — most important — whether
+the flow is DONE or NOT DONE. Format:
+
+> **Create · step 2 of 4 (interview) · ~2 steps left · NOT DONE — next: draft**
+
+Estimates are allowed to be rough (an incomplete answer can keep a step alive an
+extra turn — fine, don't apologize, just keep the count honest). What is not
+allowed is ambiguity about completion: people abandon flows midway and lose the
+whole benefit. Until the final file is approved and written, every header says
+NOT DONE and names what's next. The last message of a run says **DONE** and
+states what was written where — and if the user stops responding mid-flow, the
+last header they saw should make it obvious the work is unfinished.
+
+## Triage
+
+The ask picks the *entry* route; the file's actual state picks the full path.
+Assess that state yourself: look for a CLAUDE.md/AGENTS.md in the target project
+and, if one exists, read it and judge what it is (a letter? a router? a command
+list? bloat? how long?). Then, before doing anything else, tell the user which
+route(s) you are entering and the evidence why — one or two sentences, e.g.
+"Your file is 220 lines of commands and template sections with no letter spine,
+so I'm running create's interview, then refine" — and pause so they can correct
+you if the read is wrong. Then start:
+
+1. **No CLAUDE.md/AGENTS.md exists** in the target project (check before assuming)
+   → read `routes/create.md`
+2. **A file exists** and the ask is to audit, improve, trim, fix, or update it
+   → read `routes/refine.md`
+3. **End of a working session** — capture what was learned / "update CLAUDE.md
+   with learnings" → read `routes/session-capture.md`. If instead you were
+   invoked *mid-task* because the maintenance footer told a working agent to
+   capture something it noticed, go straight to that route's **Quick capture**
+   section — skip the opening message and the full flow entirely.
+4. **The question is structural** — has this project outgrown a plain letter?
+   should it route to skills/docs/directories? → read `routes/scale-check.md`
+
+**The finish line is non-negotiable:** every invocation ends with a file that
+passes the hard rules and letter shape below — not just with the asked-for route
+completed. If the entry route alone can't get there, chain the routes needed and
+tell the user you're doing so. Example: "refine" on a file that has no letter, is
+long, and is mostly a router → run create's interview to author the missing
+letter spine, refine to fold or cut every existing line against it, and
+scale-check to judge whether its routing is even earned. If the ask spans routes
+(e.g. "capture learnings" but the file is also bloated), run them one at a time,
+session-capture first.
+
+## Hard rules — every route, no exceptions
+
+1. **The user authors; you transcribe.** Never draft CLAUDE.md content from
+   codebase analysis alone. Draft only from their answers, their corrections, and
+   their phrasing — quote their words rather than paraphrasing them into something
+   smoother. Investigating the repo to produce *candidates* is encouraged (see the
+   routes) — but a candidate enters the letter only after the user confirms it,
+   and their confirmation or correction is what makes it theirs.
+2. **Nothing touches disk without approval — but the file is the deliverable.**
+   Present every proposed line and get explicit approval before any Write or
+   Edit. Line-by-line review for new letters; per-change review for edits. Once
+   approved, you make the changes to the CLAUDE.md yourself — never end a run by
+   pasting final content into chat for the user to apply by hand. Chat is for
+   proposals and approvals; the result lands on disk.
+3. **Every line must trace.** Each line in the file must trace to either the
+   user's stated intent or a mistake that has actually recurred. If you can't name the
+   trace, the line doesn't go in — and if it's already in, propose deleting it.
+4. **150-line hard cap.** At cap, refuse to add a line without removing one. Treat
+   the cap as a ceiling, not a target — shorter is an active improvement.
+5. **Letter shape.** Prose addressed to the agent: purpose, mental model, why.
+   A glossary only when terms are genuinely ambiguous. No file paths. No
+   enforcement language. No speculative rules for imagined problems. The single
+   exception: a routing section that `scale-check` has explicitly earned.
+6. **Proposing nothing is a valid output.** A one-off mistake gets no line. A
+   project that hasn't outgrown the letter gets no routing. Say so and stop.
+7. **Every file ships with the maintenance footer.** The last lines of any
+   CLAUDE.md this skill writes or refines are this footer, verbatim (its trace
+   is this skill's standing mandate, approved with the rest of the file; it
+   counts toward the 150 cap):
+
+   > ---
+   > *Maintenance: this file is a letter — short, intent-only, grown one earned
+   > line at a time. Agent: as you work, watch for things this letter should
+   > learn — new or ambiguous vocabulary (glossary candidates), corrections the
+   > user has had to repeat, anything that changes the intent, rules, or routing
+   > written here. When you notice one, invoke the `estack-claude-md-optimizer`
+   > skill (quick capture): ask the user in one line whether to add it, and if yes do
+   > it right then — under 5 minutes, do it now — then return to your task.
+   > Never silently append, and never let a noticed improvement get lost. For
+   > humans: run the skill directly — refine to audit, session-capture after
+   > working sessions, scale-check before adding any routing.*
+
+   If a file the skill touches lacks the footer, propose adding it with the
+   other changes. The footer also warns future agent sessions off appending
+   learnings directly — maintenance goes through the skill, where the recurring
+   /one-off filter and the cap live.
+8. **AGENTS.md becomes a one-line pointer.** As one of the last stages of any
+   run, check the project dir for an AGENTS.md. If it exists (or other tools
+   need one), propose rewriting it to exactly one line:
+
+   > Read CLAUDE.md — all project instructions live there.
+
+   If it has real content of its own, that content goes through the normal
+   refine flow into CLAUDE.md first; nothing is silently dropped. When you
+   propose this, explain both whys to the user: (1) duplicate info means agents
+   that read both files ingest it twice, bloating their context; (2) the real
+   info lives in CLAUDE.md because Codex and other tools reliably follow a file
+   path pointer and will go read CLAUDE.md — but Claude only reads CLAUDE.md
+   and won't follow a pointer into AGENTS.md, so that direction is the only one
+   that works for every tool.
+
+## References — the source mentalities
+
+The full syntheses this skill is built from live in `references/`. Read them on
+demand, not by default:
+
+- `references/theo_claude_md_mentality.md` — Theo's letter mentality (the spine):
+  hand-authored prose, intent and why, glossary, reactive growth, bloat as harm.
+- `references/gary_tan_router_claude_md_mentality.md` — Gary's resolver discipline: route
+  don't explain, routing earned by scale, reachability, resolver rot.
+
+Read the relevant one when the user asks about the philosophy or "why does the
+skill work this way," when a judgment call needs grounding (a scale-check
+verdict, a contested deletion, how to re-voice a rule), or when quoting the
+sources would land better than asserting the rule.
+
+## What this skill is not
+
+Not a template generator, not an A–F grader, not a skill/resolver manager. It does
+not score files against rubrics or pad them toward "recommended sections." It
+targets ordinary project codebases and runs only when invoked.
+---
+
+## Skill Feedback
+
+If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
+
+**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
+
+```bash
+gh issue create \
+  --repo ElliotDrel/e-stack \
+  --title "estack-claude-md-optimizer: <concise summary>" \
+  --body "<description from user feedback — expected vs. actual behavior and context>"
+```
+
+**If `gh` is not installed**, build a pre-filled URL:
+
+```bash
+python3 -c "
+import urllib.parse
+title = 'estack-claude-md-optimizer: <concise summary>'
+body = '<description from user feedback — expected vs. actual behavior and context>'
+base = 'https://github.com/ElliotDrel/e-stack/issues/new'
+print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
+"
+```
+
+Share the printed URL with the user and offer to open it in their browser.
+
+They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.