You are reviewing an entire codebase in a single context window. I am pasting [NUMBER] files below, totalling roughly [NUMBER] tokens.\n\nDo not summarise file by file. Instead:\n\n1. Map the real dependency graph, including the imports that cross module boundaries in ways the folder structure hides.\n2. Name every place where the same logic is implemented twice, and say which copy is authoritative.\n3. List the five changes that would most reduce coupling, ordered by how much breakage each would cause.\n4. Flag anything that reads like it was written by a different person or a different era of the project.\n\nQuote exact file paths and line ranges. If two files contradict each other, show both and say which one the runtime actually uses.\n\n[PASTE FILES]
Attached is a screenshot of [WHAT IT IS -- an app screen, a dashboard, a competitor page].\n\nProduce a build specification from it, not a description of it. Cover:\n\n- Every interactive element, what it does, and what state it has\n- The layout rules that would survive a resize to phone width\n- Spacing, type scale and colour values as tokens, not one-off numbers\n- The data each region needs, and where an empty or error state is missing\n- Anything on screen that you cannot explain the purpose of\n\nWrite it so a developer who has never seen the screenshot could build it. Mark every assumption you had to make with ASSUMPTION so I can correct you.
Translate the following into [LANGUAGES]. Large 4 was trained across 160+ languages, so treat the less common ones with the same care as the common ones.\n\nRules:\n\n- Keep the register consistent with the source. If the source is blunt, do not soften it.\n- Do not translate product names, feature names or code identifiers.\n- Where a phrase has no natural equivalent, give the closest version and add a bracketed note explaining what was lost.\n- Flag anything that would read as rude, childish or machine-made to a native speaker.\n- Return a table: language, translation, confidence, notes.\n\n[PASTE SOURCE TEXT]
I am currently sending this workload to [MODEL] at [PRICE] per million output tokens. Here is a representative sample of the inputs and the outputs I need.\n\nTell me honestly which of these three buckets each task falls into:\n\n1. Needs a frontier model. Say which capability specifically.\n2. Would work on a cheaper model with a better prompt. Write that prompt.\n3. Does not need a model at all. Say what would replace it.\n\nThen estimate the monthly cost of each bucket at [VOLUME] requests per month, and tell me what the split would save. Do not round in favour of using more model.\n\n[PASTE SAMPLES]
Review the following for security problems. Assume an attacker who has read the code and has a budget.\n\nFor each finding give me:\n\n- The exact input or sequence that triggers it\n- What the attacker gets, concretely, not in categories\n- Whether it is exploitable today or requires another weakness first\n- The smallest change that closes it\n\nRank by what an attacker would actually try first, not by severity label. If a finding only matters in a configuration I have not shown you, say which configuration.\n\nDo not list things that are merely untidy. If you find nothing serious, say so.\n\n[PASTE CODE OR CONFIG]
I need to migrate [SYSTEM] from [CURRENT] to [TARGET]. Full current state is pasted below.\n\nStart with what will break. Specifically:\n\n- Every behaviour that changes, including ones the documentation calls equivalent\n- Every piece of data that cannot be represented in the target\n- Every integration that assumes current behaviour\n\nThen give me the migration in stages where each stage leaves the system working. For each stage: what changes, how to verify it, and how to roll back.\n\nIf the honest answer is that this migration is not worth doing, say that and explain what it would cost to stay.\n\n[PASTE CURRENT STATE]