Communitygithub.com

TongyiDai/geometry-board-skill

蓝色波点|Blue Dot — 把复杂内容提炼成一张「一图一意」、克制、可插入飞书文档的几何视觉画板

geometry-board-skill 是什么?

geometry-board-skill is a Claude Code agent skill that 蓝色波点|Blue Dot — 把复杂内容提炼成一张「一图一意」、克制、可插入飞书文档的几何视觉画板.

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add TongyiDai/geometry-board-skill

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

Blue Dot Geometry Canvas

Goal

Transform knowledge representation into a "one image, one meaning" geometric diagram. The core visual language is points, lines, surfaces, volumes, and their relationships: first refine the single core judgment, then determine objects and relationships, choose between card/point-line/mixed expression, subsequently select a composition, generate a Scene JSON, perform deterministic structural validation with scripts/validate_scene.py, and finally generate SVG according to the visual system rules; do not let the model skip Scene JSON and validation to directly pile up pixels or SVG paths arbitrarily.

Default output: white background, black, white, gray plus an accent color, ample whitespace, stable geometric semantics, straightforward and concise text. The visual should convey the feeling of "editing a structural diagram" rather than an information card wall; prioritize content accuracy, clear focus, immediate reader comprehension, and reusable results, then pursue decoration; the canvas is responsible for the core judgment, relationships, and necessary subtitles, while the body text handles background, evidence, and details, removing any explanatory text redundant with the canvas after writing.

Standard Process After Trigger

  1. Obtain input. Prioritize reading user-provided text or currently selected text; if the user provides an existing diagram, first extract its information and relationships, then decide whether to enter a "redrawing" process.
  2. Write an internal summary: What should the reader understand at a glance? What will the reader take away?. Retain only one core judgment, and first state it clearly in everyday business language; with mixed technical backgrounds, first write the shared benefits, judgment criteria, or next action, then include necessary terms; the title should be directly repeatable by an unfamiliar reader; if the reader has to explain a metaphor before grasping the conclusion, continue rewriting; if there are genuinely two incompatible judgments, split into two images or explain the trade-off to the user.
  3. Extract information: entities, objects, actions, relationships, hierarchies, sequences, states, comparisons, key points, and auxiliary information.
  4. First, use the "Expression Method Selection" to decide between cards, point-line, or mixed; then use Point-Line-Surface-Volume and Visual Relationship Language to determine geometric semantics and primary visual variables; finally, choose a main composition based on the decision rules below. For multiple canvases, first establish a "topic → core judgment → composition family" checklist, avoiding consecutive use of the same reading direction and framework; default to generating only one optimal result, offer at most two alternatives only when the user requests them.
  5. Generate structured scene data conforming to the Scene JSON Protocol. Every node, edge, and text must have an expressive purpose.
  6. Run scripts/validate_scene.py for structural constraint checks; fix the Scene JSON first if there are errors, do not mask structural issues with post-rendering visual fixes.
  7. First execute the "Straightforward + Text Restraint Mode": delete redundant explanations, examples, long sentences, abstract noun clusters, and non-critical qualifiers; if necessary, compress a line of explanation into a subtitle, then generate SVG from the Scene JSON (structure constrained by validate_scene.py, visual presentation generated by the model according to the following rules). If the canvas will be inserted into body text, retain background, evidence, and links in the body, and remove statements redundant with the title/subtitle. Use the dimensions, colors, font sizes, line widths, margins, and disallowed rules from the Visual System; when dealing with points, lines, surfaces, volumes, rhythm, Gestalt, layers, transparency, grids, or dynamic relationships, refer to Point-Line-Surface-Volume and Visual Relationship Language.
  8. Perform visual review: check for overlaps, overflow, alignment, line crossings, text density, visual focus, number of colors, and readability when scaled down. For multiple canvases, also check that composition families, reading directions, and visual gravity centers have sufficient differences. If standards are not met, prioritize reducing information, rearranging layout, or switching compositions.
  9. Present a preview to the user, accompanied by a one-sentence description of the core judgment and chosen composition. If the user requests a file, output SVG; if compatibility is needed, additionally export a high-resolution PNG.
  10. Write to Feishu document only after user confirmation. Before writing, confirm the target document, target account/tenant, and writing method; do not mix personal and corporate identities. First build a "canvas topic → paragraph anchor" mapping according to the document structure, then insert each canvas near its corresponding paragraph; by default, do not append multiple canvases to the end of the document or concentrate them in one place. Use the currently available Feishu document/cloud drive capabilities to write and read back for verification.
  11. For natural language modifications, only change parts explicitly mentioned by the user, preserving other nodes, relationships, and style; when the user requests to retain or restore a composition, freeze the geometric skeleton and only modify text and necessary spacing; after modification, re-run validation, rendering, and review.

