Run the full guide-building pipeline on the attached transcript, start to finish, and deliver the finished guide — not an outline, not a plan, not a proposal to review first.

Classify the source against this project's source-type table (custom instructions §4) before doing anything else: implementation/how-to, persuasive/philosophical social posts, conceptual/teaser, multi-source with contradictions, or third-party strategy/evaluative documents. Name the type — and a secondary type if it's a genuine blend — before proceeding. This decision determines everything downstream: which skill applies, whether verification stays visible or silent, and what the finished guide looks like.

Decide which skill applies, and read its SKILL.md (and reference files) before producing anything:

/transcript-deep-dive is built for a shallow, solo technical walkthrough — the classic implementation/how-to case, whether delivered solo or through an interview format.
/transcript-superguide handles everything else: persuasive, conceptual, multi-source, evaluative, or a genuine multi-speaker debate with real disagreement worth adjudicating. It runs its own six-phase pipeline (classify, inventory, research, improve, catalog, assemble).
If /transcript-superguide's own classifier returns a shallow, solo technical source, hand the gap-fill to /transcript-deep-dive and don't duplicate the work — this project's skill-routing discipline (§5) governs when the two compose versus when only one applies. Use both only when the source genuinely needs it — for example, an implementation walkthrough that also contains one real, substantive disagreement worth resolving in place, not as a default.
Read the entire source before outlining. Use bash cat/sed on anything long enough to risk truncation — never the view tool, which truncates silently within a range and leaves missing content that looks complete.

Verify every volatile claim before writing a word of the guide: prices, tool and model names, version numbers, platform features and fees, anything that could have changed since the source was recorded. Search primary sources — never assert a checkable fact from memory. Identify and correct anything the source got wrong, anything transcription mangled (misheard names, garbled tool names, misattributed claims), and anything genuinely unconfirmable after a real search attempt gets flagged, not invented.

Run one gap analysis — not a token pass, and not a second one after the first. For the source's actual type, find every concept named but not explained, every step referenced but not walked through, every configuration mentioned but not shown, every prerequisite assumed, every edge case ignored, every comparison left without criteria for choosing, and every resource with no link to verify it by. Research and close each one against primary sources before writing.

Build the guide in the format this project's custom instructions (§4, §6, §7, §8) specify for this source's type — don't default to any single template regardless of what the source actually is:

An implementation/how-to source becomes a procedural manual: prerequisites, step-by-step sections with exact commands, a practical-workflows/day-to-day-use section, verification folded silently into confident prose — no visible correction tags, no headline gaps section — and a closing checklist instead of a prose summary.
A persuasive/philosophical, conceptual/teaser, multi-source, or evaluative source gets the treatment §4 specifies for it instead — including, for the latter two, this project's visible source-fencing labels and a mandatory Honest Gaps section, since those are the guide types where showing the verification work is the point, not a liability.
Whatever the type, hold the guide to the same bar the most recent implementation guide in this project was held to: every checkable claim actually checked, every real gap closed or honestly flagged, nothing padded to look thorough, and — specifically for implementation sources — something the reader can act on, not a report about the source.
Deliver one finished markdown file via create_file and present_files (split into at most three only if length genuinely forces it, at natural section boundaries, per the stop-gate protocol — never all at once). No index, no extra artifacts, no re-presenting anything that already exists in this project.

Avoid: defaulting to the implementation-guide template for a source that isn't one; running both skills redundantly when the source only needed one; treating a resource catalog or a Honest Gaps section as required for every guide type when §4 reserves them for three of the five; and asserting anything checkable without having actually checked it.