This is the hands-on companion to How I Use AI for Product Work and How My AI Product Second Brain Evolved. Those posts explain the philosophy; this one gets you to a working OpenCode setup in 30 minutes.

By the end, you’ll have a folder structure, three useful slash commands, and a context file that makes the AI actually useful.

Prerequisites

You’ll need OpenCode installed and configured. Follow the installation guide to get started. If you can run opencode in your terminal and get a response, you’re ready.

Step 1: Create the Folder Structure

Create a new directory for your product second brain. I recommend keeping it in a git repo so you can version your prompts over time.

mkdir -p product-ai/{context,prompts/pm,.opencode/command}
cd product-ai
git init

Your structure should look like this:

product-ai/
├── .opencode/
│   └── command/       # Slash commands live here
├── context/           # Personal context files
├── prompts/
│   └── pm/            # PM-specific prompts
├── AGENTS.md          # Instructions for OpenCode
└── opencode.jsonc     # OpenCode config

Step 2: Create Your Context File

The context file tells the AI who you are and how you work. Create context/about-me.md:

# About Me

## Role
[Your title] at [Company], working on [your area].

## What I Care About
- [Your product philosophy, e.g., "Start with the problem, not the solution"]
- [Your working style, e.g., "Bias toward shipping and learning"]
- [Your communication preferences, e.g., "Direct feedback, no hedging"]

## Current Focus
- [Project or initiative 1]
- [Project or initiative 2]

Keep this updated as your focus changes. The more specific you are, the more useful the AI becomes.

Step 3: Create AGENTS.md

This file tells OpenCode how to behave in your repo. Create AGENTS.md in the root:

# Product AI Second Brain

Read this file before responding.

## Who I Am
Read `context/about-me.md` for personal context.

## Slash Commands
Run these by typing the command in OpenCode:

| Command | Purpose |
|---------|---------|
| `/prd` | Review a PRD |
| `/debate` | Stress-test a product idea |
| `/okr` | Review OKRs |

Step 4: Add Your First Commands

Slash commands are markdown files in .opencode/command/. Each command file is a thin wrapper that points to a full prompt file in prompts/pm/. This separation keeps commands simple while allowing prompts to be detailed and shareable.

Command 1: /debate (Stress-test an Idea)

Create .opencode/command/debate.md:

---
description: Stress-test a product idea with pro vs skeptic debate
---

# Product Debate

Read these files before proceeding:
- `prompts/pm/debate-product-idea.md` - **REQUIRED: Full debate framework**
- `context/about-me.md` - Your product beliefs and context

## Your Task

$ARGUMENTS

## Instructions

Then create the prompt file prompts/pm/debate-product-idea.md with your full debate methodology. The basic structure: define two personas (a Visionary who argues for the idea and a Skeptic who pokes holes), have them debate, then synthesize the strongest arguments from both sides.

Command 2: /okr (Review OKRs)

Create .opencode/command/okr.md:

---
description: Review OKRs for clarity and outcome-orientation
---

# OKR Review

Read these files before proceeding:
- `prompts/pm/review-okrs.md` - **REQUIRED: Full OKR review framework**
- `context/about-me.md` - Your product beliefs and context

## Your Task

$ARGUMENTS

## Instructions

Then create prompts/pm/review-okrs.md with your OKR criteria. Mine checks for outcome-orientation (are these outputs or outcomes?), measurability, and whether the key results actually ladder up to the objective.

Command 3: /prd (Review a PRD)

Create .opencode/command/prd.md:

---
description: Review a PRD for completeness and clarity
---

# PRD Review

Read these files before proceeding:
- `prompts/pm/review-prd.md` - **REQUIRED: Full PRD review framework**
- `context/about-me.md` - Your product beliefs and context

## Your Task

$ARGUMENTS

## Instructions

Then create prompts/pm/review-prd.md with your PRD review criteria.

Step 5: Try It Out

