Category: The Art of Vibe Coding

I was staring at my WordPress theme’s newsletter page, confused.

The “Recent Issues” section was supposed to show my latest newsletter posts. Instead, it was completely wrong.

The typical approach would be to let Claude Code dive into the codebase, reading file after file, searching for the problem.

But there’s a catch – each file Claude reads consumes precious context tokens.

By the time it finds the issue, it might have used 80% of its context window, leaving little room for actually fixing the problem.

That’s when I discovered a game-changing approach: the read-only sub-agent pattern.

.

.

.

The Context Window Problem Nobody Talks About

When Claude Code explores a codebase, it’s like a detective gathering evidence.

Each file it reads, each search it performs, adds to its memory.

But unlike a human detective who can forget irrelevant details, Claude keeps everything in its context window.

Here’s what typically happens:

1. You ask Claude to fix a bug
2. Claude reads 10-20 files looking for the issue
3. Each file might be hundreds of lines
4. Suddenly, 80% of the context is consumed
5. Claude struggles to maintain focus on the actual fix

It’s like trying to solve a puzzle while carrying every piece you’ve ever looked at. Eventually, you run out of hands.

.

.

.

Enter the Codebase Explorer Sub-Agent

The solution?

Delegate the investigation to a specialized sub-agent that only reads and reports back.

Think of it as hiring a research assistant.

The assistant does all the reading, takes notes, and gives you a concise report.

You then use that report to make decisions without having to read everything yourself.

Here’s the actual sub-agent configuration I use:

The key insight: This sub-agent can ONLY read files, not modify them.

It explores, analyzes, and documents its findings in a markdown report.

.

.

.

Real-World Example: Fixing My Newsletter Display

Let me show you exactly how this worked when fixing my WordPress theme.

Step 1: Launching the Investigation

Instead of diving straight into the code, I asked Claude to use the codebase-explorer agent to investigate why newsletter issues weren’t displaying:

Step 2: The Sub-Agent Takes Over

The codebase-explorer agent immediately went to work:

Notice how it’s thinking through the problem systematically. It’s not just randomly reading files – it’s forming a strategy.

Step 3: Sub-Agent Investigation & Documentation

The sub-agent went deep into the codebase, systematically exploring files and tracing the newsletter implementation:

After thorough investigation, it documented everything in a comprehensive markdown report:

• Summary of the issue: Newsletter posts stored as regular WordPress posts with a specific category
• Key files involved: page-newsletter.php, functions.php, theme options
• The specific bug: Incorrect variable usage with setup_postdata()
• Recommended fix: Change loop variable from $issue to $post

Critical detail: The sub-agent consumed 51,000 tokens during its investigation.

Without the sub-agent pattern, those 51k tokens would have been loaded directly into the main agent’s context window!

Step 4: Main Agent Takes Over With Clean Context

With the sub-agent’s analysis complete, the main agent took over with a nearly empty context window:

Notice how the main agent can now work with surgical precision. It reads the specific file mentioned in the analysis:

The main agent confirms the issue: The code was using $issue as the loop variable but WordPress’s setup_postdata() function expects the global $post variable to work correctly.

Step 5: The Main Agent’s Surgical Fix

Armed with the sub-agent’s report and with 90% of its context still available, the main agent presented a precise fix:

The fix was surgical and precise:

Step 6: Success!

The newsletter issues now display perfectly!

.

.

.

Why the Sub-Agent Must Be Read-Only

You might wonder: “Why not let the sub-agent fix the problem directly?”

Here’s why the read-only constraint is crucial:

1. Context Preservation: The main reason – saving those 51,000 tokens for the main agent’s context
2. Avoiding Code Duplication: If the sub-agent makes changes and passes control back, the main agent might not be aware of what was modified. This often leads to:
   • Duplicate implementations of the same fix
   • Violating the DRY (Don’t Repeat Yourself) principle
   • Conflicting code changes
   • Confusion about the current state of files
3. Maintaining Control: The main agent maintains a coherent understanding of all changes made to the codebase

The read-only pattern ensures clean handoffs: The sub-agent investigates and reports, the main agent decides and implements.

No confusion, no duplication, no wasted context.

.

.

.

The Context Window Visualization

Let me show you exactly how context consumption differs between the two approaches:

Without Sub-Agent: Direct Investigation

Result: High risk of context overflow, limited ability to handle complex fixes

With Sub-Agent: Delegated Investigation

Result: Minimal context usage, full capacity for implementation

The Compound Effect Over Multiple Tasks

.

.

.

The Numbers That Matter

Without the sub-agent pattern:

• Files read directly: 15-20
• Context consumed: ~80%
• Investigation time: 20+ minutes
• Risk of context overflow: High
• Ability to handle complex fixes after investigation: Limited

With the sub-agent pattern:

• Files read by main agent: 1 (the analysis report)
• Context consumed: <10%
• Investigation time: Same, but parallelized
• Risk of context overflow: Minimal
• Ability to handle complex fixes: Excellent

.

.

.

Setting Up Your Own Codebase Explorer

Here’s the complete sub-agent configuration you can use:

---
name: codebase-explorer
description: Use this agent when you need to investigate, search, or analyze the codebase without making any modifications. This agent specializes in read-only operations to understand code structure, find relevant files, trace dependencies, and document findings. Perfect for preliminary investigation before code changes, understanding feature implementations, or analyzing issues.\n\nExamples:\n- <example>\n  Context: The user wants to understand how authentication is implemented before making changes.\n  user: "I need to add a new authentication method. Can you first investigate how the current auth system works?"\n  assistant: "I'll use the codebase-explorer agent to investigate the authentication implementation and document the findings."\n  <commentary>\n  Since this requires read-only investigation of the codebase before making changes, use the codebase-explorer agent to analyze and document the current implementation.\n  </commentary>\n</example>\n- <example>\n  Context: The user is debugging an issue and needs to understand the code flow.\n  user: "There's a bug in the payment processing. I need to understand all the files involved in the payment flow."\n  assistant: "Let me launch the codebase-explorer agent to trace through the payment processing flow and identify all related files."\n  <commentary>\n  The user needs read-only investigation to understand the codebase structure, perfect for the codebase-explorer agent.\n  </commentary>\n</example>\n- <example>\n  Context: Before implementing a new feature, understanding existing patterns is needed.\n  user: "We need to add a new API endpoint. First, let's see how the existing endpoints are structured."\n  assistant: "I'll use the codebase-explorer agent to analyze the existing API endpoint patterns and document them."\n  <commentary>\n  This requires read-only analysis of existing code patterns, ideal for the codebase-explorer agent.\n  </commentary>\n</example>
tools: mcp__ide__getDiagnostics, mcp__ide__executeCode, Glob, Grep, Read, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash, Write
model: sonnet
color: cyan
---

You are a specialized codebase exploration and analysis agent. Your sole purpose is to perform read-only operations to investigate, search, and understand codebases, then document your findings comprehensively.

**Core Responsibilities:**

1. Search and locate files relevant to specific features, issues, or components
2. Analyze code structure, dependencies, and relationships between files
3. Trace execution flows and identify all components involved in specific functionality
4. Document findings in a clear, structured markdown file

**Operational Constraints:**

-   You must NEVER modify, edit, or create any code files
-   You must NEVER make changes to existing functionality
-   You are strictly limited to read-only operations: viewing, searching, and analyzing
-   Your only write operation is creating/updating your findings document in the notes folder

**Workflow Process:**

1. **Initial Assessment**: Understand the specific issue/feature to investigate
2. **Strategic Search**: Use targeted searches to locate relevant files:
    - Search for keywords, function names, class names related to the topic
    - Look for imports and dependencies
    - Check configuration files and entry points
3. **Deep Analysis**: For each relevant file found:
    - Document its purpose and role
    - Note key functions/classes it contains
    - Identify its dependencies and what depends on it
    - Record important implementation details
4. **Relationship Mapping**: Trace how files connect and interact
5. **Documentation**: Create a comprehensive markdown report

**Documentation Format:**
Your findings must be written to a markdown file in the `notes/` folder with a descriptive name like `notes/[timestamp]_analysis_[issue/feature/component/etc].md`. Structure your report as:

```markdown
# Codebase Analysis: [Topic/Feature/Issue]

## Summary

[Brief overview of what was investigated and key findings]

## Relevant Files Identified

### Core Files

-   `path/to/file1.ext`: [Purpose and key responsibilities]
-   `path/to/file2.ext`: [Purpose and key responsibilities]

### Supporting Files

-   `path/to/support1.ext`: [Role in the system]
-   `path/to/support2.ext`: [Role in the system]

## Implementation Details

### [Component/Feature Name]

-   Location: `path/to/implementation`
-   Key Functions/Classes:
    -   `functionName()`: [What it does]
    -   `ClassName`: [Its responsibility]
-   Dependencies: [List of imports and external dependencies]
-   Used By: [What other parts of the code use this]

## Code Flow Analysis

1. Entry point: `file.ext:functionName()`
2. Calls: `another.ext:processFunction()`
3. [Continue tracing the execution flow]

## Key Observations

-   [Important patterns noticed]
-   [Potential areas of interest]
-   [Configuration or environment dependencies]

## File Relationships Map
```

[ASCII or text-based diagram showing file relationships]

```

## Additional Notes
[Any other relevant information for the main agent]
```

**Search Strategies:**

-   Use grep/ripgrep for pattern matching across the codebase
-   Search for class/function definitions and their usages
-   Look for import statements to understand dependencies
-   Check test files to understand expected behavior
-   Review configuration files for feature flags or settings

