>Why create prompts by LLM at all? Presumably you have to start with inputting what you want to happen, so why pass it through two LLMs instead of one?
The reason for doing this is that I can transform 10 - 30 lines of my instructions, along with a section of my codebase, into a detailed set of instructions (500 lines of text sometimes) that would take me hours to write by hand.
Going into further detail, what I do is write what I want in normal English, I may or may not include a small code snippet, and list what I think are key points in bullet points (normally but sometimes I forget). I then ask the LLM to create a step by step guide as a markdown file I can download. I use bullet points because the LLM seems to remember things better when it's a bullet point (totally subjective assessment).
Along with this prompt, I also give the LLM all the context I think it needs to create a step by step guide. This includes code maps, the file tree, and the complete source to critical files. This part of the prompt is usually between 2000 to 6000 lines.
Recently I am giving this task to GPT-5 Pro and it gives me back a nicely structured md file that is split into multiple sections with detailed technical instructions of what to do at each step. This file is normally 200 - 500 lines long. I skim it and prune it, then pass it to Claude Code. Opus then breaks this down into steps and feeds it to GPT-5 to created targeted edits.
>The important bit - how did they get Opus to write the prompt without them writing all those things in the meta-prompt - is missing.
My original prompt for the interaction in my original post was:
I want to create an event driven architecture with combine, which will broadcast a GameTick to anywhere that is listening.
/// Represents the state of the game at a specific turn or "tick".
/// This data is expected to be received from the server in the future.
public struct GameTick {
/// The current, sequential turn number of the game.
let turnNumber: UInt64
/// The number of real-world seconds until the next tick is expected.
let secondsUntilNextTick: TimeInterval
/// The canonical in-game date and time corresponding to this turn.
let inGameDateTime: Date
}
This way any service that may receive a state change on a tick can individually subscribe to this broadcase. Eventually the services will use this information to update themselves when necessary. For now I only want GameService and PlayerService to subscribe. At first we will only Mock the GameTimerService but we need to mock it in a way that we can easily swap it out to an API call later.
Create a step-by-step plan to implement this feature. Put your plan in a markdown file.
>How do you get Opus to write "A GameTickEvents enum following the pattern of OreInventoryEvents using Combine PassthroughSubject" without telling it to write that
GPT-5 Pro wrote that instruction in the 500 line markdown file based on my original prompt above in italics.