The Transmutation of Form

This chapter fits Claude's idiom almost exactly, and the source examples already use tags for the input. Build on that: keep the source in its own tag, add <destination_form> and <reader> tags, and put the <task> instruction last. The distinctive gain here is the audit - ask what was lost in the conversion, what had to be inferred, and where the source was ambiguous, and you get an honest account rather than a confident rewrite.

• Keep the source in its own tag; <task> last.
• Tag the reader separately from the form.
• Ask what was lost in the conversion.
• On expansion, require an <inferred> list.
• Use an Artifact for anything you will keep editing.

<source_clause>
The Lessee hereby covenants to indemnify and hold harmless the Lessor from and against any and all claims, liabilities, damages, and expenses, including reasonable attorney's fees, arising out of or in connection with the Lessee's use and occupancy of the demised premises, or any act or omission of the Lessee, its agents, employees, or invitees.
</source_clause>

<destination_form>
A three-point summary in plain English. Each point one short sentence, in the register of speech rather than of law.
</destination_form>

<reader>
A first-time tenant in Hyderabad who has never read a lease before and is being asked to sign this one. Not a lawyer. Will read the three points and nothing longer. Needs to know what they are agreeing to and what could cost them money.
</reader>

<constraints>
- No legal vocabulary survives the translation. "Indemnify", "hold harmless", "lessee", "demised premises", "invitees" must be rendered into ordinary words, not restated.
- "Invitees" is the clause's real sting and the part most tenants miss. One of the three points must cover it concretely - that this can reach to guests they bring home.
- Each point states the practical consequence, not the legal mechanism.
</constraints>

<task>
Write the three points.

Then <what_the_summary_loses>: anything in the clause the three points do not carry, so I know where the summary stops being complete. Three sentences cannot hold everything in that clause and I would rather know what fell out.

Then <ambiguities>: any part of the clause that genuinely has more than one reading. Do not silently pick the likely one - name it. "Any act or omission" is very broad and I want to know how broad.

Then <questions_to_ask>: two or three things this tenant should ask before signing.

Then <scope_of_this_answer>: state plainly that this is a plain-English reading and not legal advice, and that you are not telling me whether this clause is enforceable or standard under Indian rental law. If you are uncertain about how Indian law treats indemnity clauses in residential leases, say that rather than reasoning from general principles as though they applied.
</task>

<data_points>
Product: Mobile App 'ConnectLocal'
Launch Date: January 2025
Target Market: Small businesses in Hyderabad
Q3 User Growth: 300%
Key Feature Used: 'Local Discovery' tool
User Testimonial: 'Our sales doubled thanks to this app!' - Latha's Sarees
</data_points>

<destination_form>
A success story of about 250 words for the company's internal blog. Proud and inspiring in tone, but the pride earned from the specifics rather than asserted with adjectives.
</destination_form>

<reader>
Our own employees, most of whom worked on this product and know the real story. That is the binding constraint: anything inflated is immediately obvious to them, and an internal post that reads as spin is worse than no post.
</reader>

<the_expansion_problem>
Six facts are being turned into a narrative. The gap between them is where invention happens, and I want it left visibly empty rather than filled.

Do not add: reasons for the growth beyond what the data states; anything about the team, the process, late nights or anyone's motivation; numbers not listed; further customers or testimonials; anything forward-looking.

The Latha's Sarees quote is used verbatim and attributed exactly as given.

Build the story through structure, not embellishment: open on the saree shop whose sales doubled, widen to the 300% growth, land on 'Local Discovery' as the mechanism. Narrative shape can carry this without a single invented detail.
</the_expansion_problem>

<task>
Write the post.

Then <inferred>: everything your draft implies that the data does not state. Include causal implications - the data says 'Local Discovery' was the key feature used, not that it caused the 300% growth, and if your copy implies causation I need that on the list. Be thorough here; this section is the reason I am asking you rather than writing it myself.

Then <where_i_wanted_more>: the single fact you most needed and did not have. Name it, so I can go and get it before publishing.

Then <honest_assessment>: does 250 words of proud narrative actually survive on six data points, or does the brief require more than the data can support? If the honest answer is that the post is thin and needs one more real detail, say so - I would rather hear that than receive a well-written piece quietly propped up on invention.

Put the draft in an Artifact; I will revise the opening over a few turns.
</task>

<role>
You are a senior marketing copywriter.
</role>

<technical_features>
* 1.1 kg ultra-lightweight magnesium-alloy body
* 18-hour battery life
* Fingerprint sensor for login
* AI-powered noise-cancelling microphone
</technical_features>

<destination_form>
One persuasive paragraph for a product webpage. About 90 words.
</destination_form>

<reader>
A busy working professional in India. Commutes. Works from cafes, client offices and airport lounges. Takes calls from places that are never quiet. Frequently cannot find a socket. Not reading spec sheets - wondering whether this machine will make their day less annoying.
</reader>

<the_transmutation>
Every feature becomes an experience. None of the technical vocabulary survives: not magnesium-alloy, not 1.1 kg, not 18-hour, not fingerprint sensor, not AI-powered, not noise-cancelling. The numbers go too - the reader should feel the lightness, not be told the weight.

- Weight becomes what carrying it all day is like
- Battery becomes not hunting for a socket
- Fingerprint login becomes the seconds not lost
- Microphone becomes being heard clearly from somewhere loud
</the_transmutation>

<avoid>
- "Seamless", "effortless", "game-changing", "empower", "unleash". Dead words.
- Inventing features, prices, warranty terms or comparisons to named competitors.
- Claiming performance the features do not state. Nothing here says the machine is fast.
</avoid>

<task>
Write the paragraph. Then two alternative opening sentences.

Then <jargon_audit>: go back through your own paragraph and confirm no banned word appears. Then name any sentence that is technically compliant but still reads as a spec sheet in disguise - "carry it from meeting to meeting without feeling it" is a translation; "remarkably light" is the spec with the number removed.

Then <hardest_to_translate>: which of the four features resisted translation most, and why. In my experience the feature that will not translate into an experience is usually the feature that matters least to the reader, and I want to know if that is what you found.

Then <what_the_copy_cannot_say>: what a reader will want to know that these four features do not tell them - and that I should therefore not let the copy imply.
</task>