Core Language of Points, Lines, Surfaces, Volumes

  • Points express positions and objects; lines express movement, connection, direction, and dependency; surfaces express ranges, groups, stages, and shared attributes; volumes express hierarchies, spatial cross-sections, and system wholes.
  • Relationships are expressed through position, distance, scale, direction, line weight, alignment, repetition, containment, overlap, transparency, and whitespace; each visual variable should primarily carry only one meaning.
  • From points to volumes, prioritize generative relationships, isometric projections, cross-sections, stacking layers, and transparency; do not use realistic light and shadow to create decorative three-dimensional effects.
  • Rhythm comes from repetition and variation; balance comes from symmetry and intentional asymmetry; hierarchy comes from scale, position, line weight, and contrast.
  • Lines are not all straight by default: axes, boundaries, alignment lines, and clear stepwise relationships can use straight lines; flow, feedback, collaboration, loops, and cross-space relationships preferentially use natural arcs.
  • Multiple arcs must share a common geometric basis, such as a shared center, common control points, uniform curvature, or mirror symmetry; as the number of arcs increases, preferentially use parallel offsets or symmetrical unfolding; do not allow random bending, inconsistent directions, or floating for the sake of "design."
  • Geometry Blue #2F6BFF is the only default accent color, used sparingly and precisely, only to mark core objects, main paths, current states, risks, or changes.
  • A blue dot is an optional "state locator," not a mandatory decoration. Only use it when it clearly marks a change, feedback, decision, signal, or current focus and is connected to the main path; remove it if there is no clear semantic reason.
  • Blue dots can appear one or multiple times, but the quantity is determined by semantics, not by layout filling. Multiple dots must express the same type of state or a set of comparable events, and maintain consistent position, size, and connection rules.
  • When using a blue dot, first answer "What is happening at this point?" and "Which relationship does it change?". The dot should be placed at the geometric center, main axis, turning point, or connection endpoint; do not let it float next to text or use it to replace ordinary nodes.
  • Detailed semantics, visual variables, and design principles are in Point-Line-Surface-Volume and Visual Relationship Language.

Composition Choices

  • Clear time, process, causality, or evolution: axis-flow
  • Top-down dependencies, platform/product/organization layering: layered-architecture
  • A single center connecting multiple objects: radial-center
  • Two evaluation dimensions, classification, priority, or risk impact: matrix-2d
  • Input passes through an intermediate mechanism to produce output: input-process-output
  • Group classification, filtering, transformation, or scale convergence: dot-filter
  • Internal system hierarchy, platform capabilities, or spatial cross-section: section-space
  • Old vs. new, conflict, trade-off, competition, or goal-reality tension: tension-contrast

If unable to decide, prioritize the composition that best expresses the relationship, not the most familiar traditional flowchart. If the input lacks clear relationships, contains too scattered information, or is better suited for a table or data chart, clearly inform the user and suggest narrowing the scope or changing the expression method.

Composition Strategy for Multiple Canvases

  • Unify the visual system, actively vary the main composition. Keep title position, font, color, and line weight stable; relationship areas can switch between convergence, vertical filtering, two-column, top/bottom boundaries, dual paths, and two-dimensional matrices.
  • Use at least 3 composition families for 4 canvases; at least 4 composition families for 6 canvases. Do not let two consecutive canvases share exactly the same reading direction, visual center, and node skeleton.
  • Reserve one classic anchor diagram. If the series begins by expressing "several inputs compose a system and produce an outcome," preferentially use the classic convergence structure: left inputs → middle system/harness → right outcome. The classic composition carries recognition and tone; do not delete it for the sake of variation.
  • Composition differences must arise from information relationships. Use paths for processes, funnels for filtering, two columns for dual types, top-bottom penetration for cross-boundary actions, dual paths for presence/absence of increments, and two-dimensional matrices for dual-condition judgments.
  • Detailed series arrangement and content-composition mapping are in Visual System.

Expression Method Selection: Cards, Points-and-Lines, or Mixed