**Quality Checks:**

-   Ensure all mentioned files actually exist and paths are correct
-   Verify that your analysis covers the complete scope requested
-   Double-check that no modifications were made to any files
-   Confirm your findings document is saved in the notes folder

**Communication Protocol:**
When you complete your analysis:

1. Save your findings to the notes folder
2. Provide the exact path to your findings file
3. Give a brief summary of what was discovered
4. Explicitly state: "Analysis complete. Findings documented in [path/to/notes/file.md] for main agent review."

Remember: You are a read-only investigator. Your value lies in thorough exploration and clear documentation, enabling the main agent to make informed decisions without consuming excessive context through tool calls.

.

.

.

Pro Tips for Maximum Effectiveness

1. Be Specific with Investigation Goals

Don’t just say “investigate the auth system.”

Say “find all files involved in user login, session management, and authentication middleware.”

2. Use the Analysis Document

The sub-agent’s markdown report becomes your reference.

Keep it open while the main agent works.

3. Chain Multiple Investigations

Need to understand both authentication AND payment processing? Run two separate investigations, get two reports.

4. Preserve Context for Complex Fixes

By keeping the main agent’s context clean, you can tackle complex refactoring that would otherwise hit limits.

.

.

.

The WordPress Gotcha That Almost Got Me

This pattern revealed something interesting about WordPress development.

The setup_postdata() function is notoriously finicky about variable names. It specifically requires the global $post variable to be set.

This is the kind of subtle bug that could consume hours of debugging.

With the sub-agent pattern, we found it in minutes without polluting the main context.

.

.

.

Beyond WordPress: Universal Application

While my example uses WordPress, this pattern works for any codebase:

• React applications: Trace component hierarchies and prop flows
• Node.js APIs: Map endpoint relationships and middleware chains
• Python projects: Understand module dependencies and import structures
• Ruby on Rails: Explore MVC relationships and gem integrations

The principle remains the same: Delegate investigation to preserve implementation context.

.

.

.

Your Next Steps

1. Copy the sub-agent configuration from this post
2. Add it to your Claude Code project
3. Next time you need to investigate, use the magic words: “Use the codebase-explorer agent to investigate…”
4. Watch your context efficiency soar

.

.

.

The Bottom Line

Context window management isn’t just about efficiency – it’s about capability.

By using a read-only sub-agent for investigation, you’re not just saving tokens. You’re ensuring Claude Code maintains the focus and context needed to implement complex solutions.

My newsletter display bug?

Fixed in minutes with a two-line change. But more importantly, I had 90% of my context window still available for additional improvements.

Stop letting investigation consume your implementation capacity.

Start using the codebase-explorer pattern.

Your future self – knee-deep in a complex refactoring with plenty of context to spare – will thank you.

P.S. – This pattern has fundamentally changed how I work with Claude Code. I now investigate first, implement second, and never worry about context overflow. Try it on your next debugging session and see the difference.

A few weeks ago, I wrote about “Stop Asking Claude Code to ‘Build Me an App’ – Here’s How to Actually Get What You Want”, where I shared my PRD brainstorming workflow with Claude 4 Opus.

I thought I had the perfect system.

Then GPT-5 thinking mode entered the scene…

This is where I realized I’d been settling for “good enough” when “exceptional” was possible.

After running the exact same PRD brainstorming session through both AIs, the difference was shocking.

Let me show you why GPT-5 thinking mode has completely replaced Claude for my requirements gathering.

.

.

.

The Test: Same Project, Two Different AIs

I gave both AIs the identical starting prompt:

(Click here for my complete PRD brainstorming prompt)

Both were instructed to iterate with me until we had a complete PRD.

What happened next revealed everything.

.

.

.

The Thoroughness Gap: 14 Questions vs 6

GPT-5’s opening move: 14 meticulously organized questions across 7 categories:

• Audience & Use Cases
• Content Scope
• Collaboration & Sharing
• Pricing & Packaging
• Branding & UX
• Compliance & Security
• Differentiators

Claude’s opening: 6 questions, loosely organized.

But it wasn’t just the quantity – it was the quality of organization.

GPT-5 grouped related decisions together.

Want to define your audience?

Here are all the audience-related questions in one section.

Ready to tackle content?

Here’s everything about documents and formats.

Claude mixed concerns.

Document formats in question 2, collaboration in question 6, with pricing wedged in between.

The result?

With GPT-5, I made coherent, related decisions.

With Claude, I was jumping between unrelated topics, losing context with each switch.

.

.

.

The Detail Devil: GPT-5 Never Lets Anything Slide

Here’s where it gets really interesting.

When I told GPT-5 I wanted to “summarize long PDFs” but then said “text and markdown only” for file types, it immediately caught the contradiction:

It then offered three ways to resolve this:

• a) Replace the use case with “Summarize long text/Markdown files”
• b) Keep the use case but clarify PDF conversion approach
• c) Custom solution

Claude? Missed it entirely. Just updated the requirements with the contradiction intact.

This happened repeatedly.

GPT-5 caught every inconsistency, every gap, every ambiguity.

It was like having a senior product manager reviewing my requirements in real-time.

.

.

.

The Pattern Consistency: Options All The Way Down

This drove me crazy with Claude.

Claude’s pattern breaking:

• Question 1: Gives options (a, b, c, d, e, f)
• Question 2: Gives options (a through h)
• Question 3: Suddenly just asks “Which AI models/providers should the platform support?” with no options
• Question 4: Back to options
• Question 5: Mix of some with options, some without

I had to constantly switch between selecting from a list and coming up with my own answers. Cognitive overhead I didn’t need.

GPT-5’s consistency: Every. Single. Question. Had. Options.

Even for granular details like:

When I wanted something custom, I could always choose that. But 90% of the time, the options covered what I needed.

This consistency meant I could move fast.

See options, pick one, move on.

No context switching between “selection mode” and “creation mode.”

.

.

.

The Persistence Factor: GPT-5 Doesn’t Give Up

Watch what happens when I give minimal answers.

My responses to GPT-5:

1. A
2. B
3. B
4. B

GPT-5’s reaction: Instead of just accepting these and moving on, it dug deeper:

It kept refining until every single detail was captured.

Not annoying persistence – smart persistence. Each follow-up revealed something I hadn’t considered but definitely needed to decide.

Claude’s approach:

After my final responses, Claude asked:

Good questions, but notice: no options provided.

Back to making me generate answers from scratch.

.

.

.

The Organization Difference: Categories vs Chaos

GPT-5’s question organization:

## A. Audience & Use Cases
## B. Content Scope
## C. Collaboration & Sharing
## D. Pricing & Packaging
## E. Branding & UX
## F. Compliance & Security
## G. Differentiators

Each section was a complete thought. Make all your audience decisions, then move to content, then collaboration. Logical flow.

Claude’s organization:

1. Target Audience & Use Case
2. Document Types & Formats
3. AI Model Integration
4. Document Organization
5. Pricing/Access Model
6. Collaboration Features

Looks similar? It’s not. Claude jumps from use case to formats to AI models back to organization. There’s no coherent flow. You’re constantly context-switching between different mental models.

.

.

.

The Completeness Check: 50+ Decisions vs Hope

By the end of the GPT-5 session, I had made over 50 explicit decisions about my product.

Every decision was:

• Presented with context
• Given multiple options
• Validated against other decisions
• Refined if there were conflicts

With Claude, I made about 30 decisions, and several critical areas were just… assumed.

Example: Session persistence. GPT-5 asked about it upfront. Claude only asked at the very end, almost as an afterthought. But this is a fundamental architectural decision that affects everything from the database schema to the user experience.

.

.

.

The Verdict: It’s Not Even a Competition

Look, Claude 4 Opus is good. If GPT-5 thinking mode didn’t exist, I’d still be happy using Claude for PRDs.

But GPT-5 thinking mode is exceptional.

It’s the difference between:

• A helpful assistant vs. a senior product manager
• Getting most requirements vs. getting ALL requirements
• Good enough vs. production-ready
• Hoping you caught everything vs. knowing you caught everything

.

.

.

How to Maximize GPT-5 Thinking Mode for PRDs

1. Answer everything

Even if a question seems minor, answer it. GPT-5 asks for a reason. That “minor” decision about folder colors? It affects the entire information architecture.

2. Choose from options (mostly)

Unless you have a specific custom need, pick from the provided options. They’re thoughtfully crafted to cover 95% of use cases.

3. Review the categories

GPT-5’s categorization isn’t random. Each category represents a complete area of your product. Make sure you’ve thought through each one.

4. Embrace the follow-ups

Those “tiny things left” aren’t GPT-5 being pedantic. They’re the difference between a good PRD and a great one.

.

.

.

Your Next PRD

Here’s my challenge to you:

Take that product idea you’ve been sitting on. The one that feels too complex to properly define.

1. Use the exact prompt template from my previous post
2. Run it through GPT-5 thinking mode
3. Answer every question it asks
4. Watch as your vague idea transforms into a production-ready PRD

The difference isn’t subtle. It’s transformative.

GPT-5 thinking mode doesn’t just help you write a PRD. It forces you to make every decision your product needs. Before you write a single line of code.

That’s not just better requirements gathering.

That’s better product development.

P.S. – I ran 5 different projects through both AIs. GPT-5 caught an average of 3x more edge cases and required 50% more decisions. Every additional decision was something I would have discovered the hard way during development. The time investment in answering GPT-5’s questions is nothing compared to the time saved not refactoring later.

