How I Used Code + Warp.dev (AI) to Turn a Requirements Doc + Code into a Detailed Slideshow and KB Article in About an Hour

darrin

— 7 min read

We have about 1 million lines of code across TOT and it is impossible to know everything. The goal here is to give the rest of the team a repeatable pattern for turning code + docs → slides → KB content for your own use and for the broader team in cases where you want to Brown Bag or just see how the code solves for the requirements of a Trello card, JTBD or user story.

This is a quick “how‑to” guide for the JTBD / Insight Engine deck and article that I built and talked about here: https://ghost-tot-u35315.vm.elestio.app/our-customer-led-growth-operating-engine-insights-to-execution/.

It covers:

  • How I used Warp (the agentic terminal) to assemble a simple HTML slide deck to share with the team in about an hour while doing other things.
  • How I used Warp live during the Q&A to generate extra slides from the team’s questions during the presentation.
  • How we then turned the deck into a Ghost article, and what other sharing options are available.

Tools & ingredients

  • Warp – our agentic development environment; lets you run terminal + agents in the same place and feed them repo context.
  • Your Repo: in my case I used the tot-ops-merged but you can point Warp.dev to any repo.
  • 2024 Business Operating Engine document – last year’s vision (about a 20 page document in markdown) for how we wanted to use Insights and JTBDs to drive business decisions. This is what our current tot-ops infrastructure was built to realize.
  • reveal.js – open‑source HTML slide framework used to build the presentation - I'm completely unfamiliar with but it was referenced in the static HTML code generated by Warp.dev.
  • Ghost – where we publish internal KB articles.
  • LLM agent – the assistant running inside Warp that we nudged along and refined.

1. Context-gathering in Warp

The first phase was about getting context out of the repo quickly and tying it back to last year’s vision.

In Warp I:

  1. Fed in the 2024 Business Operating Engine document
    This described how we wanted to use Insights + JTBDs to drive business decisions. I asked the agent to:
    • Analyze that vision,
    • Analyze the current code and configuration in tot-ops-merged,
    • Tell us how we’re doing relative to the vision,
    • Provide breadcrumbs into the code (where specific behaviors live), and
    • Draft a narrative for the team about:
      • What we’ve done,
      • What we’re doing now,
      • Why it matters,
      • How it relates to specific modules and flows,
      • What is not done yet,
      • What’s next.
  2. Opened the repo and core docs
    • Read README.md, docs/operational-architecture.md, and src/node/matchInsights.md to ground the business context.
    • Skimmed JTBD‑related modules (matchInsights.js, jtbdMatcher.js, JTBD observers, escalation code).
  3. Asked the agent for a synthesized view
    Summarized:
    • How JTBDs are stored and loaded,
    • How notes are fetched from ProductBoard,
    • How Insights are scored and escalated,
    • How Pipedrive and high-value prospects fit into that flow.
  4. Time cost:
    Roughly an hour total, but interleaved with other tasks:
    • Ask the agent for a summary or outline,
    • Do something else,
    • Come back, skim what it produced, and refine.

Warp gave me a tight loop: “look at the code and vision → ask questions → refine understanding” without leaving the terminal.

2. Co-designing the slide deck with Warp + reveal.js

Once the context was clear, the next step was to turn it into a slide sequence.

2.1. Drafting the structure

With the agent in Warp I:

  1. Asked for an outline of a deck aimed at:
    • Explaining where this code fits in the 2024 Business Operating Engine,
    • Tying JTBDs and Insights to the team’s work,
    • Making it understandable to Ops Dev, QA, and Scrum Masters.
  2. Iterated on the outline:
    • Added a clear “What is an Insight?” section.
    • Pulled in Avoma/Freescout/Pipedrive flows.
    • Added “What we can do today” vs “Where we’re going next”.
    • Added role‑specific Q&A sections.
  3. Settled on a roughly 12–15 slide structure, then asked the agent to generate a reveal.js‑based HTML deck following that outline.

2.2. Building the HTML slide deck

The agent assembled an HTML file that:

  • Loaded reveal.js from a CDN.
  • Defined one <section> per slide with headings and bullets.
  • Used simple CSS tweaks for readability.

Then I:

  • Opened the file in a browser.
  • Read every important slide:
    • Rewrote wording where needed,
    • Asked the agent to break up dense slides (e.g., the data flow) into multiple readable ones,
    • Inserted additional slides for:
      • Pipedrive/high‑value prospects,
      • The global data flow,
      • Role‑based Q&A.

I did this while doing other work, checking in on the deck between tasks, but the net time was still about an hour. The important part:

I never hand‑coded the deck from scratch; the agent generated the reveal.js scaffolding and I edited/refined.

3. Presenting with live, agent‑generated Q&A slides

This is the part I’d highlight for other teams: we used Warp during the meeting, not just before it.

3.1. Starting with a prepared deck

By the time of the all‑hands:

  • The reveal.js deck was “good enough” and proofed for:
    • Big-picture narrative,
    • Data flow,
    • What the engine can do today,
    • Where we’re going,
    • Initial role-based Q&A.

I opened it in the browser and presented directly from that HTML file.

3.2. Feeding live questions into Warp and generating slides

Ahead of and during the Q&A, we collected more detailed questions, especially from the Scrum Master and QA side. Rather than pre‑baking all of them, I:

  1. Pasted those questions into Warp at the start of the presentation.
  2. Asked the agent to:
    • Answer them in our existing terminology,
    • Propose slide‑friendly content (titles + bullet answers).

