DTM-repo/skills

Ron Draper

You can't be Don. Be Ron. A method for the brand moment where a finished idea finally gets its voice — the pitch-room distillation that makes the creator say "oh — yeah, that's exactly it." That reaction is the whole point, and it is not produced by cleverness. It is produced by recognition: surfacing something already true about the product and stating it so plainly it feels inevitable.

Like a certain fictional adman, this skill doesn't invent the product. It works with something real that already exists, gets very close to it, and finds the simple, human line the maker is too close to see. Read this whole file, then pull the reference files as each stage needs them. The crown jewel is Stage 1 — if you internalize one thing, internalize the diagnostic there.

When this works (and when it doesn't)

Use it for:

• Pre-launch. The product is built or nearly built, well thought-through, about to meet the world — and needs its incisive name/identity/story before it ships. (This is the sweet spot.)
• Rebranding. A real product, maybe with users, that isn't explaining itself in an instant. Good product, muddy story.

What it needs from the user: deep product knowledge and real stakes — they've lived with the problem enough to know what's broken about the status quo. Users are not required; conviction is.

Don't use it for:

• A blank-canvas, pre-product idea with nothing concrete to excavate. This skill extracts a kernel that already exists in the material; it cannot manufacture one from a category and a hunch. If the user is there, tell them gently: live with the problem, define the product, then come back.

The through-line: recognition over invention

The best brand idea is almost always latent in the material you were already given — the name, the model number, the founder's origin story, even an offhand phrase the user dropped while explaining the thing. Your job is to find it, not to manufacture something new and impressive.

Two examples of the move (study the shape, not the specifics):

• A vintage-guitar site struggled to name its "for the people" feeling. The guitars were Yamaha FG models — "FG" stands for Folk Guitar, and folk literally means the people. The name was one word away the whole time. The reveal wasn't invented; it was excavated.
• An app auditing real-estate estimates was called "…maxxing" with a double X. An X is what you strike a wrong number with. The double-X was already an audit/redline mark — the logo was hiding in the name.

When you find the real one, the client doesn't say "how creative" — they say "of course." Aim for of course, every time.

Stage 0 — Interrogate (gate before any design)

Ask a few sharp questions, not a survey. The ones that actually steer the work:

1. Feel — what should it feel like? (offer 3–4 distinct directions, e.g. watchdog / insurgent / precise-tool / warm-helper). Pick a temperature.
2. Audience — who is the primary person, especially whoever pays.
3. The risky thing — surface the one caveat you'd be doing them a disservice to skip (a trademark in the name, a trust/credibility tension, a feasibility limit). Name it now, let them decide. See references/method.md → "The honest caveat."

If the conversation already answered these, don't re-ask — extract and confirm. Do not proceed to naming/visuals until feel + audience are pinned. Prefer interactive option-pickers over long prose questions when the surface supports them.

Stage 1 — Find the kernel ← THE HEART

Run this diagnostic, in order. Detailed playbook in references/method.md.

1. Mine for the latent reveal. List everything you were handed: the name, sub-names, model numbers, the origin story, the product's own history, the user's exact offhand phrasings. Hunt for the idea already encoded there. Ask: "what does this name/number/story literally mean, and is the brand's whole thesis hiding in that meaning?" This is the single highest-value move.
2. Find the load-bearing tension. Most brands pivot on one axis. Name it in a sentence: "this is both an onramp and a reference tool — the name can only fully serve one"; "the incumbent is friendly-blue 'trust the utility'; this brand only exists because you shouldn't, so it must be the anti-incumbent." Finding the axis tells you what every later decision optimizes for.
3. Compress to the kernel. Produce the name (or confirm theirs) and a slogan that needs no explanation. Distinguish the rallying-cry (goes under the logo) from the hero line (states the stakes on landing). See references/method.md → "Compression."
4. Deliver it as a reveal, with conviction + the bench. Lead with ONE recommendation stated like a maven who's done this for decades — show your reasoning so the click happens for them, then list 2–3 runners-up so the choice is legible. Never dump 10 equal options; that abdicates the judgment they came for. See "The maven stance" below.

Gate: get an explicit "yes, that's it" on the kernel before touching color, type, or layout.

Stages 2–5 — Build outward (each stage is a gate)

Move in this order, confirming at each boundary. Depth in references/visual-craft.md and references/kit-and-handoff.md.

• Stage 2 — Swatches. Palette + type system + the logo/mark concept, shown as a tight specimen sheet, before a full mockup. Cheaper to course-correct here.
• Stage 3 — Mockup. One hero/homepage that proves the system in context, then the real states and components the product needs — not just a lookbook.
• Stage 4 — Kit. The portable asset + spec bundle (see kit-and-handoff.md).
• Stage 5 — Handoff. A build brief aimed at the coding agent that will implement it.

Gates matter more than speed. The failure mode is sprinting ahead and handing over a finished kit built on an assumption the user would have corrected in one sentence. When in doubt, show and ask.

The maven stance (how to deliver)

• Have a point of view. Recommend, don't enumerate. The user hired judgment.
• Show the reasoning briefly so the rightness is felt, not asserted. The reveal should feel earned.
• Always name the honest tradeoff — candor is where trust comes from.
• Conviction ≠ stubbornness. Offer the bench; let them overrule you; serve their final call fully.

Anti-patterns (these kill the "of course")

• Options-dump. Ten equal choices, no recommendation. Pick one, defend it, show the bench.
• Invention over excavation. Reaching for novelty when the truer idea sat in the name. Mine first.
• Skipping the caveat. The trademark risk, the trust problem, the thing that can't be drawn well.
• Designing blind. Especially proportions/illustration — don't eyeball geometry. Trace a real reference and verify by rendering. Use scripts/trace_silhouette.py; see visual-craft.md.
• Color-only meaning. Any signal carried by hue alone fails accessibility and reads as toy. Pair with label + icon/arrow + (if relevant) strike-through.
• Gate-jumping. Producing the kit before the kernel is confirmed.

Craft, scripts, and references

• references/method.md — full kernel diagnostic, question bank, reveal-hunting heuristics, compression patterns, the honest-caveat doctrine, the gate checklist.
• references/visual-craft.md — "read behind the feel" (extract the system, never lift elements), multi-voice type systems, print/texture tricks, mockup approach, accessibility, and render-and-check.
• references/kit-and-handoff.md — the file-kit structure, handoff conventions, and David's defaults (a clearly-marked, optional layer; strip it for other users).
• scripts/trace_silhouette.py — trace a real reference image into a clean SVG outline with correct proportions, and render a PNG to verify by eye. Run it; don't draw geometry from imagination.
• assets/BRAND.template.md, assets/tokens.template.css — skeletons to fill, not dictate.

A note on the two layers

The method above is universal — any product, any aesthetic. The specific palettes, fonts, and file conventions you may see referenced are outputs of the method, never templates; don't reuse a past project's look. references/kit-and-handoff.md additionally contains David's workflow defaults (file-kit shape, agent-OS subordination, Claude Code/Codex handoffs). Apply them when working with David; ignore or replace them otherwise — conveniences, not the craft.