math-skill 1.0.0 → 2.1.0

package/references/gpu-friendly-math.en.md

@@ -0,0 +1,65 @@
+# GPU-Friendly Math Checklist
+
+> This file is the **single source of truth** for the "GPU-feasibility" acceptance gate.
+> The activator, the 16 thinking weapons, `books/*.md`, and `../agents/math-critic.md` all reference this file; no duplicate definitions elsewhere.
+>
+> This file is the single source of truth for the "GPU-feasibility" acceptance gate. The activator, the 16 weapons, the book references, and the math-critic all point here.
+
+## Core Proposition
+
+**Mathematical beauty ≠ computability.** For a structure to truly enter training and inference on modern GPU clusters, it must simultaneously satisfy two requirements:
+
+1. **Mathematically correct (beautiful in math)** — The structure is self-consistent, differentiable (or relaxable to differentiable), with correctness guarantees.
+2. **Hardware-feasible (friendly to GPU)** — It can be efficiently mapped onto GPU microarchitecture (Tensor Cores, memory hierarchy, parallelism, and interconnects).
+
+Many "beautiful on paper" modern mathematical structures cannot run at high performance once they encounter GPU parallelism and low-precision arithmetic errors. This checklist turns "GPU feasibility" into an **item-by-item scorable** engineering standard, preventing non-computable constructs from being accepted as deliverables.
+
+## The 8-Dimension Scorecard
+
+For any candidate structure (operator, attention variant, routing mechanism, regularization term, compression scheme…) rate each dimension as `Friendly / Adaptable / Unfriendly` and provide adaptation recommendations.
+
+| # | Dimension | Key Question | Friendly ✅ | Unfriendly ❌ |
+|---|-----------|-------------|------------|--------------|
+| 1 | **Tensorization** | Can it be expressed as dense tensor operations, avoiding element-wise irregular control flow? | Batched tensor algebra | Scalar loops, data-dependent branches |
+| 2 | **GEMM Mappability** | Can it be reduced to matrix multiplication / batched GEMM / convolution to fully utilize Tensor Cores? | Expressible as a GEMM chain | Irregular computations that cannot be expressed as matrix operations |
+| 3 | **Complexity** | Is the forward/backward pass sub-quadratic? How does it scale with sequence length / model size? | Linear / sub-quadratic, blockable | $O(n^2)$ or worse memory/compute blowup |
+| 4 | **Memory & KV-Cache** | Peak memory usage; activation / state / KV footprint; can it be compressed? | Low-rank / quantized / block-summary compressible | Must materialize large intermediate tensors |
+| 5 | **Low-Precision Stability** | Is it stable under fp16/bf16/fp8 with deterministic reproducibility? | Controlled dynamic range, numerically robust | Catastrophic cancellation, ill-conditioned, requires fp64 |
+| 6 | **Parallelism & Communication** | Can it be parallelized across SMs / devices? Communication-to-compute ratio; can overlap be achieved? | Highly parallel, communication overlap-able | Long serial recurrences, communication bottleneck |
+| 7 | **Sparsity** | Structured or unstructured sparsity? | Block / banded structured sparsity | Random gather/scatter |
+| 8 | **Kernel Fusion** | Can kernels be fused to avoid materializing large intermediates (FlashAttention-style)? | Fusible, recomputable | Frequent small kernels, divergent control flow |
+
+**Scoring conclusion**: Retain only candidates that are **mathematically beautiful AND (all eight dimensions friendly or adaptable)**; any dimension rated "unfriendly and non-adaptable" means the candidate must be adapted or eliminated.
+
+## Common "Beautiful but Non-Computable" Anti-Patterns
+
+- **Dense global $O(n^2)$ operators**: Naive softmax attention explodes with context length.
+- **Unstructured sparsity / irregular graph traversal**: Random memory access destroys locality.
+- **High-precision dependency**: Ill-conditioned problems that require fp64 for correctness (most training runs only bf16/fp16/fp8).
+- **Serial recurrence**: Long-range dependencies that cannot be parallelized (naive RNN-style).
+- **Frequent small kernels + control-flow divergence**: Launch overhead and warp divergence consume throughput.
+- **Non-differentiable / requiring discrete search**: Breaks end-to-end gradient-based training.
+
+## Make-It-Computable Toolkit
+
+Common techniques for transforming "beautiful but non-computable" into "both beautiful and computable":
+
+- **Discrete → continuous relaxation**: Gumbel-softmax; **piecewise-linear** gating on the **tropical semiring** as a replacement for hard Top-K.
+- **Block sparsification**: Dense attention within blocks, structured sparse between blocks (e.g., DeepSeek CSA-style blocking).
+- **Low-rank / projection compression**: Restriction maps via low-rank linear transformations; **low-rank basis-style block summaries** for KV-Cache compression (store the basis rather than Plücker coordinates — the latter expands when low-rank).
+- **Numerical reparameterization**: log-sum-exp, normalization, stable softmax — ensuring low-precision stability.
+- **Kernel fusion / recomputation**: Fused kernels, activation recompute to save memory.
+- **Embedding structure into GEMM**: Express algebraic/geometric transformations as **learnable linear maps** so they naturally map onto Tensor Cores.
+
+## Worked Example: Tropical Sheaf Attention
+
+Drawn from the auto-research directions cited in `agentic-workflow.md`, demonstrating how a **candidate design enters the 8-dimension verification**:
+
+| Component | Mathematical Source | GPU Friendliness |
+|-----------|-------------------|-----------------|
+| Tropical Gating | Tropical semiring, piecewise-linear | Replaces Top-K: element-wise max-plus — dim 1 ✅ Tensorization / dim 2 ❌ Not a Tensor Core GEMM (runs on CUDA cores) / dim 3 ✅ Per-token gating only, sub-quadratic (min-plus matmul is APSP-hard, not sub-quadratic); sub-differentiable, kinks require LogSumExp smoothing (smoothing recovers standard softmax) |
+| Cellular Sheaf Diffusion | Algebraic geometry / topology (sheaves, restriction maps) | Each edge is a low-rank linear transform = small GEMM (dim 2/4) |
+| Čech Cohomology Regularization | Algebraic topology (first cohomology $H^1$) | Local, inexpensive; serves as an algebraic criterion for hallucination (dim 3/8) |
+| Low-Rank Basis KV Compression (Plücker/Grassmannian perspective) | Projective geometry | Store the basis rather than Plücker coordinates (the latter expands when low-rank); block-summary candidate — compression ratio / error / throughput must be benchmarked (dim 4) |
+
+Do not treat the table above as validated conclusions. The correct approach is to enter each component into the test plan: prove or estimate complexity, measure peak memory and throughput, check bf16/fp8 stability, and confirm whether it can be mapped to GEMM / batched GEMM / fused kernels. Only after both empirical benchmarks and theoretical derivations pass should a component be labeled "math beautiful × GPU friendly."

