{ "format": "promtly.pack/1", "name": "Cook", "author": "promtly", "description": "The prompts that change what a coding assistant gives back. Each one forbids the thing a model does instead of the good answer, and says where the saved effort should go.", "decks": [ { "id": "deck_cook", "name": "Cook", "tiles": [ { "id": "tile_cook_01", "label": "Cook harder", "body": "Double down on this and build it properly, now.\n\nDecide instead of asking: where it's ambiguous, take the strongest reading, state the assumption in one line, and keep going. Only stop to ask if proceeding could lose data or money.\n\nWrite the real thing. No stubs, no TODOs, no \"in production you’d...\". If a piece is required for it to work, build that piece too. Then go one step past the first version that works — the version you’d actually defend.\n\nDon't spend anything on: tests I didn't ask for, plan or summary documents, narrating your steps, listing options, re-reading what you just wrote, or justifying the approach. Trust your own code. We debug when something actually breaks, not before.\n\nDo spend it on: the hard part, the case that will actually bite in use, and whatever makes this good instead of adequate.\n\nFinish with two lines max — what you built, and anything you deliberately left out.", "color": "amber", "uses": 0 }, { "id": "tile_cook_02", "label": "Finish it", "body": "Finish this end to end. Don’t hand me back a list of what’s left, a caveat list, or an \"open items\" table.\n\nIf part of it is genuinely blocked, do every other part in full, then say in one line what you left and why. Scaling the work down is my call, not yours.\n\nOnly tell me it’s done when it’s done AND you’ve checked it.", "color": "amber", "uses": 0 }, { "id": "tile_cook_03", "label": "Debug it properly", "body": "Find the cause before you touch anything.\n\nSay what you expected, what actually happened, and the narrowest thing that explains the difference. Name the step in your reasoning you’re least sure about and what evidence would settle it.\n\nDon’t patch the symptom, don’t wrap it in defensive try/catch, and don’t change three things at once so we can’t tell which one mattered. If your first theory doesn’t survive contact, say so out loud and take the next one.", "color": "rose", "uses": 0 }, { "id": "tile_cook_04", "label": "Prove it", "body": "Don’t tell me it works — show me.\n\nName the instrument, paste what it actually returned, and say what reading would have meant failure. If the only evidence is that you read the code and it looks right, say exactly that instead of dressing it up.\n\nCheck the case most likely to disagree with you, not the one most likely to pass.", "color": "green", "uses": 0 }, { "id": "tile_cook_05", "label": "Read it first", "body": "Open the actual files before you propose anything, and quote the lines you’re relying on.\n\nNo guessing at function names, arguments, config keys, or what a library returns. If you’re inferring an API rather than reading it, stop and read it. If something isn’t there, say it isn’t there instead of writing a call that looks plausible.", "color": "blue", "uses": 0 }, { "id": "tile_cook_06", "label": "Don't break what works", "body": "Before you change this, list what currently works that I’d notice losing — behaviour, not files.\n\nKeep every one of those working, and say which ones you actually exercised afterwards. If the change makes one of them impossible, tell me before you do it, not after.\n\nDon’t rename, reformat or \"tidy\" anything I didn’t ask about — it hides the real diff.", "color": "violet", "uses": 0 }, { "id": "tile_cook_07", "label": "Land it", "body": "Land this. Every call still open is yours — make it, and fold what you chose into a sentence rather than asking me.\n\nCommit and push. If something needs my hands (a deploy, a sign-in, a purchase), do everything up to it and give me the one command.\n\nThen report in two lines: what is done, and what is waiting on me. No per-item tables, no lane-by-lane breakdown, no recap of the work — I was here.", "color": "green", "uses": 0 }, { "id": "tile_cook_08", "label": "Yours to decide", "body": "You are asking me something you can settle yourself. Settle it.\n\nTake the strongest reading, say what you chose in one clause, and carry on. Only put it back to me if it spends money, is irreversible, needs my credentials, or is my taste on something I have to live with.\n\nDon’t queue it, don’t list it as an open item, and don’t ask again for the next one like it.", "color": "amber", "uses": 0 }, { "id": "tile_cook_09", "label": "Elevate the design", "body": "Make this look considered, not decorated. The palette is not the lever — the structure is. Changing colours on a generic layout produces a generic layout in new colours.\n\nDon’t give me: a centred column with an eyebrow, a giant gradient headline, one paragraph and two buttons; a grid of equal cards; stock photography or an abstract blob standing in for content; emoji as icons; placeholder copy; or vertical padding doing the work of composition.\n\nDo give me: real content in the real layout — actual copy, actual data, the actual UI, never a grey rectangle; one focal point with a deliberate reading order; density where there is something to read; and asymmetry unless centring is itself the idea.\n\nName what you are calibrating against and why. Then say which single decision carries the design — if you can’t name one, it is decoration.\n\nLook at it rendered, at true size, before you tell me it is done. Report the one thing you would change next.", "color": "violet", "uses": 0 }, { "id": "tile_cook_10", "label": "Argue against this", "body": "Argue against this. Strongest objection first, then what I’m assuming without noticing, then where it breaks first under real use.\n\nBe specific and don’t soften it to be agreeable. If you think it’s actually fine, say that plainly and say what would change your mind.", "color": "violet", "uses": 0 } ] } ] }