Imported from dxiiren/cinema-ticket-booking (.claude/skills/llm-transfer/SKILL.md). Install upstream with npx skills add dxiiren/cinema-ticket-booking --skill llm-transfer. Copyright stays with the author.

llm-transfer - Master Prompt Handoff to an External LLM

Package the current work into one self-contained master prompt that a fresh external model - ChatGPT, Ollama (local), Gemini, DeepSeek, any LLM - can act on with zero prior context: no access to this repo, this session, or any tool. This skill IS the framework: run it and it assembles the handoff for you.

Whatever the target, the reader is a cold, tool-less model receiving a pasted or piped prompt - even Ollama, whose plain ollama run terminal session has no repo/file access unless you wire up tools yourself. So the job is always the same: embed everything the model needs.

Trigger

/llm-transfer                          # hand off the current work (asks which tool)
/llm-transfer {topic}                  # hand off a specific problem/task
transfer this to ChatGPT / Ollama / Gemini
hand this over to another LLM
make a master prompt for an external LLM
export context for an external LLM

What to do when invoked

Perform these steps in order. Do not skip the plan-mode step - the handoff is drafted and reviewed before it is final.

1. Enter plan mode. Call EnterPlanMode immediately. Assembly and review happen inside plan mode; you ExitPlanMode only when the master prompt is ready.

2. Determine scope, target tool, AND mode.

   • Scope: the {topic} argument, else infer from the current session/task.
   • Target tool + subdir: gpt (ChatGPT), ollama, gemini, codex, ... - sets the transfers/{tool}/ subdir and which Per-target notes apply. If unclear, ask once.
   • Mode (decides the output): is the target agentic (Codex / opencode / Aider - has the repo + runs commands) or cold (browser / plain ollama run - no tools)? Agentic -> emit the orchestration brief; cold -> the self-contained master prompt. See "Two target modes" below.
   • If the ask is ambiguous (continue the work vs. second opinion), fold it into the same one question.

3. Gather context. Pull only what's relevant: the objective and why, the current state (done / tried / failed / where it stands), the exact code / config / logs / errors / data - read the real files so artifacts are verbatim - the constraints/stack/ conventions, and the open questions.

4. No redaction - verbatim. The saved file is git-ignored and stays on this machine, so secrets/tokens are kept as-is. External exposure happens only when you send the prompt, which you drive:

   • Local Ollama - nothing leaves the machine; fully safe.
   • ChatGPT / Gemini / Ollama Cloud (Turbo) - the content goes to a third-party service when you paste/send it. If a specific live credential worries you, strip that one line by hand first. The skill won't.

5. Assemble the master prompt using the framework below.

6. Deliver.

   • Print the full master prompt in chat as a single fenced text block.
   • Save it to .claude/workspace/reports/transfers/{tool}/ as {YYYY-MM-DD}-{topic}.md ({tool} = gpt / ollama / gemini; {topic} names the work, not this skill). Create the folder if missing.
   • Tell the developer how to feed it to the target (see Per-target notes), then ExitPlanMode.

THE FRAMEWORK - master prompt template

Fill every section. Omit a section only when it truly doesn't apply, and say so rather than leaving it blank. Keep the headings - the structure is what makes the handoff legible to a cold model. Restate the task at the very end: for a long prompt, the key instruction should appear at BOTH the top and the bottom (see Design basis).

# MASTER PROMPT - {one-line title of the task}

## 1. Role
You are {persona - e.g. a senior VB.NET/WinForms engineer / a desktop-UX reviewer / a
security tutor}. {Any relevant seniority, domain, or mindset.}

## 2. Mission
{The single objective, in 1-2 sentences. What "success" delivers.}

## 3. Background & Context
{Everything a model with ZERO prior knowledge and NO repo access needs to understand the
situation: what the project is (an archived VB.NET WinForms cinema ticket booking app - 8
forms, flat-file auth, .NET Framework 4.7.2), the domain, and WHY this task matters.
Self-contained - assume the reader has never seen this codebase.}

## 4. Current State
- What is already done: ...
- What has been tried: ...
- What failed and how: {exact symptom / error}
- Where it stands right now: ...

## 5. Relevant Artifacts
{Inline the actual code / config / logs / errors / data. Each block labeled with its source
path, separated from your instructions by a fence. Verbatim. Only what's relevant - not a repo
dump.}

`Cinema Ticketing Booking System/Login.vb` (excerpt)
```
{exact contents or the relevant excerpt}
```