First determine whether the reader needs to see "the objects themselves" or "the relationships between objects," then decide on containers and connectors:

  • Cards: Use when objects are relatively independent, need side-by-side comparison, or require clear boundaries—e.g., plan options, role responsibilities, capability units, metric groups. Cards carry only a title and a short description; size or position can express hierarchy; they are not all equal by default.
  • Points and Lines: Use when the focus is on sequence, paths, dependencies, networks, flows, signals, changes, or a common center. Points express objects/events, lines express relationships/directions; prioritize making relationships directly visible.
  • Mixed: Use when objects themselves need to be seen as modules, yet there are also significant relationships between modules. Cards express real boundaries; points and lines express paths between modules; cards must not obscure the main relationship.
  • Judgment Method: If the relationship remains clear after removing borders, the borders are likely decorative and should be replaced with points and lines; only retain cards if removing boundaries makes independent modules hard to identify. Cards are not forbidden; card walls are the problem.
  • Visual Review: Explain why this expression method was chosen; if everything can be mechanically stuffed into identical cards, it means the relationship judgment has not been completed.

Layout & Arrangement Principles

  • Centering: The main visual center falls on the canvas's main axis or an intentionally set visual center; text uses a clear center anchor and unified baseline; geometric center, text center, and visual gravity should not conflict.
  • Alignment: Use an 8 px grid, common baseline, common axis, and uniform inner padding; alignment makes relationships readable, not to mechanically align all elements in the same column; rather than leave "almost aligned" edge misalignment, re-layout.
  • Arrangement: Organize according to the reader's reading order, defaulting left to right, top to bottom; keep only one main path per image; group related elements, separate unrelated ones; minimize line crossings. Natural arcs must have clear start and end points and cannot pass through text; multiple arcs should use symmetry, mirror, or equidistant offsets.
  • Proximity: Distance expresses relationship strength. Use 8 / 16 / 24 px for same-group elements, 40 / 64 px for related groups, and larger whitespace for independent groups; do not spread all elements evenly across the canvas.
  • Density: Dense relationship areas can be compact, but must retain clear hierarchy; sparse areas keep whitespace, not fill with extra components. Whitespace is part of the structure, not an unfinished area.
  • Visual Emphasis: Use different sizes, line weights, contrasts, or colors for primary objects, main paths, and secondary information; forbid multiple competing visual centers of equal intensity.
  • Relationship Priority: First check whether containers help the reader identify relationships; if borders are decorative or obscure the main path, delete the cards and use dots, lines, surfaces, layers, or spatial distance instead.

Detailed principles for points-lines-surfaces-volumes generative relationships, rhythm and balance, scale, Gestalt, layers, transparency, modules, grids, patterns, time, and rules are in Point-Line-Surface-Volume and Visual Relationship Language.

Hard Constraints

  • Default canvas 1200 × 675, ratio 16:9, 8 px grid; can switch to 4:3 or A4 portrait on user request.
  • Outer margins approximately 8% of canvas width, safe zone 64–96 px; whitespace not less than 40% in principle.
  • Colors only use #111111 / #666666 / #999999 / #222222 / #B8B8B8 / #E8E8E8 / #F5F5F5 / #FFFFFF plus at most one accent color; default accent is #2F6BFF (Geometry Blue); accent area not more than 8% in principle.
  • Default line widths: 0.5 / 1 / 1.5 px; axes and boundaries preferentially use straight lines; flow and feedback preferentially use natural arcs; avoid thick arrows, random curves, and meaningless lines.
  • Chinese: prioritize PingFang, Source Han Sans, HarmonyOS Sans, or system sans-serif; English/Numbers: prioritize Inter, SF Pro, Helvetica Neue, or IBM Plex Sans.
  • No more than three font-size levels; a single node label no more than 12 Chinese characters; total visible Chinese text not more than 80 characters by default, hard upper limit 120 characters.
  • Nodes not more than 15 by default; edges not more than 20 by default; no disconnected or semantically meaningless decorative nodes.
  • Forbidden: blue-purple gradients, glassmorphism, large shadows, high-saturation color schemes, colored rounded-corner card arrays, cartoon icons, realistic 3D, complex illustrations, and templated SmartArt aesthetics.
  • Forbidden: splitting content into more than three equal-sized information cards, rounded-corner card walls, tag pills, or dashboard-style module arrays; relationships should be expressed through axes, points, surfaces, layers, overlaps, auxiliary lines, and spatial distance.
  • Do not add important facts not present in the original text; mark unconfirmed relationships as hypotheses or request user confirmation.

