Welcome to Part III of this series in which I will focus on the Strategize phase of rapid application prototyping. If you haven’t already, you can
- Read Part I here: Prototyping using Gemini & Claude – Part I
- Read Part II here: Prototyping using Gemini & Claude – Part II
Step 2: Strategize
The Strategize phase focuses on developing the master prompt for Claude and Gemini, our chosen assistants. Within this initial prompt, you must ensure the product brief created in the Visualize phase remains available to the assistants as a constant reference. Creating the master prompt is just the beginning. After providing it and initiating the build, you’ll engage in extensive conversations with each coding assistant – often switching between them – to achieve your precise objectives.
Remember that unlike traditional UX design, AI-driven rapid prototyping generates actual code, not just mockups. Despite thorough preparation and reference materials, AI will make mistakes. These errors manifest as code defects that can seriously impact your prototype’s functionality. Learning to anticipate these issues and developing quick response strategies is crucial for saving time and reducing frustration. I learned these vital lessons through difficult experience.
You should also prepare for Context Dilution. As conversations with coding assistants lengthen, you will hit the context window limits of your chosen LLM. The assistants will begin losing track of earlier exchanges, often suggesting previously attempted changes that you know are ineffective. This becomes extremely frustrating, making it essential to develop strategies to anticipate and mitigate Context Dilution.
Finally, once your functional prototype is ready, you’ll make numerous visual adjustments to align the app with your vision. Each change risks breaking something. Having a reliable recovery mechanism is therefore essential.
Anecdote: One of application prototypes was coming around perfectly until I decided to add some minor finishing touches like SEO optimization and code cleanup. The Claude Code agent confirmed it had completed all tasks, but when I tested the application one final time, I discovered the landing page was completely broken. All my meticulous changes had vanished. The interface looked like the V1 that Claude had created after my initial prompt, and navigation between pages no longer worked. With growing dread, I checked the other pages and found everything was broken throughout the application. I asked Claude Code to revert to the previous working version, but despite confirming it had done so, nothing changed. I spent a frantic 3 hours (not counting the 5-hour break when Anthropic locked me out for exceeding my plan’s rate limits) trying to identify all the issues and get Claude to fix them. Nothing worked. As a last resort, I asked Claude to reference my original PRD and rebuild the application to that specification. This reverted my application to its most basic version, but at least the core functionality worked again.
Documentation & Memory Management Strategy
To avoid disasters like these, it is important to have a documentation & memory management strategy. For every application prototype that I work on, I make a point to ponder on and answer these questions within my master prompt. These directions enable me to ensure that a.) I am always in a position to recover from a disaster, and b.) my coding assistants do not lose context.
Stage 1: Answering the basics
- What does my versioning strategy look like?
- Is this application complex enough to create a git repository and check code in frequently?
- Is the application complex enough for me to maintain dev and main branches, followed by periodic merging?
- Is the application simple enough to maintain a changelog file to document every change, so that exact code revisions are preserved and roll backs continue to be viable options?
- Do I need forking? I typically consider this as an option if I plan to prepare multiple iterations for A/B testing. Forking allows for creating multiple offshoots of the same basic applications, but for this to work you also need to check code in to GitHub or another source control hub.
- What is my check-in frequency?
- What is my code refactoring strategy and frequency?
- What is my deployment strategy?
Stage 2: Managing visual changes & assistants
- How do I manage visual changes? As you start visually polishing the application, you will need to make a number of small and big changes to the UI and the UX, and you absolutely need to retain the ability to go back and revert changes if they don’t work.
- How do I manage context switching between AI assistants & context dilution?
After answering these questions, you’ll have a clear vision for your master prompt. A significant portion of this prompt establishes the foundation for your project through a documentation strategy, giving the model a reference path to stay aligned with your goals. Consider your documentation strategy as providing the AI with three distinct memory layers:
- Long Term Memory (Project Specification Document) – This document, generated by your master prompt, contains the unchanging complete blueprint. Claude Code explicitly requires this document, and while Gemini doesn’t mandate it, maintaining this document for Gemini is equally essential. Each file should be tailored for its intended assistant. For instance, if you’re using Claude Code for functional development and Gemini for visual enhancements, specify these roles in the respective files. These files are typically named Claude.md and Gemini.md and should use markdown format.
- Working Memory (Summary Files) – Named as claude-summary.md and gemini-summary.md, the files track what has been accomplished and what is currently in focus. Think of these files as the AI’s working notebook. They capture not just what was done, but what’s currently in focus, what decisions were made, and what comes next. These files directly address the context dilution problem.
- Episodic Memory (Visual Changes File) – The visualchanges.md file functions as episodic memory, documenting specific visual change moments and enabling you to revisit previous visual states. Each entry in this specialized UI changelog captures not only what changed but also includes the “before” state and precise rollback instructions. If you decide yesterday’s new card design isn’t working as expected, you can simply find the entry and follow the exact reversion steps. This file serves as a time machine for your website’s appearance, independent of your code versioning system.
This three-layer approach resolves two critical AI-assisted development challenges. First, it addresses context dilution. As conversations lengthen, the AI’s sliding attention window causes earlier details to fade from immediate awareness. Your summary files serve as concentrated extracts of recent relevant work, ensuring the AI maintains situational awareness. Second, it manages visual changes, which are subjective and sometimes don’t work as initially expected. The visual changes file creates an independent visual “undo” system that complements your code versioning. Finally, the unchanging project documentation serves as the authoritative product specification that coding assistants must reference before, during, and after completing each milestone.
Handoff Protocol
Your master prompt should also document a handoff protocol that ensures smooth transitions between Claude and Gemini. This means that in your master prompt, you should add instructions that before switching assistants, the current AI updates its summary file with exactly where things stand, what it was working on and what should happen next. This is like leaving detailed notes for a colleague taking over your shift, the incoming AI assistant knows exactly where to pick up the work.
Include a handoff protocol in your master prompt to ensure seamless transitions between Claude and Gemini. Direct the current AI to update its summary file before switching assistants, clearly documenting the current status, work in progress, and next steps. This is like leaving detailed notes for a colleague taking over your shift, the incoming AI assistant knows exactly where to pick up the work.
Update Frequency, Baselines & Structure
Your master prompt should specify clear document update intervals to prevent documentation drift. Include requirements that summary files must be updated at natural breakpoints—such as the end of a session, before switching assistants, or when reaching milestones. For the visual changes file, insist that updates be documented before implementation rather than after. This prevents the common problem of forgetting what the original state looked like.
Also have the master prompt include the concept of a “baseline visual state.” This documents the initial visual state when you first set up the design system with your specified color palette. Direct the AI to document this starting point in the visualchanges.md file. This baseline provides a reliable ground truth you can always return to if needed.
Finally, instruct the master prompt to maintain documentation in a structured format. I typically store these five files in a dedicated ‘docs’ folder at the root of my project. This organization separates documentation from code while keeping everything easily accessible. Include the baseline visual state in the visual changes file as both a template and example entry, guiding the AI on proper formatting for future entries. If your project includes wireframes, store these in a folder within the same docs folder. Also include a manifest file documenting what each file represents.
Generating the master prompt
After all this preparation, we finally arrive at the critical step: creating an initial master prompt for your coding assistant. For this, I use Meta Prompting, a technique where you use an LLM to generate and refine your master prompt. OpenAI offers an excellent article on Meta Prompting that explains this approach.
I typically divide this process into two straightforward steps:
- First, generate a prompt to create comprehensive project documentation, then use that prompt to produce the documentation
- Second, use the completed project documentation to create an initial master prompt for your coding assistants
My workflow looks something like:
For project documentation and master prompt generation, I rely on models with superior reasoning capabilities. Claude’s Opus 4.1 with extended thinking and “Explanatory” style consistently delivers the best results. During my research into effective prompting methods, I discovered the “Ultimate Prompt Architect” (UPA) on GitHub—an exceptional resource that I’ve configured as a Claude project to generate high-quality master prompts.
Step 1: Generate a prompt to create project documentation
After setting up the prompt generator as a Claude project, I provided it with the product brief along with all design system elements, color palette, and other details I had documented during the Visualize phase and document strategy steps.
Here’s what my comprehensive 24-page master prompt for generating project documentation looked like:
I then initiated a new conversation with Claude Opus 4.1 and submitted this master prompt to generate the complete project documentation.
Step 2: Use project documentation to generate an initial master prompt
After generating all the project artifacts, I returned to my Ultimate Prompt Architect to create the initial master prompts for Claude Code and Gemini CLI.
Since I planned to switch between these two assistants during development, I specifically asked the UPA to address context switching in the master prompts.
The UPA then delivered the following initial master prompts:
Gemini CLI Master Prompt
You are Gemini CLI, responsible for the initial setup and configuration phases of a personal website project.
## Your Primary Responsibility: Phases 1-2
You are specifically tasked with completing the foundational work:
- Phase 1: Project Initialization (Tasks 1.1 through 1.4)
- Phase 2: Configuration Files (Tasks 2.1 through 2.3)
## Documentation System
Your key documents:
1. **gemini.md** - Contains your detailed task checklists
2. **gemini-summary.md** - Track your progress here
3. **visualchanges.md** - Document any visual decisions
4. **wireframe-manifest.md** - Note if you reference wireframes
## Starting Protocol
1. Read gemini.md focusing on Phases 1-2
2. Check gemini-summary.md for current status
3. Execute tasks sequentially using the exact commands provided
4. Check off completed items as you go
## Handoff Preparation
When you complete Phase 2, prepare for handoff to Claude by:
1. Updating gemini-summary.md with "Phase 1-2 Complete, ready for Claude Phase 3"
2. Documenting all created files and configurations
3. Noting any decisions that will affect component implementation
4. Creating a version snapshot
5. Clearly marking Phase 3 as "Ready to Start"
Your goal: Create a rock-solid foundation that Claude can build upon for the design system and component work.
Ready to begin with Task 1.1?
Claude Code Master Prompt
You are Claude Code, responsible for the design implementation and component architecture phases of a personal website project.
## Project Status Check
First, determine where the project stands:
1. Read claude-summary.md to check current state
2. If Phases 1-2 are complete (by Gemini), proceed to Phase 3
3. If project is not started, you CAN begin from Phase 1 if needed
## Your Primary Responsibility: Phases 3+
After foundation is laid, you excel at:
- Phase 3: Carbon Design System Integration (custom theming)
- Phase 4: Component Development (with wireframe interpretation)
- Phase 5+: Complex integrations and architectural decisions
## Documentation System
Your key documents:
1. **claude.md** - Your architectural guide and philosophy
2. **claude-summary.md** - Your progress tracking
3. **visualchanges.md** - Critical for component visual decisions
4. **wireframe-manifest.md** - Your visual source of truth
## Starting Protocol
IF project is initialized (check for package.json, directory structure):
- Begin with Phase 3: Carbon Design System setup
- Reference wireframes in docs/wireframes/ for visual guidance
- Focus on the "why" behind design decisions
IF project is NOT initialized:
- You can execute Phase 1-2 if needed
- But note that gemini.md has more detailed setup commands
## Your Strengths
Leverage your abilities in:
- Interpreting wireframes and making design decisions
- Understanding component architecture patterns
- Solving complex integration challenges
- Explaining architectural reasoning
Ready to assess the project state and proceed accordingly?
With the completion of the Strategize phase, I was now completely prepared to begin building my personal website. In the next part, we’ll explore the Realize phase and discuss how other phases apply to rapid prototyping.
I welcome your thoughts on this framework and would be happy to address any questions in the comments.