package/references/gpu-friendly-math.md

@@ -0,0 +1,67 @@
+> **语言路由**：若用户消息为英文，请读取并遵循同目录下的 `gpu-friendly-math.en.md`。
+
+# GPU 友好性总清单 / GPU-Friendly Math Checklist
+
+> 本文件是「GPU 可行性」验收门的**唯一权威来源（single source of truth）**。
+> activator、16 个思想武器、`books/*.md`、以及 `../agents/math-critic.md` 都引用此处，不重复定义。
+>
+> This file is the single source of truth for the "GPU-feasibility" acceptance gate. The activator, the 16 weapons, the book references, and the math-critic all point here.
+
+## 核心命题 / Core Proposition
+
+**数学美 ≠ 可算。** 一个结构要真正进入现代 GPU 集群的训练与推理，必须同时满足两件事：
+
+1. **数学正确（beautiful in math）**——结构自洽、可微（或可松弛为可微）、有正确性保证。
+2. **硬件可行（friendly to GPU）**——能高效映射到 GPU 微架构（Tensor Core、显存层级、并行与互连）。
+
+许多"看上去很美"的现代数学结构，一遇到 GPU 的并行计算与低精度数制误差就无法高性能运行。本清单就是把"GPU 可行性"变成**可逐项打分**的工程标准，避免把不可算的东西当成果。
+
+## 八维检查 / The 8-Dimension Scorecard
+
+对任何候选结构（算子、注意力变体、路由、正则项、压缩方案……）逐项评 `友好 / 可改造 / 不友好`，并给出改造建议。
+
+| # | 维度 | 关键问题 | 友好 ✅ | 不友好 ❌ |
+|---|------|---------|--------|----------|
+| 1 | **张量化 / Tensorization** | 能否表达为稠密张量运算，避免逐元素不规则控制流？ | 批量张量代数 | 标量循环、数据相关分支 |
+| 2 | **GEMM 可映射 / GEMM mappability** | 能否落到 矩阵乘 / batched GEMM / 卷积，吃满 Tensor Core？ | 可写成 GEMM 链 | 无法矩阵化的不规则运算 |
+| 3 | **复杂度 / Complexity** | 前向/反向是否亚二次？随序列/规模如何增长？ | 线性/亚二次、可分块 | O(n²) 起的显存/算力爆炸 |
+| 4 | **显存与 KV-Cache / Memory** | 峰值显存、激活/状态/KV 占用；能否压缩？ | 低秩/量化/块摘要可压 | 必须物化巨大中间张量 |
+| 5 | **低精度稳定 / Low-precision** | fp16/bf16/fp8 下是否稳定、可确定性复现？ | 动态范围可控、数值稳健 | 灾难性抵消、病态、需 fp64 |
+| 6 | **并行与通信 / Parallelism** | 能否跨 SM/设备并行？通信 vs 计算、能否 overlap？ | 高并行、通信可 overlap | 长串行递推、通信瓶颈 |
+| 7 | **稀疏结构 / Sparsity** | 是结构化还是非结构化稀疏？ | 块/带状结构化稀疏 | 随机 gather/scatter |
+| 8 | **算子融合 / Kernel fusion** | 能否融合、避免物化大中间量（FlashAttention 式）？ | 可融合、可重计算 | 频繁小 kernel、发散控制流 |
+
+**评分结论**：只保留**数学美 AND（八维全部友好或可改造）**的候选；任何一维"不友好且不可改造"，要么改造、要么淘汰。
+
+## 常见「美但不可算」反模式 / Anti-Patterns
+
+- **稠密全局算子 O(n²)**：朴素 softmax 注意力随上下文爆炸。
+- **非结构化稀疏 / 不规则图遍历**：随机访存毁掉访存局部性。
+- **高精度依赖**：病态问题，需 fp64 才正确（绝大多数训练只有 bf16/fp16/fp8）。
+- **串行递推**：长程依赖无法并行（朴素 RNN 式）。
+- **频繁小 kernel + 控制流发散**：启动开销与 warp divergence 吃掉算力。
+- **不可微 / 需离散搜索**：阻断端到端梯度训练。
+
+## 改造手法 / Make-It-Computable Toolkit
+
+把"美但不可算"改造成"既美又可算"的常用招式：
+
+- **离散 → 连续松弛**：Gumbel-softmax；**热带半环（tropical semiring）上的分段线性**门控替代硬 Top-K。
+- **块稀疏化**：块内 dense attention、块间结构化 sparse（如 DeepSeek CSA 式分块）。
+- **低秩 / 投影压缩**：限制映射（restriction map）用低秩线性变换；**低秩基底式块摘要**压缩 KV-Cache（存基底而非 Plücker 坐标——后者低秩时反扩张）。
+- **数值重参数化**：log-sum-exp、归一化、稳定 softmax，保证低精度稳定。
+- **算子融合 / 重计算**：融合 kernel、activation recompute 省显存。
+- **结构嵌入 GEMM**：把代数/几何变换写成**可学习线性映射**，使其天然落到 Tensor Core。
+
+## 范例对照：Tropical Sheaf Attention / Worked Example
+
+来自 `agentic-workflow.md` 引用的 auto-research 方向，演示一个**候选设计如何进入八维验证**：
+
+| 组件 | 数学来源 | GPU 友好性 |
+|------|---------|-----------|
+| 热带门控 Tropical Gating | 热带半环分段线性 | 替代 Top-K：逐元素 max-plus——dim 1 ✅ 张量化 / dim 2 ❌ 非 Tensor Core GEMM（落 CUDA core）/ dim 3 ✅ 仅逐 token 门控亚二次（min-plus matmul 则 APSP-hard 非亚二次）；次可微，折点需 LogSumExp 软化（软化退回标准 softmax）|
+| 胞腔层扩散 Cellular Sheaf Diffusion | 代数几何/拓扑（层、限制映射）| 每边低秩线性变换 = 小 GEMM（维度 2/4）|
+| Čech 上同调正则 | 代数拓扑（一阶上同调 H¹）| 局部、廉价；作幻觉的代数判据（维度 3/8）|
+| 低秩基底 KV 压缩（Plücker/Grassmannian 视角） | 射影几何 | 存基底而非 Plücker 坐标（后者低秩时反扩张）；块摘要候选，压缩率/误差/吞吐需实测（维度 4）|
+
+使用时不要把上表当作已验证结论。正确做法是把每个组件写进 testplan：证明或估计复杂度，测峰值显存和吞吐，检查 bf16/fp8 稳定性，确认能否落到 GEMM / batched GEMM / fused kernel。只有实测和推导都通过后，才标为 "math beautiful × GPU friendly"。