Navigate to your product-ai directory and run OpenCode:

cd product-ai
opencode

Test each command:

/debate Should we build a self-serve dashboard for customers to debug their own issues?

/okr [paste your OKRs here]

What’s Next

Once you’re comfortable with this setup, consider adding:

• More commands: /retro for retrospectives, /feedback for drafting colleague feedback
• Skills: Methodology files that OpenCode loads automatically based on context (see the skills documentation)
• Daily summaries: A /today command that summarizes what you worked on
• Project-specific context: Folders for major initiatives with their own context files

The key is to start small and add complexity as you identify repeated workflows. If you find yourself doing the same thing more than twice, it’s probably worth automating.

If you build something useful on top of this, I’d love to hear about it!

A couple of weeks ago I wrote about how I use AI for product work: the basic setup of context files, prompts, and the @ mention system in Windsurf. Since then I’ve moved tools, added slash commands, and automated a few things, so here’s the update.

The philosophy has shifted. I still don’t use AI to do my core thinking. I write my own PRDs and strategy docs. But I’ve come to rely on it more as a helpful assistant for the work around the work: reviewing documents before I share them, researching technical questions, summarizing my week, preparing for meetings. These days I treat it as a capable colleague who’s always available.

From Windsurf to Claude Code / OpenCode

The biggest shift was moving from Windsurf to Claude Code, Anthropic’s terminal-based AI assistant. Claude Code runs in your terminal and has direct access to your filesystem, which changes how you can structure these workflows.

The key feature that made this worthwhile is slash commands. Instead of manually @-mentioning prompt files, I can type /ask-se and Claude Code automatically loads the right context, reads the relevant files, and knows how to respond. It’s a small thing, but removing that friction makes a real difference in how often I actually use these tools.

I also started using OpenCode, an open-source alternative that works similarly. Both tools read from the same instruction files, so I maintain one set of prompts that work in either environment.

Slash Commands

The prompts I described in the original post are now wrapped in slash commands. The files live in .claude/commands/ and look like this:

.claude/commands/
├── prd.md          # Review a PRD
├── okr.md          # Review OKRs
├── debate.md       # Stress-test a product idea
├── ask-se.md       # Research technical questions
├── briefing.md     # Calendar briefing
├── today.md        # End-of-day summary
├── weekly.md       # Weekly summary
└── ...

Each command file contains instructions for the AI, plus a $ARGUMENTS placeholder for any input I provide. When I run /debate should we build a developer portal?, Claude Code reads the debate prompt, substitutes my question for the placeholder, and runs through its process.

The commands I use most often:

• /prd. Reviews a PRD I’ve written and pushes back on vague problem statements, missing success metrics, or unclear scope. I run this before sharing drafts with stakeholders.
• /debate. Simulates a debate between an optimist and a skeptic about a product idea. This is probably the command I reach for most when I’m still forming an opinion about something.
• /ask-se. Helps me answer specific technical questions about our products. For example, today I ran /ask-se On Gateway HTTP Logpush jobs, what would trigger "unknown" as the action? The command uses MCP (Model Context Protocol) servers to search our public documentation and internal wiki, then synthesizes an answer I can actually use. It’s how I get product answers without interrupting engineers or digging through docs myself.

I don’t have to remember file paths or compose context any more. I type the command and start the conversation.

Skills: Persistent Methodology

Commands are things I invoke explicitly. Skills are methodology files that get applied automatically when they’re relevant.

I have three skills set up:

1. pm-thinking. Applies my product philosophy to any PM-related work. When I’m reviewing a PRD, it automatically checks for problem-first thinking, measurable outcomes, and clear non-goals.
2. cloudflare-context. Loads knowledge about Cloudflare’s products and triggers proactive use of internal data sources (more on this below).
3. data-team-context. Specific context about my team’s priorities, current initiatives, and constraints.

