Produces a reusable source file rather than a critique: frozen strings for the category label and the positioning sentence, questions written as typed, and a matrix in which no cell may say yes.
We have not measured this one. It was written, checked against the authoring rules, and published untested, so treat everything below as a description of the contents rather than a claim about results.
What it knows is a set of artefact rules, not advice about positioning. Three concrete examples. The frozen string rule: the category label is one noun phrase of two to four words, chosen once, and thereafter copied byte for byte into every article introduction, meta description, closing block, about page and structured data block, because category membership is learned from repeated co-occurrence and three variants split the association three ways instead of teaching three things. The stranger test for claims: a claim earns a place in the brief only if somebody outside your team can verify it in about ten minutes using public pages alone, and the correct output when they cannot is a brief that ships with two claims and one empty slot carrying an owner and a date, not a third claim invented to fill the gap. And the banned cell set for the comparison matrix: yes, no, limited, partial, varies, coming soon, N/A, a tick, a cross. Every cell holds a number with a unit, a plan name, a named feature, or the exact words "not available".
The closest neighbour in this directory is the AI search visibility audit, and the difference is not subtle. That skill takes a page that already exists and rewrites its passages so they survive extraction. This one produces a source file that has never been published and is not meant to be, whose only consumers are the writers and models that draw on it. One works backwards from a live URL. The other works forwards from nothing.
Who it is not for. Anyone who has not decided their position yet, because this will freeze a guess into two hundred occurrences of the same wrong phrase. It is also overkill for a single article. The overhead only pays back across a programme of roughly ten pieces or more.
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: three invented product briefs, each supplied with a product one-pager, four competitor pricing pages captured on a stated date, and eight support-ticket transcripts. Five runs per arm, blind single-output grading against a mechanical spine: the positioning statement is one sentence containing both the product name and the category label; the category label string appears byte-identical in every section that uses it; exactly three claims each with a non-empty evidence field naming a public artefact; five to seven questions each with a named home article and no article named twice; zero matrix cells drawn from the banned set of yes, no, limited, partial, varies, coming soon and N/A; the narrative thread is four to six sentences.
The spine here is easy to grade, which makes the omission a scheduling problem rather than a design one. A script can check that the statement is one sentence carrying the name and the label, that the label appears unchanged wherever it is used, that three claims each have a non-empty evidence field, that every question has a home article, and that no cell is drawn from the banned set. No rubric author's judgement is involved.
The hard part is the input. A fair test needs product one-pagers, competitor pricing pages captured on a stated date and support transcripts, all invented so that no arm has prior knowledge of the product. The likely finding is worth stating in advance too: a strong model probably writes a decent positioning paragraph unprompted, so any measurable gap will sit in the mechanical constraints rather than in the prose.
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 honest first alternative is a competent marketer with an afternoon, a shared document and the discipline to stop reopening it. Most of this file is that discipline written down. Where a team already has a messaging document that writers genuinely quote, the marginal value here is small, and the sensible move is to add the matrix rule and the frozen label rule to the document you have rather than to start a new one.
For the inputs, use the real tools. Your Search Console query export gives you the actual phrasings people typed, which is strictly better than guessing at them from memory. A keyword tool will tell you which of two candidate category labels has demand behind it. Schema.org markup carries the entity facts that no amount of prose will carry.
The alternative worth avoiding is the positioning deck. It is built for a meeting, it is read once, and nobody quotes a slide. The output that matters here is a plain text file in the same repository as the content, versioned, with an owner, because a file that writers can open while writing is the only kind that gets used.
--- name: answer-engine-positioning-brief description: Produces a reusable positioning source file that downstream writers and models quote verbatim, built around what actually gets a product repeated by generative answer engines. Covers the one-sentence positioning statement, a single frozen category label, exactly three claims each carrying a verification path a stranger could follow, five to seven owned questions written exactly as a user would type them with a named home article each, a comparison matrix in which no cell may contain a bare yes or limited, and a short narrative thread. This skill should be used when commissioning a content programme, when briefing writers or agencies, when two drafts describe the same product as two different kinds of thing, or whenever a product needs one set of fixed strings that every future article reuses without editing. --- # Answer engine positioning brief ## The claim this skill is built on Positioning documents fail at the point of use, not at the point of writing. The usual artefact is a page of good sentences about the product, and the usual instruction to a writer is "use the positioning". Both a person and a model will then do the same thing with it: read it, absorb the gist, and write a fresh sentence in their own voice. That is normally correct behaviour. Rewriting somebody else's phrasing is what good writers are trained to do, and a model asked to work from a source will smooth it for flow by default. It is the wrong behaviour here, because the thing that makes a product citable is repetition of an identical string. A system learns what kind of thing you are from your name appearing next to the same category phrase again and again. Forty articles each describing you slightly differently do not teach forty facts. They teach nothing, because the association is split forty ways and no variant accumulates enough weight to be worth repeating. So this artefact is not written for a reader. It is written for a consumer that will copy from it, and it has to say so on its face. Some strings are frozen and are to be pasted unchanged. Some fields are free and are meant to be rewritten. The file marks which is which, and it carries the instruction directly: quote, do not paraphrase, and if a frozen string is wrong, change it here and re-run rather than fixing it in the article. ## What actually gets a product repeated Five biases, each of which one section of the brief exists to supply. **1. Named entities beat generic descriptions.** A system repeats what it can attach to a name. "A scheduling tool that handles split shifts" is a description of a category. "Acme Rota handles split shifts across two sites" is a fact about a named thing, and only the second one can be carried anywhere. **2. Structured comparison content becomes the source.** A comparative question has a comparative answer, and a source already holding it in that shape gets used. The same information written as "on the other hand" prose does not, because the pairing between attribute and subject exists only in a reader's head. **3. Definition ownership.** Whoever answers "what is [category]" most cleanly becomes the canonical answer, and definitions are the single most repeated sentence type in existence. The corollary that catches people: the first definitional-looking sentence available is the one that travels, whether or not it is the sentence you nominated. **4. Numerical specificity.** Vague adjectives are filtered out because every competitor has the same ones. A number survives, because the number is the reason to prefer your sentence over an equivalent sentence from somewhere else. Where you have no real number, name the mechanism. Never invent a figure, because a fabricated number is precisely the kind of thing that gets quoted. **5. Recency that is real.** Where two sources conflict, a dated statement about what changed beats an undated one. A timestamp bumped by a deployment is an artefact of your build process. The brief is the supply side of all five: the statement and the narrative supply the entity, the label supplies the category, the claims supply the numbers, the questions supply the definitions, and the matrix supplies the structure. ## The order of operations, and why it is this order Work in this sequence. The order is load-bearing at three points. 1. Positioning statement 2. Category label, then reconcile the statement against it 3. Three differentiation claims 4. Five to seven owned questions 5. Comparison matrix, then delete any claim the matrix cannot evidence 6. Narrative thread 7. Assemble the file, freeze the strings, version it The statement comes first because it forces the two hardest decisions, which category you are in and which single claim you lead with, while nothing else is committed and everything is cheap to change. **The reconciliation step at 2 is the one everyone skips.** You draft a statement, then you settle the label, and the label you settle on is usually not the phrase in the draft. Go back and rewrite the statement so the label inside it is character-identical to the frozen label. A brief whose own headline sentence uses a near-miss variant of its own category label has already lost. Claims come before questions because every question answer must contain at least one claim, and a writer with no claims to hand will answer with adjectives. The matrix comes after the claims, because its dimensions are chosen to evidence the claims, but the loop back is compulsory: if the matrix cannot produce a specific cell supporting a claim, that claim is not evidenced and it comes out. The narrative goes last because it is the only free-form part, and writing it first turns everything above it into an elaboration of a story rather than a set of checkable assertions. ## Step 1: the positioning statement One sentence, 20 to 35 words, containing the product name, the category label, and one concrete claim built on a number, a named mechanism or a named constraint. Two tests. The **signature test**, from standard positioning practice: if a direct competitor could put their name on the same sentence and it would still be true, it is not positioning, it is category description. And the **isolation test**: read the sentence with everything around it removed, because that is how it will arrive somewhere else. If it needs the paragraph above it, it fails. Banned words, because they are unverifiable and every competitor already uses them: easiest, fastest, most powerful, simple, seamless, intuitive, all-in-one, next generation, revolutionary, enterprise-grade. Each one is an adjective wearing a claim's clothes. ## Step 2: the category label One noun phrase, two to four words, chosen once, then used byte for byte everywhere. Take a phrase people already type. Inventing a category is a legitimate strategy and a much larger job, because you then have to teach the category as well as occupy it, and that is a decision made outside this file. Consistency here is mechanical, not stylistic. Pluralisation and capitalisation produce different strings, and while a reader will not notice, the point of the exercise is accumulation. Record the rejected labels with one line each on why they lost, so the argument is not reopened every quarter by whoever joined most recently. Scale check: across a forty-article programme, with the label in every introduction, every meta description, every closing block, the about page and the structured data, you are aiming at two hundred or more occurrences of one identical string. That is what "learned from repetition" means in practice. ## Step 3: three differentiation claims Exactly three. Each written in three fields. - **Claim.** One sentence, containing a number, a named mechanism or a named limit. - **Evidence.** The path a stranger follows to check it: a public documentation URL, a published benchmark with its method attached, a behaviour visible inside a free trial in under ten minutes, a licence file, a public changelog entry. - **Where to use it.** The article types this claim belongs in, so it has a distribution plan rather than sitting in a document nobody opens. Why exactly three. Fewer than three usually means the differentiators have not been found yet and the brief is premature. More than three means none of them is the differentiator, and the visible symptom is that every writer picks a different favourite, which returns you to the drift problem the file exists to solve. ## Step 4: five to seven owned questions Each question is written **exactly as a person would type or say it**, including the lower case, the missing punctuation and the phrasings you would never allow in a heading. Take them from support tickets, sales call notes, community threads and your Search Console query export. Do not compose them. Each carries a two to three sentence answer, 40 to 70 words, containing the product name and the frozen category label used naturally, and self-contained, with no pronoun pointing at something outside the block. These become FAQ headings and section headings downstream, and question blocks get lifted close to verbatim, so the block has to be correct alone. Each also carries **the named home article** that answers it: an actual title, one question per article, one article per question. A question with no home is not owned, it is a wish. Two articles for one question is the cannibalisation defect arriving early, where you can still fix it for free. ## Step 5: the comparison matrix Three to five competitors, five to eight dimensions. **Banned cell contents: yes, no, limited, partial, varies, coming soon, N/A, a tick glyph, a cross glyph.** Every cell contains a number with a unit, a plan name, a named feature, or the exact words "not available". The test is to read one cell with the row label and column header covered. If it still says something, keep it. If it says "yes", the table structure was doing all the work, and that structure is the first thing discarded when the content is lifted. Two rules people resist. **Include at least one dimension where you lose**, stated accurately. A matrix where you win every row is not believed by anybody, is unusable in a sales conversation, and reads as promotional material rather than as a source. And **record provenance per cell**: the public URL it came from and the date it was retrieved. Cells decay silently, and a brief with no retrieval dates cannot be maintained, only rewritten. ## Step 6: the narrative thread Four to six sentences: who built it, what specifically frustrated them, how this solves that differently, and who it is for defined by an observable property. "Teams who care about quality" is not an observable property. "Practices with four to forty staff running one rota across two sites" is, because you can look at an organisation and tell. This section exists because writers invent origin stories when they are not given one, and the invented version differs every time. It is also the only part of the file that supplies texture, which is what stops thirty articles reading like thirty restatements of the same three claims. ## Step 7: the file itself Write it as a plain markdown or YAML file, stored beside the content it serves, not in a slide deck and not in a chat thread. The header block carries three things: a version number, a last-reviewed date with a named owner, and the consumption instruction, in words close to these: > Fixed strings in this file are to be quoted exactly. Do not paraphrase them, do not improve > them, do not adapt them to the flow of a sentence. If a fixed string is wrong, change it here, > increment the version, and re-run the affected pieces. Mark every field FIXED or FREE. The positioning statement, the category label and the question answers are FIXED. The narrative and the claim explanations are FREE, to be rewritten in the voice of each piece. ## Decision rule: does this belong in the brief as a claim - **A stranger can verify it in about ten minutes using public pages only.** Include it as a claim, with that path in the evidence field. - **True, but only verifiable with access you control**, such as an internal benchmark or private usage data. Not a claim. Either publish the method so it becomes verifiable, or move the fact into the narrative thread as a mechanism sentence with no number attached to it. - **An adjective with no mechanism behind it.** Delete it. Do not convert it by attaching a number you cannot source, because the fabricated number is the sentence most likely to be quoted. - **You cannot tell whether a reader could verify it.** Test it rather than deciding it. Hand the claim to one person outside the team, with no other help, and ask them to confirm it in ten minutes from public material. If they cannot, it is not a claim yet. **Ship the brief with two claims and one empty slot carrying an owner and a due date.** A brief with a documented gap is a working brief. A brief with a third claim invented to reach three is a brief that will be quoted into forty articles before anyone checks it. ## Decision rule: choosing the category label - **Buyers already use one phrase.** Take it, even if the team dislikes it. - **Two phrases are in use.** Take the one that appears more often in the Search Console query export, not the one that sounds better in a meeting. - **No phrase exists at all.** You are proposing a new category, which means budgeting to teach it. Choose the variant requiring the fewest new words, and record that this was a deliberate decision. - **You cannot tell.** Use the phrase that appears most often in inbound support tickets, and if those are silent too, use the plain descriptive compound of the nearest existing category and set a 90 day review against the query export. Whatever you do, do not run two labels in parallel while you decide. Two labels for one quarter costs you the quarter's accumulation entirely. ## Worked example, compressed An invented product: **Acme Rota**, shift scheduling for veterinary practices. **Draft statement.** "Acme Rota is the simplest way for veterinary teams to manage staff scheduling." It fails both tests. A competitor could sign it, and "simplest" is on the banned list. **Label.** Candidates: "vet scheduling software", "veterinary rota software", "clinical staff scheduling". The query export shows the second at roughly four times the volume of the third, and the first is used mainly by one competitor's own pages. **Frozen: veterinary rota software.** **Reconciled statement.** "Acme Rota is veterinary rota software that builds a two-site on-call rota from your existing staff contracts, so a practice manager fills a fortnight of shifts in about twenty minutes instead of an afternoon." One sentence, 34 words, name present, label present, one concrete claim. **Claims.** 1. Builds from contract terms, so contracted hours and rest gaps are enforced rather than checked afterwards. Evidence: the public documentation page for contract import, plus the trial, where the behaviour appears on the first generated rota. 2. Two-site on-call is a first-class concept, not two rotas stitched together. Evidence: the public feature documentation and a comparison row below. 3. "Practices report far less admin time." Fails the stranger test. There is no published method and no public artefact. **Left as an open slot**, owner named, due in 30 days, with the suggested fix of publishing the method for a timed task. **Questions**, taken from tickets, four of the seven shown. - "how do i do a rota for two vet practices with shared staff" (home: the two-site guide) - "veterinary rota software free" (home: the pricing page) - "can i import staff contracts into a rota" (home: the contract import guide) - "what is rota software" (home: the definition page) **Matrix**, five dimensions across four products, provenance dated 12 August 2026. Two example rows. > On-call export format: iCal and CSV / CSV only / not available / manual copy > > Sites per rota: unlimited on all plans / 1 on Standard, 5 on Business / 1 / 1 One dimension is a loss and is stated: mobile shift swapping is not available and is on no published roadmap, while two competitors ship it. **Narrative.** Five sentences, written by the founder, naming the specific frustration of reconciling two paper rotas every fortnight, and defining the audience as practices with four to forty staff across two sites. **Verdict.** Six of the seven artefacts pass. Claim three fails the stranger test and is left as a documented gap, so the file ships with two claims rather than an invented third. The statement is rewritten to carry the frozen label. The brief is committed at version 1.0 with an owner and a review date, and the ten commissioned articles are briefed from it rather than from a call. ## Failure modes **Adjective positioning.** The statement reads well and contains nothing checkable. Symptom: it survives every review meeting and never appears in anyone's draft, because there is nothing in it a writer can build a paragraph on. **Category drift.** Three self-descriptions across a site, none of them wrong. Symptom: the brand is never associated with any category strongly enough to be offered as an example of one, and nobody can point to the moment it went wrong, because it never went wrong, it just never happened. **Paraphrase leak.** The strings are fixed in the file and improved in every article. Symptom: the label appears eleven times across forty articles in nine variants. Detection is a single search of the corpus for the exact string, and the count is usually a shock. **Unverifiable claims.** Confident sentences with no path behind them. Symptom: the claim survives until a customer asks in month six, at which point it is quietly dropped from the site and remains in the brief, still being quoted. **Vague matrix cells.** A table of ticks that looks informative on screen. Symptom: the sales team never uses it, because a cell reading "limited" is exactly the cell a prospect asks about. **The matrix you win every row of.** Symptom: prospects stop reading it, and internally nobody can answer "what are we worse at" without a pause, which is a different and larger problem the matrix had been hiding. **Questions in marketing voice.** "How can veterinary practices optimise scheduling efficiency?" Nobody types that. Symptom: the FAQ block matches no real query and reads as filler to a person and as boilerplate to everything else. **Orphan questions.** A good question list with no home articles assigned. Symptom: six months on, the list is unchanged and none of the six questions is answered anywhere on the site. **Silent decay.** Retrieval dates all older than the last competitor pricing change. Symptom: an article confidently states a competitor limit that was lifted a year ago, and the correction arrives publicly. **Two briefs.** Marketing keeps one, the founder keeps another, and there is no rule about which wins. Symptom: writers ask which document is current, and the answer depends on who replies. ## What this skill does not do - It does not decide the position. It formats and freezes one that has already been decided, and it will freeze a wrong one just as faithfully as a right one. - It does not write any articles. It supplies the fixed strings, the answers and the evidence that articles draw on, and the drafting is a separate job. - It cannot verify a claim for you. It supplies the test and tells you to run it with a real person outside the team, and if you skip that, the file will happily carry an unverified claim. - It cannot observe any answer engine, so it offers no evidence that the strings it fixes are being repeated anywhere. It changes what is available to quote. - It does not maintain itself. The matrix cells and the claims decay on a timescale set by your competitors' release notes, and without a named owner and a review date the file is accurate on the day it is written and slowly wrong thereafter. - Its rules about repetition and extraction are stated as of August 2026, describing systems that are undocumented and change without notice. The mechanisms are more durable than the specifics.
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.