7 Claude Tools You Can Open Right Now

<context> Build me a single self-contained HTML file I can open in any browser. Everything must be in one file: HTML, CSS and JavaScript. No build step, no frameworks, no external requests of any kind. </context> <tool> Name: Runway Tracker What it does: Shows the month the bank account hits zero, accounting for burn that grows over time. </tool> <inputs> - Cash in the bank - Net burn per month - Burn growth per month, as a percentage - Monthly revenue </inputs> <logic> - Each month, subtract net burn minus revenue from cash, then grow the burn by the growth percentage - Continue until cash reaches zero, capping the loop so it cannot run forever - If revenue covers burn, report that there is no run-out date rather than a misleading number - Calculate the date to start raising, defined as six months before zero </logic> <output> - Headline: months remaining and the calendar month it happens - Supporting: the month to start raising to leave a six-month cushion - Current net burn per month - A clear "default alive" state when revenue exceeds burn </output> <interface_rules> - Recalculate live as I type. No calculate button. - Sensible default values already filled in, so it does something useful the moment it opens. - The headline result should be large and immediately readable, with the supporting detail underneath. - Clean and calm. Generous spacing, one accent colour, readable at a glance on a phone. - Never show NaN, Infinity, or a blank result. Handle zero and empty inputs gracefully with a helpful message. - Format currency and percentages properly, and never imply more precision than the inputs justify. </interface_rules> <constraints> - One file. No CDN links, no fonts loaded from the internet, no analytics. - Comment the calculation logic so I can change the assumptions myself. - Do not invent benchmark figures or industry averages. If a comparison would need one, let me enter it. </constraints>

<task> Extend my runway tool to show the full month-by-month projection, not just the final answer. </task> <current_tool> [paste your runway tool] </current_tool> <instructions> Add a table showing each month: opening cash, revenue, burn, net change, and closing cash. Highlight the month cash drops below three months of burn, and the month it hits zero. Keep it in one HTML file with live recalculation. Make the table scrollable rather than letting it stretch the page. </instructions>

<task> Build a tool that shows what one hire does to my runway. </task> <inputs_needed> Current cash, current net burn, current monthly revenue, the new salary plus an employment cost multiplier, the start month, and any revenue the hire is expected to generate with a ramp-up period. </inputs_needed> <instructions> One self-contained HTML file, live recalculation. Show runway before and after the hire, the months of runway the hire costs, and the month at which their expected revenue contribution turns net positive if it does. Let me set the ramp-up period explicitly rather than assuming immediate productivity, and default it to something realistic rather than zero. </instructions>

<task> Build a tool comparing three cost-reduction scenarios against doing nothing. </task> <inputs_needed> Current cash, burn and revenue, then for each of three scenarios: the monthly saving, the month it takes effect, and any one-off cost to implement it. </inputs_needed> <instructions> One HTML file, live recalculation. Show runway under each scenario and against the baseline, as months and as a date. Rank them by months of runway gained per unit of one-off cost. Include a plain-language note that this model captures only the cash effect and not the effect on the business, since cuts that gain three months but stop growth are not obviously good. </instructions>

<task> Help me size a raise properly instead of picking a round number. </task> <situation> [current cash, burn, revenue, growth rate, and what you want to achieve with the money] </situation> <instructions> Work backwards from the milestone I need to hit and the runway I want on the other side of it. Show the calculation as clear steps: cost to reach the milestone, plus the buffer months, plus the time it takes to raise again. Give a low, base and high figure with what each buys me. Flag the assumption the whole number is most sensitive to, and be direct if the milestone looks unreachable on any of these amounts. </instructions>

<task> Attack my runway assumptions and tell me where this breaks. </task> <assumptions> [paste your inputs: cash, burn, burn growth, revenue, and any revenue growth assumption] </assumptions> <instructions> Identify which assumptions are most likely to be optimistic, and why, based on how these models usually go wrong. Rework the runway under a realistic-pessimistic version of each. Tell me the single assumption that, if wrong, most changes when I need to act. Be blunt. If the plan only works under assumptions that rarely hold, say so plainly. </instructions>