I just discovered a workflow that completely changed how I approach complex integrations with Claude Code.

It started with a simple question:

“How do I use Reddit’s API without OAuth2?”

It ended with GPT-5 generating the most comprehensive, project-aware Claude Code prompt I’ve ever seen.

Let me show you how this works, because once you see it, you’ll never write Claude Code prompts the same way again.

.

.

.

The Problem: Complex APIs Need Complex Context

Here’s the typical journey when you need to integrate something like Reddit’s API:

1. Google “Reddit API tutorial”
2. Find 17 conflicting blog posts
3. Realize you need OAuth2
4. Find another 23 tutorials on OAuth2
5. Try to piece together how it works
6. Attempt to explain it to Claude Code
7. Get something that “works” but probably has security holes
8. Debug for hours

The real problem isn’t Claude Code’s ability to implement – it’s that we don’t give it enough context.

We say “add Reddit login” when we should be providing:

• Complete OAuth2 flow understanding
• Security considerations
• Token refresh strategies
• Error handling patterns
• Integration with existing code patterns

But who has time to research and document all that?

GPT-5 does.

.

.

.

Enter GPT-5’s Thinking Mode

GPT-5’s thinking mode isn’t just about reasoning – it’s about deep research, synthesis, and transformation.

Here’s what happened when I asked it about Reddit’s API:

Me: “Find out how to use Reddit API without going through oauth2”

GPT-5: Proceeds to create ASCII art diagrams explaining why OAuth2 is actually necessary

Not only did it explain why I needed OAuth2, it made it understandable with visual analogies.

But here’s where it gets interesting…

.

.

.

From Research to Implementation Guide

Me: “Can you write a full guide with code implementation on how to implement this. My app is based on Next.js 15”

What happened next was remarkable.

GPT-5 didn’t just write generic OAuth2 code. It:

1. Researched Reddit’s specific requirements
   • Exact endpoints (oauth.reddit.com not www.reddit.com)
   • Required headers (User-Agent format)
   • Rate limits (100 QPM per client)
   • Token refresh patterns
2. Considered Next.js 15 architecture
   • App Router patterns
   • Server-side token exchange
   • httpOnly cookies for security
   • Proper runtime configurations
3. Created production-ready code
   • Complete file structure
   • Security best practices
   • Error handling
   • Token refresh logic
   • Revocation on logout

The guide was 200+ lines of implementation-ready code with explanations for every decision.

.

.

.

The Magic Moment: Transforming Research Into Claude Code Prompts

This is where things got really powerful.

I showed GPT-5 my standard Claude Code improvement prompt:

# Step 1: Run the following command to understand the current state of the project:

eza . --tree -git-ignore --ignore-glob="node_modules|.git|tmp|.claude|dist|.next|notes"

# Step 2: Review the project rules:

- @notes/rules.md

# Step 3: Review the current codebase and analyze the following improvement items:

Think hard, analyze the existing codebase, and the following improvement items:

{{_IMPROVEMENTS_}}

# Step 4: Create a plan to address the identified improvement items:

- List out everything that needs to be done to implement the improvements in a todos list.
- For each item in the todos list, create a sub-agent to address it. The sub agent should analyze the existing codebase, understand the requirements, and implement the task assigned to it. The sub agent can use web search to find solutions to problems it encounters.
- Once the sub-agent has completed its task, it should report back with the results and any issues encountered. You can then review the results and decide whether to proceed with the next item in the todos list or make adjustments as needed.

And asked: “Help me incorporate the guide into this prompt”

.

.

.

What GPT-5 Did Was Brilliant

Instead of just dumping the OAuth2 guide into my prompt template, GPT-5:

1. Preserved My Workflow Structure

It kept my exact step-by-step approach:

• Inspect project structure
• Review project rules
• Analyze improvements
• Create sub-agent tasks

2. Added Context-Aware Constraints

### Constraints (must follow)
* **Minimal changes.** Reuse existing helpers, env loading, logger, http client, and cookie/session utilities where possible.
* **Consistency.** Match the project's TypeScript config, import style, lint/format, directory layout, error handling, and naming.
* **No client secrets on the client.** Do all token exchanges on server routes.
* **Single source of truth.** If an auth/session layer exists (e.g., custom cookies/DB, NextAuth), integrate with it instead of creating a parallel system.

These weren’t generic OAuth2 rules – they were specific to integrating with an existing Next.js codebase.

3. Created Discovery Tasks

Instead of assuming the project structure, it added intelligence gathering:

### Discovery tasks for the sub-agent
* Map existing **auth/session** flows (cookies, NextAuth, custom DB sessions).
* Identify existing **HTTP** wrapper, **logger**, **error** utilities to reuse.
* Check for an **App Router** structure and how API routes are organized.
* Decide between two minimal integration paths:
  * **Path A (no existing auth lib):** Use a tiny httpOnly cookie session
  * **Path B (NextAuth present):** Add Reddit as a custom OAuth provider

