Semantic Center

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).

Grounding

This skill combines three public ideas into an agent workflow:

• Graph centrality names a family of methods for asking which node is structurally important in a network; this skill uses the same intuition qualitatively, without pretending to compute a formal centrality metric.
• SKOS distinguishes hierarchical and associative semantic relations; this skill uses a practical relation vocabulary so supporting parts are not left as vague "related" items.
• The Pyramid Principle frames communication around one governing point with supporting ideas underneath it; this skill applies that one-point discipline to system explanation.

The workflow is heuristic, not mathematical. Use semantic-relations when one edge needs precise relation semantics, and use a graph-analysis tool when the question requires computed centrality rather than explanatory judgment.

Workflow

The skill is the five-step workflow below. Each step produces explicit output. Steps run in order; a missing step downstream usually means the analysis short-circuited at the previous step.

Step 1: Classify the unit of analysis
Step 2: Find the single most important part
Step 3: Map secondary parts in relation to the primary part
Step 4: Produce the structured output
Step 5: Reduce to one sentence

Step 1 — Classify the Unit of Analysis

Before analyzing, explicitly state what kind of thing this is. The category shapes which relation types and tests are most likely to matter.

Rule: say explicitly, "This is a [category]." If you cannot pick a category, the unit of analysis is too vague — narrow it before continuing.

Step 2 — Find the Primary Part

Use these tests, in priority order. The first test that produces a clear winner is the test you cite.

Rules:

• Prefer one primary part. If the removal test is genuinely tied between two, name the tie explicitly rather than hiding it behind a list.
• Distinguish importance from visibility — the loudest element is not necessarily the most load-bearing.
• Distinguish importance from recency — the most recently changed part is rarely the semantic center.
• Distinguish importance from stakeholder emphasis — the part people talk about most may be a symptom, surface, or reporting layer rather than the governing structure.
• Cite the test that selected the primary part. A center without a named test is a preference, not an analysis.

Tie Handling

True ties are allowed, but they must be explicit. Use this sequence:

1. Try the removal test first. If removing either part breaks the whole in different ways, continue.
2. Try the governance test. The part that constrains or authorizes the other usually wins.
3. If still tied, name the tension and choose a temporary center for the purpose of the explanation.
4. Mark the other tied part as a secondary part with contrast/tradeoff or constraint/enabler, not as a hidden second primary.

Step 3 — Map Secondary Parts

List secondary parts only in relation to the primary part. Every secondary part must have an explicit relation type from the taxonomy below.

Rules:

• Every secondary part must have an explicit relation type from this list.
• Proximity is not a relation. Two parts being "near each other" in the codebase is not a structural relationship — name the actual relation or drop the part.
• Chronology is not enough when a stronger structural relation exists. Use sequence/timeline only as a last resort.
• Symmetric "A and B both explain each other" is not allowed — choose the dominant direction.
• If the relation type itself is the hard part, pause and apply semantic-relations before completing the map.

Relation Strength Order

When more than one relation label seems plausible, prefer the strongest truthful relation in this order:

1. governing / constraint — one part authorizes, limits, or defines the allowed shape of another
2. dependency / input-output / source-consumer — one part cannot function or be understood without the other
3. cause-effect / trigger-result — one part produces a state change in the other
4. parent-child / owner-owned — one part structurally contains or governs lifecycle of another
5. contrast / tradeoff — parts compete or represent alternatives
6. sequence / timeline — temporal order only when no stronger structural relation is true
7. semantic grouping — same-family grouping only when the relation is genuinely loose

Step 4 — Structured Output

Use this output skeleton verbatim. Each H2: label below becomes a real ## heading in the produced analysis document.

H2: Unit of Analysis
    [Category]: [Name]

H2: Primary Part
    [Name of the single most important part]

H2: Why This Is the Primary Part
    [Which test(s) it passes and why]

H2: Secondary Parts
    - [Part A] — [role]
    - [Part B] — [role]

H2: Relation Map
    - Primary → Part A: [relation type] — [explanation]
    - Part B → Primary: [relation type] — [explanation]

H2: Simplest Explanation
    [2-3 sentences]

H2: Important Distinction
    [What people most often confuse]

H2: Common Misunderstanding
    [What goes wrong and why]

H2: Naming Recommendation
    [If naming is misleading, suggest better names]

Step 5 — Final Reduction

End with exactly one sentence in this form:

The core is [X], and everything else matters because it [supports / depends on / constrains / expresses / feeds / consumes] X.

If you cannot write this sentence in one line, the analysis is not yet finished — return to Step 2.

Codebase Analysis Mode (Overlay)

When the unit of analysis is a real repo surface rather than a pure concept, add these steps before Step 2:

1. Grep for the entity or surface name across the codebase.
2. Read the primary implementation file.
3. Follow the data or event path one hop in each direction.
4. Read tests if they exist.

Then add to the structured output:

• ## Key Files — list the files that participate in the analyzed unit
• ## Verified Against — list the artifacts that confirmed the analysis (grep results, test names, log lines)

Do not claim a file, route, function, or dependency exists unless it was found through search or read during the analysis. If the codebase surface is unavailable, say the analysis is conceptual-only and omit code-specific claims.

Anti-Patterns

Verification

After delivering a semantic-center analysis, verify:

• Exactly one primary part was identified (a stated tie counts as one, not two)
• Every secondary part has an explicit relation type from the taxonomy
• No relation is just proximity dressed up as structure
• No symmetric "A and B both explain each other" relations remain
• The "Important Distinction" is non-obvious rather than a restatement of the primary part
• The final reduction is exactly one sentence in the prescribed form
• The output stays in explanation mode rather than drifting into implementation or prioritization
• If codebase analysis mode was used, ## Key Files and ## Verified Against are present and grounded in actual reads

Do NOT Use When