Forge a title + subtitle (or reframe) for a book, article, talk, or any technical piece 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', 'ชื่อมันเชย', 'คิดชื่อ'. DO NOT TRIGGER for: writing the body content itself (use kien-thai / the book skills).
SKILL.md
/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.)
Installs
0
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).
🎯 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 top of the
7 moves:
Spine test — say it out loud as if recommending it. If it needs a subtitle to make
sense spoken, the main title is doing too little.
Shelf test — write it next to three real books in the same genre. Generic titles
vanish; that is the whole signal.
Subtitle carries the technical axes (the 7 moves already say this); the main title
carries the tension. Do not let the subtitle rescue a dead title.
Then: the cover
This skill does not draw. Stated plainly because the alternative is pretending:
capability
present here
generative image tool (Imagen / DALL-E / SD)
no — no such tool in this session
codex CLI
yes — but codex does not generate images either
ImageMagick (convert / magick)
yes — composition only: type on a ground, crops, gradients
typst
yes — vector/typographic covers rendered with the book
So a cover here is one of two honest things: found art (licence-checked) or a
typographic composition. Neither is "the AI drew it", and neither should be described
that way.
Hand off to /oracle-book-cover — it already does this properly: finds real art with a
LICENCE gate, runs a 5-lens prism (Reader / Editor / Artist / Designer / Ads), renders 2-3
PNG candidates, bakes the winner into the book.typ cover block only, and exports social
crops. Do not rebuild that pipeline here.
/oracle-title-forge → title + subtitle
↓
/oracle-book-cover → art (licence-checked) or typographic cover → book.typ
If /oracle-book-cover is not installed on this machine, say so and stop — do not
improvise a cover with convert and call it a design. A typographic fallback is legitimate
only when the human asks for it knowing no illustration is involved.
Delegating to codex: /codex:rescue or the codex-rescue agent can take a
cover-generation task (typst layout, ImageMagick composition, asset wrangling). It cannot
produce an illustration. If someone asks "get codex to draw it", the answer is that no
agent in this fleet has an image model — the work has to be found art, vector, or type.
