My AI Development Prompts

A developer shared three prompting strategies for AI-assisted software development: an incremental story-by-story approach, a single large "one hit" prompt, and a hybrid method that uses a chat session to produce a detailed implementation plan for a separate build agent. The developer emphasized keeping prompts short and focused, attaching files for extra context, and manually compacting chat sessions before hitting context limits.

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: 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. 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: 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. 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 I found myself using this less and less over time, which is counter intuitive when you think improved promoting experience will make this better. 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: 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: 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. 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: 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 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: 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. 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. - 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. 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 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 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 https://codeappjs.com 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: 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 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. 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. 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. 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 https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md skill. And there are lots more out there, Matt Pocock https://github.com/mattpocock/skills 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 .