<context> Build me a single self-contained HTML file I can open in any browser. Everything must be in one file: HTML, CSS and JavaScript. No build step, no frameworks, no external requests of any kind. </context> <tool> Name: Headline Grader What it does: Scores a headline out of 100 and explains exactly what is holding it back. </tool> <inputs> - A single text input for the headline </inputs> <logic> - Start from a base score - Add points for word count in the 6 to 13 range, which is the readable-in-a-feed window - Add points for total length at or under 65 characters, which avoids truncation - Add points for containing a specific number - Add points for concrete framing words such as how, why, without, stop, cut - Subtract points for vague jargon such as solution, leverage, seamless, robust, empower - Clamp the final score between 0 and 100 </logic> <output> - Headline: the score out of 100 plus a verdict of Ship it, Close, or Rewrite it - Supporting: a bulleted list explaining each factor that helped or hurt, with the actual counts - Every note should be specific enough to act on, not generic advice </output> <interface_rules> - Recalculate live as I type. No calculate button. - Sensible default values already filled in, so it does something useful the moment it opens. - The headline result should be large and immediately readable, with the supporting detail underneath. - Clean and calm. Generous spacing, one accent colour, readable at a glance on a phone. - Never show NaN, Infinity, or a blank result. Handle zero and empty inputs gracefully with a helpful message. - Format currency and percentages properly, and never imply more precision than the inputs justify. </interface_rules> <constraints> - One file. No CDN links, no fonts loaded from the internet, no analytics. - Comment the calculation logic so I can change the assumptions myself. - Do not invent benchmark figures or industry averages. If a comparison would need one, let me enter it. </constraints>

<task> Recalibrate my headline grader against headlines that actually performed for me. </task> <winners> [paste 10 headlines that performed well, with their results if you have them] </winners> <losers> [paste 10 that underperformed] </losers> <current_tool> [paste your grader HTML] </current_tool> <instructions> Identify the patterns that actually separate my winners from my losers, rather than assuming generic copywriting rules apply. Adjust the scoring weights and word lists accordingly, and tell me plainly which of the original assumptions my own data does not support. Return the updated single HTML file. If my sample is too small to justify a change, say so rather than overfitting. </instructions>

<task> Extend my headline grader so it also suggests improved versions. </task> <current_tool> [paste your grader] </current_tool> <instructions> Keep the scoring, and add a section that suggests three rewrites addressing the specific weaknesses the score identified. If the headline lacks a number, the rewrite should show where a number would go using a bracketed placeholder rather than inventing one. If it is too long, show the trimmed version. Never fabricate a statistic. Keep it in one file with live updating. </instructions>

<task> Build a version of this grader for email subject lines rather than headlines. </task> <instructions> Build it as one self-contained HTML file. The rules differ from headlines: shorter optimal length, mobile preview truncation around 35 to 40 characters, the effect of the preview text alongside it, and the risk of spam-trigger phrasing. Include a preview-text field alongside the subject and show how the two read together in a typical inbox, since that pairing is what actually gets opened. Score and explain as before. </instructions>

<task> Score these headlines and tell me which two to test. </task> <headlines> [paste your candidates] </headlines> <context> [what it is for, who the audience is, and where it will run] </context> <instructions> Score each one and explain the score briefly. Then group them by the angle they take, because testing two headlines with the same angle teaches nothing. Recommend the two to test first, chosen to be maximally different in approach rather than simply the two highest scores. Say what a win for each one would actually tell me about the audience. </instructions>

<task> This headline scored well but did not perform. Work out why. </task> <headline> [the headline] </headline> <results> [what happened: impressions, clicks, conversion, compared to what] </results> <context> [audience, placement, and what the landing page said] </context> <instructions> Work through the possibilities in order: mismatch between headline and the page it led to, wrong audience rather than wrong headline, the placement or format, saturation from prior exposure, and finally the headline itself. For each, say whether the evidence supports it and what would confirm it. Be clear about which of these the data can and cannot distinguish between. </instructions>