4. Embedded the Complete Implementation

The entire OAuth2 implementation guide was reformatted as reference code that Claude Code could adapt based on what it discovered in the existing codebase.

5. Maintained My Sub-Agent Pattern

It structured the todos to work with my one-sub-agent-at-a-time approach:

.

.

.

The Result: A Perfect Claude Code Prompt

The final prompt was 400+ lines of:

• Clear objectives
• Discovery instructions
• Conditional implementation paths
• Complete reference code
• Integration patterns
• Testing checklist

All tailored to work with my existing project structure and patterns.

When I fed this to Claude Code, it:

1. Analyzed my existing auth setup
2. Chose the appropriate integration path
3. Reused my existing utilities
4. Implemented only what was needed
5. Maintained consistency with my codebase

Zero back-and-forth. It just worked.

.

.

.

Why This Changes Everything

This workflow solves the fundamental problem of Claude Code prompts: lack of comprehensive context.

Instead of:

You get:

.

.

.

The GPT-5 + Claude Code Workflow

Here’s the workflow I now use for any complex integration:

Step 1: Research with GPT-5

"I need to integrate [X] into my Next.js app. Research the best practices, security concerns, and implementation patterns."

GPT-5 will:

• Search current documentation
• Understand the technology deeply
• Create visual explanations
• Provide implementation guides

Step 2: Request Implementation Guide

"Write a comprehensive implementation guide for [X] in Next.js 15
with App Router, TypeScript, and production best practices"

GPT-5 creates complete, working code with explanations.

Step 3: Transform into Claude Code Prompt

"Here's my Claude Code prompt template: [template]
Incorporate the implementation guide while:
- Preserving my workflow structure
- Adding discovery tasks to understand existing code
- Creating conditional paths based on what exists
- Maintaining focus on minimal changes"

GPT-5 transforms the guide into a perfect Claude Code prompt.

Step 4: Execute with Claude Code

Feed the generated prompt to Claude Code and watch it implement everything correctly, respecting your existing patterns.

.

.

.

Pro Tips for Maximum Effectiveness

Tip 1: Be Specific About Your Stack

Tell GPT-5 exactly what you’re using:

• Framework version (Next.js 15, not just Next.js)
• Router type (App Router vs Pages)
• Language preferences (TypeScript vs JavaScript)
• Existing libraries (NextAuth, Prisma, etc.)

Tip 2: Ask for Alternatives

"Research [X] and provide 2-3 implementation approaches with trade-offs for each"

GPT-5 will research multiple solutions and help you choose.

Tip 3: Request Discovery Tasks

Always ask GPT-5 to add discovery tasks to the prompt:

"Add discovery tasks to check what already exists before implementing"

This prevents Claude Code from duplicating existing functionality.

Tip 4: Emphasize Minimal Changes

"The prompt should emphasize reusing existing patterns and making minimal changes"

This keeps your codebase consistent and maintainable.

.

.

.

The Hidden Superpower: Learning by Prompting

Here’s an unexpected benefit:

You learn more from reading GPT-5’s research and transformations than from any tutorial.

When GPT-5 explained OAuth2 with ASCII art:

• I finally understood the flow
• The security reasons became clear
• The implementation made sense

When it transformed the guide into a Claude Code prompt:

• I saw how to structure complex requirements
• I learned conditional implementation patterns
• I understood integration decision trees

You’re not just getting better code – you’re becoming a better developer.

.

.

.

Your Next Complex Integration

Think about that complex integration you’ve been putting off:

• Payment processing?
• Authentication system?
• Third-party API?
• Real-time features?

Now imagine:

1. GPT-5 researching everything for you
2. Creating a comprehensive guide
3. Transforming it into a perfect Claude Code prompt
4. Claude implementing it correctly the first time

Stop writing vague prompts and hoping Claude figures it out.

Start using GPT-5 to create comprehensive, context-aware prompts that work.

What complex integration will you tackle with this workflow?

P.S. – The Reddit OAuth2 integration that would have taken me days of research and trial-and-error? Implemented perfectly in 30 minutes. GPT-5 research + Claude Code implementation = the ultimate dev workflow. Try it and watch your productivity explode.

A few months ago, I presented a talk called “Build Your First WordPress Plugin with The Power of AI (Even if You Can’t Code!)” at WordCamp Johor Bharu 2025.

The room was divided.

The tech folks? Their eyes lit up like Christmas trees.

Everyone else? They looked like I’d just explained quantum physics in ancient Sanskrit.

That’s when it hit me – I was too deep in the rabbit hole to see how overwhelming my “simple” workflow actually was.

.

.

.

