Semantic Center

Concept of the skill

Semantic-center analysis is a figure-ground reduction method. Treat the unit of analysis as a graph of parts, then name the one part that carries the most structural load and place every other part in relation to it. The center is not automatically the most visible, newest, largest, or first-in-sequence part; it is the part whose removal, governing role, purpose explanation, semantic weight, or decision leverage best explains the whole.

This skill prevents flat explanations. It turns "here are all the parts" into "this is the primary part, these are the supporting parts, and this is how each support, constrains, feeds, or depends on the primary." That makes dense systems, pages, workflows, and concepts easier to understand without turning the answer into a prioritized task list or a formal domain model.

This skill owns explanatory reduction for one system, feature, workflow, concept, decision, problem, or page. It does not own user-goal decomposition and friction scoring, full conceptual modeling, precise edge semantics for a single relation, cross-instance pattern detection, implementation, code review, model routing, or project prioritization. Use the specialist skill once the work changes from explanation to those activities. Semantic-center analysis is like finding the load-bearing column in a room: furniture, paint, wiring, and fixtures all matter, but the explanation becomes useful only after the column that everything else depends on is named. The common mistake is believing the semantic center is whatever is most visible or most recently discussed. Visibility is a UI fact, recency is a conversation fact, sequence is a timeline fact, and none of them alone proves structural importance.

Coverage

A structured explanatory workflow for identifying the semantic center of any system, feature, concept, page, workflow, decision, or problem and mapping how surrounding parts relate to it. Covers (1) unit-of-analysis classification (system / feature / module / page / workflow / concept / data model / decision / problem); (2) primary-part identification via the five tests (removal, governance, purpose, weight, decision) ranked by priority; (3) typed secondary-part relation mapping using a fixed taxonomy of relation types (dependency, input/output, parent/child, source/consumer, cause/effect, owner/owned, trigger/result, semantic grouping, constraint/enabler, sequence/timeline, contrast/tradeoff); (4) structured-output production following a fixed skeleton; and (5) final one-sentence reduction in a fixed grammatical form. Includes a "codebase analysis mode" overlay for analyzing a real implementation surface (grep, read primary file, follow data path, read tests) and an anti-pattern catalog (everything-is-important flattening, visibility-as-importance, proximity-as-relation, chronology-instead-of-structure, symmetric-relation blur).

Philosophy of the skill

Most explanations fail because they present everything at the same weight. A user asks "how does this work?" and receives a chronological walkthrough or a laundry list, neither of which tells them what the system depends on. Until one part is named as load-bearing, the explanation is not structurally useful — the reader still has to do the reduction work themselves.

The core rule is: prefer one primary part and typed supporting relations over multiple co-equal "important" parts. When more than one thing seems important, the removal test or the governance test usually breaks the tie. If it doesn't, state the tension explicitly rather than hiding it behind a list. The five-step workflow exists to force that reduction every time, not as an aesthetic preference but as a structural one.

This skill is for explanation, not for execution. It tells you which part of a system carries the most semantic load. It does not tell you which task to start next (a prioritization concern), how to design the bounded contexts and aggregates of the system (a domain-modeling concern), or how to implement any of it (a domain skill concern).