The skill files live in .claude/skills/ and contain triggers (when to apply) and behaviors (what to do). For example, the pm-thinking skill flags anti-patterns like “vague success metrics” or “jumping to solutions without understanding the problem.”

This means even when I’m not explicitly running a PM-focused command, the AI still knows to apply my methodology.

Daily and Weekly Summaries

One of the more useful additions: automated work journaling. At the end of the day, I run /today. The command:

1. Finds files I modified that day using filesystem timestamps
2. Reads the key files to understand what I actually worked on
3. Asks if there’s anything else to add
4. Generates a summary focused on outcomes, not tasks
5. Saves it to a structured folder: work/cloudflare/weeknotes/2025/01/week-01/2025-01-06.md

The output follows a consistent format:

# Tuesday, December 16, 2025

## Summary
Focused on Q1 planning and customer research. Clarified success
metrics for data quality initiative and documented common Logpush questions.

## What I Worked On
- **Q1 Planning:** Reviewed OKR drafts, identified gaps in success metrics
- **Customer Research:** Documented Logpush egress IP questions for support docs

Then on Friday (or Monday morning), I run /weekly. It reads all the daily notes for the week and synthesizes them into a summary I use to prep for 1:1s and status updates.

This works because I can never remember on Friday what I did on Tuesday. The daily notes capture the work while it’s fresh, and the weekly summary rolls it up into something useful.

Calendar Briefings

The most custom piece of this system is the calendar briefing. I got this idea from an interview with Webflow’s CPO on Claire Vo’s podcast, about building an AI chief of staff. Following her example I wrote a Python script that:

1. Connects to Google Calendar via OAuth
2. Fetches events for today, tomorrow, or the week
3. Generates a briefing that flags meetings that could be async, suggests prep work, and warns if the day is overloaded

I run /briefing tomorrow before wrapping up for the day. It gives me a head start on thinking about what’s coming and whether I need to prepare anything.

The briefing uses context from my about-me.md file, so it knows things like which recurring meetings are more important than others, and what kind of prep I typically need for different meeting types.

Syncing Between Tools

One wrinkle: Claude Code and OpenCode have slightly different formats for commands. Claude Code uses plain markdown; OpenCode expects frontmatter with a description field.

So I built a sync command. Running /sync-to-opencode compares the two folders and copies any changed commands, adding the frontmatter OpenCode needs. It means I can maintain one set of prompts (in .claude/commands/) and have them work in both tools.

Most people don’t need this. I switch between tools often enough that manual syncing got annoying.

What I’ve Learned Since the First Post

A few things that have become clearer:

• Automation compounds. The daily notes feed the weekly summary. The skills apply across every conversation. The slash commands cut enough friction that I actually use the system instead of just thinking about using it.
• Custom workflows are now a one-file affair. With slash commands and skills, I can create tools that work exactly how I want to work. The /ask-se command knows my products, our customers, and the kinds of questions I typically need answered. The daily summary knows my file structure and my preferred format. I get to encode my workflow into a tool instead of adapting to whatever the tool prefers.
• Scripts fill the gaps. The calendar briefing couldn’t be a pure prompt because it needed to fetch data from an external API. Having a scripts/ folder for Python code that extends the system has been useful for anything that requires real I/O.
• Keep work output local. The prompts and context files live in a private git repo so I can sync them between machines and version them over time. But the actual work output, like weeknotes, briefings, and anything I’m working on, stays on my local machine, not in the repo. The AI helps me do the work, but the work itself doesn’t need to live in the cloud.

If you’re building something similar, I’d recommend starting with the basics from the first post: context files, opinionated prompts, and a tool that lets you compose them easily. The slash commands and automation came later, once I understood what workflows I actually used repeatedly.

The specific tooling matters less than the approach. Figure out where AI actually helps (reviewing your work, researching questions, reducing busywork) and build the smallest system that makes those things easy to do.