<context> Build me a single self-contained HTML file I can open in any browser. Everything must be in one file: HTML, CSS and JavaScript. No build step, no frameworks, no external requests of any kind. </context> <tool> Name: Meeting Cost What it does: Shows what a recurring meeting actually costs in salary terms. </tool> <inputs> - Number of people in the room - Meeting length in minutes - Average salary - How many times per month it recurs </inputs> <logic> - Hourly rate equals salary divided by 2080, being 40 hours across 52 weeks - Apply a fully-loaded multiplier of 1.25 to account for employment costs beyond salary - Cost per meeting equals loaded hourly rate times the meeting length in hours times the number of people - Also calculate the monthly and annual totals - Calculate the annual saving from halving the length, and from removing two attendees </logic> <output> - Headline: cost per meeting - Supporting: monthly and annual cost - The annual saving from cutting it to 30 minutes - The annual saving from dropping two attendees </output> <interface_rules> - Recalculate live as I type. No calculate button. - Sensible default values already filled in, so it does something useful the moment it opens. - The headline result should be large and immediately readable, with the supporting detail underneath. - Clean and calm. Generous spacing, one accent colour, readable at a glance on a phone. - Never show NaN, Infinity, or a blank result. Handle zero and empty inputs gracefully with a helpful message. - Format currency and percentages properly, and never imply more precision than the inputs justify. </interface_rules> <constraints> - One file. No CDN links, no fonts loaded from the internet, no analytics. - Comment the calculation logic so I can change the assumptions myself. - Do not invent benchmark figures or industry averages. If a comparison would need one, let me enter it. </constraints>

<task> Build a tool that costs my whole recurring meeting schedule at once. </task> <inputs_needed> A list of meetings, each with a name, attendee count, duration, frequency per month, and optionally a different average salary for that group. </inputs_needed> <instructions> One self-contained HTML file with live recalculation and the ability to add and remove rows. Show the annual cost per meeting and the total. Sort by annual cost descending so the expensive ones surface immediately. Include a column for cost per attendee-hour so short meetings with many senior people are correctly identified as expensive. </instructions>

<task> Build a tool comparing the cost of deciding something in a meeting against deciding it in writing. </task> <inputs_needed> Attendee count, meeting length, average salary, and for the written alternative: time to write the document, number of reviewers, and time each spends reviewing. </inputs_needed> <instructions> One HTML file, live recalculation. Show both costs and the difference. Include an honest note that the two are not equivalent in quality, since some decisions genuinely need synchronous discussion, and let me indicate whether this decision is one of those. The tool should inform the choice, not pretend to make it. </instructions>

<task> Here is my recurring calendar. Tell me what to cut. </task> <meetings> [list each recurring meeting: name, attendees, duration, frequency, and its purpose] </meetings> <instructions> For each meeting, assess whether its stated purpose requires synchronous time, requires everyone invited, and requires that frequency. Recommend keep, shorten, shrink the invite list, reduce the frequency, or replace with a written update. Give a one-line reason each. Rank the recommendations by hours returned per unit of disruption, and be honest about which cuts would be politically difficult rather than pretending they are all equally easy. </instructions>

<task> Write an agenda that would let this meeting finish early. </task> <meeting> [what it is for, who attends, current length] </meeting> <typical_problems> [what usually makes it overrun] </typical_problems> <instructions> Write an agenda where every item states the decision to be made and who owns it, with a time box. Specify what must be read before the meeting rather than presented during it, since presenting is what causes overrun. Include an explicit first item that confirms whether the meeting is still needed. Keep it to one screen. </instructions>

<task> Help me argue for cancelling this recurring meeting without damaging relationships. </task> <meeting> [what it is, who runs it, who attends, what it costs annually from the calculator] </meeting> <my_position> [your relationship to the meeting owner and how much political capital you have] </my_position> <instructions> Write the case. Lead with what the meeting is trying to achieve and propose a specific alternative that achieves it, rather than simply arguing for removal. Include the annual cost figure but do not lead with it, since leading with cost reads as an attack on the organiser. Offer a trial period rather than a permanent cancellation. Keep it under 200 words and give me a softer variant. </instructions>

