I'm not going to lie, deep down I still love to actually build things (UI and code), but the simple truth is I still have more ideas then time and I'm super lazy (I often say being lazy is my super power as it drives me to be efficient), and that combo is perfect for AI development (aka vibe coding).
So I thought I would share my prompting strategies, hopefully you might find them useful.
Callout I am in no way a production developer, so all of my prompts come from someone who:
- builds tools to solve my own problems
- some small scale production solutions
- not business critical full stack solutions
- The Different Prompt Strategies
- Prompt Techniques
- What Goes With The Prompt
- Tips
1. The Different Prompt Strategies
There are 3 different prompt strategies I use, in practice there are many different shades of grey, with it being more of a scale then points of a triangle.
Incremental
Often my default and probably the most enjoyable. The incremental approach works from a story approach with the project broken up into small pieces (just like a feature story). I plan out my design, what I need and break it down into story's, normally something like this:
- setup covering basing loading and any databases and auth
- menu, navigation, settings
- feature 1 (most important or if dependency based arch the most required)
- feature 2
- feature 3
- etc
After each prompt I test and review, and if needed drop in some follow on prompts to refine/debug. Once happy I normally clear the context with a new chat (unless there are heavy overlaps with previous story).
This approach is the easiest to pickup, as it allows you to pivot/change direction and is most forgiven if the llm isn't doing as you wish.
One Hit
This is the one everybody thinks of, you describe everything you want in one big prompt and hit send. The key to this approach is planning, you need to make sure know exactly what you want and cover everything.
Plenty of planning and thought is needed, and it is ideal for
- Small projects - like a small dev tool you want
- Replication - something you have already built but want a clone variant
- Migration - moving an existing solution to a different platform, as the code is the context
- Expanding PoC - similar to replication but adding features/polish
I found myself using this less and less over time, which is counter intuitive when you think improved promoting experience will make this better.
Project
This is kind of a combination of the other strategies. In this approach I work with the LLM in a chat window first. Asking questions about what options I have, What's possible, identifying trade offs, and inspiring new ideas. Once this process is complete I ask it to create me a detailed implementation plan for another agent to actually build. This markdown file is then included in my build prompt, along with the over arching goal.
This approach is great for:
- Large / complex projects
- Blue sky ideas
- Anything new tech stack you are trying
What's particularly cool about this approach is if you have the budget you an run different models on the same project, and compare the 2 to find the best.
The difference between Incremental and One Hit can be very marginal, as often a one hit leads to a few follow on prompts to fix bugs / small updates. But its the underlying approach that is different, do you try and solve everything at first, then fix it. Or do you start small and layer on.
The strategy you pick can depend on many different factors:
- Personal Preference
- Clarity of project (low generally go with Incremental)
- Complexity (high go with Project)
- New Tech (if its new to you use Project)
- Learning/PoC (the more tactical it is the more I lean to One Hit)
What I'm trying to say is understanding that there is different strategies is the most important thing, as over time you will naturally see your prompts falling into one of them, and then you are able to learn when best to use which.
2. Prompt Techniques
There are many many different prompt techniques, with the title of Prompt Engineering making it an entire role/speciality, so instead of diving into many I thought I would show you the ones I use:
Size
My approach has always been to keep my prompts short and focused, if additional information is required I normally add that as an attached file
- Complex plan, create a markdown file with all of the steps you want
- Debug something, include the error in a text/json file
Another key consideration to the size is context, as every follow on message to the LLM includes all previous messages (from both you and the LLM). So it is key to reset your chat sessions at the right time to keep the size right.
To do this I think about the follow on request:
- Is it related directly to previous message (i.e same feature or even same specific file in the project)
- Is there value in the context (i.e use same technique)
If you are unsure I generally keep the same session, or I create my own compaction (Compaction is an automatic process that the model can use to summarise your session). Creating your own has 2 benefits of automatic, you can do it earlier (automatic happens when you have almost reached context limit, which can be up to 1 million tokens), and you can give guidance on what you think is important to keep in the summary.
Top tip, an image tells a thousand words, using screenshots in your prompts is a game changer. Simply take a screen shot, add red boxes and arrows and reference it in the prompt. The LLM can understand them easily and they use up less context.
I want the map to work well when zooming out, the cut off sections of France (see image) don't look right, please remove them.
Structure
My prompts generally follow a standard structure for new sessions, they are:
Start with a SDG (Simple Design Goal), this is a sentence that describes the goal and the value of the request. It ensures that the LLM doesn't just deliver the letter of and not the spirit of the request
An example would be:
I need an app that creates me a single pain of glass for my work week, pulling in all of my meetings, tasks, chats into one place so I can plan my week most effectively.
After the SDG I want my requirements. I normally use bullet points for these, they are technical and specific to exactly what I want. They can cover a behaviour, or the how.
An Example would be:
- Show totals by source
- Show a percentage bar of meetings for the week complete
- To get around outlook page limits and to improve performance load in blocks of 20 emails, if the oldest email is before this week stop, else loop until you have all emails for the week. Loads these as they arrive
- Create links to emails and chats to take the user directly to them so they can complete them
The key thing about requirements is they allow the model to have the right scope of work and know when its finished. If you want to be very open and let it decided, you still need to gate keep it with what done looks like. That could be a status like:
You will know when you are done when all my work sources are available in the app
The next thing I include is what I call Gotchas, this is a list of anything that you want to warn the model not to do.
An Example would be:
- The Teams get chat api doesn't cover group chats, use the graph/me api
Gotchas are a great starting point for a Skill, if you find yourself using them often create a Skill.md out of them to make it easy to reuse
The last thing you can sometimes include is any areas that you want the LLM to check with you. I generally don't set exactly what I want it to check, more if its unsure.
If you are unsure or are hitting blockers for below, please ask me what to do
- handling email pagination
- authentication
If you see these validation stages appearing across projects, they are a good thing to add to your instruction.md file.
Design
Another thing I include in my prompt when doing front end is to create 5 html mock-ups. I include the overarching style I want and even a colour pallet.
Example:
To help me decide on the right UI create me 5 html mock-ups. The should all be varied and unique, have a modern, minimalist, and professional style using #2f4858, #86BBD8 and #33658A.
To make it easy to review add a next/previous modal to navigate them
3. What Goes With The Prompt
Along with your prompt and context, you can send additional information. This is generally split into Agent.md, Instruction.md, and Skill.md files.
The line between Instruction.md and Agent.md is very blurred, and the simple fact are they are all just context that we add to our prompt, but for me I have a pattern that I use
Agent.md
I use them for specific coding languages and setups. This means with full stack you can have multiple Agent.md, frontend, backend, etc. These can be generic/global, or get tailored to particularly large projects.
The best example I have is when I build CodeApp JS apps, as these are a custom implementation of Power App Code Apps I created to allow vanilla JavaScript instead of React, coupled with the requirement to use the SDK for all API calls. Without it the LLM would presume its a standard React app and use TypeScript and commands like fetch() instead of the SDK.
Includes:
- SDK requirements
- Testing requirements
- Project structure
- Nudge/guidance (e.g. Always read Dataverse schema files before using the api)
We all know Anthropic likes to be different, and they use a Claude.md file instead, though I believe a recent update to Claude Code now accepts the Agent.md (as this is the industry standard), though any Claude.md takes precedent in the prompt hierarchy. It can also be useful to have your claude.md configured to work better with Claude models, and Agent.md with GPT, Grok, or your lab of choice
Instruction.md
Think of this as personalising the LLM to be like you, with the desired output code that is easy for you to read and modify. I have one instruction.md file that I use for everything, and because of that it has to be coding language and LLM agnostic. I've seen others use coding_standards.md for the same purpose, and it doesn't really matter about the name as long as your harness can read them.
Includes:
- Naming Convention
- Coding preferences (e.g JavaScript use arrow functions)
- Code Style (e.g. function based for reusability)
- Library preferences (e.g. Tailwind)
Skill.md
Skill.md sits at the closest point to that actual prompt, and its power comes from the ability to dynamically use them. They allow you or the LLM to add targeted context to that particular prompt. This allows the context to stay as short as possible, and removes contradictory information that could be across 2 skills.
Examples of this would be CodeApp JS, where I have specific skills for specific connectors. If the app isn't using SharePoint I wont include the SharePoint Skill.md.
Includes:
- Specific technical knowledge
- Specific requirements
- Examples
- Templates
- Gotchas (e.g. this normal behaviour wont work)
- Preferred solution approach's
Code App SharePoint (part of, the actual is 300 lines which is at the very top end I would recommend)
## Core App Rules
- Prefer dedicated SharePoint helpers over raw HTTP.
- Keep SharePoint list discovery inside `sharepoint.js`, not in app pages or components.
- Do not pre-encode the site URL. Pass the raw URL string and let the wrapper encode it.
- Always resolve through `resolveSharePointList(...)` once at startup so the wrapper can match the connector table token.
- If the app only knows a list name, use `resolveSharePointList(...)` or a by-list helper and let the wrapper do `listTables(...)` lookup.
4. Tips
The key thing to remember about prompts and all the accompanying context is:
Incremental learning/refinement is key. You need to have a constant feedback loop. If something works, identify what it is. If something goes wrong once, figure a fix and update your md or prompt style. Some recommend a total burning of your md files every 6 months/new model launch, and starting a fresh, while I'm not sure of that, I do think a cadence for deep dive refresh is a good idea.
Never presume things stay the same, not only are there constantly new models, the labs are constantly tinkering with them so something that works for Opus one day might suddenly not the next day (don't expect it to be a big change, more of diminished/inconsistent result)
Don't over rely on LLM's to help write prompts and md files. Asking a LLM to create you a prompt only adds very marginal improvements (think of it logically, if it understands the prompt to rewrite it, why does it need to rewrite it). Its not quite the same with md files, there is some value in using them to create the foundation, but you really need to read and modify. And once in use you need to be constantly reviewing them. Though there is definite value in getting the LLM to "Create me a short sentence with your learnings from this to ensure next time we can do it quickly and easily", then adding that to the right md.
Leverage others, there are so many great md files already out there, so why re-invent the wheel. One of my most used Skill.md is Anthropic's frontend-design skill skill. And there are lots more out there, Matt Pocock has an amazing suite of them, so make sure you are out there reading, and either using them or being inspired to improve your own (though as a quick cautionary note, always read the md file fully, in a plane text editor, as there has been cases of people prompt injecting using html comments not visible in places like GitHub).
