Produces a tool concept, a validated keyword cluster and a build specification, or a documented refusal, which is the more common outcome and an equally correct one.
We have not measured this one. It was written and checked against the authoring rules, then published untested, so read the following as a description of the contents rather than a claim about outcomes.
The knowledge in it is a placement heuristic and a refusal condition. The adjacency rule says the free tool sits one step upstream of, or directly beside, the paid product's core job, and it comes with a one-sentence test: you must be able to write "a person who needs this output will need the paid product's job within a stated period", in one hop, with a real period rather than "eventually". A publishing product gets a previewer, a delivery product gets a checker, a document product gets a generator. Two hops away and the traffic arrives and leaves.
The recommendation bar is four conditions with numbers attached, all four required: a twelve-month average cluster volume of at least 1,000 a month, no more than two working free tools in the top ten results, a weakest top-ten result whose referring domain count you could plausibly match, and one-hop intent. It also carries the arithmetic that most of these plans skip, which is that 1,000 sessions a month at a 2 to 5 percent click-through and a 1 to 5 percent trial rate produces between zero and three trials, so a tool justified only by trials needs roughly ten times that traffic before the sums work.
And it argues, at length and deliberately, that "drop it, the data does not support building this" is a correct and complete output, not a failure to produce a recommendation. A drop that names the failing condition and the numbers behind it saves the two weeks of engineering that the alternative spends.
Who it is not for. Teams with no engineering capacity at all, since the output is a build specification. And anyone who has already decided to build the tool, because the only thing this adds at that point is a specification they could write themselves.
Measuring one skill honestly costs about twenty model sessions: five runs with it, five without, on real material, each output graded alone by a session that is not told the other arm exists, against a rubric written by somebody who never saw the skill. We have not spent that on this one yet, so it ships labelled rather than ships silently.
How it would be measured. Tier A. Material: five invented product briefs, each paired with real keyword data pulled for its candidate clusters and a captured results page for the head term, where three of the five are built to fail the bar on volume, incumbency or intent distance. Five runs per arm, blind single-output grading on whether the output names a keyword cluster with a numeric monthly volume and a difficulty figure, names the domains currently ranking in the top ten, states an explicit path from tool user to paid product, and returns a drop naming the failing condition on the three that should fail.
The gradeable spine is clear: does the output name a cluster with a numeric volume, name the domains currently ranking, state a funnel path, and refuse on the cases built to fail. The obstacle is the material. A fair test needs five invented products paired with real keyword data and captured results pages, three chosen so the honest answer is no, and assembling that without signposting which is which takes care.
One specific worry is worth writing down first. The failure this skill prevents is enthusiasm, and enthusiasm may not be a defect the control shows when the data plainly does not support a build. If the control refuses just as readily on the three failing cases, the measurable value collapses to the placement heuristic and the specification format.
The rule that decides pass or fail was written down before any run was executed and it does not move afterwards. It is in the method note on the hub, along with the full results table including every skill that was tested and cut.
Stated plainly, because a skill that claims everything is useful for nothing.
name and description in the file's frontmatter, so you can also invoke it by name.The strongest alternative is a keyword tool and an hour of somebody's attention. Google Keyword Planner gives you volume, Google Trends tells you whether the interest is seasonal or dying, and opening the results page in a private window and reading the top ten tells you most of what any difficulty score is approximating. Someone experienced does all of that in an afternoon and reaches the same verdict.
Where this differs is the ordering and the refusal. The common failure is not an inability to read a keyword tool, it is that the tool gets opened after the decision to build, at which point the numbers become supporting material rather than a gate.
A genuine alternative for a well-resourced team is to skip validation and build the tool because it is useful to customers regardless of search. That is a legitimate product decision and it should be made explicitly, with the acquisition argument dropped rather than quietly assumed. The version to avoid is the one that claims both, builds on intuition, and reports search traffic as the justification afterwards.
--- name: free-tool-seo-play description: Finds, validates and specifies a free satellite utility that ranks for phrases the paid product's buyers already search, then routes those users towards the paid product. Covers the adjacency heuristic for placing the tool one step upstream of the core job, the four-condition recommendation bar with real volume and incumbency thresholds, the arithmetic that shows how much traffic a tool actually needs, the fixed hand-back package, and the build specification down to the no-signup-on-first-use rule. It treats a documented drop as a correct output. This skill should be used when planning content or growth work, when deciding what to build with a short engineering window, or when somebody proposes a free tool and nobody has checked whether anyone searches for it. --- # Free tool SEO play ## The claim this skill is built on Two failures produce almost every free tool that never works, and they are opposites. The first is that the play never comes up at all. Asked for a growth or content plan, the default answer is more articles, because articles are what content plans contain. A working utility that answers a query directly is frequently the better asset for the same effort, and it does not get proposed because nobody is in the habit of proposing it. The second is that it comes up as a hunch. Somebody suggests a calculator, everybody likes it, and it is built. Nobody expands the phrase into its real cluster, nobody pulls a volume figure, and nobody opens the results page to see that four established free tools already occupy it. The tool ships, ranks eleventh, and is quietly unmaintained a year later. So the discipline is: raise it deliberately, then try to kill it with data before anyone writes a line of code. **The most common correct output of this skill is a drop, and a drop that names the failing condition and the numbers behind it is a finished piece of work.** It is worth more than a plausible recommendation, because it returns the two weeks of engineering intact. ## Step 1: raise the play deliberately Whenever the work is growth, launch, positioning or content strategy, ask the question unprompted, before proposing anything else: is there a free utility adjacent to this product's core job that could be hosted on the main domain and ranked? Ask it even when the brief says "content plan". The brief is describing a format, not an outcome. ## Step 2: place the candidate by adjacency **The tool sits one step upstream of, or directly beside, the paid product's core value.** Never downstream, and never inside it. Generalisations, to be adapted rather than copied: - A product that **publishes** something gets a **previewer or tester**: show the person what their thing will look like, or whether it is valid, before they have anywhere to publish it. - A product that **delivers** something gets a **checker or scorer**: tell them whether the thing they already have will arrive, pass, or fail. - A product that **produces documents** gets a **generator**: hand them one correct instance of the document, free, for the single case. - A product that **manages a recurring process** gets a **calculator**: do the one-off arithmetic people currently do in a spreadsheet. - A product that **connects two systems** gets a **converter**: turn one format into the other, once, without an account. **The one-hop test.** Write this sentence and fill both blanks with something specific: "A person who needs [the tool's output] will need [the paid product's job] within [a stated period]." If the sentence needs two hops, or the period comes out as "eventually", the traffic will arrive and leave. That is the second-most common way this play fails and it is entirely predictable in advance. **Downstream is the trap.** A tool that does part of what the product is paid for is not a satellite, it is a free tier with no upgrade path, and it competes with your own entry plan. If the candidate cannibalises the cheapest paid tier, the decision belongs to product and pricing, not to a content plan. ## Step 3: validate with real data, before recommending anything Four pulls, in this order. The order matters because each one can kill the candidate and they are in increasing order of effort. 1. **Expand the seed phrase into its cluster.** The head term is rarely where the volume or the intent lives. Collect the head phrase, the "free" variants, the "how to" variants, the "vs" and "alternative" variants, and the format variants. Ten to forty phrases is a normal cluster. 2. **Pull twelve-month monthly volumes for the whole cluster**, not the head term alone. Sum them, and check seasonality while you have the series: if one month contributes more than about 40 percent of the annual total, the average is describing a spike, and the tool will be idle for nine months of the year. 3. **Score difficulty**, understanding what the score is. Every difficulty figure is a model of an average site's chances, not yours. Use it to rank candidates against each other and never as a pass mark on its own. 4. **Read the actual results page for the head term.** This is the step people skip, and it is the one that decides most drops. Count how many of the top ten are working free tools. Note the referring domain count of the weakest result that is not a tool. Note whether any ordinary article still ranks, which tells you whether the engine has settled on a tool-only page for this query. Record the date of every pull. Volumes and results pages both move, and a recommendation with no date on it cannot be revisited, only redone. ## Step 4: the recommendation bar Four conditions. **All four must hold.** Three out of four is a drop, not a compromise. **Condition 1, volume.** A twelve-month average of at least **1,000 combined monthly searches** across the cluster. Between 300 and 1,000, recommend only if the tool doubles as a sales asset that the team would use in conversations anyway. Below 300, drop, whatever else is true. **Condition 2, openness.** At most **two working free tools in the top ten**, and at least one ordinary article still ranking. Three to five tools means the page is contested and you need a wedge, usually a narrower and better-served variant of the query. Six or more is locked, and locked pages are where good engineering goes to rank fourteenth. **Condition 3, reachability.** The weakest top-ten result must sit on a domain you could plausibly match. The blunt proxy: **if the weakest top-ten result has more referring domains than your entire site**, treat the page as locked regardless of the difficulty score. **Condition 4, intent proximity.** The one-hop sentence from Step 2, written out and legible. **Then do the arithmetic, before recommending.** Take the honest planning assumptions, and mark them as assumptions: a well-placed contextual link from a tool result to a product page converts in the region of **2 to 5 percent**, and a product page to a trial or signup in the region of **1 to 5 percent**. A tool at 1,000 sessions a month therefore produces something between **zero and three** trials a month. That is the number the plan has to be defensible at. The conclusion follows directly and is the most useful sentence in this file: **if the only justification offered is trials, the volume bar is not 1,000, it is closer to 10,000.** Below that, the tool has to be justified by the second-order returns, and those should be named explicitly in the recommendation: referring domains earned by a working tool at a rate ordinary posts do not reach, internal links pointing at the pages that sell something, use in sales conversations, and a page with a genuine chance of being cited as an answer. ## The decision rule - **All four conditions hold.** Recommend the build, and hand back the full package from Step 5. - **Volume is there and the page is locked.** Drop the head term. Before dropping the candidate entirely, look once for the underspecified variant, the narrower query where the incumbents are giving a generic answer. If there is no such variant, drop and say why. - **Volume is thin but intent is perfect.** Build only if it doubles as a sales asset, and state in the recommendation that the search case did not carry it. Do not restate a sales asset as an acquisition channel. - **Intent is two hops away.** Drop, regardless of volume. This is the case where the numbers look best and the outcome is worst, because you will get the traffic and it will not convert, and the tool will be judged a success for two quarters on sessions alone. - **You cannot tell.** The keyword tool returns no data, or the category is genuinely new and the phrase has no history. Do not guess in either direction. Run the cheap proxies: does autocomplete offer the phrase, does any free tool rank for it at all, are there community threads asking for exactly this, is anybody bidding on the phrase in paid search, which is a demand signal even at low volume. If two or more proxies fire, treat it as the thin-volume branch. If they are all silent, **return "cannot validate" as the output**, naming what data was missing and what would settle it. That is a legitimate third answer and it beats both a guess and a shrug. ## A drop is a finished piece of work State it in the write-up in those terms, because a recommendation of no is routinely received as no recommendation. A drop should contain the candidate, the cluster, the numbers pulled and the date pulled, the condition that failed and by how far, and one sentence on what would change the answer. "Cluster averages 240 a month over twelve months, against a bar of 1,000, and seven of the top ten results are established free tools with referring domain counts in the thousands. Drop. This changes only if the category grows or the product moves closer to that query." That paragraph is the deliverable. It ends the discussion, it is checkable in a year, and it is the reason the engineering time went somewhere else. ## Step 5: the hand-back package Five parts, fixed, in this order: 1. **The tool concept.** One sentence: the single input, the single output. 2. **The target keyword cluster**, listed with per-phrase twelve-month monthly volumes and the date they were pulled. 3. **The difficulty figure**, with the provider named, since these numbers are not comparable across providers. 4. **Who currently ranks**, listing the top ten domains and marking which are working tools. 5. **The funnel path**, written explicitly: what the user has just done, what they are shown next, which page they land on, and what that page asks of them. If any of the five is missing the package is not finished, and in particular a recommendation with no funnel path is a request for traffic rather than a plan. ## Step 6: delegate the pulls, keep the verdict Raw keyword exports and full results pages are large and mostly irrelevant to the decision. Push those pulls out to a separate process or a subagent and have it return only the summarised figures: cluster total, per-phrase volumes for the top ten phrases, difficulty, the ranking domains, and the tool count. This is not tidiness. A working context filled with raw rows degrades every subsequent judgement in the same session, and the numbers that matter fit in a short table. ## Step 7: the moat argument, in the write-up Include it, because it is the part that survives the meeting. A working tool is harder to copy than an article. An article can be matched in an afternoon by anybody with a writer. A tool has to be specified, built, hosted and kept working, which is a different order of commitment, and most competitors will not make it. It also demonstrates competence rather than asserting it: somebody who has just watched your tool do a fiddly job correctly has evidence about your engineering that no landing page provides. ## Step 8: specify the build The specification is the deliverable, so make it complete enough to hand to an engineer with no further conversation. **The single input and the single output.** One of each. Every additional field halves completion. If the tool needs three inputs, two of them should have defaults that are correct for the common case. **What it must not ask for.** No account, no signup, no email before the result is shown. This is a ranking decision and not a generosity decision, for three reasons. A person who meets a wall returns to the results page immediately, which is the behaviour the ranking is built to detect. Nobody links to or reviews a tool whose output they cannot see, and links are where most of the return lives. And the free alternative is one click away, always. Ask for the email **after** the result is on screen, in exchange for saving, exporting or sharing it. That trade converts and costs nothing. **Where it lives.** A subdirectory on the main domain, /tools/[name]/, not a subdomain and not a separate domain. The links the tool earns are the return, and you want them arriving at the domain that sells the product. **Crawlable text.** A widget rendered entirely in the browser gives a crawler nothing to index. Server-render 300 to 600 words of genuine explanation beneath the tool: what it does, how to read the output, and the two or three edge cases people get wrong. That copy is also the only part of the page with any chance of being quoted by an answer engine. **Title and description** built on the validated head phrase, with the phrase in the H1 as well, because the page has one job. **One contextual link to the paid product**, placed after the result, phrased as the next job rather than as an advertisement. "This checked one file. The paid product watches the folder and tells you when one breaks." **Input handling across platforms.** If the tool accepts a file or pasted text, accept both LF and CRLF line endings and both UTF-8 and legacy Windows-1252 encodings, and normalise on the way in. A spreadsheet exported on Windows and one exported on a Mac differ on both counts, and a tool that fails on half of its visitors' exports produces exactly the bounce the whole exercise was designed to avoid. Test the tool in a browser on both operating systems before it ships. **An owner and a review date**, because a broken tool that still ranks is worse than no tool. ## Worked example, compressed An invented product: **a subscription billing service for small software teams**. The brief asks for a content plan. The play is raised at the start instead. **Three candidates by adjacency.** - A: an **invoice number format generator**. Upstream, one hop. - B: a **proration calculator**, working out what a customer is charged when they change plan mid-cycle. Adjacent, one hop. - C: a **sales tax rate lookup**. Adjacent, but the hop to billing is loose. **Data, pulled on the same date and recorded.** - A: cluster of 11 phrases, twelve-month average **110 a month**. Fails Condition 1 outright. Dropped in one line. - C: cluster of 26 phrases, twelve-month average **18,000 a month**. Results page holds **eight working free tools**, all on tax software domains, the weakest of which has more referring domains than the whole product site. Fails Conditions 2 and 3. The underspecified-variant check finds nothing narrow enough. Dropped, with the numbers. - B: cluster of 14 phrases, twelve-month average **2,400 a month**, no month above 14 percent of the annual total. Results page holds **one working tool**, four ordinary articles and three documentation pages, and the weakest top-ten result has 34 referring domains. One-hop sentence: "A person calculating a proration by hand is running a subscription business and will need billing software within a quarter." Passes all four. **Arithmetic, stated in the write-up.** 2,400 sessions a month, at 2 to 5 percent through to the product page and 1 to 5 percent to a trial, gives roughly **one to six trials a month** at the optimistic end and closer to one at the realistic end. The recommendation therefore rests on the links and the sales use, and says so rather than promising a pipeline. **Specification.** Input: current plan price, new plan price, days remaining in the cycle. Output: the prorated charge with the arithmetic shown line by line. No account, no email until the user asks to copy the result to a shareable link. Hosted at /tools/proration-calculator/. Five hundred words underneath on the two rules teams get wrong. One link after the result, to the billing product's mid-cycle change documentation. **Verdict.** Two of three candidates dropped with the failing conditions named and dated. One recommended with a cluster of 2,400 a month, a difficulty figure from a named provider, ten ranking domains listed, an explicit funnel path, and a build estimated at four engineering days. The dropped pair is the more valuable half of the output, because C is the one the room wanted. ## Failure modes **The hunch tool.** Built because it sounded good in a meeting. Symptom: nobody in the project can say what the target phrase was, and the analytics show single-digit organic sessions a month, six months in. **Two hops away.** Symptom: the tool ranks, traffic is healthy, and the trial numbers are unchanged. It is usually defended for two quarters on sessions alone, because sessions are the metric that looks fine. **The locked page.** Symptom: a well-built tool sitting at position eleven to twenty for a year, with everybody suggesting more backlinks, when the results page was full before it was written. **The default to prose.** Symptom: three consecutive quarterly plans made of articles, while a competitor's calculator quietly ranks first for the phrase your buyers use most. **Context flooding.** Symptom: raw keyword exports and full page dumps pasted into the working session, after which the recommendation drifts and starts citing phrases nobody selected. **Traffic with no funnel.** Symptom: a popular tool with no link to the product, or a link in the footer that nobody clicks, reported as a marketing success on sessions. **The email wall.** Symptom: rankings that fall in the weeks after the gate is added, a bounce rate that climbs, and zero new referring domains, because reviewers cannot see the output they would be reviewing. **The invisible page.** A tool rendered entirely in the browser with no server-rendered text. Symptom: it works perfectly for humans and has nothing indexed except the title. **The orphan subdomain.** Shipped on tools.example.com or on its own domain. Symptom: the links accumulate on a property that sells nothing and the main site's rankings never move. **Tool rot.** An API changes, a rate table goes stale, the output becomes quietly wrong. Symptom: a tool that still ranks and now damages trust on every visit, discovered through a support ticket. **Scope creep.** The three-day tool acquires accounts, saved history and a dashboard. Symptom: the paid roadmap slips a month and the free tool is now a product with no revenue. **Cannibalising the entry tier.** Symptom: cheapest-plan signups fall while tool usage rises, and the tool is reported as a win in one meeting and a mystery in another. ## What this skill does not do - It does not pull search data. It states which numbers are required and what to do with them, and without a keyword tool and a results page it can only return cannot validate. - It does not build the tool. The output is a specification of roughly two to fifteen engineering days, and that cost is exactly what the bar exists to justify. - It cannot judge whether your domain can rank. The referring domain proxy is crude, and a proper answer needs your own Search Console history and a backlink tool. - It does not predict revenue. It gives you the arithmetic and honest planning ranges, and if your own conversion rates are unknown the output is a range too wide to plan against. - It has no view of maintenance capacity, which is the reason most of these tools eventually become liabilities rather than assets. - Its thresholds are defaults chosen for a small site in August 2026, not laws. Move them deliberately, in writing, with the reason recorded, or they stop being a bar at all.
These skills all ask your assistant to check things against your actual codebase, your actual schema, your actual design system. Locul keeps that context current on its own, from the files you already have, on your machine. Mac and Windows, free to start.