Visual Positioning: Geometric Editing Feel, Not Information Cards

  • Treat the canvas as a structural diagram being edited: prioritize geometric bodies, main axes, auxiliary lines, alignment lines, anchor points, cross-sections, boundaries, and spatial relationships; these elements must have structural function, not decoration.
  • Set only one main visual center or one main path by default. Use the clearest outline and the single accent color for the primary object; reduce contrast, size, or line weight of other elements; do not let multiple modules compete for attention.
  • Advanced aesthetics come from proportion, alignment, whitespace, line hierarchy, and restrained contrast, not from complex textures, shadows, gradients, icons, or stacking more components.
  • If a composition can be easily rewritten as "three side-by-side cards," preferentially restructure it into an axis, hierarchy, central geometric body, overlapping relationship, or spatial layout.
  • During visual review, temporarily ignore text: even without reading the text, one should see the focus, direction, and relationships; if removing text leaves only a set of boxes, the card feel is too strong and must be rearranged.

Text Restraint Mode (Default)

  • Keep only one core judgment; the title expresses the judgment, geometric relationships express logic, the subtitle supplements one line of "why/how to use" when necessary, and the body carries background, evidence, and details.
  • Default three text layers: title, keyword nodes, necessary annotations; when a subtitle serves as local explanation, delete introductory sentences with the same meaning from the body; remove bottom notes by default.
  • Control visible Chinese text within 80 characters by default; hard upper limit 120 characters for complex structures. Sentences other than titles should not exceed 18 Chinese characters.
  • Nodes preferentially use 2–8 character keywords; move full explanations to the document body.
  • Keep at most 6–8 key nodes per image; if information is excessive, first delete examples and background, then delete secondary nodes; do not rely on shrinking font size.
  • If five layers of copy appear (title + subtitle + stage explanation + node explanation + footer), delete at least two layers.
  • When modifying existing diagrams, proceed in order: delete long sentences → compress nodes → delete redundant subtitles → delete footer → check again if relationships remain clear.

Audience & Takeaway Mode

  • When technical and non-technical readers co-view, first answer "What does this mean for me?": shared language, judgment criteria, application boundaries, or next action; terms follow benefits.
  • The canvas title carries the conclusion, the subtitle eliminates ambiguity, and nodes carry actions and results; the three form a short reading path, not repeating the same point.
  • For light-reading scenarios like kitchen-table chats, group chats, or internal referrals, the body first gives the reason to read and the takeaway, then provides the entry link; the canvas serves as a quick entry, bearing minimal necessary explanation.
  • When canvas and body text appear together, retain background, evidence, data, links, and details that need expansion; delete sentences that the reader can already deduce from the title, subtitle, and relationship diagram.

Straightforward Mode (Same Priority as Text Restraint Mode)

  • Prefer phrases colleagues would use in daily conversation, so even those unfamiliar with the original text can understand; state the conclusion first in the title; nodes should be written as "who does what / do this first / the result is this."
  • Use verbs instead of abstract nouns whenever possible; use short sentences instead of concept piles. For example, "say it clearly first" is better than "refine the judgment"; "put it back into context" is better than "determine the output."
  • Avoid generic terms like "赋能 (empower), 抓手 (grasp), 沉淀 (precipitate), 洞察 (insight), 画像 (persona), 机制 (mechanism), 链路 (linkage), 闭环 (closed loop)" by default; if they must be retained, add a more straightforward explanation or change them into specific actions and outcomes.
  • Retain English abbreviations only when strictly necessary; prioritize giving the Chinese meaning at first occurrence; do not make the reader rely on a glossary to understand the diagram.
  • For each title and node, perform a "unfamiliar colleague test": looking only at the canvas, can they say who, does what, why, or what the next step is? If not, first change the text, then consider changing the layout.
  • Perform a "3-second restatement test": looking only at the title and main relationship, the reader should be able to state the core judgment. Formulas can be written directly as formulas; categories can be stated as "divided into two types"; conditions can be stated as "only if two conditions are met"; do not let the reader guess the conclusion from abstract metaphors.
  • Nodes can use question sentences to reduce comprehension cost, e.g., "Who is this person?" "What is this world?"; result nodes should prefer "get the information" "verify the result" "complete the action" "modify the next step."
  • Straightforward does not mean overly colloquial: maintain professionalism, accuracy, and restraint; do not add judgments or emotions not present in the original text.

Handling Modification Instructions

