The Power of the Negative Command

Put the bans in their own tag - <do_not> alongside <do> - and pair each prohibition with its replacement. The move that makes this work on Claude is asking for the audit afterwards: a <ban_check> tag where it quotes its own lines that drifted toward the banned thing, including ones it caught and fixed. It will do this honestly, which tells you where your constraint fought the material.

• Separate <do_not> from <do>; pair each ban with a replacement.
• Ask for a <ban_check> quoting its own near-misses.
• Let it tell you when a ban is hurting the output.
• Standing bans belong in a Project, not every prompt.
• Never rely on a ban for anything that matters - read it.

<task>
Draft a professional email to a client whose payment is 15 days overdue. The goal is a payment date, not a won argument - I want to keep working with this client.
</task>

<tone>
Firm but polite. Formal without being stiff.
</tone>

<do_not>
Each ban with what to do instead:

- No emotional or accusatory language. No "you have failed to", "we are disappointed", "as you are well aware". Instead: state the facts and the ask neutrally.
- No informalities, slang or contractions. "Do not", never "don't". Instead: plain professional English.
- No passive-aggression. This is the real risk and it hides inside polite phrasing: "just following up again", "I'm sure this is an oversight", "per my previous email", "gentle reminder" are all banned. Instead: say directly what is outstanding and what you want.
- No threats or implied threats. Nothing about legal action, late fees, suspended work or escalation. Instead: make the ask clear enough that it needs no consequence attached.
- No over-apologising. Do not apologise for sending it or for the inconvenience of being owed money. Instead: courteous without deference.
</do_not>

<do>
- Open on the specific invoice: number, amount, original due date.
- One line acknowledging invoices get missed, without excusing it.
- A direct ask: a payment date, or a reply stating when payment will come.
- A line offering to clear any blockage - a missing purchase order, a wrong detail on the invoice. That is frequently the actual cause.
- Subject line. Body under 150 words.
- Use [INVOICE NUMBER], [AMOUNT], [DUE DATE] as placeholders; invent nothing.
</do>

<task_after_drafting>
Write the email.

Then <ban_check>: go back through your own draft and quote any phrase that comes close to anything in <do_not>, including anything you wrote and then revised. Passive-aggression is the one to be strict about - it survives rewriting because it reads as polite, and I would rather see a phrase flagged as borderline than discover it after sending.

Then <how_this_lands>: one paragraph on how the email would read to a client who is late because of cash flow trouble, which is the most likely reason. If the draft would make that situation worse, tell me which line does it.

Then <the_ban_i_should_reconsider>: if any of my bans is making the email less effective - if the ban on implied consequences means there is no reason for them to act at all - say so. I would rather hear that the email is too soft to work than send a polite note that gets ignored for another fifteen days.
</task_after_drafting>

<task>
A comparison table for a tech entrepreneur choosing between Hyderabad and Bangalore for their startup headquarters.
</task>

<rows>
At minimum: Office Space Cost, Talent Pool Availability, Government Incentives.

You may add rows only if they are strictly business factors - commute time's effect on usable working hours, ecosystem density, airport connectivity for client travel. For each added row, one line on why it affects the decision.
</rows>

<do_not>
- No tourism, nightlife, food or general lifestyle content. Not as rows, not as asides inside business rows, not in the summary. This is the central constraint: almost everything written comparing these two cities is lifestyle content, and I need the business version. Instead: where something lifestyle-adjacent has a real business consequence, state only the consequence.
- No "quality of life" row. That is lifestyle in a business suit.
- No weather - unless it is data centre cooling cost, in which case say that explicitly.
- No city-pride language. No "vibrant", no "Silicon Valley of India", no "up-and-coming". Instead: what is measurable.
- No invented figures. Do not state rupees per square foot or engineer headcounts from memory as though sourced. Instead: give the relative position - lower, comparable, higher - and name the source I should check.
</do_not>

<format>
Four columns: Factor | Hyderabad | Bangalore | Where to verify this. The fourth names a specific source - a state IT department, a published commercial property report, a government scheme page.
</format>

<task_after_the_table>
Then <which_factor_decides>: of all the rows, which one actually determines the answer for most early-stage companies, and why. A table implies every row carries equal weight and they do not - this is the most useful thing you can tell me and the table format actively hides it.

Then <what_a_table_cannot_hold>: the business factors that do not fit this format at all - where your first customers are, where your co-founder lives, your own network. If one of those should outweigh the entire table, say so.

Then <lifestyle_check>: confirm nothing lifestyle-related got in, and quote anything borderline.

Then <currency_warning>: flag any scheme or figure that may be out of date. Government incentive schemes change and a lapsed scheme stated confidently is worse than silence.
</task_after_the_table>

<task>
A four-stanza poem about the arrival of the monsoon in Hyderabad.
</task>

<what_it_is_about>
The relief of the first rain after long heat. Petrichor - the smell of earth taking water. The green that follows within days. Positive and celebratory throughout, and staying there.
</what_it_is_about>

<do_not>
- No traffic, flooding, waterlogging, potholes or power cuts. Instead: the poem lives in the hour of arrival, not the week after.
- No turn into melancholy. Monsoon poems default to nostalgia - rain as memory, rain as grief. Instead: present tense, and in the body. Heat, then water, then green.
- No sadness in the final stanza. That is where a positive poem usually collapses into wistfulness. Instead: end on the green, or on a next-morning image.
- No "pitter-patter", "Mother Nature", "liquid gold", "thirsty earth". Instead: one specific image a Hyderabad reader would recognise - a particular surface going dark with water, a particular smell.
- No landmarks as scenery. No Charminar or Hussain Sagar dropped in for atmosphere. Instead: let the city arrive through sensory detail.
- No rhyme scheme you cannot hold without strain. Instead: free verse if the rhyme is bending the lines.
</do_not>

<task_after_the_poem>
Write the poem.

Then <ban_check>: quote any line that drifted toward the negative, the melancholic or the cliched - including lines you wrote and then revised. Where the pull was strongest is what I actually want to know.

Then <where_the_constraint_fought_me>: be straight with me here. I have banned every difficult thing about the monsoon, which is most of what the monsoon is in a city like this, and I have banned the melancholy that monsoon poetry naturally reaches for. Tell me where that made the poem weaker or less true - and if you think the honest version, with the flooding and the ambivalence in it, would be the better poem, say so and show me one stanza of it so I can judge.

I would rather have that disagreement than a thinner poem delivered without comment.
</task_after_the_poem>