Produces the map rather than the schedule: one greppable pillar declaration per cluster, a closure pre-flight that stops the run, posture and saturation labels, and per-row ownership walls.
Untested. What follows describes what is inside the file, not how it performed.
Everybody can draw a hub and spoke diagram. The gap between a diagram and a working topology is where content programmes lose months, and the file is built around three specific rules rather than around the picture.
The first is that the pillar declaration must use one literal, greppable form, the same in every cluster. This sounds like formatting pedantry and it is not. A pillar declared in prose cannot be extracted, so the link check that was supposed to verify pillar targets cannot run, so it reports nothing, and nothing reads as compliance. In one review of ten properties, exactly one used a consistent declaration format, which meant the check had never actually run on the other nine and every report from them had been silence misread as health.
The second is the hub-slug publishing rule. A cluster's flagship article publishes at the hub slug, meaning the value its children name as their parent, not at the slugified version of its own long title. Get this wrong and the flagship exists, ranks, looks fine, and every child link points at a slug that will never be created.
The third is a closure pre-flight that stops the run. Before a word is written, every link target and every parent value is resolved against the union of three sets: slugs the queued rows will create, the published index, and approved non-article pages. An unresolvable target halts the plan rather than producing a warning nobody reads.
Who this is not for. A site with one subject and twelve pages does not need a topology file. This starts paying when more than one person writes, when a cluster has more than about eight members, or when a sibling property covers overlapping ground.
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 but fully specified products, each with a 50-keyword portfolio and a published index of about 40 live slugs, plus one deliberately awkward case where a sibling property already covers a third of the subject. Objective spine: every pillar declaration matches the literal declared form and is machine-extractable, every declared pillar slug resolves either to the published index or to a queued row, every internal link target in the map resolves to a slug something creates, no flagship row publishes at a slugified title rather than its hub slug, per-cluster share of the publishing window computable and inside the stated cap, and every cluster carries a posture label and a saturation value from the fixed vocabularies.
The spine is real but the fixture is heavy. Six of the checks are mechanical: whether each pillar declaration matches the declared literal form, whether each declared pillar slug resolves to something that exists or is queued, whether every link target resolves, whether any flagship row is scheduled at a title slug rather than its hub slug, whether each cluster carries a label from the fixed posture and saturation vocabularies, and whether the per-cluster share of a publishing window can be computed at all.
What makes a fair test expensive is that the interesting failure only appears with a published index that disagrees with the plan. A topology built against an empty site closes trivially, because every target is a queued row. The awkward cases need forty or so live slugs, two of them published under a slug the map does not expect, plus a sibling property covering a third of the same subject so the cross-property dedupe section has something to do.
The honest expectation is that a strong model produces a plausible cluster map unprompted. The delta sits in whether the output is parseable at all, and in whether closure is resolved before writing or discovered afterwards.
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.A whiteboard and an hour produces the same clusters. What it does not produce is a file a script can read, and that is the difference the whole skill is about: an unparseable map cannot be checked, and an unchecked map decays without anyone noticing.
If you pay for a keyword platform, let it draw the cluster boundaries from observed click behaviour rather than from anyone's mental model, then bring the clusters here for the closure rules, the caps and the ownership walls, which no keyword tool provides.
If the site is small enough that one person holds it in their head, the honest answer is to skip this and keep a list. The overhead of posture labels and saturation values on a four-cluster site exceeds what they buy.
And if the map claims anything is already live, verify it with a crawler in list mode before trusting a single line of it. A topology that has never been fired at a real server is a set of intentions.
--- name: cluster-topology-blueprint description: Produces a pillar and cluster topology as a machine-parseable specification: one literal greppable pillar declaration per cluster, existing and planned supporting articles, posture and saturation labels from fixed vocabularies, a five-slot link matrix, per-row ownership walls, and a cross-property deduplication section. Enforces a closure pre-flight that resolves every link target and parent value before anything is written, and the hub-slug publishing rule that keeps a flagship article from publishing at its title slug and orphaning every child link. This skill should be used when planning the structure of a content programme, when a link or pillar check keeps reporting nothing on a site known to be broken, or when several articles in one cluster have started restating the same thesis. --- # Cluster topology blueprint ## The claim this skill is built on The obvious approach is a diagram. A hub in the middle, spokes around it, arrows pointing inward. Everyone recognises it, everyone agrees with it in the meeting, and it is close to useless six weeks later. It fails for one reason: **nothing can read it.** A topology is only worth anything if later work can be checked against it, and checking requires extraction. If the pillar for a cluster is stated in a sentence, no script can find it, so the pillar-link check that somebody proudly added to the pipeline silently matches nothing on every run. It does not error. It reports zero findings. Zero findings reads as compliance, and the report is filed as good news for as long as the programme lasts. That is the central claim: **a machine-parseable declaration is a precondition for any later check existing at all.** Not a nicety. A precondition. Most of the value of this file is upstream of any linking advice, in making the topology a thing a program can resolve. The second claim is that closure is a pre-flight, not a review. A map where a link points at a page nothing creates is not a slightly imperfect map. It is a map that guarantees broken links, because a writer given a slug will use it. ## Step 1: declare the governance split at the top of the file Three documents govern a content programme and they must not blur. - **The topology governs WHERE.** Which cluster a piece belongs to, what it links to, what it may not absorb. - **The strategy document governs WHY.** Positioning, audience, the argument the domain is making. - **The writing specification governs HOW.** Structure, depth, voice, claim sourcing. State this in the first ten lines. It is not decoration. Without it, every future edit to the topology arrives carrying an opinion about tone, and the file that decides structure becomes a second, contradictory style guide. ## Step 2: the cluster record, with one literal pillar declaration Every cluster is a heading followed by the same fixed field set, in the same order, in every cluster without exception. The pillar line uses **one literal form** and nothing else: ``` **Pillar:** `cluster-hub-slug` at /path/to/hub ``` Pick a form, write it down, and never vary it. The exact form matters less than that it is exact. What must be true is that a five-line script can extract every pillar slug and every pillar URL from the file without a language model, because the moment extraction needs judgement, extraction stops happening. The remaining fields per cluster: - **Existing supporting articles.** Slugs that already exist, or the literal phrase `none yet, greenfield`. A blank field is ambiguous between "nothing yet" and "nobody checked". - **Sub-clusters**, each with its own pillar slug, declared in the same literal form. - **A strategy paragraph.** Two or three sentences on what this cluster is arguing. - **Routing.** Which angles, intents or audiences send a reader here. - **Posture** and **saturation**, from the vocabularies below. ## Step 3: posture and saturation, from fixed vocabularies Two labels per cluster, each drawn from a closed list. Closed lists rather than free text, because a free-text posture field fills up with sentences and stops being sortable, and the first thing anyone wants to do with a topology is sort it. **Posture**, meaning what to do next: `Extend` / `Extend aggressively` / `Maintain` / `Hold` / `Hold, merge into other clusters` / `Expand, highest-upside net-new` / `Optional` **Saturation**, meaning how much room is left: `High` / `Saturated` / `Medium` / `Low` / `Open` The pairing carries the decision. `Saturated` plus `Extend aggressively` is a contradiction that should be caught in review, and it is only catchable because both fields come from a vocabulary. ## Step 4: the hub-slug publishing rule This is the rule that costs the most when it is missed, and it takes one sentence to state. **A cluster's flagship article publishes at the hub slug, which is the exact value its children carry as their parent, not at the slugified version of its own title.** The failure is ordinary. A pillar is declared as `invoice-automation`. The flagship gets briefed with a full title, something like "The complete guide to automating invoice approvals in 2026". Whoever publishes it lets the platform derive the slug from the title, and the page goes live at `the-complete-guide-to-automating-invoice-approvals-in-2026`. The page is fine. It ranks. Nothing errors. But every spoke in that cluster names `invoice-automation` as its parent and links to it, and that URL will never exist, so every one of those links 404s. On one real site, two clusters had declared pillars that were never published under the declared slug, and every child link in both clusters was dead. The pillar pages themselves were live and performing, which is why it took months to find. Two defences, and use both. Pass the slug explicitly on the publish call rather than letting it be derived. And add the flagship's hub slug to the closure set as a queued row, so the pre-flight fails if the plan ever schedules it at a different slug. ## Step 5: closure pre-flight, and it is a hard stop Before anything is written, resolve **every** internal link target and **every** parent value in the map against the union of three sets: 1. Slugs the queued rows will create. 2. Slugs in the published index, meaning the live corpus rather than anyone's recollection. 3. Approved non-article pages, from the link target registry. If a single target does not resolve, **stop**. Do not write the article. Do not warn and continue. Do not add a note to a review column. The reason this must be a stop rather than a warning is behavioural. A writer handed a plan containing a slug will use the slug, because it is written down and it looks like every other slug in the file. The link renders normally, passes visual review, and returns 404 to the first crawler that finds it, which is usually weeks later. The only reliable moment to prevent it is before the plan is handed over. When the pre-flight passes, **assert it inside the file itself**: ``` Closure: verified closed on <date>. Every link target resolves to a slug some row creates, a slug in the published index, or an approved page. ``` The assertion is dated because it decays. It is true on the day the map is written and untrue the first time a row is deleted from the backlog. ## Step 6: the link matrix, so the rule becomes a column Abstract linking rules do not survive contact with a spreadsheet. State the matrix as **five named slots**, so each row of the backlog carries a cell rather than an instruction: ``` [parent_pillar, cta_page, sibling_1, sibling_2, bridge_or_comparison] ``` And state the directions with counts, because "link generously within the cluster" produces both three links and thirty. - **Child to pillar: always.** Every member of a cluster links up. No exceptions and no judgement. - **Pillar to child: mandatory, no exceptions.** This is the one that gets skipped, because it is an edit to an already-published page rather than part of writing a new one. A pillar that does not link down is a menu, not a hub, and the cluster never forms. - **Sibling to sibling: two to four within the cluster.** Below two, the cluster is a star with no internal structure. Above four, later members have nothing left to link to that is not already linked. - **Cross-cluster: zero to two**, or zero to one if it is a bridge or comparison piece. Cross-cluster links are how a topology becomes a mesh, and a mesh has no hubs. These counts are working defaults from one multi-site operation. The reasoning is what transfers: enough internal links that a cluster reads as a set, few enough that any individual link is a deliberate choice. ## Step 7: saturation guardrails, in numbers Four concrete caps. Each one is a default with a reason, not a published law. **Cap an audience-adjacent cluster at roughly 15 per cent of any multi-week publishing window.** Audience-adjacent means a cluster your readers plausibly care about that is not what you sell. It is the cluster that grows without resistance, because the topics are easy and the traffic is real. Fifteen per cent is one row in seven, which is enough to hold a position and not enough to change what the domain appears to be about. **Keep a marginal cluster to five to eight rows, or reassign it.** Below five, a cluster has no internal linking to do and its members are effectively orphans with a label. Above eight, it is no longer marginal and needs a strategy paragraph that says why. **Write thin individual terms as roll-ups.** Twenty near-identical single-entity pages, one per tool, one per integration, one per city, compete with each other, split their own links, and read as templated. One roll-up covering all twenty carries the same demand and concentrates everything. Split it later if a single entity earns its own page on evidence. **Over-invest early in the one genuinely open cluster.** Most portfolios have exactly one cluster labelled `Open`, and the window on it is shorter than the window on the saturated ones. Front-loading is the only cap here that pushes upward. ## Step 8: cross-property deduplication, written first If a sibling property in the same portfolio covers the same subject, write this section **before** any cluster records, because it changes what the clusters are allowed to contain. Three parts, all concrete: - **Acceptable angles.** Named. "Implementation detail for practitioners" is an angle. "Different tone" is not. - **Not-acceptable angles.** Named, with the property that owns each one. This list is longer than the acceptable one and it is the useful half. - **A shape test.** One sentence that decides an ambiguous case without a meeting. For example: if the piece answers "should we" it belongs to the other property, and if it answers "how do we" it belongs here. Written as a vibe rather than as three lists, this section is ignored within a month, and both properties end up publishing the same article with different headings. ## Step 9: ownership walls, per row, before anything is written The map assigns topics. Ownership walls assign **boundaries**, and without them three articles in a cluster each restate the whole thesis, because each writer independently decided the reader needs the background. Write walls as explicit sentences naming specific rows: - "Row A defines the concept and builds the thing. The diagnosis belongs entirely to row B. A links out to B rather than absorbing it." - "Row C is the vision piece only and must not give the how-to. The how-to is row D." - "Each of the three thesis rows cites a different proof, so the domain reads as depth rather than repetition." The third form is the one people skip and it is the one that decides whether a cluster reads as authoritative or as padding. ## Step 10: never invent a URL, and version the file If a pillar page does not exist live yet, link the nearest existing parent and flag it in the notes column. Do not write the future URL. A plausible URL in a plan becomes a real link in an article, and the plan is where it stops being catchable. Version the file with a changelog, and make each entry say **which rule is load-bearing** in that revision. A changelog listing what changed is a diff. A changelog saying "this revision makes the hub-slug rule mandatory because two clusters shipped with dead child links" is the thing that stops the rule being quietly relaxed next quarter. ## Decision rule: this row wants to link to a page that does not exist yet 1. The target is a slug some queued row will create, and that row is scheduled **before** this one. **Allow it.** The page will exist by publication. 2. The target is a queued row scheduled **after** this one. **Do not allow the link.** Either reorder so the target comes first, or drop the link. A forward reference is a 404 with a publication date. 3. The target is a non-article page and it appears in the link target registry as confirmed. **Allow it.** 4. The target is a non-article page that is not in the registry. **Do not invent it.** Link the nearest confirmed page instead, or drop the link and note it. 5. **You cannot tell.** The target looks live, the published index does not list it, and the registry says nothing. Do not guess and do not construct the URL. Fetch it once. A 200 means the index is stale, so record the discrepancy and allow the link. A 404 or a redirect means treat it as non-existent under rule 4. If it cannot be fetched at all, because the environment has no network or the page sits behind authentication, **halt the row and escalate it by name**. It does not silently become allowed, and it does not silently become a warning in a column nobody sorts by. ## Worked example, compressed A documentation site for a fictional project management tool. Four clusters proposed, one sibling property already covering part of the subject. **Governance split** stated in six lines at the top. **Cross-property section written first.** The sibling property owns "should we adopt" content. Acceptable angles here: implementation, migration, administration. Not acceptable: tool selection, buying guides, pricing comparison. Shape test: if the reader has not chosen yet, it is not ours. Two proposed clusters lose three rows each to this rule before any of them are written. **Cluster records.** Four clusters, each with the literal pillar declaration. Cluster one, `task-automation`, posture `Extend`, saturation `Medium`, eleven existing articles. Cluster two, `reporting`, posture `Expand, highest-upside net-new`, saturation `Open`, none yet, greenfield. Cluster three, `integrations`, posture `Hold, merge into other clusters`, saturation `Saturated`, because it is nineteen near-identical single-integration pages, which the roll-up rule converts to two roll-ups plus three genuinely-earned individual pages. Cluster four, `remote-team-culture`, posture `Optional`, saturation `High`, and it is audience-adjacent, so it is capped at 15 per cent of the window, which over a twenty-row window is three rows. **Hub-slug check.** Cluster two's flagship is briefed as "How to build a reporting layer your finance team will actually read". Its hub slug is `reporting`. The plan records both, and the publish instruction carries the slug explicitly. Without that line the page would have shipped at the title slug and all six planned children would have linked to nothing. **Closure pre-flight.** Twenty rows, sixty-two link targets. Fifty-eight resolve. Four do not: two point at a pricing page that the registry lists as unconfirmed, one points at a cluster-three page that the roll-up rule just deleted, and one points at a row scheduled two weeks later. The run **stops**. Two links are dropped, one is repointed at a roll-up, one row is reordered. Re-run: sixty-two of sixty-two resolve. **Ownership walls.** Cluster one's row 3 defines and builds. Row 7 diagnoses. Row 3 links out to row 7 and is explicitly forbidden from covering diagnosis. **Verdict: the map is closed and publishable, at nineteen rows rather than twenty-six.** Seven proposed rows were removed by the cross-property rule and the roll-up rule before anyone wrote a word, one cluster is on a stated cap, and the closure assertion is written into the file with the date it was verified. ## Failure modes **The pillar declared in prose.** From the outside: a link check that has reported zero findings every run since it was added, on a site where people know the pillars are a mess. Nothing is broken except that the check matches nothing, and silence is being read as health. **The flagship at its title slug.** The pillar page is live, indexed and performing. Every child link to it 404s. Because the pillar itself is fine, the diagnosis usually starts in the wrong place, and the fix arrives after the children have already lost whatever they were going to gain. **A cluster past its cap.** The audience-adjacent cluster is now a third of the corpus, the domain's most-visited pages are all about a subject you do not sell, and any attempt to prune is resisted because those pages have traffic. There is no clean fix available afterwards, which is why the cap is a pre-commitment. **Absent ownership walls.** Three articles in one cluster, each spending its first six hundred words restating the same argument before reaching its own topic. Reads as padding, is really three writers each being conscientious in isolation. **Cross-property dedupe as a vibe.** Both properties publish the same article within a quarter, the two pages compete, and neither team did anything wrong by the guidance they were given. **The unresolvable target that became a warning.** The pre-flight found four broken targets, someone recorded them in a notes column, the rows were written anyway, and three of the four shipped as live links because the writer had a slug and no reason to doubt it. **Closure verified once and never again.** The assertion in the file is eight months old. Four rows have been deleted from the backlog since, and every link that pointed at them is now a forward reference to nothing. **A perfect map with nothing under it.** Every cluster labelled, every declaration parseable, closure asserted, two articles published. The topology is not wrong. It is just not doing anything, and its tidiness makes the programme feel further along than it is. ## What this skill does not do - It does not do keyword research and cannot measure demand. It arranges a portfolio somebody else validated, and it will arrange a bad one just as neatly. - It does not write the schedule. Row order, article type quotas and word count targets belong to a backlog, and this only constrains what that backlog is allowed to contain. - It cannot confirm that any URL it names is served. Every claim about a live page needs a real request, and a crawler in list mode is the right tool for that. - It has no opinion on search intent for individual terms, so a cluster boundary it draws is a subject-matter judgement rather than a demand-based one. - Its caps and counts are working defaults from one operation, not published thresholds, and a cluster that is your entire business is a legitimate reason to ignore all of them. - It publishes nothing and edits nothing. The pillar-to-child links it mandates are edits to existing pages that somebody has to actually make, and that is the step most often skipped.
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.