Classify user modifications into three types:

  • Content: delete, add, rename, merge nodes; simultaneously update related nodes and edges.
  • Structure: change to three-layer, left-right comparison, timeline, closed loop, or vertical layout; only restructure the affected parts.
  • Visual: make it simpler, increase whitespace, reduce colors, highlight paths, shrink auxiliary information; preferentially adjust tokens and layout without changing semantics.

Each modification must retain unmentioned content, re-run validation and visual review, and explain what was actually changed.

If feedback points to only one canvas, update only that canvas and its source file; do not redraw the entire set. If the user says "keep the previous composition, only change the content," treat the composition as an already confirmed asset; maintain node positions, main path, and visual center; only change the copy and necessary adaptations.

Feishu Writing & Delivery

Default to delivering reviewable SVG/PNG and a one-sentence result description, then perform the insertion. If the user explicitly requests direct insertion, still generate and check the result first.

Section Positioning & Insertion Rules

  • First read the document's heading hierarchy, paragraph order, and existing canvases; for long texts, prioritize reading the outline and context of candidate sections; do not guess positions based on headings.
  • Write a one-sentence internal positioning description for each canvas: topic → corresponding chapter/paragraph → insertion anchor. The canvas expresses the relationship, process, or judgment just introduced by that paragraph.
  • By default, insert the canvas after the corresponding paragraph and before the next topic heading; if the paragraph has a subheading, prioritize inserting after the explanatory paragraph under that subheading, not at the beginning of the chapter or end of the document.
  • When multiple canvases correspond to different topics, insert them dispersed according to the order in which the topics appear in the body; when multiple images are needed for the same topic, keep them consecutive but only within that topic's subsection.
  • Preserve the original document's existing canvases and their relative positions; unless the user explicitly requests rearrangement, do not move, replace, or merge existing canvases.
  • If an exact anchor point cannot be found, select the nearest semantically complete paragraph and explain the position assumption to the user before writing; do not concentrate placements just to complete the insertion.
  • After writing, not only confirm the number of canvases, but also read back the outline and the text before and after each insertion point to check whether the "canvas topic—paragraph topic" matches.
  • If the canvas title and subtitle already serve as the local explanation for that paragraph, a compact structure of "chapter title → canvas" can be used; do not force a redundant introductory sentence to remain.

Before writing to Feishu:

  • Confirm the target document and insertion location;
  • Verify that the currently used account/tenant matches the user's target;
  • Upload/insert according to the currently available connector or Feishu Skill specifications;
  • Read back the document or resource metadata after writing to confirm successful insertion;
  • Distinguish among three states in the result: "generated," "inserted," "kept as source file only."

If Feishu image preview temporarily returns a placeholder or blank image, first check the native node count and export the remote SVG; if the remote SVG can be correctly read back and rendered, the canvas content has been written; then retry the image preview. Do not mistake preview cache delay for canvas loss.

If the Feishu side cannot retain SVG editability, insert a high-resolution PNG and keep the SVG source file simultaneously; do not mistakenly report a successful PNG insertion as an editable canvas.

Delivery Checklist

Before declaring completion, confirm:

  • The core judgment can be stated in one sentence and is consistent with the original text;
  • The canvas text is straightforward and understandable; an unfamiliar reader does not need additional terminology explanations;
  • The card, point-line, or mixed expression method matches the information relationship, and the choice reason can be explained;
  • Centering, alignment, arrangement, and proximity have been checked; relationship strength matches spatial distance;
  • The composition matches the relationship;
  • Multiple canvases meet composition diversity requirements, and a classic anchor diagram suitable for the content is retained;
  • The title and main relationship pass the "3-second restatement test"; the reader does not need to interpret a metaphor first;
  • No overlaps, text overflow, meaningless nodes, or obvious line crossings;
  • Arcs have clear relational semantics; multiple arcs have been checked for symmetry, mirroring, or equidistance; no random bending;
  • Black, white, gray plus one accent color; font sizes / line widths / corner radii are uniform;
  • Whitespace is ample; the overall relationship is still understandable when scaled to 25%;
  • Scene JSON has passed validation;
  • Multiple canvases have been dispersed to their corresponding paragraphs based on topic, not added centrally without reason;
  • File paths or Feishu document write status can be verified by the user.

Detailed composition templates, visual tokens, forbidden styles, and review weights are in references/visual-system.md; Scene JSON fields and examples are in references/scene-json-schema.md.

相关技能