<context> Build me a single self-contained HTML file I can open in any browser. Everything must be in one file: HTML, CSS and JavaScript. No build step, no frameworks, no external requests of any kind. </context> <tool> Name: Break-Even Check What it does: Shows how many orders an ad spend must produce to break even, and the maximum you can pay per customer. </tool> <inputs> - Ad spend - Average order value - Gross margin as a percentage - Landing page conversion rate as a percentage </inputs> <logic> - Profit per order equals average order value times gross margin - Orders needed equals ad spend divided by profit per order - Required ROAS equals one divided by the gross margin - Clicks needed equals orders needed divided by the conversion rate - Maximum cost per click equals ad spend divided by clicks needed </logic> <output> - Headline: orders needed to break even, rounded up - Supporting: the required ROAS stated plainly at the given margin - Maximum you can pay per customer - Clicks needed and the resulting cost-per-click ceiling </output> <interface_rules> - Recalculate live as I type. No calculate button. - Sensible default values already filled in, so it does something useful the moment it opens. - The headline result should be large and immediately readable, with the supporting detail underneath. - Clean and calm. Generous spacing, one accent colour, readable at a glance on a phone. - Never show NaN, Infinity, or a blank result. Handle zero and empty inputs gracefully with a helpful message. - Format currency and percentages properly, and never imply more precision than the inputs justify. </interface_rules> <constraints> - One file. No CDN links, no fonts loaded from the internet, no analytics. - Comment the calculation logic so I can change the assumptions myself. - Do not invent benchmark figures or industry averages. If a comparison would need one, let me enter it. </constraints>

<task> Extend my break-even tool to account for customers who buy more than once. </task> <current_tool> [paste your tool] </current_tool> <instructions> Add inputs for expected repeat purchases per customer and the time window over which they happen. Show two break-even figures: on the first order alone, and across the full lifetime value. Be explicit about the cash-flow implication, that lifetime break-even may be months away and requires funding in the meantime. Keep it in one HTML file with live recalculation. </instructions>

<task> Build a tool comparing break-even economics across several acquisition channels at once. </task> <inputs_needed> For each channel: name, spend, average order value, conversion rate, and the cost per click or cost per lead if known. Plus a single shared gross margin. </inputs_needed> <instructions> One HTML file with add and remove rows and live recalculation. For each channel show orders needed, CPC ceiling, and whether the actual cost per click is above or below that ceiling, colour-coded clearly. Sort by headroom, meaning the gap between the ceiling and the actual cost, since that is where budget should go. Do not invent benchmark costs, let me enter my own. </instructions>

<task> Given what I can actually pay per click, what conversion rate do I need? </task> <situation> [your average order value, gross margin, and the real cost per click in your market] </situation> <instructions> Work backwards to the conversion rate required to break even at that cost per click, then to the rate required for a target profit margin I specify. Compare both against my current rate and state the gap plainly. If the required rate is implausibly high, say so directly and identify which lever, price, margin, or cost per click, would have to move instead. Show the arithmetic at each step. </instructions>

<task> Build a tool showing how long it takes to earn back customer acquisition cost. </task> <inputs_needed> Cost to acquire a customer, average order value, gross margin, purchase frequency, and monthly churn rate. </inputs_needed> <instructions> One self-contained HTML file, live recalculation. Show the payback period in months, the proportion of customers still active at that point given the churn rate, and the effective payback once churn is accounted for. Make the point clearly when churn means a meaningful share of customers never pay back their acquisition cost at all, because that is the case this model exists to catch. </instructions>