Do you ever listen to a podcast episode and wish you could have a summary you could reference later? Not the whole transcript or someone else’s review, just a concise breakdown of the key points in a format you can scan quickly when you need to remember what was covered. Well, that’s why I spent the weekend building TL;DL (Too Long; Didn’t Listen). It generates AI summaries from podcast episodes.

Beyond that, there were a few other podcast use cases I kept running into:

• Catching up on episodes I missed. Sometimes a podcast gets 10 episodes ahead while life happens. A summary helps me decide which ones are worth going back to.
• Getting a feel for a new podcast. Before committing to a full episode, I want to know if a new show covers topics in a way that works for how I think and learn.
• Quick reference after listening. When I want to apply something from an episode—like a framework or technique—I don’t want to re-listen to an hour of audio to find the relevant 5 minutes.

So I built something for myself, and now I’m making it available to others.

How It Works

Registered users can submit an Apple Podcasts episode URL, choose a summary template, and the system does the rest. It transcribes the audio (using OpenAI Whisper), generates a summary (using GPT–5.2), and caches everything for a year.

The three templates are designed for different types of content:

• Key Takeaways & Practical Steps — This is the default, and it’s what I use most. The summary includes an overview, key insights, actionable steps, and notable quotes. Best for professional development and craft podcasts where you want to walk away with something to implement.
• Narrative Summary — For story-driven content and interviews. Instead of bullet points, this generates flowing prose that captures the arc of the conversation, including key moments and themes.
• ELI5 (Explain Like I’m 5) — For technical or complex topics. It breaks down dense material using everyday analogies and simple language.

The ELI5 Template Passed the Real Test

My wife is a therapist. She listens to highly technical psychology podcasts about things like Transference-Focused Psychotherapy and pathological narcissism. When I ran a recent episode she listed to through TL;DL, she was genuinely impressed by the “Key Takeaways” summary. It captured the clinical nuances accurately.

I, on the other hand, didn’t understand a word of it.

So I generated another summary using the “ELI5” template, and suddenly I could follow along. Concepts like devaluation got explained as “when a patient puts down the therapist, the therapy, or anything connected to it.” The technical frameworks became accessible. Here’s the episode page if you want to toggle between the two summaries yourself.

A Note about Podcast Creators and Attribution

Attribution matters to me. Every episode page prominently displays the podcast name, creator names, and both a “Listen on Apple Podcasts” link and a “Website” link to the official podcast website. My hope is that TL;DL helps expand a podcast’s audience by making the content more accessible. Summaries should bring people to a podcast, not replace the experience of listening—most podcasts have transcripts available already after all.

That said, if creators would rather not have their podcast processed, they can opt out and I’ll add their show to the blocklist.

The Technical Bits

For those interested in the stack: TL;DL runs entirely on Cloudflare’s edge platform. Cloudflare Workers handles the serverless compute, Workers KV stores the cached transcripts and summaries, and Cloudflare Queues manages the background job processing.

One interesting technical challenge was job status consistency. When you submit an episode, you want to see the status update in real-time as it progresses from “queued” to “transcribing” to “summarizing” to “completed.” Workers KV is eventually consistent, which meant status updates could lag by up to a minute. Users would refresh and still see “queued” even after the job was done.

I solved this with Durable Objects, Cloudflare’s strongly consistent coordination layer. The job status gets written to both the Durable Object (for immediate reads) and KV (for persistence and fallback). The UI now updates instantly.

Audio file handling for long episodes was another challenge. OpenAI Whisper has a 25MB file size limit. For podcasts that exceed this, I implemented MP3 frame-aware chunking—splitting the audio at frame boundaries so transcription can be stitched back together cleanly. The overlap handling ensures no words get lost between chunks.

What’s Next

Beyond solving my own problem, this was one of those projects where the building itself was the reward. The technical challenges were interesting, the product felt useful from day one, and I got to learn Durable Objects properly.

Submitting new episodes is currently invite-only while I iron out the rough edges. If you’re interested in access, reach out. For now, you can browse existing summaries to see how it works.