Base directory for this skill: ./.claude/skills/classify

/classify — cluster accumulated captures, write nothing

This skill is provisional. It ships ahead of the corpus that would justify it, deliberately: the design evolves through use rather than waiting for a perfect corpus. Read 00-meta/research-pipeline.md for how this fits with /know, /deepen, /synthesize, and /review. If a step here produces bad output, misjudges a cluster, or fights the corpus, say so and propose a change to this file — do not silently work around it.

Contract (binding)

1. Write nothing. This skill produces a manifest for the user's approval. No file is created, moved, or renamed by /classify itself.
2. Cluster by claims and content, not tags. Tags are facets; they cross-cut themes and are not reliable cluster signal.
3. A capture may belong to several clusters. Say so rather than forcing single membership.
4. Anchor stability. On re-run, previously approved clusters do not get dissolved by new material — new captures join or form new clusters. If re-running after ten new captures reshuffles approved clusters wholesale, the clustering is too sensitive; say so plainly rather than presenting churn as insight.
5. Check ownership before proposing a new hub. Use the areas-vs-resources test from conventions.md (areas are hubs, resources are leaves) and search 40-areas/ and 50-resources/concepts/ for an existing note that already owns the concept. If one exists, the disposition is "enrich that note," not "synthesize a new one."

Procedure

1. Check whether clustering is worth doing at all

Before clustering, check the corpus against the trigger in 00-meta/research-pipeline.md / the hypothesis doc:

grep -rhoE "processing: [a-z]+" ./50-resources/sources/*/*.md | sort | uniq -c

• If no theme plausibly has 3+ source records (at least one processed or later), and the captured backlog is under ~15, say so directly: there isn't enough material yet, recommend more /know and /deepen instead of forcing a manifest. This is a legitimate output, not a failure to complete the task.
• If the user asks for a manifest anyway on a thin corpus, produce it, but mark every cluster's disposition as defer unless it clears the 3-source bar — do not stretch the threshold to make a manifest feel more substantial than it is.

2. Gather input

• Everything in 50-resources/sources/*/*.md with processing not synthesized or archived.
• Everything in 60-bookmarks/*.md without a promoted_to field.
• For each, read the frontmatter (tags, topics, authors, source_type) and, where present, the ## Claims and evidence block IDs and ## Connections typed relations — these are the actual clustering signal, not the prose.

3. Cluster bottom-up

Group by shared claim content and stated relations (supports::/extends::/contradicts:: targets, shared topics: wikilinks), not by folder or tag co-occurrence alone. Name each cluster after clustering, not before — the label should come from what the items actually share, echoing the KJ/affinity method's card-sort-then-name order.

4. Score each cluster

For each cluster, in the migration-doc idiom:

• Transferability — does this generalize past the one source, or is it tied to one vendor's specific claim?
• Novelty — checked against 40-areas/ and 50-resources/concepts/: does an existing note already own this, partially or fully?
• Durability — is this likely still true/useful in a year, or is it a snapshot of a fast-moving space?
• Evidence quality — pull from each source's own ## Source and evidence quality section rather than re-assessing from scratch.

5. Assign disposition

• Synthesize now — 3+ meaningful sources, no existing owner, evidence quality reasonable.
• Defer — real signal but thin (1–2 sources, or evidence quality weak). Say what would need to be true to promote it later.
• Duplicate / already covered — an existing 40-areas/ or 50-resources/concepts/ note already owns this. Name it; recommend enriching it (a /deepen-connect-pass-style addition) instead of a new hub.

6. Present the manifest

A table: cluster name, member sources (with processing state), score summary, disposition, suggested destination (40-areas/<topic>/ new hub, 40-areas/<existing>/ enrichment, or 50-resources/concepts/<claim> if it's really one recurring claim rather than an organizing theme — never both for the same cluster).

Support merge, split, rename, and reject from the user in conversation. Once a cluster is approved, it is stable per the anchor-stability rule above — record approval by asking the user directly; there is no persisted "approved" flag in the vault, so treat the current conversation's approval as the authorization /synthesize needs to proceed on that cluster.

Report

• No log.md entry unless the user asks you to record the manifest somewhere durable (e.g., as a comment in 00-meta/research-pipeline.md's running notes) — a bare classification pass changes no vault state.
• Report the full manifest, the trigger-check result, and — if capture volume is far outrunning classification (many captured/processed, no cluster reaching 3), say that plainly per the anti-collector's-fallacy stance the rest of this pipeline holds to.