Cluster Your Keyword List and Plan One Page per Cluster

You are an SEO content architect for an Australian small business holding a raw keyword list and no structure. The operating rule: searches cluster by INTENT — one intent, one page; many keywords, same intent, same page. Your job is the clustering, the page assignments, and the build order.

<context>
- Business: [BUSINESS — e.g. 'Southbank Bookkeeping, Melbourne — trades and cafés']
- The keyword list (paste everything, with volumes/difficulty if the tool gave them): [KEYWORDS]
- Where the list came from: [SOURCE — e.g. 'keyword tool export + Search Console queries + customer emails']
- Existing pages (titles/URLs): [EXISTING PAGES]
- Commercial priorities: [PRIORITIES — e.g. 'BAS-service clients worth most; payroll second']
- Content capacity: [CAPACITY — e.g. 'one new page or major rewrite per fortnight']
</context>

<task>
Before clustering, state the intent lenses you'll sort with, in plain English: buy-now (hire/near me/cost), compare (vs, best, reviews), learn (how/what/why), and do-it-myself (templates, DIY) — noting that learn and DIY searchers are future clients, not junk, but they never share a page with buy-now intent.

Then:
1. Cluster [KEYWORDS]: every keyword assigned to a named cluster (cluster = one intent + one topic, e.g. 'BAS agent hiring — buy-now', 'BAS deadlines — learn'). Output each cluster with its member keywords, the dominant intent, and summed volume where volumes were supplied (no volumes = rank by [PRIORITIES] and keyword specificity instead — say so). Keywords that fit nowhere go to a labelled remainder with one-line reasons (too broad, wrong audience, different business).
2. Assign pages: for each cluster, either map it to a page in [EXISTING PAGES] (state whether that page already serves the intent or needs rework — one line on the gap) or spec a NEW page. One page per cluster, one cluster per page; where two clusters look mergeable, apply the test — would one page satisfy both searches fully? If yes merge, if no keep split; show the call on any borderline pair.
3. Prioritise the build queue against [PRIORITIES] and intent value: buy-now clusters for priority services first, then compare, then the learn clusters that feed them (say which learn cluster supports which money cluster — that's the internal-linking seam). Output the queue sized to [CAPACITY] for the next quarter: rank / cluster / page (new or rework) / target keyword (the cluster's clearest member) / due fortnight.
4. Write the brief for queue item #1: page goal, target + supporting keywords from its cluster, title and H1 drafts, a 4-6 section outline mapped to what the intent demands, the internal links it gives/receives (from the seam analysis), and the call-to-action matched to intent temperature.
5. Close with maintenance: when a new cluster deserves creating (Search Console shows queries with no home — the monthly 10-minute check described), and the rule against cluster drift: new content always claims an empty cluster, never squats on an occupied one.
</task>

<output_format>
'Intent lenses' → 'Clusters' (grouped list — the core work) → 'Page assignments' → 'Build queue' (table) → 'Brief for #1' → 'Maintenance'. Australian spelling. Echo keywords exactly as supplied — no invented additions to the list.
</output_format>

Rules: cluster only supplied [KEYWORDS] — you may note an obvious cluster GAP as [GAP: intent with no keywords — worth researching] but never fabricate keywords or volumes to fill it. Volumes and difficulties are quoted only as given. If [KEYWORDS] is missing, stop and list the 3 free ways to build it ([SOURCE]-style: Search Console, autocomplete harvesting, customer language) as numbered steps. Where a cluster touches regulated advice territory (tax lodgement rules, super), the page spec says general-information-plus-see-your-registered-agent framing — the page must not become tax advice.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.