<task> This channel was profitable and is not any more. Work out what changed. </task> <before_and_after> [spend, cost per click, conversion rate, average order value and orders, for both periods] </before_and_after> <instructions> Decompose the change and attribute it: how much came from rising cost per click, how much from falling conversion, how much from a change in order value, and how much from mix. Show each contribution as a number, not a narrative. Then identify which of these I can actually influence and which are market conditions I have to accept or exit. Be clear about which the data cannot separate. </instructions>

<context> Build me a single self-contained HTML file I can open in any browser. Everything must be in one file: HTML, CSS and JavaScript. No build step, no frameworks, no external requests of any kind. </context> <tool> Name: Copy Tightener What it does: Cuts padding from a block of copy and shows how much shorter it got. </tool> <inputs> - A large text area for pasting copy </inputs> <logic> - Replace wordy phrases with short equivalents: "in order to" becomes "to", "due to the fact that" becomes "because", "are able to" becomes "can", "on a regular basis" becomes "regularly", "in the event that" becomes "if", "for the purpose of" becomes "for", "a large number of" becomes "many" - Remove filler words: very, really, just, basically, actually, literally, quite, simply, essentially, totally, definitely - Collapse the resulting double spaces and fix spacing before punctuation - Recapitalise the first letter of each sentence after edits - Count words before and after and calculate the percentage reduction </logic> <output> - Headline: the percentage reduction and the before and after word counts - Below it: the tightened copy, selectable for copying - Handle an empty input with a prompt rather than an error </output> <interface_rules> - Recalculate live as I type. No calculate button. - Sensible default values already filled in, so it does something useful the moment it opens. - The headline result should be large and immediately readable, with the supporting detail underneath. - Clean and calm. Generous spacing, one accent colour, readable at a glance on a phone. - Never show NaN, Infinity, or a blank result. Handle zero and empty inputs gracefully with a helpful message. - Format currency and percentages properly, and never imply more precision than the inputs justify. </interface_rules> <constraints> - One file. No CDN links, no fonts loaded from the internet, no analytics. - Comment the calculation logic so I can change the assumptions myself. - Do not invent benchmark figures or industry averages. If a comparison would need one, let me enter it. </constraints>

<task> Extend my copy tightener to show exactly what it changed. </task> <current_tool> [paste your tool] </current_tool> <instructions> Add a side-by-side view with the original on the left and the tightened version on the right, with removed text struck through and replacements highlighted. Keep the word counts and percentage. Add a toggle to accept or reject each individual change rather than only all or nothing. Keep it in one self-contained HTML file. </instructions>

<task> Build a tool that assesses how hard my writing is to read. </task> <instructions> One self-contained HTML file with live recalculation as I type. Report: average sentence length, the longest sentence with it quoted, the proportion of sentences over 25 words, passive-voice constructions found and quoted, and paragraph lengths. Do not reduce it to a single grade-level score, since those are widely misused. Instead highlight the specific sentences to fix, ranked by how much they hurt readability. </instructions>

<task> Cut this to a strict word count without losing the argument. </task> <copy> [paste your copy] </copy> <limit> [the maximum word count] </limit> <instructions> Return the cut version at or under the limit. Then list what you removed, grouped by reason: redundant, unsupported, tangential, or padding. Flag anything you cut that you think was actually load-bearing, so I can put it back. If hitting the limit requires losing something genuinely necessary, say so rather than quietly cutting it. </instructions>

<task> Find every place I am hedging and show me the direct version. </task> <copy> [paste your copy] </copy> <instructions> Identify hedges: might, could, perhaps, somewhat, it seems, arguably, in some cases, I think, sort of, and similar. Quote each one in context and give the direct version. Then tell me which hedges are actually justified because the underlying claim genuinely is uncertain, since removing those would make the writing dishonest rather than stronger. Separate the two lists clearly. </instructions>

<task> Restructure this so someone skimming on a phone still gets the point. </task> <copy> [paste your copy] </copy> <context> [where it will be read and what the reader needs to take away] </context> <instructions> Restructure so the main point survives skimming: front-load the conclusion, break long paragraphs, add subheadings that state takeaways rather than topics, and pull key numbers onto their own lines. Do not shorten it unless shortening also improves it. Then show me the skim path, meaning only the text a skimmer would actually read, so I can check it still makes sense on its own. </instructions>