package/references/inspiration.en.md

@@ -0,0 +1,113 @@
+# Inspirational Musings
+
+> Mathematics is more than a computational tool — it is a way of thinking. Sometimes a mathematical concept resonates with life itself, and you suddenly realize that behind those cold formulas lies a warm perspective on understanding the world.
+
+---
+
+## 1. The Dragon-Slaying Blade: The Origin of Lie Groups and Lie Algebras
+
+I still remember reading a Zhihu answer while pondering the question "How to understand that the original motivation of Lie groups and Lie algebras was to solve differential equations?" — one response left an indelible impression on me [Source: https://www.zhihu.com/question/356243536/answer/1992290356713259459].
+
+Sophus Lie was a blacksmith who wanted to forge a **dragon-slaying blade** — a universal method for solving all differential equations.
+
+Although the final blade could not slay every dragon, the craft of its forging — the correspondence between Lie groups and Lie algebras — has been passed down through generations. Later researchers discovered that while this blade cannot cut through every differential equation, it serves as a divine instrument for **chopping vegetables** (linearizing nonlinear problems), for **sculpting** (describing physical symmetries), and for **building houses** (robot state estimation).
+
+So, when you stare at a screen full of `se(3)` and exponential map notation and feel dizzy, do not forget that all of this began with a single Norwegian mathematician wondering: what miracles would unfold if you took Galois's game of permuting roots and extended it to the infinitesimal?
+
+**This is what makes mathematics most enchanting.**
+
+A tool invented to solve a specific problem ultimately reveals value far beyond its original intent in entirely different domains. Axiomatic thinking was initially developed to make geometry rigorous, yet it became the foundational language of every mathematical discipline. The Fourier transform was originally devised to solve the heat equation, yet it became central to signal processing and quantum mechanics. Euler's generating functions were initially created to count integer partitions, yet they became universal tools in combinatorics and probability theory.
+
+Mathematical thinking works the same way — you may learn it to review a paper or solve a specific problem, but its true value lies in how it transforms the way you see the world.
+
+---
+
+## 2. Life as an Optimization Problem
+
+If you treat a human being as a high-dimensional, nonlinear, dynamic optimization problem with a time-varying objective function, you will find that optimization theory and life paths share a striking philosophical resonance.
+
+### The Objective Function: What Do You Want to "Optimize"?
+
+In mathematics, the first step is to define the objective function $f(x)$. In life, this is the value you pursue: happiness, achievement, meaning, wealth, balance…
+
+The difficulty is that life goals are often **multi-objective, vague, and time-varying** — and may even conflict with one another.
+
+### Initial Point and Resource Constraints
+
+$x_0$ is your origin, talent, and starting point.
+
+Constraint conditions: time, money, health, social rules… These are like the constraints $g(x) \leq 0$ in an optimization problem, delineating the feasible region.
+
+### Step Size and Direction: Everyday Decisions
+
+**Direction**: The direction you choose to invest effort — career, relationships, fields of study.
+
+**Step size**: The intensity and time you devote to a given direction.
+
+Precision requirement: if every step only pursues immediate returns (e.g., short-term profit maximization), you may fall into a "local optimum" trap — for example, a high-paying but meaningless job, or a busy but stagnant life.
+
+### Local Optimum vs. Global Optimum
+
+This is the core dilemma of "life optimization":
+
+- **Local optimum**: The seemingly best choice within your city, industry, and social circle.
+- **Global optimum**: Perhaps in another country, another field, or another lifestyle, there exists a life that better aligns with your true nature. But you cannot foresee the global landscape, just as an optimization algorithm can only access local information at its current position.
+
+### Randomness and Noise
+
+Life is not a smooth numerical function — it is full of random noise:
+
+Luck, opportunities, unexpected events… These are equivalent to stochastic perturbations $f(x) + \epsilon$ on the objective function.
+
+Therefore, pursuing excessive precision is often uneconomical; what you need is **robustness and adaptability**.
+
+### The Exploration–Exploitation Trade-off
+
+This is the fundamental tension of life:
+
+- **Exploration**: Trying new fields, new relationships, new knowledge — risky, but potentially discovering an entirely new "basin of attraction."
+- **Exploitation**: Deepening your current domain to harvest stable returns.
+
+Explore more when young, exploit more in middle age? But the rule is not fixed.
+
+### Dynamic Objectives and Lifelong Learning
+
+Life goals change: passion at 20, meaning at 40, legacy at 60…
+
+This means the objective function $f(x)$ itself is constantly evolving. Therefore, "optimizing yourself" is more important than "optimizing a fixed target" — this is **meta-optimization** (learning how to learn, adapting how to adapt).
+
+### Algorithm Choice: Your Life Strategy
+
+| Algorithm | Life Strategy |
+|-----------|--------------|
+| Gradient Descent | Follow the most pressing direction at each step (salary, social pressure) |
+| Momentum | Maintain historical inertia (persist in long-term goals, resist short-term fluctuations) |
+| Stochastic Gradient Descent | Accept mini-batch random samples, adjust flexibly |
+| Evolutionary Algorithms | Try multiple life paths, discard ineffective strategies, retain effective patterns |
+
+No single algorithm is universally best; what matters is knowing which strategy you are using and adjusting it at the right time.
+
+### The Most Important Insight
+
+In mathematical optimization, we assume a global optimum $x^*$ exists. But in life, there may be no "absolutely optimal life" at all.
+
+We are merely "participants" in our own lives, searching for a satisfactory solution and striving to make the process full of learning, growth, and meaning.
+
+What matters is not finding the legendary "global optimum," but rather, at each iteration:
+
+- Keeping the general direction roughly correct
+- Balancing exploration and exploitation
+- Accepting noise and constraints
+- Allowing the objective function to evolve gracefully as experience grows
+
+**The process itself is the meaning; optimization is life.**
+
+---
+
+## How These Stories Connect to This Project
+
+The inspiration for this project stems precisely from these two insights:
+
+1. **The value of mathematical tools far exceeds their original intent** — Sophus Lie's dragon-slaying blade story teaches us that a tool invented for solving differential equations ultimately became the universal language for describing symmetry. This is the core idea behind "thinking weapons": every mathematical concept carries transferable value far beyond its original application domain.
+
+2. **Mathematics is a lens for understanding life** — Optimization theory is not just about algorithms; it is a framework for understanding the structure of life decisions. When you transfer the "exploration–exploitation trade-off" from reinforcement learning to career choices, or the "local optimum trap" from convex optimization to everyday decisions, mathematics steps off the blackboard and into daily life.

package/{docs → references}/inspiration.md

@@ -1,3 +1,5 @@
+> **语言路由**：若用户消息为英文，请读取并遵循同目录下的 `inspiration.en.md`。
+
 # 灵感杂谈 / Inspirational Musings
 
 > 数学不只是一种计算工具，更是一种思想方法。有时，某个数学概念与人生之间的共鸣，会让你突然意识到——那些冰冷的公式背后，藏着理解世界的温暖视角。

package/skills/abstraction/SKILL.en.md

@@ -0,0 +1,117 @@
+---
+name: abstraction
+description: |
+  Trigger when extracting mathematical structures from complex problems, discovering cross-domain commonalities, building general theories; or finding transferable abstract structures (category/algebra/topology) for algorithm/operator design.
+---
+
+# 🧩 Abstraction
+
+> "The power of mathematics lies in abstraction: ignoring contingent details to reveal necessary structures."
+>
+> — Algebra, Topology, Category Theory
+
+## Core Principle
+
+**Abstraction is not distancing from reality but penetrating into it — by stripping away superficial, contingent details, one reveals deep, essential structures. Problems from different domains often share the same abstract structure.** In the context of this skill pack, abstraction is the core operation of "cross-domain activation": transferring structures from algebraic geometry / topology to algorithm design relies on identifying the abstract structures shared by both.
+
+Three progressive levels of abstraction: **Distillation** (identifying common structure across multiple instances) → **Generalization** (extending theorems from special to general cases) → **Structurization** (reconstructing the entire problem domain in the language of structure).
+
+> **Mathematical Formalization**
+>
+> Category-theoretic perspective: Objects and morphisms form a category **C**; functors **F, G : C → D** preserve structure; natural transformations **η : F ⇒ G** relate functors; **Yoneda Lemma**: Hom(Hom(−, A), F) ≅ F(A), i.e., an object is completely determined by all morphisms pointing to it.
+>
+> Algebraic perspective: Groups (closure, associativity, identity, inverse); rings (additive group + multiplicative semigroup + distributivity); fields (ring + multiplicative inverses); modules (vector spaces over a ring); lattices (partially ordered set + meet and join).
+
+## GPU-Friendliness (Cross-Cutting Check)
+
+Whether an abstract structure can be deployed on GPU depends on the computational form it takes once "concretized" — pass the eight dimensions of `../../references/gpu-friendly-math.md`:
+
+- **Category / algebraic structure → GEMM**: If the abstract structure can be concretized as linear maps (e.g., restriction maps, group representations), it naturally maps to Tensor Core GEMM (friendly).
+- **Universal constructions (products / coproducts / limits)**: If materialized as large intermediate tensors, memory explodes (unfriendly) → refactor into chunked / streaming or low-rank approximations.
+- **Yoneda perspective**: Replace internal structure with Hom-behavior — if the Hom-sets themselves are huge, the construction is non-computable; friendly only when Hom can be batch-tensorized.
+- **Anti-pattern**: Forcing an essentially discrete/symbolic abstraction (e.g., exact computation of general cohomology) into training is often "beautiful but not computable."
+
+Eight-dimension minimum assessment (formal terminology): **Tensorization** — whether abstract objects can be concretized as batched tensors; **GEMM-Mappability** — whether morphisms / representations / restriction maps can reduce to linear maps; **Complexity** — whether the abstraction layer introduces super-linear global constructions; **Memory & KV-Cache** — whether products / limits / Hom tables are materialized; **Low-Precision Stability** — whether concretization depends on ill-conditioned inversion or exact symbolic equalities; **Parallelism & Communication** — whether the construction is locally block-decomposable; **Sparsity Structure** — whether it yields block/banded structure rather than random access; **Operator Fusion** — whether abstract interfaces can converge into a small number of fused kernels.
+
+> In conjunction with `../../references/books/algebraic-geometry-rising-sea.md`, `abstract-algebra.md`, `smooth-manifolds.md`.
+
+## When NOT to Use
+
+- **Every detail is critical** (e.g., debugging a specific bug) — abstraction would discard key information.
+- **A specific numerical answer is needed** (e.g., "what is this integral equal to") — abstraction does not provide concrete calculations.
+- **The problem is already in its simplest form** — no further abstraction is needed.
+
+## When to Use
+
+- When facing a complex problem and not knowing where to start — first abstract out the core structure.
+- When two seemingly different problems share similarities — seek a common abstract framework.
+- When generalizing specific experience into general rules, or building cross-domain general models/theories.
+- **Transferring modern math structures to algorithm/operator design** — identifying the abstract structure the problem shares with algebraic geometry / topology / Lie theory.
+
+## Method
+
+### Step 1: Describe the Concrete Problem
+Precisely describe all elements of the problem in mathematical language — objects, relations, constraints, objectives. Abstraction begins with the concrete: before abstracting, one must fully understand the concrete objects.
+
+### Step 2: Distinguish Essential from Non-Essential Features
+Examine each feature one by one: if this feature is changed, does the core structure of the problem change? **Essential features** (those whose change fundamentally alters the nature of the problem) must be retained; **non-essential features** (those whose change leaves the structure invariant) can be ignored. Example: when studying matrix invertibility, the specific entries are non-essential (invariant under similarity transformations), while rank is essential.
+
+### Step 3: Extract the Abstract Structure
+Choose the best-matching perspective from four mathematical viewpoints and execute its operations:
+
+- **Category-theoretic perspective** (focus on relations between objects): Identify "objects" and "morphisms/relations"; check that morphisms compose and have identities → forming a category; further check for functors to known categories, natural transformations relating different functors.
+- **Algebraic perspective** (focus on operations and axioms): Identify "operations" and their properties (closure / associativity / commutativity / distributivity); match axioms against group / ring / field / module / lattice; determine the best-matching structure.
+- **Topological perspective** (focus on continuity and connectedness): Identify "continuous change / proximity / connected-separated"; construct open-set structure and verify topological axioms; identify topological invariants (connectedness, compactness, fundamental group).
+- **Analytic perspective** (focus on metrics and norms): Identify "distance / size / convergence"; verify metric/norm axioms; determine properties such as completeness/boundedness, and invoke the corresponding theorems (e.g., Banach space theory).
+
+### Step 4: Solve at the Abstract Level
+Leverage existing theory of the abstract structure. Key tools:
+- **Universal constructions**: Products (unified projections), coproducts (unified embeddings), limits/colimits (merging and gluing under compatibility conditions).
+- **Yoneda Lemma insight**: An object is completely determined by all morphisms pointing to it; to understand X, examine Hom(A,X) / Hom(X,A); to prove two objects are isomorphic, it suffices to show their morphism behavior is identical.
+
+### Step 5: Concretize Back
+Precisely translate each element of the abstract solution back into the mathematical language of the original problem, ensuring every step has a correspondence. After abstraction, one must return to the concrete; otherwise abstraction loses its meaning.
+
+### Step 6: Verify
+Is key information fully preserved through the round trip? Does the answer to the original problem have a clear counterpart in the abstract solution? After translating back to the concrete, does it indeed solve the original problem? Has any essential feature been accidentally overlooked?
+
+### Step 7: Level Progression
+- **Distillation → Generalization**: When the distilled concept has been verified across multiple instances, and the theorem's natural extension appears to hold under broader conditions → generalize.
+- **Generalization → Structurization**: When generalized theorems have accumulated enough to support a self-consistent system, and different generalizations are systematically related → structurize.
+- **No premature leaps**: If distilled concepts have not been verified across enough instances, do not rashly generalize; if generalized theorems are scattered and unsystematic, do not rashly structurize.
+
+## Common Errors
+
+| Error | Critique | Correct Approach |
+|---|---|---|
+| Over-abstraction | Abstracting away essential details, distorting the problem (e.g., dropping group inverses and retaining only a semigroup) | After each abstraction, check whether key information is preserved |
+| Under-abstraction | Retaining too many non-essential details, failing to achieve simplification | Repeatedly ask: is this detail truly necessary? |
+| Abstracting to the wrong level | Using category theory for a problem that only needs group theory; or using only set theory for a problem with group structure | Choose the level matching the problem's complexity |
+| Forgetting the functorial perspective | Looking only at internal object structure while ignoring morphisms, losing half the information | Simultaneously examine Hom(A,X) and Hom(X,A) |
+| Forgetting to return to the concrete | Staying at the abstract level without translating back to the original problem | After abstraction is complete, concretization is mandatory |
+| Abstract structure is non-computable | Forcing an essentially discrete/symbolic abstraction into GPU training | After concretization, pass the GPU eight-dimension gate; if non-computable, adapt or abandon |
+
+## Operating Procedure
+
+When this skill is triggered, the output must contain:
+
+1. **[Problem Description]:[Concrete]** — Precisely describe all elements of the problem in mathematical language
+2. **[Essential / Non-Essential]:[Distinction]** — List essential and non-essential features, annotating for each whether changing it affects the core structure
+3. **[Perspective Choice]:[One of Four]** — Select the best match from category-theoretic / algebraic / topological / analytic, and execute its operational steps
+4. **[Abstract Solution]:[Construction]** — Using universal constructions or the Yoneda perspective, provide a solution direction at the abstract level
+5. **[Concretization]:[Translation]** — Precisely translate the abstract solution back into the mathematical language of the original problem
+6. **[Verification]:[Check]** — Is key information fully preserved through the round trip?
+7. **[Level Assessment]:[Progression]** — Indicate which level (distillation / generalization / structurization) is current, and assess whether a leap is warranted
+8. **[GPU Feasibility]** (if used for algorithm/operator design) — After concretizing the abstract structure, pass the eight-dimension gate, rating friendly / retrofittable / unfriendly
+
+**Output must never provide analysis alone without a conclusion.**
+
+## Relations to Other Skills
+
+- **Axiomatization**: Abstraction is the precursor to axiomatization — first abstract the essentials, then choose the axioms.
+- **Modeling**: Modeling is the concrete application of abstraction — abstracting real-world problems into mathematical ones.
+- **Transformation**: A transformation can be seen as a form of abstraction — finding simple structure in a new representation.
+- **Induction and Analogy**: Analogy is essentially identifying the shared abstract structure between two different domains.
+- **Topological Thinking**: Topological abstraction focuses on continuity and connectedness; it is the concrete form of abstraction in spatial problems.
+- **Algorithmic Thinking**: Algorithmic abstraction focuses on the structure of computational processes, abstracting concrete implementations into algorithmic patterns and complexity classes.
+- **Modern Math Activation**: `../../references/books/algebraic-geometry-rising-sea.md` (sheaves/categories → attention), `abstract-algebra.md` (groups/semirings → equivariance and routing), `smooth-manifolds.md` (manifold structure → latent-space geometry).