{error / log output, if any}
```
{exact text}
```

## 6. Constraints & Rules
- Tech stack: {VB.NET WinForms on .NET Framework 4.7.2, zero NuGet dependencies; built with
  MSBuild via `just build`, launched with `just run`}
- Standards / conventions to honor: ... (cold target: inline the repo's CLAUDE.md rules here;
  an agentic target reads CLAUDE.md itself)
- Hard do's and don'ts: ...
- Anything off-limits: ...

## 7. Your Task
{The precise, unambiguous ask. Exactly what to produce, decide, or solve. If it's a second
opinion, state the problem neutrally - do NOT lead toward a conclusion.}

## 8. Output Format & Success Criteria
- Deliver the answer as: {format - a corrected file, a diff, a step list, a decision + rationale}
- Definition of done: {how we'll know the answer is correct/complete}

## 9. Open Questions & Assumptions
- Known gaps: ...
- If blocked, either ask or state your assumption and proceed: ...

## Reminder (restate - instructions repeated at the end for long context)
{One-line restatement of Section 7: the single thing to deliver.}

Assembly rules (the craft)

• Self-contained. The model has no access to this repo, this session, or any tool. If it isn't in the prompt, it doesn't exist. Embed it.
• Selective, not a dump. Include only artifacts that bear on the task; summarize the rest. Respect context limits - three relevant files beat thirty (and see the Ollama note: local windows can be small). In this repo the hand-written form logic is tiny (43 lines of Login.vb is the biggest) - inline logic files whole, but excerpt the .Designer.vb files (up to 1101 lines of generated layout) down to just the controls that matter.
• Fidelity over paraphrase. Paste exact code, exact errors, exact paths.
• Instructions top and bottom. For a long prompt, put the key task at both the start and the end; if only once, put it above the pasted context, not below.
• Local & git-ignored. The saved copy stays on this machine and is never committed, so secrets are left verbatim. Only sending to a cloud service leaves the machine - that call is yours.
• Neutral framing for second opinions. State the problem and the evidence; don't smuggle in the conclusion you already reached.
• Portable. The handoff may target any project and any model - spell things out.

Per-target notes

• ChatGPT / Gemini (cloud): large context windows - you rarely hit a limit. Content leaves the machine when you paste it. Delivery: paste the block (or the saved .md) into the web UI.
• Ollama (local terminal): a cold model with no repo/file access in a plain ollama run session (tool-calling exists but only if you wire tools up yourself). Two real differences from ChatGPT:
  • Small default context. Ollama's default is VRAM-dependent - 4k tokens under 24 GiB VRAM (32k at 24-48 GiB, 256k at 48 GiB+), and Ollama recommends >= 64,000 tokens for coding/agent work. A big master prompt can exceed the default, so keep it tight AND raise the window: OLLAMA_CONTEXT_LENGTH=64000 ollama serve (or per-request num_ctx).
  • Delivery = pipe, not paste. cat {file}.md | ollama run {model} (stdin pipe and prompt-as-argument are the documented input forms). Nothing leaves the machine.
  • Cloud caveat. Ollama Cloud / Turbo offloads to Ollama's servers (opt-in, sign-in required) - when used, treat it like ChatGPT.

Two target modes: agentic vs cold

The output depends on whether the target can read the repo and run commands.

Agentic target - Codex / opencode / Aider (or Ollama running inside one)

It HAS the repo, reads files, and runs commands. Do not dump a payload - emit a lean orchestration brief that drives the agent to use our own conventions and skills. Include:

1. Conventions: "Follow the repo's CLAUDE.md." (Codex/opencode/Aider read AGENTS.md / the repo's instructions automatically; the line reinforces which file to honor.)
2. Situation (continuation state): use claude-transfer's brief template - mission, DONE / IN PROGRESS / NEXT, pointers (path:line, recent commits), open questions, dead-ends, first action. Pointer-based; the agent re-reads files itself. This is the "continue where Claude left off" payload.
3. Use our skills: name the relevant playbook(s) and tell it to follow them - "For this task, read and follow .claude/skills/<skill>/SKILL.md (and the skills it references); run its scripts, e.g. python .claude/skills/<skill>/<x>.py." Our skills are just markdown playbooks + stdlib Python - an agent can read and run them. This is how the agent "uses our skills."
4. MCP caveat: skills that use the GitHub MCP need it configured in the agent (Codex supports MCP). Until then, do those steps by hand.
5. First action: the single next step.

Save to transfers/{tool}/{YYYY-MM-DD}-{topic}.md; hand the file over (paste it, or tell the agent "read <path> and proceed").

Cold target - browser ChatGPT / plain ollama run

No repo, no tools. It cannot read CLAUDE.md or our skills. Use the full self-contained master-prompt framework above; if it must follow project rules or a skill's method, inline the relevant CLAUDE.md rules / SKILL.md steps into the prompt (Section 6).

Delivery format

Chat:

```text
# MASTER PROMPT - ...
...full assembled prompt...
```

Then:

Saved: .claude/workspace/reports/transfers/{tool}/{YYYY-MM-DD}-{topic}.md
Feed it:  (gpt/gemini) paste into the web UI   |   (ollama) cat <file> | ollama run <model>

Worked example (compact)

Target: "Get a second opinion on the app's documented flat-file auth flaw from an external LLM (design review, not a code change — the repo preserves its flaws)."

# MASTER PROMPT - Review a flat-file auth design and rank its risks

## 1. Role
You are a senior application-security reviewer who explains risk to a junior developer
without condescension.

## 2. Mission
Assess the login/register design below, rank its weaknesses by real-world impact, and outline
(in prose, no code) what a minimal hardening of THIS design would look like.

## 3. Background & Context
An archived VB.NET WinForms university project (cinema ticket booking, .NET Framework 4.7.2).
Auth is a flat text file, `UsernameAndPassword.txt`, stored next to the exe: alternating
lines of username then password, plaintext. The repo deliberately preserves the flaw and
documents it; this review feeds that documentation. No repo access - everything relevant is
below.

## 4. Current State
- Done: the flaw is catalogued (plaintext storage, append-without-dedup, no validation).
- Not done: an expert ranking of which parts matter most, for the docs' Known Issues section.

## 5. Relevant Artifacts
`Register.vb` (the whole write path)
```
usernamePassword = File.AppendText("UsernameAndPassword.txt")
usernamePassword.WriteLine(txtUsername.Text)
usernamePassword.WriteLine(txtPassword.Text)
usernamePassword.Close()
```
`Login.vb` (the read/match loop)
```
usernamePassword = File.OpenText("UsernameAndPassword.txt")
Do Until usernamePassword.EndOfStream
    username = usernamePassword.ReadLine()
    password = usernamePassword.ReadLine()
    If (username = txtUsername.Text And password = txtPassword.Text) Then
        blnValid = 1
    End If
Loop
```

## 6. Constraints & Rules
- This is a design review of coursework - do NOT produce replacement code.
- Assume a single-machine, single-user desktop context when ranking impact.

## 7. Your Task
Rank the weaknesses (plaintext at rest, duplicate usernames with divergent passwords, empty
credentials accepted, file location next to the exe, bare-catch error handling) from most to
least consequential IN THIS CONTEXT, justify each rank in 2-3 sentences, and sketch the
minimal-change hardening path in prose.

## 8. Output Format & Success Criteria
- Output: a ranked list with justifications + one short hardening paragraph.
- Done: every listed weakness is ranked; no code included.

## 9. Open Questions & Assumptions
- Assume the file is never synced/shared; say if that assumption changes a rank.

## Reminder
Ranked weaknesses with justifications + a prose hardening sketch. No code.

That's the shape of every handoff - scale each section up or down to fit the task.

Design basis (researched 2026-07-01)

• Instructions top and bottom of a long prompt - OpenAI GPT-4.1 prompting guide. (The template's closing Reminder exists for this.)
• Ollama specifics - verified directly from official docs: default context is small and VRAM-dependent (4k / 32k / 256k), 64k recommended for coding (context length); a plain ollama run has no tool/repo access unless the caller wires tools (tool calling); local by default, Cloud/Turbo is opt-in and sends data off-machine (cloud); stdin-pipe / argument input (cli).
• Unverified / honest gaps: the 9-section scaffold and ordering are standard practice but could not be independently confirmed - treat as judgment, not fact. The verbatim-local stance is a deliberate call; OWASP LLM02 flags the sensitive-info-disclosure risk class.

Evolution Log

• Ported from marks-counter for cinema-ticket-booking - same 9-section framework and dual-mode (agentic brief vs cold master prompt); personas and stack references adapted to VB.NET WinForms, the selectivity rule now distinguishes tiny logic files from huge generated Designer files, and the worked example became a design review of the repo's real plaintext-password auth flow (the flagship documented known issue).