/oracle-title-forge

name: oracle-title-forge
description: "Forge a title + subtitle (or reframe) for a BOOK, article, talk, or any technical piece, then hand off to a cover so it has LIFE and honesty — not clinical/dated. The method that produced 'Claude Code Channel ปะทะ Hermes Gateway'. Describe-before-you-name, find the real tension, prism the candidates, calibrate register (eloquent but dev-natural, not poetic), name the real technical axes in the subtitle, refuse a fake winner. Use when: a title feels เชย/dead/generic, when naming a book or post, when reframing a comparison as a genuine contest, or when the user says 'ตั้งชื่อ', 'title', 'reframe', 'ชื่อมันเชย', 'คิดชื่อ'. After the title lands, offer the cover step (see 'Then: the cover'). DO NOT TRIGGER for: writing the body content itself (use kien-thai / the book skills), or for designing a cover from scratch when no title work is needed (go straight to /oracle-book-cover)."
argument-hint: "<what to title — topic, or the current dead title + what the piece is about>"
hidden: true
metadata:
  internal: true

/oracle-title-forge — forge a title that has life, honestly

> Born 2026-07-09 turning the dead "ผ่าไส้ Discord Channel ของ Claude Code" into > **"Claude Code Channel ปะทะ Hermes Gateway — สองสถาปัตยกรรมที่ทำให้ AI คุยบน Discord ได้…"** > The lesson: a great title is *grown from understanding what the thing IS*, not shuffled from words.

Why the method works (read this first)

A dead title fails one specific way: it has **clarity without intrigue**. "ผ่าไส้ X" tells you the topic and nothing else — no tension, no question, no stake. Every principle below exists to add intrigue *without lying*. The magic isn't wordsmithing; it's that each step forces you to understand the material more deeply, and the title falls out of that understanding.

The method — 7 moves

1. Describe before you name

Never start by brainstorming words. First write **what each thing IS** — once vividly, once in plain technical terms. The title grows from this. (For the Discord book, writing "the plugin is a stdio bridge tied to a session's lifecycle; Hermes is an always-on daemon" is what *revealed* the contest.)

2. Find the real tension — and check it's not forged

If it's a comparison/VS, run a **skeptic pass**: is the contest real or clickbait? Two things at different layers can't fight on features. Reframe the tension at the honest layer — *philosophy, fit, tradeoff* — not a fake feature-fight. A title promising a showdown the book can't deliver is a lie. (Discord book: they're transport vs runtime — so the contest is "two philosophies of presence," which is true, not "which codes better," which is false.)

3. Prism the candidates — 3-5 lenses

Look at each candidate from angles a single view misses. Useful lenses for titles:

• **🏪 Bookshelf browser** — does the spine make someone pick it up?
• **💀 Honest skeptic** — does the title over-promise? name only one side of a two-sided story?
• **🧑‍💻 Dev-ear** — *would a developer actually say this phrase?* Kill words devs don't use

("ให้ AI พูด" → "AI คุยบน Discord"; "ต่อ AI เข้ากับ Discord" → clunky; "data เข้าทางไหน" ✓ real).

• **✍️ Thai editor** — cadence, clean noun phrases, cut stray connectors (ด้วย/ต่อ...เข้ากับ).
• **🎯 Precision** — does the subtitle name the *real axes*, not vague adjectives?

4. Apply the craft principles (from title research)

• **Tension = clarity × intrigue.** The reader must grasp *something* instantly AND be compelled

to open it for the rest.

• **Contrast breeds curiosity.** Unexpected/opposed words hook ("The Wealthy Barber"). A "ปะทะ" /

"vs" between two named things is contrast built-in.

• **Formula: short curious head + longer explaining subtitle.** Head = hook (1-6 words / a clash /

a question). Subtitle = context + payoff.

• **Question form** raises the stakes above the mechanism ("ใครควรได้…").
• **Cadence / list-of-three** makes the subtitle linger ("data ขาเข้า, การคุมสิทธิ์, วงจรชีวิต").

5. Calibrate register with the human

Draft, then dial. Common arc: *clinical → too poetic → eloquent-but-technical*. The target for technical work: **สละสลวยแต่ตรง, ไม่เล่นอุปมามาก** — pleasant to the ear, but every phrase points at something real in the code. Show the human one sample paragraph in the proposed voice and let their taste calibrate. Their "แปลกๆ" is data — chase the specific weird word.

6. Name the real technical axes in the subtitle

Don't sell with adjectives ("powerful, elegant"). Sell with the **concrete things the piece compares/covers** — the axes a practitioner cares about (data path, access control, lifecycle), ending on the payoff ("ตัวไหนเหมาะกับงานแบบใด").

7. Honesty is a feature, not a weakness

Refuse the cheap winner. "Generic: it's a tie on different axes; situational: here's the matrix" reads as *more* authoritative than "X wins." A title/frame that promises an honest verdict earns trust the clickbait can't.

Output shape

Offer **2-3 candidates**, each *described by the feeling it gives + the craft reason it works* (not a bare list), recommend one with why, then render the full cover block (head + subtitle) so the human sees it assembled. End by asking which — let taste decide the last 5%.

Proven example

# Claude Code Channel ปะทะ Hermes Gateway
สองสถาปัตยกรรมที่ทำให้ AI คุยบน Discord ได้ — เทียบตั้งแต่ data ไหลเข้าทางไหน
คุมสิทธิ์การเข้าถึงยังไง ไปจนถึงว่าตัวไหนเหมาะกับงานแบบใด

Head = two named contenders + ปะทะ (contrast). Subtitle = 3 real axes + payoff. Register = eloquent but dev-natural. Verdict promised = honest (fit, not a fake winner).

Related: [[kien-thai]] (Thai prose engine), [[oracle-prism]] (the lens method), the book skills (oracle-write-complete-book / -booklet / -combine-blogs) that consume the forged title.

---

Book mode

A book title carries more weight than an article's: it is the spine text, the search result, and the thing someone repeats to a friend. Two extra constraints on