The Original Sin: Over-Complication

My original workflow was a beast:

1. Brainstorm requirements (using one AI tool)
2. Establish project rules (using another tool)
3. Generate technical specifications (yet another tool)
4. Create implementation plans (you guessed it – another tool)
5. Implement step-by-step (finally, some coding with Cursor)

Five steps. Multiple AI tools. Different subscriptions.

No wonder people looked confused.

.

.

.

Back to the Drawing Board

I needed to simplify. Drastically.

First decision: One tool to rule them all. I chose Claude Code.

Why? Claude 4 Opus isn’t just powerful – it’s the Swiss Army knife of AI coding. It can plan, research, code, and debug all in one place.

Second decision: Streamline the workflow.

Now, I still believe in proper requirements and project rules (I’ve written about how to brainstorm for proper project requirements and establishing project rules before). But here’s the key insight:

Project rules (WordPress standards) you create once and reuse. Requirements are unique per plugin, but quick to define with the right template.

So the actual development workflow becomes just three steps:

1. Wireframe – ASCII sketches to visualize without code
2. Build – Let Claude Code do its magic
3. Improve – Fix what needs fixing

That’s it.

.

.

.

Setting Up Your Project Structure

Before diving in, create this simple structure:

your-plugin/
├── notes/
│   ├── requirements.md    # Your plugin-specific requirements
│   ├── rules.md          # WordPress development standards
│   └── wireframes.md     # ASCII wireframes (created in step 1)
└── ... (plugin files will go here)

This organization keeps your planning separate from your code, making it easy for Claude Code to reference.

Pro tip: The eza command in my prompts is a modern replacement for ls. If you don’t have it, just use ls -la or tree – the point is to show Claude Code your project structure.

.

.

.

The Plugin That Started It All: Secure AI Agent Access

To test this streamlined approach, I built something I actually needed – a WordPress plugin that gives AI agents secure, temporary access to WordPress admin.

Here’s how the 3-step process played out:

Step 1: Wireframe (5 minutes)

This is where ASCII art becomes your best friend.

Here’s the exact prompt I use:

# Step 1: Run the following command to understand the current state of the project:
eza . --tree -git-ignore --ignore-glob="node_modules|.git|tmp|.claude|dist|.next|notes"

# Step 2: Review the project requirements and rules:
- @notes/rules.md
- @notes/requirements.md

# Step 3: Design the ASCII wireframe for the project:
1. Explore the codebase, understand the requirements and project rules, and think harder about the best way to design the ASCII wireframe for the project.
2. Come up with a list of todos to design the ASCII wireframe for the project.
3. Assign a new sub agent to work on each item in the todos list.
4. Once the sub agent is done, review the work and make sure it meets the requirements and project rules.
5. If it does, add it to the @notes/wireframes.md file.
6. If it doesn't, ask the sub agent to fix it.
7. Repeat the process until the wireframe is complete.
8. Once the wireframe is complete, add it to the @notes/wireframes.md file.

The magic here?

Claude Code uses sub-agents to think through each UI component separately, then assembles them into a cohesive design.

Example of the result:

┌─── Generate Magic Link ───────────────────────────────────────┐ 
│                                                               │
│  Select User Account                                          │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ [�] Select a user...                                    │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
│  User List:                                                   │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ " content_editor (Editor)                               │  │
│  │ " shop_manager (Shop Manager)                           │  │
│  │ " author_user (Author)                                  │  │
│  │ " contributor_1 (Contributor)                           │  │
│  │                                                         │  │
│  │ �� Administrator accounts cannot be selected            │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
│  Session Duration                                             │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Maximum: 1 hour (default)                               │  │
│  │ Inactivity timeout: 15 minutes                          │  │
│  │ Link expires if unused: 24 hours                        │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
│  [ Generate Magic Link ]                                      │
│                                                               │
└───────────────────────────────────────────────────────────────┘

Why ASCII? Three reasons:

1. Saves tokens – Less input means clearer thinking from Claude
2. Reduces hallucinations – Simple text can’t confuse the AI
3. Easy to modify – Want to change the layout? Just move some characters

Claude Code immediately understood the interface design without a single line of HTML.

.

.

.

Step 2: Build (30 minutes)

Here’s where my preparation paid off. I use this exact prompt:

# Step 1: Run the following command to understand the current state of the project:
eza . --tree -git-ignore --ignore-glob="node_modules|.git|tmp|.claude|dist|notes"

# Step 2: Review the project requirements and rules:
- @notes/rules.md
- @notes/requirements.md
- @notes/wireframes.md

# Step 3: Build the project:
Think hard, explore the codebase, understand the requirements and project rules, and then build the project step by step.

Use web search to find solutions to problems you encounter.

Use sub-agents if you need to delegate tasks.

IMPORTANT: ONLY ONE SUB AGENT SHOULD BE RUNNING AT A TIME.