Important nuance:

  • I didn’t fully proof these extra slides before presenting – there wasn’t time.
  • Instead, I used them as draft scaffolding in the Q&A:
    • Flip to the new Q&A slide,
    • Use it to guide the explanation,
    • Correct/clarify verbally as needed.

This is a good pattern:

For prepared content, proof the slides; for live Q&A, let the agent give you a structured first draft and use your judgement in the room.

4. Turning the deck into KB content (Ghost) – Option A

After the session, I wanted to share two things with the rest of the team:

  1. The content itself (what the JTBD / Insight engine does), and
  2. How we built and delivered it (this article).

There are several ways to do that; for this run we chose the lowest‑friction option.

4.1. Option A – The simplest approach: Narrative Ghost article (what we did)

We took the prepared deck and:

  1. Exported the content to markdown (with the agent’s help).
  2. Turned each major slide into a section in a Ghost article:
    • H2 headings like “Why this engine exists”, “End‑to‑end data flow”, “How Pipedrive fits”, “Role-specific notes”.
    • Bullet lists became paragraphs or section bullets.
  3. Added context at the top:
    • “This is the narrative version of the deck we just presented,”
    • Space to link:
      • The HTML slide deck,
      • The meeting recording.

This option is:

  • Quick – no extra hosting, just paste markdown into Ghost.
  • Searchable – works like normal documentation.
  • Easy to update as the engine evolves.

4.2. Option B – Embedded deck (static site + iframe) – for the future

We didn’t do this yet, but it’s worth documenting because it’s close to zero extra work once a static host exists:

  1. Host the *.html reveal.js deck somewhere (S3/CloudFront, Netlify, internal nginx).
  2. In Ghost, create a short intro article and embed the deck with an <iframe>.
  3. Link the recording.

This would let people page through the slides inside the KB. It’s almost as easy as Option A, especially once we’re comfortable publishing small static bundles from Warp.

4.3. Option C – Slide-style article (KB only)

Another option we considered conceptually:

  • Use the deck to define the structure,
  • Recreate each slide as a section in Ghost with:
    • A bold “slide title”,
    • 3–5 bullets,
    • Optionally a screenshot of the actual slide.

This keeps everything inside the KB and looks “slidey,” but we didn’t need it for this iteration.

5. The workflow recipe (step-by-step)

For anyone wanting to repeat this pattern, here’s the minimal recipe.

Step 1 – Clarify your audience and questions

  • Who is this for? (Ops Dev, QA, Scrum Masters, whole company?)
  • What questions do they already have?
  • What “story” do you want to tell from code → business outcome?

Capture that in Warp as a short prompt to the agent.

Step 2 – Use Warp to mine the repo + vision

Inside Warp:

  • Feed in the relevant vision/operating docs (in this case, the 2024 Business Operating Engine).
  • Ask the agent to:
    • Compare the vision with the current code and configuration,
    • Locate the relevant modules, tests, and docs,
    • Summarize behaviour in plain language,
    • Call out gaps and “what’s next”.
  • Cross‑check against files (and read them yourself for anything critical).

Step 3 – Co‑design an HTML deck with reveal.js

Still inside Warp:

  1. Ask the agent for a slide outline; refine it until it matches your narrative.
  2. Have the agent generate a reveal.js HTML deck implementing that outline.
  3. Open it in a browser and edit:
    • Split dense slides,
    • Fix wording,
    • Ensure the story flows for your audience.

Target: about an hour of total work spread around other tasks.

Step 4 – Present, then extend with live Q&A slides

During the session:

  • Use the prepared deck for the main story.
  • Collect new questions (Slack, verbal, etc.).
  • Paste them into Warp and have the agent propose Q&A slides.
  • Use those slides as scaffolding to answer live; adjust verbally as needed.

Step 5 – Publish to the KB

Pick one of the three options:

  1. Option A (what we did):
    • Convert the slide content into a narrative Ghost article.
    • Best when you want a long‑lived, searchable reference.
  2. Option B:
    • Host the reveal.js deck as a static HTML file and embed it in a short Ghost article via <iframe>.
    • Best when you want the interactive slide experience.
  3. Option C:
    • Build a slide‑style KB article where each section mirrors a slide.
    • Best when you want the look/feel of slides but don’t want extra hosting.

In this case we went with Option A because it was the fastest path to “something everyone can read tomorrow,” knowing that Option B (publishing the entire static site) would be almost as easy once we’re ready to formalize that pipeline.

Why this matters

This workflow isn’t just about one deck:

  • It shows how Warp + agents + reveal.js can turn a messy system into a clear narrative in an hour.
  • It gives us a repeatable path for turning code + docs → shared understanding → KB content.
  • It scales: the same pattern works for other subsystems (CI pipelines, scoring models, data flows, etc.).

If you’d like to apply this to another area of the codebase, you can:

  • Start by writing down your audience and questions,
  • Open Warp on that repo and feed in the relevant vision docs,
  • And then follow the same loop: context → outline → deck → Q&A → article.

Read more

How do you setup identity or age verification so that only certain locations need to get verified?

Answer: Use Location-Based Identity Verification. This is enabled via the locationRestrictions.requiresVerification attribute in your application configuration to define which countries and regions require verification. Summary Token of Trust now supports location-based verification requirements through the locationRestrictions configuration. This feature allows you to specify which geographic locations (countries and regions)

By darrin