<context> Build me a single self-contained HTML file I can open in any browser. Everything must be in one file: HTML, CSS and JavaScript. No build step, no frameworks, no external requests of any kind. </context> <tool> Name: Offer Builder What it does: Turns a flat feature list into offer-framed copy aimed at a specific audience. </tool> <inputs> - Who it is for - The result they want - A list of features, one per line </inputs> <logic> - Compose a positioning line combining the audience and the result, framed as achieving it without an obvious cost or disruption - For each feature, generate a benefit line that connects the feature to a consequence the reader cares about - Generate a suggested headline built from the audience, the result, and the number of features supplied - Handle an empty feature list by prompting rather than producing empty output </logic> <output> - Headline: a label indicating the offer has been reframed - The positioning line - Each feature paired with its benefit framing - A suggested headline to test </output> <interface_rules> - Recalculate live as I type. No calculate button. - Sensible default values already filled in, so it does something useful the moment it opens. - The headline result should be large and immediately readable, with the supporting detail underneath. - Clean and calm. Generous spacing, one accent colour, readable at a glance on a phone. - Never show NaN, Infinity, or a blank result. Handle zero and empty inputs gracefully with a helpful message. - Format currency and percentages properly, and never imply more precision than the inputs justify. </interface_rules> <constraints> - One file. No CDN links, no fonts loaded from the internet, no analytics. - Comment the calculation logic so I can change the assumptions myself. - Do not invent benchmark figures or industry averages. If a comparison would need one, let me enter it. </constraints>

<task> Attack this offer and tell me where it is weak. </task> <offer> [the audience, the promise, what is included, and the price] </offer> <instructions> Identify: whether the promise is specific enough to be believed, whether the price is anchored against anything meaningful, what proof is missing, which included item adds cost without adding perceived value, and the most likely reason someone who wants this still does not buy. Be direct about whether the offer is actually differentiated or just competently described. If it is undifferentiated, say so. </instructions>

<task> Design a guarantee that removes the real reason people hesitate. </task> <offer> [what you sell, the price, and who buys it] </offer> <hesitations> [what you know about why people do not buy] </hesitations> <instructions> Propose two or three risk-reversal options addressing the specific hesitation rather than a generic money-back guarantee. For each, state what it costs me if abused, roughly how often that is likely, and how to word it so it is reassuring rather than legalistic. Recommend one. Flag any option that would attract the wrong customers, because a guarantee that fixes conversion and wrecks refunds is not a win. </instructions>

<task> Design a sequence of offers rather than a single one. </task> <current_offer> [what you sell now and at what price] </current_offer> <audience> [who they are and where they are in their journey] </audience> <instructions> Design a ladder: an entry offer, the core offer, and a higher-value offer. For each, specify who it is for, the outcome it delivers, the price, and the natural reason someone moves up to the next rung. Ensure each rung is genuinely valuable on its own rather than a deliberately crippled version of the next one. Flag any rung that would cannibalise the one above it. </instructions>

<task> Give me name options for this offer. </task> <offer> [what it is, who it is for, and the outcome] </offer> <instructions> Give ten name options across genuinely different approaches: descriptive, outcome-led, metaphorical, category-defining, and plain. Label each with its approach and a one-line note on what it signals and what it risks. Then recommend two, and say which one is safer and which has more upside. Avoid anything that requires explanation to make sense. </instructions>

<task> Turn this offer structure into a full page. </task> <offer_structure> [paste the output from the offer builder or your own structure] </offer_structure> <proof> [any real results, testimonials or specifics you can use] </proof> <instructions> Write the full page: headline, subhead, the problem framed in the reader's terms, the offer, what is included with each item framed as an outcome, proof, risk reversal, pricing, objection handling, and a single clear call to action. Use only the proof I gave you and mark clearly anywhere the page needs proof I have not supplied. No invented testimonials or statistics, and no em dashes. </instructions>