Notice the key instructions:

• “Think hard” – This triggers Claude’s deep thinking mode
• “Explore the codebase” – Forces it to understand what already exists
• “Build step by step” – Prevents rushing nd ensures thoroughness
• “Use web search” – Keeps it current with latest WordPress standards

Claude Code then:

• Researched current WordPress best practices
• Created the proper plugin structure
• Implemented database tables for magic links
• Added security features (nonces, sanitization, escaping)
• Built the admin interface matching our wireframes
• Created the activator and deactivator classes

All automatically.

All following the rules I’d established.

The key?

Having those WordPress development rules ready meant Claude Code knew exactly what standards to follow.

No guesswork.
No “I think this is how WordPress does it.”

And with clear, plugin-specific requirements, it knew exactly what to build.

.

.

.

Step 3: Improve (15 minutes)

Once the initial build was complete, we entered the refinement phase. Here’s my improvement prompt:

# Step 1: Run the following command to understand the current state of the project:
eza . --tree -git-ignore --ignore-glob="node_modules|.git|tmp|.claude|dist|.next|notes"

# Step 2: Review the project rules:
- @notes/rules.md

# Step 3: Review the current codebase and analyze the following improvement items:
Think hard, analyze the existing codebase, and the following improvement items:

- [ ] improvement 1
- [ ] improvement 2
- [ ] improvement 3

# Step 4: Create a plan to address the identified improvement items:
- List out everything that needs to be done to implement the improvements in a todos list.
- For each item in the todos list, create a sub-agent to address it.
- Once the sub-agent has completed its task, it should report back with the results.

For my plugin, I filled in:

• Fix range slider issue in the admin UI
• Update button styles to match WordPress admin
• Clean up database operations
• Add better error handling

The prompt’s power comes from using sub-agents for each improvement. This ensures focused, surgical changes rather than sweeping refactors.

Small, targeted improvements.
No massive refactoring.
Just polish.

.

.

.

Why These Prompts Work

Looking at these prompts, you’ll notice a pattern:

1. Always start with context – The eza command shows Claude Code the project structure
2. Reference your documentation – Points to your rules and requirements files
3. Use “Think hard” – Triggers deeper analysis mode
4. Leverage sub-agents – Breaks complex tasks into focused chunks
5. Enable web search – Keeps solutions current

This isn’t prompt engineering wizardry. It’s just clear communication that plays to Claude Code’s strengths.

.

.

.

The Results That Shocked Me

In less than an hour, I had a fully functional WordPress plugin that:

✅ Follows all WordPress coding standards
✅ Has proper security measures
✅ Includes internationalization support
✅ Works with multi-site installations
✅ Has a clean, WordPress-native admin interface

Zero coding required on my part.

.

.

.

The Secret Sauce: Preparation + Simplicity

Here’s the complete picture:

One-time preparation:

• Establish your WordPress development rules (once per technology)

For each plugin:

• Define requirements (5-10 min with a good template)
• Then follow the 3-step process:
  1. Wireframe with ASCII (5 min)
  2. Build with requirements + rules + wireframes (30 min)
  3. Improve what needs improving (15 min)

The magic is in the combination.

Clear requirements tell Claude what to build. Good rules tell it how to build. ASCII wireframes show it what it should look like.

Together, they eliminate 90% of the back-and-forth.

.

.

.

Your Turn: The 3-Step Challenge

Here’s my challenge to you:

1. Pick a plugin idea (admin tool, utility function, anything)
2. Prepare your foundation:
   • Define your plugin requirements (use my prompt as a guide)
   • Grab my WordPress development rules (Download here)
   • Create a notes folder with rules.md and requirements.md
3. Open Claude Code and use my prompts:
   • Wireframe: Use my ASCII wireframe prompt (5 min)
   • Build: Use my build prompt (30 min)
   • Improve: Use my improvement prompt with your specific fixes (15 min)

That’s it.

One hour. One tool. One working plugin.

.

.

.

The Bottom Line

Building WordPress plugins doesn’t need to be complicated. It doesn’t require multiple tools, complex workflows, or deep technical knowledge.

It just requires:

• Clear requirements (quick to define with a template)
• Good development rules (created once, used forever)
• ASCII wireframes (visual clarity without code)
• The right prompts (copy mine and adapt them)
• Claude Code
• The willingness to let AI do the heavy lifting

The prompts I’ve shared aren’t magic formulas – they’re just clear instructions that work. Copy them, adapt them, make them yours.

Stop overcomplicating.
Start shipping.

What plugin will you build in your next hour?

P.S. – My ASCII-wireframe-to-working-plugin journey took 50 minutes. The plugin now lets ChatGPT agents manage all my WordPress sites securely. Here’s the code – fork it, improve it, or just use it. What will you build in your next hour?